105,7
рейтинг
21 января 2015 в 15:11

Разработка → 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.

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

Что почитать


Владимир Завертайлов @zevvssibirix
карма
125,0
рейтинг 105,7
Главный бармалей
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (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
      Автор привел каноническое написание на русском языке базового термина Кайдзен — не очень понял, где в статье про ударение. Гляньте первоисточники — хорошие переводы работ Масааки Имаи.

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

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

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

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

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

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