На прошлой неделе провел первый семинар для бывших коллег по цеху — программистов и ИТ-консультантов. Хотел бы поделиться наблюдениями, которые сделал по ходу этого семинара.
Первое, и самое, наверное, очевидное наблюдение касается сути процесса разработки программного обеспечения (ПО). То, что я несколько раз наблюдал на семинарах по бережливой разработке продукции подтвердилось и в разработке софта: существует отдельный процесс разработки или написания нового ПО и существует отдельный процесс доработки и исправления ошибок в существующем ПО. И чаще всего это разные процессы, а значит и требования к ним должны быть разными.
Второе наблюдение связано с использованием специализированной деловой игры. У меня нет сотни готовых примеров применения методов бережливого производства в разработке ПО, но игра послужила для участников семинара хорошей опорой для переноса не всегда сразу понятных идей на свою практику. В этом смысле игра является хорошим помощником в обучении. Минус деловой игры, который я обнаружил немедленно на следующий день после ее использования, заключается в том, что она создает мнимое ощущение, что с новым методом работы все понятно и дальше можно легко и просто приступать к его реализации.
То же видео на Youtube:
Вот список вопросов (без определенного порядка), которые все-таки возникли у участников, когда я попросил их подумать над реализацией канбанов в своей компании:
- Как перейти из текущей ситуации с перегрузкой к канбанам?
- Кто устанавливает лимит на количество задач на этапе?
- Что делать с задачами (разработка), которые вернулись из тестирования?
- Как уточнять лимит?
- Как установить приоритеты?
- Кто это должен делать:
- Как переключаться между крупными и мелкими задачами?
- Как организовать управление срочными (неожиданными) задачами?
- Как установить приоритеты задачам из разных проектов?
- Как учитывать возвраты задач?
- Что делать со сроками? Что говорить клиенту?
- Нужно ли группы делить на людей?
- Стоит ли завязываться на время при установке лимитов?
- Как учитывать этапы, которые делает заказчик?
- Как учесть когда человек участвует в нескольких этапах?
- Как установить лимиты на количество задач?
- Какие должны быть ограничения при получении задач от заказчика?
- Как быть, когда задача находится одновременно на нескольких этапах?
- Как собирать статистику?
- Нужно ли перерабатывать бизнес-процессы?
- Нужно ли использовать карточки?
- Сколько должно быть этапов?
И если вы хотите попробовать переложить канбаны на вашу систему разработки ПО и вас интересуют ответы на эти вопросы — пишите, ответы на них у меня есть.
Однако самые главные вопросы оказались неназванными, а как раз они-то и имеют ключевое значение при внедрении канбанов:
Какие продукты / услуги создает ваша компания?
Каков процесс создания?
Какие действия совершаются на каждом этапе этого процесса?
Какие у этих действий есть общие и обязательные элементы?
Без ответов на эти и другие вопросы добиться работоспособности канбана в разработке программного обеспечения не выйдет. Максимум, что вы сможете достичь будет заключаться во фразе «Канбан? Да это какая-то ботва с карточками, которая нужна чтобы лучше контролировать, что программисты не пинают балду в соцсетях». В принципе, для такого результата не надо проводить обучение и отрывать коллектив от работы, а чтобы лучше контролировать программистов, над ними нужно просто поставить одного злобного финансиста, который не будет поддаваться на аргументы, на 90% состоящие из неизвестных ему слов. А вот если вы действительно хотите повысить эффективность процесса разработки (а канбаны, как ни странно, могут в этом серьезно помочь), то тогда нужно основательно поработать над множеством мелких элементов.
Поверьте, сопоставляя программерские канбаны с канбанами производства я могу абсолютно точно утверждать это: без хорошего понимания внутренних процессов, от начала и до конца, попытка внедрения канбанов провалится, а разработка софта будет похожа на производство самодельных автомобилей кустарями-самоучками.
Ну и последнее наблюдение, в бонус, так сказать. На третий день мы лишились электричества. Хорошо, что не надолго, но примерно полчаса я рассказывал страшилки про стандартизацию работы дизайнеров в полной темноте:
Как отметила Ольга Чумакина на facebook (ссылка https://www.facebook.com/olga.chumakina без VPN не работает — ВК, 28.12.2025) , я приобретаю всё больше возможностей работать в любых условиях. Два года назад я первый раз столкнулся с последствиями пожара (хорошо, что не лично тушил), а теперь вот извольте: презентация без проектора, слайдов и даже мало-мальского освещения. Мутант за моей спиной, положившей руку мне на плечо — это всего лишь моя тень. 😉 А если вы смогли разглядеть, что на доске есть надписи — то это ровно те условия, в которых находились и все участники мероприятия. «Видим, что написано, но ЧТО написано — не видим». Так что теперь я знаю, как рассказывать о бережливом производстве (и многом другом) «после апокалипсиса».
Заказать трехдневный семинар можно в лин-магазине.
Фото «Во тьме» Ольги Чумакиной.
Кому это может быть интересно
Узнать, кто эти люди…
