F-Secure разрабатывает в Финляндии антивирусные программы и программное обеспечение в сфере безопасности для международного рынка. Партнер компании предложил ей войти в специфический сегмент рынка антивирусного обеспечения, где она раньше не участвовала, – предстояло разработать дополнительный функционал для партнерской компании, которая затем бы продавалась под ее брендом.
F-Secure использовала эмпирический подход к разработке программного обеспечения в течение трех лет. В компании знали, сколько в среднем полезного функционала ее команды разработки могут создать в течение одной итерации. Основываясь на этом знании, она согласовала с партнерской компанией план разработки: создать частичный релиз программного обеспечения к запланированной пресс-конференции, а вскоре после этого выпустить на рынок первый релиз. К несчастью, команды F-Secure, назначенные для разработки этого продукта, создали в течение первых трех итераций меньше функциональных возможностей, чем планировалось, – 25 % необходимого для пресс-конференции. Уже было ясно, что продукт не будет готов вовремя.
Партнер и руководство F-Secure обсудили замедление прогресса в разработке и приостановили все процессы. Деньги были потрачены, но ничего полезного не было создано. Партнер, узнав, что не получит продукт в срок, остановил все приготовления к пресс-конференции, свернул маркетинговую активность и тем самым спас себя от потери репутации на рынке. Ценным опытом, полученным в результате этого проекта, было ограничение потерь.
Многие люди испытывают трудности с эмпирическим процессом. Может так случиться, что команда не разработает столько функциональных возможностей, сколько планировалось. Тому, кто вкладывает деньги, труднее всех: он точно знает, что хочет получить после каждой итерации, и, если команда не оправдывает ожиданий, заказчика ждет разочарование. Демонстрируя его, он, по сути, разрушает эффективность и дух команды.
Эмпиризм – искусство сделать лучшее, что ты можешь, с тем, что у тебя есть. Эмпиризм открывает все виды возможностей. Однако если вы думаете, что можете решить, чего вы хотите, и давить, чтобы это получить, к сожалению, это закрывает перед вами другие возможности. Вы больше не имеете дела с реальностью, а стараетесь сделать реальностью то, что хотите, приказываете. Такой подход может быть приемлем в простой ситуации, но, когда проблема сложная, он лишь деморализует и разочаровывает.
Самая важная задача менеджера – помочь людям делать их работу. Дайте им цель и позвольте им ее достичь. Уберите с их пути все препятствия. Делайте все возможное, чтобы они стали более эффективными и продуктивными. Только в этом случае организация может превратить плоды их работы в капитал.
Требовать прозрачности и создать соответствующую обстановку для ее процветания
Чтобы принять обоснованное решение, у вас должно быть твердое понимание реальных фактов. В эмпирическом процессе разработки программного обеспечения инкремент – ясная и прозрачная информация, на которой основано принятие решений.
Люди должны чувствовать себя в безопасности, обсуждая критические вопросы, открыто выражать то, что они думают и чувствуют, и взаимодействовать с другими без препятствий и вреда. Все это – основа эмпирического процесса. Множество рабочих пространств небезопасны. Политические программы и скрытые мотивы искажают прозрачность. Основная задача менеджера – создать защищенное место, где люди уважают друг друга и чувствуют себя в безопасности.
Прозрачность нейтральна в том смысле, что это не хорошо и не плохо. Она просто должна быть. Обсуждение необходимо при принятии трудных решений. Если решения принимаются в угоду руководству, если разработчики искажают реальность, чтобы нравиться начальству, эмпирический процесс развалится на части.
Компания Kronos из Бостона – девелопер софта для планирования ресурсов организации и учета рабочего времени. Компания предприняла попытку использовать эмпирический метод, чтобы ускорить свои процессы разработки. В 2008 году правление компании было недовольно прогрессом в разработке нового релиза. Команде девелоперов дали это понять и попросили работать усердней. Те, пытаясь соответствовать требованиям руководства, стали создавать функционал быстрее, чем обычно, но с гораздо более низким качеством.
В конце каждой итерации руководство поощряло разработчиков за их тяжелый труд. Однако инкремент не был прозрачным. Руководство думало, что инкремент полностью закончен и стабилен, а он между тем был только частично законченным и практически полностью нерабочим. Когда Kronos приблизилась к дате релиза, недостатки были обнаружены, и дата выхода сдвинулась на шесть месяцев.
Рассчитывать, что ваши люди могут сделать больше
Разработчики лучше всех ориентируются в процессе и знают, как лучше. Эта мысль идет вразрез с большинством управленческих курсов. Менеджер должен ставить перед собой цели, выяснять, как их добиваться, а потом заставлять остальных следовать его плану. Однако в таком случае вся работа зависит от опыта, интеллекта и организаторских способностей конкретного менеджера.
Если люди, делающие свою работу, свободны решать, что им делать, они могут адаптироваться к обстоятельствам и реальности, с которой сталкиваются. Они могут поделиться идеями и опытом, чтобы прийти к лучшему решению. Когда они пробуют какой-то подход и он не работает, то они могут предложить что-то другое. Это называется самоорганизацией и повышает общий уровень знаний всех членов команды. Они не ограничены мышлением менеджера и свободны сделать свою работу лучшим способом.
Роль менеджера при таком подходе – только устанавливать цели, содействовать и устранять препятствия. Он наделяет членов команды правом принимать решения.
Помогите людям ослабить их желание определенности
Мир изменчив. Разработка программного обеспечения тоже изменчива. Но решения по-прежнему нужно принимать, и организация, которая принимает лучшие решения, процветает. Программное обеспечение за 30 дней дает вам надежную, полезную информацию о том, что будет происходить по крайней мере каждые 30 дней. Итерация – ограниченная по времени авантюра. Команда способна практически без сбоев создать программное обеспечение, представляющее определенную ценность. Даже в худшем случае, когда команда не создает ничего, это дает ценную информацию о том, что пока это невозможно.
Расположенная в Филадельфии компания Primavera, которой сейчас владеет Oracle, создает программное обеспечение для управления проектами, основанными на предиктивном процессе. Учредители понимали иронию: использовать эмпирический процесс разработки программного обеспечения для создания своих предиктивных (прогнозируемых) инструментов. Тем не менее, чтобы решить свои проблемы, они должны были к нему прибегнуть.
В конце самой первой итерации команда разработки и высшее руководство собрались посмотреть демонстрацию инкремента. Функционал работал прекрасно. Однако СТО указал на то, что команда планировала создать семь функций, а реализовала только пять. СТО почувствовал себя некомфортно. Он попросил команду собрать статистику – как много времени занимает та или иная работа. Он подумал: если собранная статистика будет объединена в базу данных, команда станет более тщательно выполнять задачи. Они могли бы оценивать размер предстоящей работы по статистике из базы данных в начале новой итерации. Тогда они могли бы знать заранее, что сделают только пять функций.
