Меня всегда смущало противопоставление водопадной и гибкой моделей, а также общепринятая мысль (в статье она отсутствует, но во многих головах имеет место быть) о том, что водопадная модель устаревает, гибкая более нова и должна прийти ей на смену. На самом деле все и сложнее, и проще одновременно, а противопоставление — не то, что нужно для понимания этих моделей.

Начнем с того, что гибкая модель гораздо старше водопадной, хотя многие почему-то считают иначе. Это не доказано, конечно, это мое глубокое имхо. Гибкая модель обязана была появиться в тот момент, когда появилось «клиент всегда прав». Не языковое выражение, конечно, а понимание того, что, кто платит, тот и устанавливает правила. А было это, наверное, еще раньше, чем в эпоху пирамид. Даже тысячи лет тому мир был изменчивым, а люди такими же, как сейчас — не могущими предвидеть все свои хотелки при реализации проекта, будь то строительство дома, изготовление мебели или любой другой «проект». И я уверена, что еще тогда заказчики хотели того же, чего они хотят сейчас — знать точную цену и сроки, но при этом иметь возможность видоизменять проект по ходу дела, видеть и даже мочь использовать его промежуточные итерации. Уверена, что еще до эпохи пирамид заказчик дома по десять раз передумывал, как ему строить какой-нибудь там бассейн во дворе. Еще тогда такой заказчик плевал на подготовленные заранее чертежи и натасканные во двор плиты, если узнавал, что у какого-то из его соседей есть не только бассейн, а вокруг него еще и колонны стоят, а сам он в два раза глубже (ну условно, конечно).

То есть, заказчик — это как раз тот, кто всегда хотел, хочет и будет хотеть гибкую модель, кто прекрасно без наших объяснений понимает все ее преимущества, связанные с возможностью маневра и сдачей в эксплуатацию промежуточных итераций. Более того, заказчик и есть инициатор этой гибкости, потому что ему самому гибкость на порядок удобнее, не нужно себя ограничивать. Вот только все это никогда не было удобно подрядчику, потому что цену-то оговаривали на берегу. Водопадная модель зародилась в тот момент, когда первый подрядчик понял, что, несмотря на то, что фактически он 10 раз построил бассейн (посредством его переделки), заплатят ему только за один. Идут века, а водопадная модель все крепнет, и не потому, что кто-то не понимает ее недостатков с точки зрения «хорошести» для результатов проекта, а потому что мы, подрядчики, вынуждены защищаться от проблемы, созданной заказчиками, под названием «гибкая разработка за фиксированную цену». Водопадная модель — это не модель, это — компромисс в результате конфликта интересов заказчика и подрядчика. Гибкая же модель — тоже не модель — это конфликт, в котором подрядчика устраивает все (гибкой работе гибкая цена), а заказчика устраивает только первое (гибкая работа, но не гибкая цена). Повторюсь — не модель и модель, а конфликт и вариант его решения.

Вариантов решения, конечно, больше, чем два. Практика в большинстве случаев представлена двумя краевыми схемами — водопадная (фиксированная работа за фиксированную цену) и, скажем так «абонентская» (сколь угодно гибкая работа за зарплату или абонентскую плату). В сущности, работа на з/п или абонентке — это некий краевой гипертрофированный вариант аджайла, когда обе стороны утратили конкретную цель, и понятие «проекта» уже не существует, но им удобно друг с другом, и они оба видят пользу от сотрудничества. В итоге мы имеем редкий случай, когда в реальности процветают краевые схемы, а золотая середина недостижима.

Даже если заказчик смирился с абонентской платой, как только он спросит подрядчика «а все-таки, за сколько месяцев абонентской поддержки вы точно сделаете все, что я хочу», схема рушится. Никакой заказчик не хочет платить неизвестную цену за, как ему кажется, известную вещь. Защитники скрама и итеративных моделей могут сколько угодно говорить, что все прозрачно — цена за первую итерацию-то фиксирована, но никого не интересует одна итерация, нужна цена за проект в целом.

