Владимир Завертайлов, апологет гибких методик веб-разработки, опубликовал ряд евангелических статей, две из которых вместе подробно раскрывают тему:
Scrum — зачем заказчику знать такие непонятные слова? (2011 год)
Scrum должен быть по фиксированной цене (2013 год)
За два года сторонники гибких и «жёстких» методик, похоже, подошли с разных сторон к наиболее приемлемой для рынка модели разработки. «Scrum по фиксированной цене» называется просто «итеративной моделью».
Статья предназначена для клиентов, но полезна и веб-студиям. В ней предложен ещё один взгляд на разные модели разработки, описаны ключевые причины их достоинств и недостатков на сегодняшний момент.
Надеюсь, что публикация поможет решить две задачи:
убедить клиентов в выгоде гибких и итеративной методик,
подсказать исполнителям ещё пару идей для обоснования этих подходов клиенту.
Резюме статьи для клиентов
Если проект небольшой, методология не играет роли. Можно использовать любую.
Если проект большой, выбирайте гибкие методики.
Если проект большой, а вы не преодолели недоверие к гибким методикам или конкретному подрядчику, выбирайте итеративную разработку.
Особенности веб-проектов
Три главных характеристики любого проекта по веб-разработке с точки зрения заказчика:
Высокая изменчивость среды. Интернет меняется так быстро, что вчерашние ожидания или планы могут сегодня не иметь отношения к действительности (как в лучшую, так и в худшую сторону).
Высокая степень неопределённости. Если вы разрабатываете и запускаете проект «с нуля», всё, что у вас есть, это гипотезы. Гипотезы о вашей целевой аудитории и её поведении, о конкурентном окружении, об эффективности того или иного канала привлечения посетителей. В худшем случае даже гипотез нет, просто «мне нужен сайт».
Ограниченность ресурсов. Заказывая сайт, клиенты почти всегда ограничены либо в деньгах, либо во времени до запуска, либо в том и другом.
Исторически рынок привык к «водопадной» модели разработки, когда этапы следуют друг за другом (перечень может отличаться):
Проектирование
Дизайн
Вёрстка
Разработка
Тестирование и ввод в эксплуатацию
Есть и другие варианты, давно привычные для других индустрий. Давайте разбираться в их достоинствах и недостатках.
Водопад
Для маленького проекта «водопад» работает. Для большого проекта «водопад» это снежный ком проблем.
Водопадная модель вообще нечувствительна к изменчивости. Риски вообще не запустить проект или сделать нечто неэффективное возрастают экспоненциально с ростом сложности и длительности проекта.
Маленький проект (посадочная страница, мини-сайт, промо-сайт) хорошо делаются «по водопаду».
Как только проект оценивается в 6 месяцев разработки и более, риски, связанные с изменчивостью, накапливаются как снежный ком.
Ваш бизнес может поменяться за это время и принципиально изменить требования к проекту. Это основная причина, из-за которой долгие проекты не запускаются вообще.
Конкуренты могут запустить похожий проект раньше вас.
Крупный игрок (например, Яндекс) может выкатить продукт или функционал, который сделает ваш проект бесполезным.
Поведение потребителей может ощутимо измениться (например, они пересядут с ноутбуков за планшеты).
Эта модель плохо чувствительна к высокой неопределённости. Веб-студии и агентства полируют профессиональные навыки и старательно усложняют процесс разработки, дробя его на всё большее количество этапов. Это делается, чтобы снижать риски, связанные с неопределённостью. Чем больше проект, тем хуже это работает.
Представим себе развитый водопадный процесс хорошей веб-студии. Он включает в себя, к примеру:
бизнес-анализ и целеполагание,
сбор информации о целевой аудитории, конкурентном окружении и среде проекта,
проектирование (включая описание персонажей и сценариев, информационную архитектуру, функциональные требования, прототипирование, системную архитектуру и т.д., и т.п.)
создание визуальной концепции,
разработку дизайна,
вёрстку,
программирование,
тестирование,
ввод в эксплуатацию.
Поначалу кажется, что это хороший процесс по отношению к неопределённости:
клиент и исполнитель формируют общее понятийное поле,
клиент и исполнитель вместе снижают неопределённость,
клиент и исполнитель вместе снижают неопределённость,
клиент и исполнитель вместе снижают неопределённость,
клиент и исполнитель вместе снижают неопределённость,
в разработке и вводе в эксплуатацию запускается понятный и эффективный проект.
А в жизни это выглядит так:
исполнитель формирует понятийное поле, заказчик скучает,
исполнитель собирает информацию, заказчик скучает и уже немного нервничает,
исполнитель выдвигает и фиксирует гипотезы о ЦА, заказчик нервничает и хочет увидеть картинки,
исполнитель выдвигает очередные гипотезы о ЦА, заказчик видит картинки, которых он не ожидал,
в результате долгой и муторной борьбы и процесса согласований исполнитель фиксирует в дизайне ряд собственных непроверенных гипотез и «хотелок», которые продавил заказчик,
в разработке и вводе в эксплуатацию запускается проект, базирующийся на непроверенных гипотезах о ЦА и жизненном опыте исполнителя и заказчика.
Если это большой проект, основные риски, связанные с неопределённостью, таковы:
Вы можете не дождаться картинок, если активно не вовлечены в процесс проектирования.
Вместе с исполнителем вы можете слишком глубоко встроить в свою картину мира неверные гипотезы относительно целевой аудитории.
Гипотезы рано или поздно придётся проверять. В водопадной модели до этого момента пройдёт очень много времени — весь проект должен быть разработан и запущен.
Наконец, водопадная модель неплохо справляется с ограниченностью ресурсов. Но только при условии качественного менеджмента. Это означает:
Требования к проекту должны быть зафиксированы в начале проекта и неизменны до ввода сайта в эксплуатацию.
Ресурсы должны выделяться вовремя.
Оценка требуемых ресурсов исполнителем должна быть достаточно точной.
В жизни получается иначе по всем пунктам — клиент меняет требования, исполнители промахиваются с оценками (особенно на длительных проектах!), согласования и платежи задерживаются. Всё это усугубляется изменчивостью и неопределённостью, которые раскручивают эти проблемы.
Гибкие методологии
В гибких методиках разработки вы точно знаете, сколько потратите, точно успеете в срок, но не можете быть уверены на 100%, как много в итоге получите.
Гибкие методики развились в разработке десктопного программного обеспечения и веб-сервисов. Из популярных названий на слуху Agile, Scrum и Fix time, Fix budget, Flex scope.
Основные идеи манифеста Agile:
люди и взаимодействие важнее процессов и инструментов;
работающий продукт важнее исчерпывающей документации;
сотрудничество с заказчиком важнее согласования условий контракта;
готовность к изменениям важнее следования первоначальному плану.
Во всех подобных методиках разработка производится быстрыми итерациями. Цитируя Википедию, «каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование».
Гибкие методологии дружат с изменчивостью. Вы получаете постоянно «растущий» сайт, который каждую итерацию можно «перенаправлять» в зависимости от полученной статистики, доказанно ошибочных гипотез и так далее. Вы можете ранжировать требования к сайту и внедрять их, начиная с самых важных.
Гибкие методологии дружат с неопределённостью, если заранее чётко описаны показатели эффективности, и вы непрерывно замеряете эти показатели. Быстрыми итерациями вы можете тестировать любые гипотезы относительно целевой аудитории и отказываться от неэффективных инструментов, не вкладываясь в крупный блок разработки. Например, увидеть, что вашей аудитории не нужен онлайн-калькулятор стоимости услуги, зато обычная форма заявки на обратный звонок работает хорошо.
Гибкие методологии дружат с ограниченностью ресурсов. Вы можете не волноваться, что уложитесь в срок. Вы можете не волноваться, что превысите бюджет.
У гибких методик имеется единственный подвох: если обстоятельства проекта изменились или исполнитель ошибся в оценке сроков (не успел разработать всю функциональность за одну итерацию), то клиент получает меньшую функциональность за те же деньги.
Фрустрирует?
Разделение ответственности и рисков в проекте
Гибкие методики по-честному делят риски между клиентом и исполнителем. Водопад заставляет исполнителя перезакладывать риски в цену.
Выложим карты на стол. Когда вы заказываете сайт с привычной водопадной разработкой, вы не можете быть на 100% уверены, что сайт будет сдан с полной функциональностью точно в срок. Практика показывает, что на рынке минимум две трети проектов сдаются с задержкой.
Поэтому жёсткие договоры, штрафы, пени, угрозы — психологическая защита заказчика. Она не даёт гарантий, потому что каждому проекту по природе присущи риски. Лучшее, что могут сделать клиент и исполнитель — не добавлять к ним новых.
Как мы обсудили выше, главные «природные риски» проекта связаны с тем, что:
никто не может абсолютно точно прогнозировать будущие изменения среды,
никто не может выдвигать только правильные гипотезы о потребностях и поведении ЦА,
никто не может абсолютно точно оценить сроки разработки без долгой стадии проектирования.
Остальные риски добавляются участниками из-за шероховатостей процесса, недостаточного профессионализма и недоверия друг другу.
При фиксировании сроков, стоимости и объёма функциональности все риски ложатся на исполнителя. Логично, что исполнитель завышает оценку сроков или стоимость часа, чтобы нивелировать риски. По сути, выступает в роли страховой компании для самого себя.
Если исполнитель молодец, уложился в сроки и бюджет, то клиент по сути платит лишние деньги. Чем длиннее проект, тем выше риски, тем сильнее перестраховывается исполнитель, тем больше платит клиент.
Итак, при водопадном подходе клиент:
не имеет 100% гарантии получить то, что ожидал,
не знает точно, когда он получит работающий продукт;
переплачивает за результат.
В гибких методиках риски разделяются между исполнителем и заказчиком. Исполнитель несёт репутационные риски при стабильно ошибочных оценках сроков. Заказчик несёт финансовые риски при случайно ошибочных оценках сроков. Зато риски изменчивости и неопределённости нивелируются самим процессом.
То есть, при гибких методиках клиент:
не имеет 100% гарантии получить то, что ожидал,
всегда точно знает, когда он в следующий раз получит работающую итерацию,
платит за работу столько, сколько она стоит.
Явно лучше. Всё ещё слишком страшно перестраиваться? Есть компромисс.
Итеративная разработка
Итеративная модель (разработка быстрыми итерациями, в каждой из которых строго фиксируются сроки, стоимость и объём работ) является альтернативой гибким методикам, когда проект большой, а доверие между исполнителем и клиентом ещё не установлено.
В итеративной разработке выделяется (можно даже в отдельный договор) первый классический этап проектирования. Важно, что он чётко ограничивается во времени и необходим для максимально возможного снижения неопределённости за ограниченное время (например, месяц).
После проектирования клиент и исполнитель вместе определяют главную функциональность, которую необходимо запустить в первой итерации, фиксируют стоимость и сроки. Срок каждой итерации (дизайн — вёрстка — разработка — тестирование и запуск) составляет от месяца до трёх.
Объём функциональности в первой итерации строго фиксируется. Исполнитель и клиент договариваются, что если в ходе первой итерации появляются новые «хотелки», они переносятся на вторую итерацию.
Далее первая итерация разрабатывается и запускается по водопадной модели. Исполнитель несёт всю ответственность и все риски за то, что фиксированный объём работ будет выполнен за фиксированное время и фиксированный бюджет (за скобками мы оставляем нюансы согласований у заказчика).
Параллельно собираются требования для второй итерации. К концу первой итерации клиент и исполнитель вместе определяют функциональность к разработке во второй итерации, фиксируют её параметры, и так далее.
Итеративная разработка сайта дружит с изменчивостью, неопределённостью и ограниченностью ресурсов, ровно так же, как в случае гибких методик.
Итеративная разработка выгоднее водопада на больших проектах, потому что исполнитель меньше закладывается на риски, а также выравнивается денежный поток. Платежи совершаются меньше и чаще ровно так же, как в случае гибких методик.
Итеративная разработка психологически комфортнее для некоторых заказчиков.
Повторим резюме
Если проект небольшой, методология не играет роли. Можно использовать любую.
Если проект большой, выбирайте гибкие методики.
- Если проект большой, а вы не преодолели недоверие к гибким методикам или конкретному подрядчику, выбирайте итеративную разработку.
Статья подготовлена для информационной рассылки агентства «Кельник»
Оригинал: https://cmsmagazine.ru/library/items/management/modeli-zakaznoj-veb-razrabotki/