Питер Симс - Мелкие ставки. Великую идею нельзя выдумать, но можно открыть

Интересно, что основатели метода гибкой разработки изначально позаимствовали ее основной элемент из японского сборника статей о промышленности. Джеф Сазерленд, создатель Scrum-метода [23], рассказывает, что они взяли его название из статьи, напечатанной в журнале Harvard Business Review за 1986 год. Ее авторы Хиротака Такеучи и Икуджиро Нонака описывали лучшие методики, применяемые для разработки новых продуктов в таких компаниях, как Honda, Canon и Fuji. Как вспоминает Сазерленд, «мы посмотрели, каким образом они формировали свою команду, и собрали группу разработчиков таким же образом».

Такеучи и Нонака сравнили способ формирования команды в японских компаниях с тем, как ведут себя регбисты во время матча, перемещаясь по полю во время схватки за мяч и пасуя его вперед и назад нужному игроку в каждом отдельном промежутке игры. Во время игры в регби игроки должны творчески подходить к атаке в соответствии с конкретной ситуацией на поле. Очень похоже работали и команды исполнителей в японских компаниях – они были многофункциональны, самостоятельными в своих действиях и не сильно зависели от решений топ-менеджеров, самоорганизовывались и учились по мере продвижения к достижению цели. Вместо того чтобы скрупулезно планировать весь процесс создания новых продуктов и распределять полный объем работ между исполнителями, как это делали в компаниях вроде General Motors, новые венчурные команды сотрудников в компании Honda объединяли дизайнеров, инженеров, менеджеров по продажам и производству. Эти команды не расформировывались до полного завершения разработки. Их цель состояла в том, чтобы добиться максимальной скорости и гибкости, в то время как руководство оговаривало условия или осуществляло то, что сами авторы называли мягким контролем, вроде введения контрольных этапов. Такеучи и Нонака сравнили такой процесс с использованием игроков в регби с определенными достоинствами в каждом новом промежутке игры.

Но традиционно для разработки программного обеспечения способы решения задач планировались заранее, были продуманы и детализированы еще до начала работы над проектом. Это часто называют методом водопада. Так, если компания Microsoft собирается заняться разработкой новой версии Windows методом водопада, стоящие перед ней задачи совмещаются с требованиями к дизайну и формулируются заранее. Вместо того чтобы использовать небольшие команды разработчиков, перед которыми ставятся задачи и определяются методы их решения, руководство «водопадными» процессами осуществляется сверху вниз, когда старшие сотрудники распределяют и контролируют весь процесс. Этот процесс и называется водопадом, потому что начинается с определенных требований к программе, далее «стекает» непосредственно к ее проектированию, а затем уже разработчики начинают заниматься внедрением, тестированием и инсталляцией. Список требований часто представляет собой документ в сотню страниц, а задания перечисляются в последовательности, от одной фазе к другой в виде диаграмм Ганта [24], где конкретные задания и время на их исполнение отображаются в виде столбиков.

Стандартный метод водопада во многом обязан своему возникновению Министерству обороны США. В 1980-е годы это ведомство финансировало до 60 процентов всех проектов по разработке программного обеспечения и требовало от своих подрядчиков соблюдения этого метода. Принимая во внимание влиятельность Министерства обороны, остальные разработчики программного обеспечения в стране приняли метод на вооружение.

У метода водопада есть свои достоинства, в том числе визуальная наглядность и высокая степень контроля над процессом (это ясно видно на диаграммах Ганта), но есть и несколько крупных недостатков. В первую очередь это стремление руководства учесть все возможные функции программы, которые с его точки зрения могут быть востребованы пользователями. Известно выражение Стива Джобса: «Люди не могут знать, что им нужно, пока они это не увидят». Неудивительно, что многие функции программ, созданных при разработке методом водопада, никогда не используются. Другой недостаток метода в том, что ко времени, когда компания Microsoft или подобная ей заканчивает проект, длившийся один или два года, мир уже успевает поменяться. Новые проблемы возникают постоянно. Приоритет управления сверху вниз при использовании метода водопада, когда мелкие изменения требований к продукту или к его дизайну не отражаются на ходе работы над ним в течение месяцев или даже лет, стал еще большей проблемой из-за развития Интернета и ускоряющегося технического прогресса. Все это способствовало росту популярности методов гибкой разработки программного обеспечения.

При использовании метода гибкой разработки проектировщики дробят выполняемую работу на мелкие составные части, фокусируются на их реализации и на решении конкретно очерченных задач. Проблемы возникают во время разработки, а не перед ее началом. При такой постановке вопроса подразумевается реализация главного, по мнению исследователей творческой деятельности: способности активно распознавать проблемы, возникающие в процессе работы. Аналогично поступает и Гери, когда, соблюдая все требования к проекту, ищет способы улучшить акустику. Психологи Якоб Гетцельс и Михай Чиксентмихайи провели в 1970 году исследование, которое продемонстрировало важность определения конкретных проблем, возникающих во время творческого процесса.

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

Метод водопада обычно критикуют за то, что при его использовании остается мало пространства для переформулирования задач. Метод гибкой постановки задач в процессе разработки нового продукта или программы напоминает подход компании HP в то время, когда она была на острие инновационного прогресса. Как менеджеры HP определяли конкретные проблемы пользователей, в том числе разрабатывая первую модель компьютера, так и сотрудники отделов продаж и маркетинга пытались определить проблемы, возникающие перед клиентами. Допустим, компания выпускает программное обеспечение, которое помогает в работе отделу продаж. У клиента может возникнуть потребность связать свою базу адресов электронной почты с программным комплексом отдела продаж, чтобы пользователям не приходилось прикреплять файлы картотеки поодиночке. Менеджер по управлению товарным производством в софтверной компании собирает эти требования, заносит их в таблицу в Excel и расставляет соответствующие приоритеты.