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

То, что во время работы над проектом можно учитывать его соответствие конкретным требованиям, постоянно получая представление об особенностях его структуры, не означает, что все так просто; на самом деле этот процесс может очень сильно изматывать. После оцифровки макета и внесения его параметров в компьютер часто оказывается, что параметры здания превышают заданные, и коллег Гери это не сильно вдохновляет. «В таких случаях я говорю им: “Бог мой, дизайн здания выглядит отлично, но, видимо, нам действительно придется отнять тут десять процентов”». Такой подход крайне важен и позволяет проектировщикам с подъемом исправлять проект. Архитектурные планы разрабатываются с учетом требований заказчика, учитывая все подробности до мелочей – где будут находиться титановые панели, а где каменные блоки. Эти требования помогают Гери решить, что именно ему надо делать и чего делать не надо.

Учет заданных параметров предусматривает действие. В некоторых областях, как, например, в архитектуре, требования к проекту, как правило, выдвигаются заказчиком. Бывает и так, что количество возможных вариантов не ограничено, например в случае «чистого листа». И тогда использование ограничительных условий, определенных самостоятельно, особенно эффективно. Суть этого метода заключается в том, что весь проект или основная задача разбиваются на более мелкие блоки и ограничения накладываются на каждый в отдельности, затем, по мере его решения, на следующий и так далее.

Такая стратегия, когда проект разбивают на составляющие, на относительно несложные задачи, с которыми проще справиться, и есть то, что Бинг Гордон, сооснователь и бывший креативный директор компании по разработке видеоигр Electronic Arts, называет дроблением. За плечами Гордона, партнера в венчурной инвестиционной компании Kleiner Perkins и члена совета директоров компаний Amazon и Zynga, огромный опыт руководства программистами. Работая в Electronic Arts, Гордон обнаружил, что когда команда разработчиков занималась длительными проектами, ее действия оказывались малоэффективными и много времени уходит на ненужную работу. Если же проект разделяли на мелкие составляющие, работа над которыми занимала гораздо меньше времени, то программисты подходили к делу более творчески и трудились эффективнее.

Сегодня подобная практика дробления проблем в Кремниевой долине общепринята, и большинство директоров называют ее одним из важнейших новых веяний в индустрии программного обеспечения – методом гибкой разработки программного обеспечения. Этот метод был предложен в 2001 году Кентом Беком, Алистером Кокбёрном и Джефом Сазерлендом при участии четырнадцати других разработчиков. Они считали, что процесс разработки должен разбиваться на мелкие составные части, в ходе его должны определяться приоритеты, а окончательные варианты выпускаемых программных продуктов должны отвечать запросам пользователей. Вместо стандартного процесса или заблаговременного планирования они стали формировать небольшие команды разработчиков, способные быстро реагировать на изменения в проекте. По их мнению, единственным критерием прогресса в проекте могут быть только законченные, функциональные программы.

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

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

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

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