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