Канбан. Альтернативный путь в Agile

Тем временем сотрудники смирились с безумной загрузкой, и непомерные объемы работы стали нормой. Кажется, никто не задумывался над тем, что у инженеров-программистов тоже может быть общественная или семейная жизнь. Звучит грубо, но это правда! Я знаю слишком много примеров, когда излишняя производственная нагрузка навсегда разрушила семейные отношения. Трудно сочувствовать типичному гику-разработчику. В моем родном штате Вашингтон доход инженера-программиста уступает только заработку стоматолога. Как и во времена Форда, то есть в 1920-е годы, когда люди на его заводах зарабатывали в пять раз больше, чем в среднем по стране, никому и в голову не приходит подумать о монотонности работы или о благополучии специалистов: им столько платят! Трудно представить себе наличие профсоюзов в таких интеллектуальных отраслях, как разработка ПО, потому что никто не станет всерьез изучать причины физических и психологических недугов, которые испытывают разработчики. Более ответственные работодатели предлагают, например, такие меры, как массаж или психотерапия. Или проводят дни психического здоровья – и это вместо того, чтобы уделить внимание изучению основных причин проблемы. Технический писатель, сотрудник известной фирмы – разработчика ПО, однажды сказал мне: «Нет ничего страшного в том, что я употребляю антидепрессанты, ведь так поступают все!» Программисты обычно соглашаются со всеми требованиями, получают неплохую зарплату и страдают от последствий. Я хотел изменить такое положение дел, найти взаимовыгодный подход, который позволял бы мне говорить «да» и при этом все же защищать свою команду, обеспечивая достижение оптимального темпа. Я хотел вернуть членов своей команды в общество и семью и улучшить условия, которые вызывали у разработчиков, не достигших и тридцати лет, стресс и проблемы со здоровьем. Поэтому я решил начать бороться с этими проблемами.

В поисках успешного управления изменениями

Вторая проблема, которая занимала мои мысли, – это управление изменениями в крупных организациях. Я был менеджером по разработке в Sprint PCS и затем в Motorola. В обеих компаниях существовала серьезная потребность в переходе на более гибкие методы работы. Но в обоих случаях у меня возникали трудности при внедрении agile-методов более чем в одной-двух командах.

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

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

Я попытался осветить эту проблему в книге Agile Management for Software Engineering, которую писал в то время. Я задавался вопросом: «Почему гибкая разработка дает лучшие экономические результаты, чем традиционные подходы?» Я хотел применить с этой целью структуру теории ограничений{4}.

В процессе исследований и написания упомянутой книги я понял, что уникальна каждая ситуация. Да и разве может сдерживающий фактор или узкое место оказаться одинаковым для любой команды и проекта в любое время? Каждая команда уникальна: иные навыки, возможности, опыт. Каждый проект отличается от других бюджетом, расписанием, объемом и рисками. Непохожи друг на друга и организации: у них разные цепочки создания ценности, они работают на различных рынках (рис. 1.1). Мне показалось, что это может дать ключ к пониманию сопротивления изменениям. Если предлагаемые перемены в методах работы и моделях поведения не дают, по мнению сотрудника, очевидного преимущества, то он не примет их. Если эти изменения не влияют на то, что воспринимается командой как ограничитель или сдерживающий фактор, то команда будет сопротивляться. Иными словами, перемены, предложенные без учета контекста, будут отвергнуты сотрудниками, которые прекрасно знают контекст работы.

Рис. 1.1. Почему универсальные методологии разработки неверны