8 сортов муды в твоей студии
Эта короткая заметка для тех, кто системно ищет, где его студия теряет деньги. Похвальное занятие в наше весёлое время.
20.01.2015 | Автор: Владимир Завертайлов, Сибирикс (Генеральный директор)
Хорошо систематизировали виды потерь ребята из 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.
Что делать: стараться время от времени ставить задачи на пределе способностей программистов. Не обязательно это делать все время, но иногда задача-вызов должна появляться у любого сотрудника.
Что почитать
Полный текст статьи читайте на CMS Magazine
