Часто заказчики и разработчики плохо понимают разницу между этими двумя подходами к разработке сайтов.

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

Проекты «под ключ»

Особенности

  1. Это нужно для очень сложных задач и фиксированных бюджетов
  2. Бюджеты тут обычно от 1 млн. руб до 10-100 млн. руб.
  3. Разработка технической документации (ТЗ, спецификации) тут делаются либо внутренними экспертами, которые умеют это делать, либо отдаются на подряд внешним экспертам. Как правило это затратная часть, которая требует оплаты.
  4. После того как ТЗ готово, оно отдается на оценку подрядчику
  5. Подрядчик оценивая проекты смотрит ТЗ, и оценка делается исходя из прогноза рисков, которые в проектах обычно высоки. И тут все просто, чем хуже сделано ТЗ и чем сложнее задача, тем больше подушка добавляется. Причем подушка в проектах может быть от 20%, до 2-4 кратного размера прогноза по себестоимости.
  6. Таким образом, если прогноз по себестоимости 500 тр, то стоимость называется как 1 млн. или 2 млн. руб. в зависимости от оценки риска

Назначение

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

Скажем на ИТ выделено 100 млн. в год. И надо расставить все по статьям бюджета, а потом важно не перелететь за бюджет.

Также это хорошо когда ответственность в целом ложится на подрядчика. И Заказчик тратит меньше своих операционных затрат на результат.

Минусы и проблемы

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

Ключевая проблема в том что проекты были придуманы для строительства, инвестиций и других интересных тем. А ИТ-продукты отличается своей сложностью, плохой предсказуемостью. Одно дело запланировать строительство дома в 2 этажа, где все достаточно предсказуемо, и другое дело запланировать разработку ПО, где через неделю все может перевернуться с ног на голову.

Потому проекты в мире ИТ применяются с опаской. Все большее число команд переходят на Agile рельсы.

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

Вход в тему

Для тех кто лучше хочет понять суть работы по проектам, рекомендую изучить материалы по этой теме либо можно потратить лет 10 опыта, чтобы прийти к этим же выводам:

  1. Критическая цепь. Э. Голдратт
  2. Цель. Э. Голдратт
  3. Мифический человеко-месяц или Как создаются программные системы» — книга Фредерика Брукса об управлении проектами в области разработки программного обеспечения, центральной темой которой стало то, что привнесение в проект новых сил на поздних стадиях разработки лишь отодвигает срок сдачи проекта. Эта идея стала известна под названием «закон Брукса».

Совмещение Agile и проекта

Для любителей говорить о Agile проектах, скажу что все верно. Никто не мешает применять Agile внутри проекта.

Для примера можно понаблюдать за тем как идет разработка крупнейшего в мире OpenSource продукта — WordPress. Там в одном проекте задействовано 300+ разработчиков. Примерный срок одного проекта от 3 до 5 месяцев. Но при этом внутри проекта есть итерации типа Agile, которые начинаются с ранних циклов и заканчиваются 2-3 бета релизами и 2-3 релиз кандидатами, после чего идет финальная итерация (релиз).

Но Agile внутри проекта никак не отменяет потребность в детальном ТЗ (прописанном охвате, списке требований), а также в больших подушках на оценку.

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

Гибкая разработка или чистый Agile

Особенности

  1. В отличие от проекта, в чистом Agile ограничение ставится не на конечном сроке результата, а на месячном бюджете, определяется примерный ритм разработки в команде продукта
  2. Продукт описывается в общих чертах, без углубления в детали
  3. Проработка деталей идет в рамках спринта (итерации, шага)
  4. Детальные ТЗ делаются только на ближайший спринт (шаг)
  5. Если допущены ошибки в постановке или появились новые идеи или приоритеты, то в следующем спринте можно быстро без лишних проблем перестроить работу и сменить курс разработки
  6. Конечный результат плохо предсказуем. Можно начать с одной темы, задумать Слоника, а в итоге получить Жирафика. Но в отличие от проекта этот Жирафик будет живым и тем что надо. Потому что Agile гибок и позволяет менять курс по ситуации. Если думали что нужен Слоник, а по ходу поняли что он не нужен, то тут это не проблема. А в проектах это как правило вызывает уйму проблем и может убить проект.
  7. Конечный бюджет плохо предсказуем. Как правило его можно оценить вилкой типа от 50 до 200 тр. А в итоге может получиться хоть 30 тр хоть 300 тр. и все зависит от того на сколько правильно будут ставиться задачи и расставляться приоритеты внутри команды продукта.
  8. Можно расширять Agile более сложными методами типа SCRUM, если того требует качество или по иным причинам. Но эти расширения как правило увеличивают операционные затраты и это тоже нужно понимать.
  9. Agile здорово дружит с Канбан. В разных вариациях.

Назначение

Agile в отличие от проектов может не иметь нижней планки. Он одинакового хорошо подходит для работ с ценой в 10 000 руб или в 10 млн. руб.

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

Мы его применяем даже в очень простых и дешевых сайтах. Мы можем стартануть сайт с прогнозом на 100-200 тр. или на 10-20 тр. и если результат выстрелит, заказчика устроит, то далее продукт докручивается через новые итерации.

Все это делается как чистый Agile (по манифесту) и с Канбан (пока на базе Трелло).

Минусы и проблемы

Часто Agile не позволяет дать точную оценку конечного результата. А заказчику очень хочется. И это конфликт. Тут надо заказчику выбрать, работать по проектам (если есть ресурсы) и там будет оценка за конечный результат. Либо работать по Agile, но конечный результат в этом случае может расплываться и меняться от месяца к месяцу.

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

Проекты внутри Agile

Да, Agile тоже может содержать внутри себя проект. Это если мы под проектом будем иметь ввиду не то что принято в PMBOK, а скажем определение из GTD от Д. Алена. В любом проекте (будь он по PMBOK, или по GTD) есть одно сходство — это срок, требования и стоимость.

Потому мы легко можем рассматривать Agile как некую программу микро-проектов (итераций, спринтов).

Но нужно понимать что итерация в Agile это от 1 до 4 недель. И называть такие мелкие задачи проектами у меня не поворачивается язык. Но если сильно надо, то можно назвать. Никто не умрет.

Резюме

Итак, мы рассмотрели два принципиально разных подхода к разработке ПО:

  1. Разработка продукта как проекта, которые имеют срок, бюджет и детально прописанный результат. Но делаются как правило долго и дорого.
  2. Разработка продукта по Agile, которые не имеют четкого срока и конечного результата, но первый результат можно получить очень быстро с понятным сроком.

Возможно использование Agile внутри проектов, как и наименование проектами спринтов внутри Agile. Все это лишь вопрос используемой терминологии.

И каждый выбирает то что ему подходит.

Если у вас бюджетирование и вам надо результат за бюджет, то вам в проекты. Но это как правило увеличивает цену в 2-3 раза от возможной.

Если вам важен результат, а бюджет можно гибко под него подстроить, то вам в Agile. Фишка в том что тут первые результаты можно получить быстрее, а стоимость может быть в 2-3-10 раз ниже чем у проектов.