Автор совершенно верно подметил три характеристики проекта: изменчивость, неопределенность, ограниченность во времени и средствах. Я бы смотрела шире — не ограниченность во времени и средствах, а просто желание точно знать, сколько будет потрачено и когда будет готово. Такое желание свойственно всем заказчикам, даже тем, кто в средствах и времени не ограничен (об этом ниже).

Очень меня смутили два утверждения в статье. Первый о том, что при водопадной модели заказчик переплачивает за результат. Второй о том, что жесткий договор — защита заказчика.

Утверждение первое: «заказчик переплачивает за результат». Если бы это было так, все заказчики поголовно уже давно ринулись бы на гибкую разработку, зачем платить больше? Но все не так. Если бы заказчик переплачивал, все сотрудники веб-разработчиков ездили бы на Порше. Но они не ездят. Большинство из них едва сводят концы с концами, а даже самые крупные и успешные отнюдь не купаются в золоте. Переплатить заказчик мог бы при двух условиях, каждое из которых является сферическим в вакууме. Условие первое. Исполнитель учитывает в проекте действительно ВСЕ свои риски, но этого не происходит. Многие из нас не могут не только количественно оценивать известные риски, но и оценивать их качественно, то есть составить список всех возможных рисков. А если риска нет в списке, то и количественно его не оценишь. Некоторые риски закладываются в проект «при прочих равных», то есть двухдневная болезнь программиста Васи в рисках учитывается, а вот увольнение Васи и невозможность его заменить в течение нескольких месяцев — нет. Отпуск маркетолога заказчика адекватной Маши в рисках учитывается, а ее увольнение и приход на ее место неадекватной стероидной стервы Ларисы, которая поломает Вам всю работу — нет. Для многих это абстрактные форс-мажоры, а не реальные риски, которые никак не учитываются в цене.

Условие второе. После того, как вы заложили абсолютно все риски и рассчитали стоимость, заказчик должен согласиться заплатить выставленную Вами цену. Но разве он платит ровно столько, сколько Вы хотите? Хоть это и звучит книжно, цена определяется рынком, а не тем, что Вы там рассчитали со своими рисками.

Зато при гибкой схеме заказчик переплачивает точно, и это знают все :). Независимо от модели все риски постепенно (по мере реализации проекта) обнаруживаются, но только в гибкой модели заказчик их оплачивает. Можно сколько угодно теоретически обосновывать обратное, но любой коммерческий, финансовый или другой, считающий деньги, директор заказчика знает на подкорке — не договоришься о цене на берегу, выйдет дороже, и он прав на 100%.

Заказчик никогда не переплачивает, и именно этим неутешительным фактом объясняется наша любовь к гибким моделям и нелюбовь к ним заказчиков. Мы хотим получать ровно столько, сколько отработали, мы хотим делить риски с заказчиком, мы хотим, чтобы заказчик сам отвечал за свои ошибки, а заказчик-то этого не хочет, и меняться ему незачем до тех пор, пока желающих делать сайты меньше, чем тех, кто их делает (то есть, всегда).

Утверждение второе: «Жёсткие договоры, штрафы, пени, угрозы — психологическая защита заказчика». Защита от чего? От того, что исполнитель нарушит сроки или не сможет сделать того, что обещал? Так это не особенность модели, это особенность хренового исполнителя. В смысле, на нашем рынке (как и на любом другом рынке проектных работ) существуют разработчики разного качества. Везде есть новички, которые мало что умеют, у них действительно проблемы со сроками, они не могут оценить свои силы. Но разумно ли на их примере разбирать модели? О каких сложных проектах и гибких моделях может идти речь, если разработчик не в состоянии оценить то, за что он берется, и выполнить взятые на себя обязательства? В контексте сложных проектов мы можем рассматривать только квалифицированных и опытных разработчиков, а у них нет проблем ни со сроками, ни с оценкой своих сил. Если речь идет о первой категории, то заказчику нет смыла защищаться договором — люди все равно слажают, а брать с них будет нечего.

