8 сортов муды в твоей веб-студии

    Муда, что по-японски означает «потери» — это любая деятельность, которая потребляет ресурсы, но не создает ценности для клиента. (Источник).



    Эта короткая заметка для тех, кто системно ищет, где его студия теряет деньги. Похвальное занятие в наше весёлое время.

    Хорошо систематизировали виды потерь ребята из 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.

    Что делать: стараться время от времени ставить задачи на пределе способностей программистов. Не обязательно это делать все время, но иногда задача-вызов должна появляться у любого сотрудника.

    Что почитать


    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 45
    • 0
      А как объяснить, что Google Translate выдаёт какие-то другие варианты произношения, совсем не похожие на предложенное?
      translate.google.com/?hl=ru#ru/ja/%D0%BF%D0%BE%D1%82%D0%B5%D1%80%D0%B8

      (Собственно, вопрос, где ударение, если это, конечно, правда?)
      • +4
        Полагаю имелось в виду 無駄 「むだ, мудá」, переводится как «отходы» или «быть напрасным».
        • 0
          Автор привел каноническое написание на русском языке базового термина Кайдзен — не очень понял, где в статье про ударение. Гляньте первоисточники — хорошие переводы работ Масааки Имаи.

          Кстати, почему в «что почитать» их нет — они вполне достойны там присутствовать.
            • +1
              無駄 (му́да) с японского переводиться как «напрасный, бесполезный, ненужный, бесплодный». Очень распространённое в разговорном языке слово на все случаи жизни. Для «потерь» более-менее подходит слово 被害 (хига́й).
              Собственно ответ: Ударения в японских словах обычно советуют ставить на предпоследний слог (на последний в словах заканчивающихся на н), в самом языке силовое ударение отсутствует.
              • +16
                По моему оно и без перевода отлично характеризует происходящее.
                • +5
                  Здесь с вами трудно не согласиться. И такое происходит очень часто. Автор предложил вполне рациональные способы «избавления от скверны». Что-то подобное видел в западном блоге, но здесь все очень хорошо адаптировано под наши суровые будни.
                  • +2
                    Именно, что отлично, даже превосходно! Будем надеяться, что материал хоть в какой-то мере поможет исправить ситуацию. Автору — отдельная благодарность за картинки (особенно заводчанин в каске и пасаж про мрозданье). Прям настроение поднимают! А так вы расписали все правильно и не заунывно. По поводу рутины — вспомнилась вот эта статья на Хабре (ой, теперь — на МегаМозге). И вот тут полезный материал в тему.
                    • +1
                      Можно было бы проще без японского — Потери из-за мудаков. Хотя в своё время в некоторых технических учебных заведениях был предмет «Нормирование рабочего времени». Многие из перечисленных правил перекликаются с тем предметом.
                      Человеческий мозг плохо приспособлен к многозадачности.

                      Не совсем верно. Даже можно сказать совсем не верно. Мозг как раз заточен под многозадачность великолепно. Пока вы набирали пост одновременно в вашем организме мозг контролировал несчётное множестов процессов и информации обрабатывал немерянно. Вот сознание, да. Его обычно не развивают под многозадачность. Требуют [от сознания] думать одну мысль.
                      • 0
                        Если нужно обратить внимание на многое — глубоко в это не погрузишься, если нужно погрузиться глубоко — много не охватишь.

                        Это вещи друг другу противоречащие по определению — концентрироваться на одном, или распыляться на многое.
                        Ну либо придется принять, что возможности человека безграничны (то, что мы можем ими пользоваться, скажем, только на треть этого еще не означает).
                        • 0
                          На первый взгляд противоречие. А если подойти с другого бока?
                          — говорящий не знает
                          — знающий не говорит…

                          Обращали внимание, что когда стараешься удержаться на воде надо тратить на это силы (знаю-знаю, можно расслабиться и лежать), но когда пытаешься нырнуть, снова приходится силиться, хотя казалось бы, только что тонул. Наверное немного пространно объясняю? Тогда такая аналогия: Чтобы повыше подпрыгнуть, надо пониже присесть. Другими словами, когда хотите сконцетрироваться глубоко на многом, всячески упирайтесь этому. Мозг вредный малый)))
                          • 0
                            Чередовать просто нужно — то концентрироваться на каком-то деле, то отдыхать/заниматься физкультурой и ни о чем не думать.
                            Во время концентрации мозг набирает информацию, во время отдыха неспеша ее переваривает.
                            • 0
                              Скорее всего не набирает информацию, а на базе имеющейся меняет нейронные связи.
                              Ни о чём не думать сложнее всего, спросите у йогов про Шава-асану. Она относится к самым сложным, хотя ней надо просто расслабленным лежать и ничего не думать.
                              • 0
                                Информация — это и есть нейронные связи.

                                Не надо рассказывать про шавасану. Лучше, к примеру, сделайте 20 отжиманий за кратчайшее время, а потом расскажите как вам во время этого думалось.
                                • 0
                                  Еще как думается. Иногда приходится соображать и одновременно эмоции с чувствами осаживать. Иначе пропал (срыв).
                  • +5
                  • +5
                    отличная статья для нового проекта ТМ megamozg.ru/, не хотите туда перенести?
                  • +11
                    Спасибо за статью. Как ни крути Тойота на пути применения Кайдзен продвинулась дальше всех и у нее стоит многому поучится.
                    Если позволите, по памяти процитирую где то вычитанный пример про упомянутый Excel и 95%. Правда в том примере был Word и применялись привычные 80% и 20%…
                    Итак, узнав, что 80% пользователей Word пользуются только 20% функций, вы решились и выпустили свой текстовый процессор. Он быстрый, простой в использовании, ведь вы реализовали только 20% функций. Для PR своего детища, вы обратились к знакомому журналисту. Он написал в целом хвалебную статью, но вот в конце, вас просто убила фраза: «Но, я этим редактором пользоваться не буду. Ведь в нем нет подсчета знаков в документе.».
                    К чему это я? Да к тому, что эти 20% для разных пользователей свои. Журналистам важен подсчет знаков, для студентов и научных сотрудников важна возможность автоматически перенумеровывать рисунки и т.д.
                  • +2
                    Похоливарили, что лучше — GIT или SVN. Реально полностью разобрались в вопросе.

                    Никогда не поздно признать свои ошибки и исправить их вместо того, чтобы отнекиваться тем, что все давно переговорено. Реально, такие мелочи способны медленно, но верно точить мотивацию членов команды. А мотивация — это наше все.
                    Кстати, в этом случае это подточит лучших людей, т.к. только ламеры развивающиеся разработчики могли остановиться на svn.
                    • +6
                      Суть не в том, чтобы остаться на svn, а в том, что все доводы и контрдоводы должны быть записаны, чтобы не мусолить всё заново.
                      Если аргумент устарел, это повод пересмотреть решение.
                      • +1
                        Кстати у меня знакомый, который работает в команде google chrome как-то рассказывал что мол весь сырец Хрома хранится в svn. Но никто в здравом уме конечно svm локально не использует, все отправляют на сервер через git-svn bridge. Как-то вот так сложилось видимо, а теперь менять все это долго и дорого.
                        • +1
                          Ну что ж, я долгое время работал в группе, которая хранила исходники в MS Source Safe. Это действительно отстойное хранилище по сравнению с тем что есть сейчас, технология отжила свое еще в прошлом веке. Тем не менее группа не испытывала никаких проблем с хранением исходников, все давно привыкли и умели. Никто не отвлекался на проблемы хранения годами.
                          Однако все остальные группы, как более молодые, к тому времени переехали на svn. И под давлением руководства последний SourceSafe решено было перевезти. Ну что ж, перевели, один день всем все настраивали и бережно переносили 10-летнюю историю. Еще неделю объясняли программистам что SVN это правда лучше (и это правда) и что скоро они почувствуют весь кайф. Еще где-то пару месяцев программисты регулярно поднимали вопросы как сделать что-то, что они могли на SorceSafe.
                          Да, через какое-то время все привыкли к SVN и перестали его замечать.
                          Но что группа или компания выиграла? Только теоретические вещи — теоретически лучше, теоретически надежнее, теоретически круче. Практически же было потеряно огромное количество человеко-часов на переезд. Зачем?

                          Я не призываю сидить на допотопных инструментах. Но каждое решение о смене базовых технологий процесса должно четко отвечать на вопрос «зачем». Ответ должен быть измерен, желательно, в деньгах.
                          • 0
                            Прежде всего, экономия при наборе новых людей в команду.
                            Если приходит новый человек, его не нужно учить SVN, а Source Safe — нужно.
                            • 0
                              Да, возможно. Но в конкретном примере текучка была меньше человека в год.
                            • 0
                              И ещё стоимость поддержки 2-х систем контроль версий против одной не посчитали (если это делается централизованно админами).
                          • 0
                            Какой хитрый заголовок. Тема лично мне не интересна, но пришлось открыть статью чтобы узнать что такое муды.
                            • +2
                              Брайан Трейси в своё время писал, что каждый человек в цепочке увеличивает время её прохождения информацией в 2 раза. Актуально для 4 и 6 пунктов, имхо
                              • 0
                                Всё очень правильно. (Кроме фразы про Excel.)
                                • +1
                                  Кстати да, эта строчка смутила. Это как швейцарский нож привести в пример «переизбытка бесполезных фич». Excel выделился если бы хоть кто-то из основных аналогов был менее напичкан. Google Docs, Polaris Office, iWork, Feng Office, OpenOffice, LibreOffice, Kngston Office… короче вы поняли.
                                  • +1
                                    В общем-то, несмотря на «напичканность» конкурентов, тем не менее, офисный пакет от MS, в том числе Excel — это до сих пор во всех отношениях самое лучшее решение (если только не требуется бесплатность).
                                  • 0
                                    Согласен, функционал хороший и профессионалы наверно в восторге, но если 90% людей пользуются минимумо функций — жди что какой-то онлайновый сервис вроде Google Docs отберет у тебя 90% рынка.

                                    Лично я пользуюсь уже им очень давно.Потом родителей подсадил и весь офис. То есть в моем окружении не осталось людей с экселем. А все потому, что не уследили за тем что нужно 90% людей.

                                    Личный пример конечно не показатель, но звоночек майкрософту.
                                    • 0
                                      Просто вы путаете рынки. Excel — это офисное приложение, оно доминирует на рынке офисных приложений.
                                      Тот факт, что массовому потребителю теперь тоже надо немного иногда посчитать-учесть, привёл к тому, что образовался другой рынок, который полностью заполнился простыми решениями, и в частности облачными.
                                      Я и сам в обычной жизни пользуюсь google docs, но уверяю вас, когда надо сделать действительно сложный документ — большой отчёт, много сложной статистики и проч., то лучше чем продукт от MS вам не найти.
                                  • +1
                                    Только с MS Word плохой пример. Большой функционал это часть стратегии.
                                    Посмотрите график: lib.rus.ec/i/27/351127/img_1.jpeg
                                    Первые в жизненном цикле идут новаторы и ранние последователи. А их 10 функциями не возьмёшь.
                                    Я про Photoshop могу тоже самое. Там такой же процент использования.
                                    • +1
                                      Похоливарили, что лучше — GIT или SVN. Реально полностью разобрались в вопросе. И как стандарт у себя решили принять svn.
                                      Не бывает. Если бы полностью разобрались — решили бы принять Git.
                                      • 0
                                        Тогда уж Mercurial, для полностью «разобравшихся».

                                        Поскольку Mercurial — это Git минус проблемы с сабмодулями и минус возможность «сделать что-то не то и сломать репозиторий».
                                        • 0
                                          Уже не помню, когда в последний раз у меня Git ломал репозиторий.
                                          Больше того, Git периодически выручал, казалось бы в безвыходной ситуации.
                                          Проблем с сабмодулями не наблюдаю тоже никаких. Возможно использую их не на «всю катушку»?
                                          Даже не представляю, что можно сделать, чтобы получилось лучше, удобнее и быстрее, чем Git.
                                          Про Mercurial слышу много хорошего, но вот чем конкретно он лучше того же мейнстримного Git, пока никто так и не объяснил.

                                      • 0
                                        Многие пункты завязаны на инструкции сотрудникам, грамотно выстроенный бизнес-процесс и хороших управленцев.
                                        Если в студии высокая текучка кадров, например, то передачи проектов неизбежны. А с ними — потеря продуктивности.
                                        По сути большинство «муд» о том, что нужно ценить людей, давать им интересные задачи и создавать комфортную рабочую среду (и речь не о настольном футболе и гамаках, а об отсутствии бесполезных брейнштормингов).
                                        • +1
                                          Сколько промежуточных звеньев между тем, как идея клиента попадёт из его головы к тому человеку, который будет конкретно ее делать?
                                          Частенько встречается ситуация, когда в небольшой компании поначалу клиент общается почти напрямую с программерами, естественно нервирует их, но задачи решаются достаточно быстро и точно.
                                          Контора подрастает, решает что нужно выделить роль РП — переговорщика с клиентом. Отлично, ввели передаточное звено. РП сразу же заваливается кучей работы, совещаний, ведь теперь чтобы передать информацию от заказчика исполнителю нужно вдвое больше времени: поговорить сначала с заказчиком, потом столько же времени с исполнителем. И это не считая затрат на потерю информации и переключения.
                                          Дальше, руководство видит что РП зашивается, не справляется общаться со всеми заказчиками и всеми исполнителями, и вводит ему подмогу со стороны программистов — техлида, например. Или руководителя группы/отдела. Но как бы не так, этот парень встает ровно в ту же лужу. Дальше вводят аккаунт-менеджера, аналитиков, пресейлов, цепочка удлиняется, пока на выходе не даст белый шум.
                                          И самое печальное, при поверхностном взгляде руководства кажется что эти ребята просто жизненно необходимы для процесса — т.к. они сильнее всех завалены работой. Но по сути эта работа — передача данных с потерями. И эту бесполезную работу делают довольно дорогие сотрудники.
                                          • +1
                                            За все надо платить, главное, чтобы затраты окупались. Когда заказчик контактирует напрямую с программистами, то мы получаем отвлечение программистов от их основных обязанностей. Введение РП позволяет команде итерацию писать код, тестировать его, документировать и т.д. А новые требования обсуждать с привлечением заказчика (или без) только раз в две недели. Что результативность команды, обычно, повышает. С другой стороны, как вы правильно заметили, снижение скорости прохождения информации и потери. Поэтому нельзя бросаться из крайности в крайность. Заказчик -> программисты — крайность, заказчик -> 100500 промежуточных звеньев -> программисты — тоже крайность.
                                            • 0
                                              Это затраты на функционирование самой системы с ее ростом. И это неизбежно (есть очень интересная тема — жизненный цикл организации).
                                              Однако никто не мешает оптимизировать процесс. Если бюрократия минимальна, а РП фильтрует пожелания клиентов и подает входные данные в обработанном и подготовленном для разработчиков формате, то от этого одни только плюсы.
                                              То, что где-то не так говорит только о том, что система организована неправильно.
                                            • 0
                                              у Хаббарда эта штука называется Девти. От слов development traffic. Суть в том что ростет трафик, а результат нет.
                                              Но идеи абсолютно идентичны. Называются иначе. Но он также исследовал этот предмет и искал пути его снижения на разных предприятиях и отраслях. Есть работы на эту тему.
                                              Мы также в свое веб студии применяли эти решения и снижаем девти (муды).
                                              Муды — как слово мне нравится больше. Перехожу на него :)

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.