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

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

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

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

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

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

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

Чтобы увидеть, как дробление может помочь в развитии нового бизнеса, достаточно взглянуть, как Андре Ванье и его бизнес-партнер Майк Слеммер разрабатывали бесплатный информационный сервис под названием 1-800-411-Save. До того как заняться собственным бизнесом, Ванье работал консультантом в компании McKinsey и был связан с рядом самых крупных организаций в Америке. Мнения о том, как именно приступить к созданию программных продуктов для своей компании, у них со Слеммером поначалу различались. Ванье считал, что, приступая к разработке программного обеспечения, которое, по идее, должно служить миллионам пользователей, сначала необходимо все досконально распланировать. А Слеммер, уже принимавший до этого участие в двух информационных стартапах, полагал, что вместо этого им следует создавать программное обеспечение постепенно, разбивая весь процесс на этапы, которые отражали бы рост количества пользователей.

Слеммер мог поклясться Ванье, что когда количество пользователей возрастет до десяти тысяч, многие из задач, сформулированных на старте и обеспечивших им десять тысяч пользователей, окажутся неверно поставленными. А когда будет достигнута цифра в один миллион пользователей, практически наверняка придется начать переписывать большие фрагменты этого программного обеспечения, так как на основе полученного опыта неизбежно возникнут новые идеи. И все повторится снова, когда количество пользователей возрастет до десяти миллионов. Поэтому Слеммер спросил Ванье, готов ли он ответить на все эти вопросы сейчас, когда у них пока нет ни одного пользователя. «Мы решили идти по второму пути», – рассказывает Ванье. Хотя пришлось соперничать с более крупными компаниями с сильной ресурсной базой. Например, с такими разработками, как 1-800-Free411[25], они оказались первыми, кто внедрил ряд новых функций, в том числе подсказки для водителей и прием заявок через Интернет на доступ к специальным предложениям.

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