Lean production

Ускоряем процесс «от идеи до прибыли». Часть 2

В прошлой статье [1] мы разобрались, что такое «Бережливое производство», откуда родилась эта методика и сопутствующие ей практики (Kanban, Scrum). Поставили цели и даже начали процесс реструктуризации отделов – мысоздали продуктовые команды.

Как уже упоминалось, сегодня важно быть гибкими и бережливыми, так как технологии развиваются очень быстро. Мы не можем позволить себе писать два месяца ТЗ и потом реализовывать его в течение года без внесения изменений. Это приведет к тому, что разрабатываемый продукт будет отставать в развитии, и им никто не станет пользоваться. А конкуренты обрадуются этому, уж поверьте.

Многие уже слышали об Agile-практиках, и мы о них упоминали, так как сейчас модно внедрять гибкие методологии: «Скрам», «Канбан», «Скрамбан»… Именно модно. У меня на собеседовании часто бывают разработчики, рассказывающие, что они на предыдущем месте работы (не лично, а руководители и команда в целом) пробовали внедрить «Скрам», но у них не прижилось. Не получилось, не смогли перестроиться. А все дело в ошибках инепонимании сути. Внедряя «Скрам», команда ждет серебряную пулю. Вот теперь заживем, теперь все задачи будут делаться в срок, планирование заработает. Прочитав пару статей в Интернете и настроив «Скрам»-доску, команда думает, что перешла на новую методологию. Но эти методологии – результат концепции бережливого производства. Поэтому они не будут работать совсем или не в полной мере, если их внедрять, не разобравшись. Ида, в одной компании в разных продуктовых командах могут быть разные методики. К примеру, для продуктовой команды лучше всего подходит «Скрам», а для отдела администрирования – «Канбан», так как эта методика хороша для потоковых задач, где нужен четкий SLA (Service Level Agreement – соглашение об уровне предоставления услуг).

Собственно, сама система «Канбан» была разработана и впервые в мире реализована фирмой Toyota. Так как автомобильное производство – это в первую очередь конвейер, то «Канбан» подходит именно к конвейерной разработке, когда не нужно ничего планировать, а просто брать приходящие задачи по мере их поступления. Эта методология была разработана в рамках «Бережливого производства» и осуществляет концепцию «Точно в срок».У системных администраторов нет демо, им не нужно показывать результаты работы. Они делают повторяющиеся операции и делают их на уровне выработанного SLA.

В нашей компании, помимо системных администраторов, есть продуктовая команда «Кафе» (CF – Cross Functional). Эта команда работает по «Скрамбан», в то время как другие продуктовые команды работают по «Скрам». «Кафе»-команда делает внутренние задачи: разрабатывает инструменты для программистов и администраторов, разрабатывает интранет-ресурсы и тому подобное программное обеспечение.

История о User story

После того как вы разбились на продуктовые команды и выбрали методологию разработки «Скрам», вы должны донести до команды, что важно создавать истории: готовые фичи, страницы и т.д. То есть то, что может представлять собой ценность. Недоделанная верстка, не протестированный код и просто макет в PSD сами по себе не представляют ценности, а, наоборот, являются так называемой муда производства. Все это лежит на «складе»до тех пор, пока не выкатится на «бой» и не начнет создавать ценность для клиента. А, как следствие, приносить прибыль.

Статью целиком читайте в журнале «БИТ. Бизнес & Информационные технологии», №3 за 2015 г. на страницах 50-54.

PDF-версию данного номера можно приобрести в нашем магазине.