Читать онлайн «Мелкие ставки. Великую идею нельзя выдумать, но можно открыть». Страница 27

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

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

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

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

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

Раз в неделю-две этот менеджер проводит совещание с командой разработчиков и теми, кто тестирует программное обеспечение, чтобы обсудить ход процесса и распределить нагрузку. Такие команды, как правило, состоят из шести-семи человек. Главная их задача – определить, как много времени займет выполнение того или иного отрезка работы. Команда начинает с выявления самых приоритетных задач, которые можно выполнить за одну-две недели. Допустим, написание модуля, обрабатывающего базу контактов для программы. Члены команды, обсудив то, что для этого потребуется, оценивают, сколько времени, причем конкретно часов или дней, по их мнению, будет затрачено. Обычно они приходят к согласованному решению и называют срок, допустим, несколько дней или неделю. Если кто-то не согласен с полученной оценкой, они это обсудят и проголосуют снова. Аналогично пройдут по всему списку приоритетных задач и в конце концов предоставят команде разработчиков максимальное время на разработку конкретного задания в предстоящий двухнедельный период. Совещание завершено, все расходятся.

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

Дробление задач не только повышает эффективность написания программы, оно также позволяет учиться в процессе. Многие пользователи программ Adobe, Apple iTunes, или Microsoft Office знают, что обновления теперь происходят намного чаще, чем раньше. Во многом это объясняется тем, что как только в программе появляется новый функционал, компании имеют возможность быстро узнать, считают ли его пользователи полезным. Как видно из приведенного примера, менеджер по управлению товарным производством может проанализировать данные и узнать, стали люди переводить свою базу электронных адресов в их программу или нет. Он также увидит, что пользователи хотели бы иметь возможность добавлять новые контакты в эту базу с других устройств или программ, например из своих почтовых клиентов или мобильных телефонов. Если это окажется достаточно востребованной функцией, менеджер проекта в таблице Excel определит приоритет разработке такого функционала. В результате будет поставлена новая задача.