Если заказчик считает, что все разработчики уроды, не успевают в сроки, делают лажу, то он просто копается не в тех разработчиках. Тут не до моделей. CMS Magazine пишет, что средняя стоимость сайта по стране — 110 тыс. Подавляющее большинство заказчиков хотят делать в Москве за 20-50, по стране еще дешевле, о каких гибких моделях тут может идти речь? Наша компания в состоянии сделать сайт за 50 тысяч при среднем чеке в 500, но для этого гайки заказчику нужно закрутить вокруг шеи так, что он задохнется.

Если автор говорит о гибких моделях, то мы говорим о чеках уже не в 500 тыс., а в миллионы, так? С такими чеками не работают компании, от которых вынуждены защищаться заказчики штрафами и угрозами, на этом уровне все точно наоборот — разработчики защищаются от заказчика договором, и именно здесь порылась очень толстая собака. Как я уже говорила выше, заказчики априори склонны к гибкой разработке, но разработчики вынуждены крутить гайки и ограничивать заказчика, чтоб не остаться при фиксированных деньгах за гибкий объем работы. Чем взрослее разработчик, тем сложнее и жестче его договор, тем сильнее закручены гайки. Жесткий договор и водопадная схема — защита подрядчика, который уже наелся «гибкими» заказчиками, а не наоборот.

Живучесть и неискоренимость водопадной модели зиждется всего лишь на двух вещах — хочу знать фиксированную цену, хочу не отвечать за свои ошибки, а вовсе не на том, что она позволяет делать лучшие проекты. Вот и все.

На досуге всем рекомендую почитать книгу «Вальсируя с медведями» ДеМарко, Листера. Особенно пример с автоматизацией аэропорта. О каких гибких методологиях при разработке банальных сайтов может идти речь, если даже на крупнейших проектах в развитых странах люди так лажают?!

Так как сам автор в начале статьи приводит в пример статьи Владимира Завертайлова с поездкой на такси и обустройством квартиры по гибкой схеме, давайте рассмотрим поездку на такси под другим углом. Примера вроде бы хорош, красиво и доходчиво обоснован, но имеет недостаток (как и пример с обустройством квартиры) — решение о бюджете принимается личностью, которая достает свои деньги из своего кармана. При веб-разработке крупных проектов это не так. Бюджет выделяется не тем, с кем Вы работаете, а его компанией где-то там наверху через сорок три колена, и там наверху никто никогда не потерпит гибкой схемы. Чем мельче проект, чем ближе владелец компании клиента к проекту, тем проще договориться о гибкой схеме. В теории же все должно быть наоборот, чем сложнее проект, тем гибче должна быть схема, а это-то как раз и не работает. Представьте себе Газпром и какой-нибудь мега проект по автоматизации его бензоколонок. Кого Вы будете убеждать в необходимости гибкой разработки? Ответственного менеджера? Бесполезно, бюджет выделяет не он, а начальство требует от него четких цифр. Президента Газпрома? Даже если Вам разрешат с ним встретиться, неужели он выдаст разрешение на гибкий бюджет, хотя знает, что не он лично будет контролировать процесс, а какой-то менеджер какого-то подразделения, который завтра может вообще уволиться. Да и Вас он знает всего 10 минут и не имеет времени разобраться в Вашем профессионализме, за одну встречу он не сможет понять, в состоянии ли Вы сделать проект на гибких условиях. Крупные организации объективно устроены так, чтобы соблюдался вагон правил и регламентов, а, следовательно, и бюджет. Я повторяю, ОБЪЕКТИВНО устроены так (почему, объяснять долго, читайте Адизеса). Это Вам не поездка на такси и не покупка мебели в Вашу собственную квартиру. Представим ситуацию, описанную Владимиром Завертайловым по иному — он не сам едет на такси, но дает на него деньги. Допустим, в гости приехал троюродный кузен пятиюродного племянника, которого Вы видели два раза в жизни, и вот этого племянника надо отправить на такси в кино, чтобы тот развлекся, и Вы даете ему свою кредитку под бюджет в ту же тысячу рублей на поездку. В итоге родственник потратил 5 тысяч и объясняет потом про пробки, бензин, перенос фильма в другой кинотеатр и прочий аджайл. Какова будет Ваша реакция? Ведь Вы толком не знаете ни своего племянника, ни таксиста, ни киноафиши. Вы не можете быть уверен в том, что все рассказанное правда, и на самом деле родственник тупо не снял лишние деньги себе в карман. Вам вообще нужна головная боль с этим разбором полетов? Полагаю, в следующий раз племяннику будет выдана тысяча налом на руки, а тот уж будет доезжать до театра, как сможет. А еще скорее не в следующий, а в самый первый раз Вы не дадите ему кредитку. Ведь есть же не только такси, есть метро и пешая перебежка между шоссе (с того, где пробки, на соседнее свободное). Понятно, что на такси ехать приятнее, чем на метро, но кого интересует? Так и с водопадной моделью — есть возможность уложиться в бюджет и таки добраться до нужного места в нужное время даже при меняющихся обстоятельствах, не говоря уже про хотелки.

Не забудем также о том, что гибкая или итеративная схема увеличивают количество принимаемых решений. Допустим, Вы президент Газпрома, вы потратили много времени на принятие решения о начале проекта по автоматизации АЗС, выбрали подрядчика, выделили деньги на первый этап. Прошел месяц, получено какое-то решение, Вам нужно начинать все заново — проверять, как работает система, оценивать результат, думать, продолжать ли с этим подрядчиком или искать для продолжения другого, думать, каков будет второй этап, опять выделять деньги — геморрооооооой. Для крупного заказчика много раз принимать решения по ходу проекта — колоссальная трата времени и ресурсов, которые в описанной гибкой системе вообще не учитываются. Это не то же самое, что мгновенно принять решение о том, доплатить ли таксисту 500 рублей, лежащих в кармане. Правильно, разработчику-то в принципе по фиг, как заказчик будет проводить оценку этапа и принимать решение о переходе к следующему, а у заказчика этот переход может занять месяцы и потребовать колоссальных управленческих ресурсов. Об это в описании гибкой модели нет ни слова.

Сам Владимир Завертайлов писал в одной из статей, которую автор не приводит (ссылки нет под рукой), что чем больше число этапов, тем ниже вероятность того, что проект перейдет к следующему этапу. Он показывает это числовыми выкладками, но в принципе и без чисел ясно, что чем больше этапов, тем больше их окончаний (приемок работы), чем больше приемок, тем больше тратится времени и нервов, чем больше времени и нервов, тем больше конфликтов, чем больше конфликтов, тем выше вероятность соскока с обеих сторон. Я не знаю, насколько вы интересуетесь жизнью коллег по цеху, я интересуюсь и вижу вот что — наибольшее число положительных отзывов и довольных клиентов у тех компаний, которые делают сайты в диапазоне 5-10 тысяч рублей максимум за неделю. Совершенно другая ситуация у крупных коллег по цеху — ими, наоборот, клиенты вечно недовольны, потому что все долго и на каждой приемке возникают конфликты. Вот и думай, какая схема лучше :).

Из этого следуют неутешительные выводы — гибкие и итеративные схемы хороши для проекта в теории, на практике же гибкость приводит к тому, что заказчик и подрядчик рассорятся задолго до окончания проекта, для доделки будет найден новый подрядчик (а может не один), и вот это-то уж точно не хорошо для проекта. Самое гадкое, что увеличение вероятности «рассоривания» при росте количества этапов не впрямую зависит от квалификации разработчика и заказчика — это пресловутый человеческий фактор.

Муссирование гибкий модели самими разработчиками — это всего лишь оформленная мысль о том, что надо совместить желаемое с действительным, заставить заказчика платить именно за ту схему работу, которую он сам хочет. То есть гибкой работе гибкая оплата. Заказчики — не идиоты, им не надо объяснять, что сложный проект надо делать гибко, что все изменчиво и непредсказуемо. Не было у нас ни одного проекта, когда бы заказчик сам не спросил, а можно ли потом немножко дизайн переделать после верстки? Говорим, что можно, и спрашиваем, а можно ли за это денег попросить? Вопрос бесполезный, ибо ответ всегда один — нет.

Короче, заказчику всего лишь надо объяснить, что за гибкую работу надо гибко платить, даже если это «гибко» выйдет дороже фиксированного. Если это удастся, мы все попадем в прекрасный мир, где заказчики платят адекватно затраченным нами усилиям, а все мы пусть не ездим на Порше, но сидим в хороших офисах, вовремя меняем парк компьютеров, короче, имеем условия, адекватные нашей работе, вместо того, чтобы каждый месяц думать о том, хватит ли бюджета на зарплату. Как только удастся убедить заказчика гибко платить, переход к гибкой модели совершится сам собой, «жаль только — жить в эту пору прекрасную уж не придется — ни мне, ни тебе» :).

Я не помню случаев, чтобы выбор методологии зависел от заказчика. Я не помню случаев, чтобы заказчик смог навязать свою методологию исполнителю. И я не помню случаев, чтобы результат проекта зависел от методологии больше, чем от квалификации менеджера.

Соответственно, всё это полезные знания — для того чтобы пораспускать перья на переговорах. Дорогие продажники исполнителей, обратите внимание: зубрите наизусть убедительные пассажи. Кроме шуток, пригодятся.

Довольно интересен термин «итеративная разработка», с учетом того что Scrum сам по себе итеративен.

Я считаю, так или иначе все сводится к одному — вовлеченности заказчика в процесс: чем больше исполнитель взаимодействует с заказчиком, тем больше итоговый результат устроит заказчика. Иными словами, когда заказчик действительно выступает в роли Product owner и принимает активное участие в проекте, то проект контролируем и предсказуем. На выходе получится то, что заказчик ожидает, так как он сам формирует беклог и в нем расставляет приоритеты для задач.

Безусловно, заказчик должен знать и следовать «правилам игры» в этом хитром итеративном процессе, что напрямую зависит от исполнителя и его стойкости.

Обобщая, текущая статья описывает следствия вовлеченности заказчика в проект. Так как очевидно, что при активном участии заказчика требования будут меняться, либо детализироваться/прояснятся (кому как угодно), и, соответственно, третий подход (так называемая итеративная разработка) для исполнителя остается единственно возможным вариантом эффективного сотрудничества.

Чистый agile очень сложно продавать. Только на поддержке и высоком уровне доверия. На новых проектах мы тоже пришли к итеративной разработке, по трудоемкости они у нас 500-1000 часов. Только итерации идут по этапам водопада.

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

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

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

В целом, я полностью согласен с автором статьи. Разница между классикой и гибкими методологиями хорошо демонстрируется на основе представления рисков.

Выступая адвокатом дьявола, хочу заметить, что подвергаемая остракизму в современном мире водопадная и другие классические модели живут и оказываются единственно возможными в целом ряде предметных областей. Так, водопад будет выбран в больших и сложных проектах, когда требуется совместная работа нескольких проектных команд или проект связан с критической инфраструктурой. Водопад отлично себя чувствует в серьезном производстве как, например, отечественный ВПК, НАСА или Боинг. В подобных областях в металле воплощаются решения, о которых говорили инженеры 10-15 лет назад, потому как все необходимо проверить и согласовать. И цена бага в несколько сотен человеческих жизней неприемлема.

Более приближенный к нашей области пример - это софтверный гигант Микрософт, с бюджетом на R&D превышающим суммарный у конкурентов. Мой добрый друг, работавший в Редмонде в Windows Core Team, говорил, что 3х месячный цикл планирования для полугодового цикла разработки это нормальная вещь.

Резюмируя, хочу отметить, что разработка по «водопадке» это скорее привилегия больших и технически сложных проектов, где рисков связанных с изменчивостью крайне мало. Для маленьких проектов вроде упомянутых промо-сайтов даже «аджайл» может быть оверкилом во многом из-за сроков — «а нам крайне важно чтобы было готово ко вчера/завтра/послезавтра» нужное подчеркнуть. В таких условиях можно уповать только на профессионализм исполнителей.

Гибкие методологии и итеративная разработка по сути одно и то же, с незначительными деталями. Суть в обоих случаях в регулярной поставке продукта, финал каждой итерации или спринта — демо для заказчика или владельца продукта (роль в скраме). Внутри спринта мы фиксируем объем задач и не меняем его.

Однако, в литературе предмету об этом не говорится, но отлично известно практикам — красивый академический «аджайл» это фантастика. В реальном мире, заказчики часто выпрыгивают, как черти из табакерки с новыми требованиями в середине спринта, которые надо обработать срочно и которые перечеркивают работы, выполненные за последние пару спринтов. А на демо заказчик занят и просит перенести «на пару дней» и вообще читать и согласовывать список задач на итерацию не царское дело ;)

А так как рынок и Agile Manifesto нам велят адаптироваться — процессы адаптируются, но представляют собой смесь водопада и аджайла меняющегося от случая к случаю. У подавляющего большинства проектных команд так называемое «скрамнецо».

И необходимо понимать, что даже подобный полу-аджайл - это методология для слаженной, профессиональной команды, способной создать проект таким, каким он нужен заказчику и конечному потребителю. В отличие от классической модели, которая, подразумевая жесткий процесс, позволяет эффективно работать совместно людям со значительной разницей в уровне профессионализма, это, конечно, секрет Полишинеля, но момент важный и его необходимо учитывать как заказчикам, так и исполнителям. Но важно понимать, что никакая методология и перезаклад рисков не спасет проект, который поручен недостаточно целостной и недостаточно подготовленной команде.

Алексей, благодарю за статью.
Вы хорошо и в доступной форме рассказали отличия между различными подходами в разработке сайтов и описали, когда те или иные подходы применимы.
В нашей практике мы часто используем итеративную разработку, даже если не называем ее так явно. Одна из причин — это то, что заказчик не всегда морально готов на гибкую разработку. Многие заказчики тяжело
воспринимают факт, что при гибкой разработке в разработанный продукт может войти не всё, что обговаривалось на начальном этапе, и именно это и является платой за ключевой фактор «уложиться в сроки и бюджет».

Буду рекомендовать вашу статью к прочтению при сложных переговорах с заказчиками!

Разработка заказных сайтов несколько отличается от разработки классического программного обеспечения, для которого и разрабатывались эти модели. Как правило, здесь все проще: этапы создания сайтов носят более определенный характер, а результаты для каждого из этапов носят вполне завершенный вид. Например, этап аналитики завершается постановкой задачи и отчетом по предлагаемой структуре сайта, этап проектирования — прототипом, техническим заданием и, возможно, дизайн-концепцией, этап дизайна — представлением заказчику готовых дизайн-макетов страниц сайта. При грамотном менеджменте со стороны исполнителя, «хотелки» заказчика должны отсекаться на этих этапах четкой аргументацией того, что нужно делать именно так, а не как предлагает заказчик (для этого и проводится этап аналитики и проектирования). Последующие этапы более технологичные по своей природе и могут содержать большое количество итераций, но, как правило, по мелочам. Конечно, мы говорим именно о «заказной» веб-разработке, когда либо заказчик точно знает, чего он хочет, либо мы ему говорим, как нужно это делать. Использование гибких методологий оправдано только в том случае, если на старте проекта очень много неопределенностей, которые не удается снять на этапах аналитики и проектирования. Но тогда речь идет, скорее всего, о стартапе, нежели о классическом заказном сайте. И еще не бойтесь тратить больше времени на детальную проработку прототипа и технического задания...