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