Нет, это не слово «mood» – настроение. И тем более мы не хотели обзывать кого-либо из твоих сотрудников, и тебя в том числе.
Муда по-японски означает «потери» — это любая деятельность, которая потребляет ресурсы, но не создает ценности для клиента. (Источник).
Мы систематизировали этот материал для тех, кто ищет, где его компания или проект теряет деньги. Хорошо, что хоть ищет 🙂
В основе этого лонгрида – книга «Дао Toyota». Джеффри К. Лайкер. Тойотовцы выделяют 7-8 видов муды – потерь на производстве. Разберемся, есть ли аналоги между потерями в автомобилестроении и проектной работе.
Муда № 1. Потери из-за лишних запасов
В проекте: Вся незавершенная или несданная работа.
- несданный дизайн;
- недоверстанный макет;
- непротестированный код;
- незапрограммированные требования;
- незадеплоенный код.
Чем больше недоделанной работы в вашей компании, тем больше у вас дебиторки. Тем больше вы рискуете прогореть.
Опять же, если посмотреть с точки зрения заказчика: недоделанная работа не приносит никакой пользы. Она ему не нужна.
Что делать: Всеми правдами и неправдами старайтесь сократить количество несданной, одновременно выполняемой работы. Лучше довести один проект до конца и затем приступить к следующему, чем взяться за 4-5 и делать их параллельно.
Муда № 2. Потери при ненужной транспортировке
В проекте: Повторное обсуждение одного и того же вопроса, по которому уже принято решение
Например, вы пришли к выводу, что не плохо бы использовать какую-то систему контроля версий. Тщательно изучили вопрос. Собрались, обсудили плюсы и минусы. Похоливарили, что лучше — 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.
Что делать: стараться время от времени ставить задачи на пределе способностей программистов. Не обязательно это делать все время, но иногда задача-вызов должна появляться у любого сотрудника.
Дополнительно от редакции:
Муда №9. «Пряничный домик» (чрезмерно верить в самомотивацию людей)
Гибкие и бережливые подходы поставили (во многом справедливо) во главу угла адекватность команды. Способность ее к самоорганизации. Способность отдельных людей — к самомотивации. Однако, возводить ее в абсолют так же нелепо, как, например, верить, что каждый человек стремится помогать ближнему. Люди — разные.
Когда только появился SCRUM, мы сразу с восторгом его приняли и внедрили – вот, мы команда, мы семья, прям братство в американском колледже, нет начальства, все равны, завтра Цукерберг нам ручки будет пожимать. Ага, сто раз.
Да простят меня мои коллеги, но в какой-то момент демократия превратилась в анархию, и пришлось переадаптировать аджайл, чтобы он работал именно в нашем проекте.
Важно понимать: некоторые люди НЕ способны к самоорганизации (это не значит, что они плохие инженеры). Кто-то нацелен использовать коллективную ответственность для личной безответственности (их лучше удалять из команды). Мир не белый (но и не черный). Люди не в один момент становятся командой а вот собутыльниками за 5 минут.
Дайте коллективу общую цель, свободу и кредит доверия, и, как минимум, в пяти случаях из десяти результат разочарует. Менеджмент предполагает ответственность внутри команды, в том числе, личную. Предполагает не только «пряник», но и «кнут» (в смысле ответственности за свою работу). Из одних пряников роль ПМ не построить.
В нашем случае мы были осликами с двумя морковками – спереди морды и сзади крупа. И в какой-то момент нас догнала морковка сзади.
Муда №10. «Взять все и поделить» (упрощать бюрократию на проекте чрезмерно)
Прямое следствие предыдущего пункта. Управлять проектами трудно потому, что решаются сложные задачи, а в команде — разные люди. И для того, и для другого десятилетиями изобретались приемы, системы мотивации, системы контроля. Некоторые из них применимы только для неквалифицированных рабочих на сталелитейных заводах, другие же актуальны по сей день.
В любом случае, существует необходимый минимум проектной бюрократии. Взять и отменить все дурацкие бумажки и диаграммы Ганта — мечта многих инженеров и, наверное, неплохой предвыборный лозунг. Однако, полная отмена бюрократии невозможна. Решения должны фиксироваться (иначе о них тупо забывают), задачи должны отслеживаться. Если вашим проектом интересуется корпоративный юрист, бухгалтер, фин. директор — с ними возникает свой документооборот.
Нужно пресекать неоправданную бюрократию, но не нужно стремиться искоренять ее на корню. Мой опыт говорит: нередко попытки отменить бюрократию совсем приводят к ее разрастанию.
Муда №11. Не работать с рисками.
Одна из самых недооцененных областей в проектном управлении – риски. Я видел ничтожное количество проектов, где менеджер и команда пытались управлять рисками. Именно эта область может сэкономить вам массу нервных клеток, и позволит менеджеру не поседеть раньше времени. Изучите риск-менеджмент (это не «rocket science», на всю теорию нужна пара вечеров) и применяйте его в своих проектах.
При написании материала использованы:
