Закрыть
E-mail:
Пароль:
Забыли пароль?
В каталоге проекта: 14 007 веб-студий, 974 CMS, 245 682 сайта.
РегистрацияCMS MagazineВход
CMS Magazine CMS Magazine

[Азбука клиента] Модели заказной веб-разработки

Владимир Завертайлов, апологет гибких методик веб-разработки, опубликовал ряд евангелических статей, две из которых вместе подробно раскрывают тему:

За два года сторонники гибких и «жёстких» методик, похоже, подошли с разных сторон к наиболее приемлемой для рынка модели разработки. «Scrum по фиксированной цене» называется просто «итеративной моделью».

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

Надеюсь, что публикация поможет решить две задачи:

  • убедить клиентов в выгоде гибких и итеративной методик,

  • подсказать исполнителям ещё пару идей для обоснования этих подходов клиенту.

Резюме статьи для клиентов

  • Если проект небольшой, методология не играет роли. Можно использовать любую.

  • Если проект большой, выбирайте гибкие методики.

  • Если проект большой, а вы не преодолели недоверие к гибким методикам или конкретному подрядчику, выбирайте итеративную разработку.

Особенности веб-проектов

Три главных характеристики любого проекта по веб-разработке с точки зрения заказчика:

  1. Высокая изменчивость среды. Интернет меняется так быстро, что вчерашние ожидания или планы могут сегодня не иметь отношения к действительности (как в лучшую, так и в худшую сторону).

  2. Высокая степень неопределённости. Если вы разрабатываете и запускаете проект «с нуля», всё, что у вас есть, это гипотезы. Гипотезы о вашей целевой аудитории и её поведении, о конкурентном окружении, об эффективности того или иного канала привлечения посетителей. В худшем случае даже гипотез нет, просто «мне нужен сайт».

  3. Ограниченность ресурсов. Заказывая сайт, клиенты почти всегда ограничены либо в деньгах, либо во времени до запуска, либо в том и другом.

Исторически рынок привык к «водопадной» модели разработки, когда этапы следуют друг за другом (перечень может отличаться):

  • Проектирование

  • Дизайн

  • Вёрстка

  • Разработка

  • Тестирование и ввод в эксплуатацию

Есть и другие варианты, давно привычные для других индустрий. Давайте разбираться в их достоинствах и недостатках.

Водопад

Для маленького проекта «водопад» работает. Для большого проекта «водопад» это снежный ком проблем.

Водопадная модель вообще нечувствительна к изменчивости. Риски вообще не запустить проект или сделать нечто неэффективное возрастают экспоненциально с ростом сложности и длительности проекта.

Маленький проект (посадочная страница, мини-сайт, промо-сайт) хорошо делаются «по водопаду».

Как только проект оценивается в 6 месяцев разработки и более, риски, связанные с изменчивостью, накапливаются как снежный ком.

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

  • Конкуренты могут запустить похожий проект раньше вас.

  • Крупный игрок (например, Яндекс) может выкатить продукт или функционал, который сделает ваш проект бесполезным.

  • Поведение потребителей может ощутимо измениться (например, они пересядут с ноутбуков за планшеты).

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

Представим себе развитый водопадный процесс хорошей веб-студии. Он включает в себя, к примеру:

  • бизнес-анализ и целеполагание,

  • сбор информации о целевой аудитории, конкурентном окружении и среде проекта,

  • проектирование (включая описание персонажей и сценариев, информационную архитектуру, функциональные требования, прототипирование, системную архитектуру и т.д., и т.п.)

  • создание визуальной концепции,

  • разработку дизайна,

  • вёрстку,

  • программирование,

  • тестирование,

  • ввод в эксплуатацию.

Поначалу кажется, что это хороший процесс по отношению к неопределённости:

  • клиент и исполнитель формируют общее понятийное поле,

  • клиент и исполнитель вместе снижают неопределённость,

  • клиент и исполнитель вместе снижают неопределённость,

  • клиент и исполнитель вместе снижают неопределённость,

  • клиент и исполнитель вместе снижают неопределённость,

  • в разработке и вводе в эксплуатацию запускается понятный и эффективный проект.

А в жизни это выглядит так:

  • исполнитель формирует понятийное поле, заказчик скучает,

  • исполнитель собирает информацию, заказчик скучает и уже немного нервничает,

  • исполнитель выдвигает и фиксирует гипотезы о ЦА, заказчик нервничает и хочет увидеть картинки,

  • исполнитель выдвигает очередные гипотезы о ЦА, заказчик видит картинки, которых он не ожидал,

  • в результате долгой и муторной борьбы и процесса согласований исполнитель фиксирует в дизайне ряд собственных непроверенных гипотез и «хотелок», которые продавил заказчик,

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

Если это большой проект, основные риски, связанные с неопределённостью, таковы:

  • Вы можете не дождаться картинок, если активно не вовлечены в процесс проектирования.

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

  • Гипотезы рано или поздно придётся проверять. В водопадной модели до этого момента пройдёт очень много времени — весь проект должен быть разработан и запущен.

Наконец, водопадная модель неплохо справляется с ограниченностью ресурсов. Но только при условии качественного менеджмента. Это означает:

  • Требования к проекту должны быть зафиксированы в начале проекта и неизменны до ввода сайта в эксплуатацию.

  • Ресурсы должны выделяться вовремя.

  • Оценка требуемых ресурсов исполнителем должна быть достаточно точной.

В жизни получается иначе по всем пунктам — клиент меняет требования, исполнители промахиваются с оценками (особенно на длительных проектах!), согласования и платежи задерживаются. Всё это усугубляется изменчивостью и неопределённостью, которые раскручивают эти проблемы.

Необходим сайт, мобильное приложение, услуги по SEO или контекстной рекламе? Тендерная площадка WORKSPACE поможет выбрать оптимального исполнителя. База проекта насчитывает более 10 500 агентств. Сервис БЕСПЛАТЕН для заказчиков.

Гибкие методологии

В гибких методиках разработки вы точно знаете, сколько потратите, точно успеете в срок, но не можете быть уверены на 100%, как много в итоге получите.

Гибкие методики развились в разработке десктопного программного обеспечения и веб-сервисов. Из популярных названий на слуху Agile, Scrum и Fix time, Fix budget, Flex scope.

Основные идеи манифеста Agile:

  • люди и взаимодействие важнее процессов и инструментов;

  • работающий продукт важнее исчерпывающей документации;

  • сотрудничество с заказчиком важнее согласования условий контракта;

  • готовность к изменениям важнее следования первоначальному плану.

Во всех подобных методиках разработка производится быстрыми итерациями. Цитируя Википедию, «каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование».

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

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

Гибкие методологии дружат с ограниченностью ресурсов. Вы можете не волноваться, что уложитесь в срок. Вы можете не волноваться, что превысите бюджет.

У гибких методик имеется единственный подвох: если обстоятельства проекта изменились или исполнитель ошибся в оценке сроков (не успел разработать всю функциональность за одну итерацию), то клиент получает меньшую функциональность за те же деньги.

Фрустрирует?

Разделение ответственности и рисков в проекте

Гибкие методики по-честному делят риски между клиентом и исполнителем. Водопад заставляет исполнителя перезакладывать риски в цену.

Выложим карты на стол. Когда вы заказываете сайт с привычной водопадной разработкой, вы не можете быть на 100% уверены, что сайт будет сдан с полной функциональностью точно в срок. Практика показывает, что на рынке минимум две трети проектов сдаются с задержкой.

Поэтому жёсткие договоры, штрафы, пени, угрозы — психологическая защита заказчика. Она не даёт гарантий, потому что каждому проекту по природе присущи риски. Лучшее, что могут сделать клиент и исполнитель — не добавлять к ним новых.

