Содержание
Муда, что по-японски означает «потери» — это любая деятельность, которая потребляет ресурсы, но не создает ценности для клиента. (Источник).
Эта короткая заметка для тех, кто системно ищет, где его студия теряет деньги. Похвальное занятие в наше весёлое время.
Хорошо систематизировали виды потерь ребята из Toyota. Тойотовцы выделяют 7-8 видов муды, потерь на производстве. Посмотрим, есть ли аналоги между потерями в автомобилестроении и работе студии.
Муда № 1. Потери из-за лишних запасов
В студии: Вся незавершенная или несданная работа.
- Несданный дизайн.
- Недоверстанный макет.
- Непротестированный код.
- Незапрограммированные требования.
- Незадеплоенный код.
Чем больше недоделанной работы в вашей компании, тем больше у вас дебиторки. Тем больше вы рискуете прогореть.
Опять же, если посмотреть с точки зрения заказчика: недоделанная работа не приносит никакой пользы. Она ему не нужна.
Что делать: Всеми правдами и неправдами старайтесь сократить количество несданной, одновременно выполняемой работы. Лучше довести один проект до конца и затем приступить к следующему, чем взяться за 4-5 и делать их параллельно.
Муда № 2. Потери при ненужной транспортировке
В студии: Повторное обсуждение одного и того же вопроса, по которому уже принято решение (Relearning).
Например, вы пришли к выводу, что не плохо бы использовать в студии какую-то систему контроля версий. Тщательно изучили вопрос. Собрались, обсудили плюсы и минусы. Похоливарили, что лучше — GIT или SVN. Реально полностью разобрались в вопросе. И как стандарт у себя решили принять svn. Внедрили как стандарт. Обучились. Начали использовать.
И вот через полгода какой-то умник говорит: «Ребята! А почему мы используем SVN, а не GIT? SVN же говно, потому, что <аргумент>, а GIT — это круто потому, что <еще какой-то аргумент>». На самом деле через полгода никто уже не помнит, то ли эти аргументы уже рассматривались (и вы вместе пришли к выводу об их недостаточности), то ли эти аргументы вы пропустили при обсуждении. Приходится изучать вопрос повторно. Тратить время, вместо того, чтобы делать деньги.
Что делать: Фиксировать не только решения, но и контекст и аргументацию по принятым решениям. Здесь хорошо работают диаграммы (Root Cause-анализ, Mind Map, A3-анализ). Найти баланс между пересмотром своих процессов/средств разработки и соблюдением принятых стандартов.
Муда № 3. Потери из-за перепроизводства
В студии: Ненужная функциональность.
Так прикольно бывает запилить для клиента пару фишечек, пасхалочек или полировать фотографии на какой-то странице 5-го уровня, на которую никто никогда не зайдет или оптимизировать страницу «Наше руководство» для скорости загрузки в 0.005 сек.
Общая идея: делать функции, которыми никто не будет пользоваться (и на которых ваш клиент не заработает) — это потери. Пример-лидер — это MS Excel: 95% пользователей постоянно используют только 5% функций. Нафига всё остальное?
Что делать: критически оценивайте то, что вы делаете с точки зрения пользы. Отмечайте и устраняйте работы, которые не приносят пользу вашим клиентам и вам самим.
Муда № 4. Потери времени из-за ожидания
В студии: Затягивание согласований.
- Ожидание согласования с заказчиком;
- Внутренние согласования;
- Бесполезные совещания, обсуждения и личные встречи;
Очень такая актуальная потеря — ожидания. Пока заказчик согласует макет на 3-х уровнях. Пока утвердит тексты. Пока юрист соизволит прислать правочки к договорчику.
Особенно много ресурсов улетает на личные встречи по пустяковым вопросам. Часто, для того чтобы прикрыть жопу и не принимать решений — на совещания по любому вопросу приглашается как можно больше людей. Перемещения тел по Москве на встречи для обсуждения «какого размера у нас будут буквы» — чрезвычайно дорогое удовольствие, но мало кто реально считает, сколько стоит собрать и провести одну такую встречу (подсказка: обычно несколько десятков тысяч рублей). Договоренности не фиксируются, обсуждения улетают в пустоту.
Что делать: сократить количество вовлеченных в проект людей до минимума. Принимать решения максимально оперативно. Сократить количество совещаний и личных встреч. Если уж и проводить собрание — иметь четкий регламент, фиксировать и четко соблюдать договорённости.
Муда № 5. Потери из-за выпуска дефектной продукции
В студии: Баги.
Что важно знать про баги: чем позже дефект найден, тем он дороже. Если вы, допустим, программист, и находите и фиксите баг сами и сразу — это стоит дешево. А вот если его находит клиент — то это уже чревато. Особенно, когда баг найден через два года, уничтожил базу данных клиента, а программист, который писал код — в отпуске, в другом городе и умер.
Что делать: как можно более раннее тестирование. На крупных проектах —автоматические тесты. Четкие стандарты кодирования. Регулярные практики code review. Наставники для новичков.
Муда № 6. Потери из-за ненужных перемещений
В студии: Потери передачи проекта.
Потеря передачи:
- Ответственности.
- Знаний.
- Проектов.
- Действий.
- Заявок.
Сколько промежуточных звеньев между тем, как идея клиента попадёт из его головы к тому человеку, который будет конкретно ее делать? Вполне возможно, что клиент сначала рассказывает свою историю аккаунт-менеджеру, затем — менеджеру проектов, затем менеджер проектов рассказывает все вводные аналитику, затем аналитику передают дизайнеру.
Каждый раз при передаче проекта происходит потеря времени и информации: вербальной и невербальной. Потеря информации в итоге приводи к ошибкам, переделкам и опять же — затратам времени. Особенно чувствительны потери при передаче проектов с одного менеджера проектов на другого, либо при смене программиста в проекте. И самый сложный случай — смена ответственного лица на стороне клиента.
Важная тонкость: когда проект изучается и анализируется в первый раз — это имеет ценность для клиента. Потерями будет только повторное размусоливание одних и тех же сведений.
Что делать: минимизировать количество вовлечённых в проект людей до необходимого минимума. Исключить передачу проектов между командами и ответственными лицами.
Муда № 7. Потери из-за лишних этапов обработки
В студии: переключение разработчиков между большим количеством разных задач
Человеческий мозг плохо приспособлен к многозадачности. Пока мы переключаемся с проекта на проект — мы теряем контекст задачи. На восстановление контекста нужно от 15 минут до получаса. Это чистые потери.
Считайте, если вы дернули человека — это вы слили 15 минут. Помножьте на ваш рейт, вычтите у себя из зарплаты. Если будет жадно — не дергайте. Если не жалко и вопрос того стоит — можно дернуть.
Кстати, если ваш программист способен переключать контекст быстро — это значит, что в нем сильны задатки менеджера.
Что делать: не дергайте людей
Муда № 8. Нереализованный творческий потенциал сотрудников
В студии: Долбаная рутина.
Всегда есть выбор: поставить на проект того человека, который сделал 100500 аналогичных проектов, или поставить того, кто еще не разобрался с такой темой. Нагружая разработчиков рутиной и не давая им действовать самостоятельно, вы увеличиваете нагрузку на вашего HR-а. За вами выбор — вложить ресурсы в обучение или вложить в HR.
Что делать: стараться время от времени ставить задачи на пределе способностей программистов. Не обязательно это делать все время, но иногда задача-вызов должна появляться у любого сотрудника.
Что почитать
