Как на растягивать простые продукты на несколько месяцев.

О модульном подходе к разработке сайтов

Рассказываем о том, как мы применяем со старта гибкие методологии разработки.

Классический подход к разработке продуктов, по крайней мере, в рамках коммуникаций с заказчиком, редко выходит за пределы каскадной модели разработки проекта (или модели водопада).

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


  • бриф;

  • подготовка технического задания;

  • макетирование;

  • дизайн;

  • верстка;

  • бекенд продукта и рендеринг шаблонов.

Даже если компания-подрядчик говорит про Agile, с учетом подобного планирования фактический водопад почти никогда и никуда не девается.

Также, правильный Agile подразумевает непосредственное участие заказчика в коммуникациях и работе с продуктом. В 90% случаев, когда на старте закладывается такая структура работы, в полной мере активной коммуникации не происходит.

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

Классический водопад недостаточно гибок

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

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

Выход из ситуации

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

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

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

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

От такого решения в реализации продукта выигрывают все:


  • снижается порог согласований,

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

  • снижается первоначальная стоимость,

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

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


Если остались вопросы

Свяжемся с вами вотсап.