Как мы обсудили выше, главные «природные риски» проекта связаны с тем, что:

  • никто не может абсолютно точно прогнозировать будущие изменения среды,

  • никто не может выдвигать только правильные гипотезы о потребностях и поведении ЦА,

  • никто не может абсолютно точно оценить сроки разработки без долгой стадии проектирования.

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

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

Если исполнитель молодец, уложился в сроки и бюджет, то клиент по сути платит лишние деньги. Чем длиннее проект, тем выше риски, тем сильнее перестраховывается исполнитель, тем больше платит клиент.

Итак, при водопадном подходе клиент:

  • не имеет 100% гарантии получить то, что ожидал,

  • не знает точно, когда он получит работающий продукт;

  • переплачивает за результат.

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

То есть, при гибких методиках клиент:

  • не имеет 100% гарантии получить то, что ожидал,

  • всегда точно знает, когда он в следующий раз получит работающую итерацию,

  • платит за работу столько, сколько она стоит.

Явно лучше. Всё ещё слишком страшно перестраиваться? Есть компромисс.

Итеративная разработка

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

В итеративной разработке выделяется (можно даже в отдельный договор) первый классический этап проектирования. Важно, что он чётко ограничивается во времени и необходим для максимально возможного снижения неопределённости за ограниченное время (например, месяц).

После проектирования клиент и исполнитель вместе определяют главную функциональность, которую необходимо запустить в первой итерации, фиксируют стоимость и сроки. Срок каждой итерации (дизайн — вёрстка — разработка — тестирование и запуск) составляет от месяца до трёх.

Объём функциональности в первой итерации строго фиксируется. Исполнитель и клиент договариваются, что если в ходе первой итерации появляются новые «хотелки», они переносятся на вторую итерацию.

Далее первая итерация разрабатывается и запускается по водопадной модели. Исполнитель несёт всю ответственность и все риски за то, что фиксированный объём работ будет выполнен за фиксированное время и фиксированный бюджет (за скобками мы оставляем нюансы согласований у заказчика).

Параллельно собираются требования для второй итерации. К концу первой итерации клиент и исполнитель вместе определяют функциональность к разработке во второй итерации, фиксируют её параметры, и так далее.

Итеративная разработка дружит с изменчивостью, неопределённостью и ограниченностью ресурсов, ровно так же, как в случае гибких методик.

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

Итеративная разработка психологически комфортнее для некоторых заказчиков.

Повторим резюме

  • Если проект небольшой, методология не играет роли. Можно использовать любую.

  • Если проект большой, выбирайте гибкие методики.

  • Если проект большой, а вы не преодолели недоверие к гибким методикам или конкретному подрядчику, выбирайте итеративную разработку.

Статья подготовлена для информационной рассылки агентства «Кельник»

Автор: Алексей Ёжиков

Комментарии участников рынка

Ольга Русакович

Компания: Webway
Должность: Заместитель директора

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ольга Павлова

Компания: «Собака Павлова»
Должность: Совладелец

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

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

Илья Макаров

Компания: CS-Cart
Должность: Технический директор

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

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

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

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

Сергей Полуэктов

Компания: My Media
Должность: Генеральный директор

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

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

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

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

Андрей Журавлев

Компания: MST Digital Agency
Должность: Системный архитектор

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

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

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

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

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

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

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

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

Роман Петров

Компания: Ай Ти Констракт
Должность: Директор

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

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

Антон Мартынов

Компания: ITECH.group
Должность: Директор департамента разработки

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

Если Вы хотите дать экспертный комментарий к статьям, публикуемым на CMS Magazine, следите за анонсами материалов в нашей группе в Facebook.

Комментарии (Facebook)

Рекомендуем:


CMS Magazine CMS Magazine
Реклама
RSS-подписка
CMS Magazine CMS Magazine
CMS Magazine