Канбан - тайный убийца инженеров

Вы когда-нибудь сидели на диете? Хотя две трети американцев заявляют, что сидят на диете, чтобы поправить здоровье, лишь несколько в действительности худеют. Более 90% диет не эффективны. 75% приводит к набору веса. Если бы любая деятельность демонстрировала такое количество неудач, мы бы немедленно ее прекратили.

Кроме, наверное, применения бережливого и Канбан-подходов к программной разработке. Я точно не знаю, какой у Канбан показатель успешности или какие метрики использовать для его определения, но на протяжении 2 последних месяцев я разговаривал с представителями 150 компаний-разработчиков ПО - картина ужасающая. Канбан ведет команды в пропасть.

Почти в каждой компании, внедрившей Канбан, наблюдаются сначала проблемы с управлением продуктом, а вскоре - и с разработкой. Считайте это ранним предупреждением - если вы используете методику Канбан, ваши команды, наверняка, страдают от этого и лучше бы вам о них позаботиться, пока они не нашли спасение в другом месте.

Перед тем, как продолжить разговор о Канбан, давайте проанализируем, почему мы вообще ведемся на модные диеты? Мы знаем, что они недейственны и каждый, кто хоть раз голодал, понимает, что диеты чреваты нервным срывом, поскольку лишают вас любимых радостей. Проще говоря, есть три главных причины:

• давление общественности;
• мы больше сосредоточены на своей внешности, чем на здоровье в перспективе;
• мы не контролируем себя.

Наверняка, вы ввели методику Канбан по тем же причинам. Но я вас не обвиняю, ведь вы поступили так из наилучших побуждений, чтобы удивить своих инженеров и быстрее поставлять продукт.

Если вы не знакомы с Канбан, позвольте вкратце его описать. Канбан ("карточка" или "доска") представляет собой систему планирования для бережливого производства точно в срок. Она позволяет контролировать логистическую цепочку производства. Канбан разработан Таичи Охно в компании Тойота для усовершенствования и поддержки высокого уровня производства. Позже Канбан расширили до метода эволюционного, постепенного улучшения процесса.

К сожалению, если вы внедрили Канбан и похожи на одну из крупных компаний-производителей клиентского ПО на Восточном побережье, с которыми я недавно общался, то вы больше не выпускаете ценное для рынка ПО, чтобы уложиться в ключевые сроки, теряете интеллектуальное лидерство на рынке, а ваши инженеры массово увольняются. Вы ищете лучшего пути, но не уверены, куда направляться дальше.

Если подобная ситуация кажется вам знакомой, то, скорей всего, вы уже пытаетесь найти причину и понять, что нужно, чтобы вернуть свой авторитет. Опытные менеджеры по продуктам и главные инженеры назвали мне несколько причин, по которым Канбан создает столько неприятностей.

Инженеры - не работники конвейера.

Нет надобности об этом писать, ведь это очевидно. И все же, почему мы превращаем инженеров в винтики большого механизма? Плюс, если бы инженеры осознавали, что принесет им Канбан, зачем бы они соглашались на такое?

Возможно ли, что если вы поручите талантливому и образованному человеку конкретное задание, он его выполнит, затем дадите ему еще одно, то он не поймет бизнес-факторов, стратегии развития продукта или не будет достаточно мотивирован закончить работу быстрее? Инженеры хотят создавать что-то значащее/ценное, а Канбан закапывает их в яму инкрементализма.

Вы не доверяете самому себе.

Канбан обесценивает способности компании, культуру, рыночные условия и уникальные технологии. Он учит тому, что вам и вашим инженерам нельзя доверить оценку работы или сложные, многосторонние проекты. Что еще хуже, он учит команду фокусироваться лишь на эволюционных улучшениях, вместо того, чтобы стремиться к масштабным прорывам. Не забывайте, Канбан разработали с целью постоянной оптимизации производственной системы.

Ограничения приводят к сопротивлению.

Поскольку Канбан навязывает концепцию "одна задача за раз" и отвергает идею вех, остальные участники организации остаются неудовлетворенными. Высокопродуктивные сотрудники и компании ориентируются на цель и сроки. Руководство производством продукта хочет поставлять набор свойств, чтобы удовлетворить потребности клиентов и обойти конкурентов, отделу маркетинга нужны прогнозируемый вывод продуктов на рынок, а отдел сбыта умеет продавать решения, а не функции. Учитывая "зацикленность" Канбана на усовершенствовании, остальные аспекты не принимаются во внимание.

Задумались? То, что я скажу сейчас, может вас ошарашить. Канбан никогда не

предназначался для разработки ПО. Дэвид Андерсон, сформулировавший основы философии Канбан, написал в конце 2010 года:

"Канбан не является методикой жизненного цикла разработки ПО или управления проектом! Это не способ создания ПО или курирования проектами по разработке ПО!"

Если вы дочитали статью до этого места, вы либо заинтересованы в теме Канбан или внедрили его и то, о чем здесь пишут, кажется правдоподобным. Итак, если вы ощутили на себе все "прелести" данной методики, советую перестать стремиться к бережливости. Лучше сосредоточьтесь на нескольких простых шагах для создания отличного ПО, верните уверенность в своих силах и проследите, чтобы ваша команда не потеряла мотивацию (и осталась работать в компании).

Сперва сформулируйте цель.

Поговорите с менеджером по продукту и попытайтесь разобраться в его стратегии удовлетворения клиентов и победы на рынке. Если таковой у него нет, настаивайте на ее разработке и помогите ему в этом. Проводите еженедельные совещания, ведь со временем в план - чтобы добиться успеха - придется внести корректировки. Как только базовый план готов, вместе создайте пользовательские истории и составьте четкую схему того, как команда инженеров должна достичь поставленных бизнес-целей.

Доверяйте себе и команде.

Уверен, что вы и ваша команда невероятно умные люди. Поэтому доверьте себе и своей команде оценку ресурсов, необходимых для поставки набора свойств, которые в итоге существенно повлияют на удовлетворенность клиентов, рынок и бизнес.

Будьте гибкими.

Возьмите за правило поставлять набор свойств до определенной даты и оставайтесь гибкими на протяжении всего процесса. Проявляйте гибкость и творчество на пути к достижению целей.

Прощайте.

Менеджеры по продукту, как и вы, не застрахованы от ошибок. Простите их и относитесь к себе менее строго, если вдруг накосячили. Еженедельные встречи команды разработчиков - прекрасная возможность поднять и решить сложные вопросы и найти возможные компромиссы. Трудности сплачивают команды.

Хватит лишений. Прекратите Канбан-безумие и вернитесь к своему подходу к разработке, в основе которого лежит достижение цели.

Создавать качественное программное обеспечение тяжело, но этот процесс не должен приносить страдания и дискомфорт.

источник