Разработка ПО с жёсткими ограничениями бюджета

Есть множество проектов, в которых нужно разработать какое-либо ПО с жёсткими ограничениями по бюджету. Хочу поделиться своим методом работы с такими проектами.

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

Сразу уточню границы. Речь не о ситуации, когда денег нет совсем, а о проекте, на который есть примерно 60–70% от необходимой суммы. Размер возможной экономии сильно зависит от квалификации техлида проекта. Также рассказ будет о создании чего-то нового, когда нельзя просто переиспользовать предыдущий опыт и готовые наработки. Не все описанные шаги нужны для каждого проекта, но пропускать их стоит осознанно, а не потому, что на них якобы нет денег.

Что нам нужно для начала работы

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

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

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

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

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

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

На этом этапе важно отделить необходимый функционал от желательного. Всё второстепенное по возможности откладываем на следующий этап.

Если в команде нет системного аналитика, его можно привлечь временно — именно для сбора и структурирования требований. Держать специалиста на протяжении всего проекта не всегда нужно, но полностью исключать аналитическую работу нельзя: кто-то всё равно должен превратить пожелания заказчика в понятную и проверяемую постановку.

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

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

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

Чеклист: что важно на этом этапе

• Сформирована рабочая группа, а представитель заказчика имеет полномочия утверждать требования.
• Основные пользовательские сценарии согласованы, а спорные вопросы либо закрыты, либо явно зафиксированы.
• Обязательный функционал отделён от второстепенного, который можно перенести на следующий этап.
• Подготовлены мокапы интерфейса и определены требования ко всем обязательным интеграциям.
• Назначен ответственный за аналитику, даже если системный аналитик привлекается только временно.

Выделяем основные элементы архитектуры

На основе уточнённых требований проводим первичное проектирование системы. Этот этап можно назвать R&D проекта. Здесь важно определиться с фундаментом системы и точно понять, какие технологии и каким образом позволят достичь целей проекта.

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

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

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

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

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

Лучше сейчас реализовать рискованное место силами одного разработчика и набить шишки, чем получить задержку, когда простаивает команда из нескольких человек.

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

На этапе R&D вся будущая команда не нужна. Это один из основных способов экономии ресурсов: специалисты подключаются только тогда, когда для них уже есть подготовленный объём работ. До завершения исследования достаточно небольшой группы, которая способна уточнить требования, выбрать архитектуру и проверить ключевые технические решения. Остальных участников привлекаем позже, под конкретные вехи.

Чеклист: что важно на этом этапе

• Стек выбран с учётом опыта команды, ограничений инфраструктуры и стоимости дальнейшей поддержки.
• Определены технические решения, которые могут сломать архитектуру или существенно изменить оценку.
• Все рискованные решения проверены на прототипах, а не только обсуждены теоретически.
• После прототипирования проведено повторное уточнение требований и принципов реализации.
• В R&D участвует только необходимая группа специалистов, а остальная команда не подключается раньше времени.

Планирование разработки

Подготовка к планированию

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

1. Пользовательский интерфейс.
2. Слой исполнения бизнес-логики — API.
3. Слой поддержки — фоновые обработчики и интеграции.
4. Инфраструктура — развёртывание сред исполнения и сопровождающие процессы.

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

Далее определяем минимальное количество разработчиков, тестировщиков и DevOps-специалистов с учётом болезней и отпусков, а также необходимую квалификацию. В основную команду для таких проектов я стараюсь брать middle-специалистов. Они могут самостоятельно решать типовые задачи, но при этом не требуют бюджета команды, состоящей только из senior-разработчиков. Ключевые архитектурные решения и контроль качества в этом случае остаются на техлиде.

Планирование

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

Очерёдность подключения может быть следующей:

1. Первыми задействуем DevOps и разработчиков, занимающихся бизнес-логикой. Они готовят окружение, основные модели данных, API и технический каркас системы.
2. Затем подключаем разработку интерфейса и слоя поддержки. К этому моменту уже есть мокапы, согласованные сценарии и понятные точки интеграции.
3. Тестировщиков подключаем тогда, когда появляется достаточный объём готового функционала, — если проект может позволить отдельных специалистов.

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

Чеклист: что важно на этом этапе

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

Управление командой

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

Пока разработчики не знакомы с проектом, нужно собирать их вместе на короткие ежедневные встречи и ставить задачи максимально точно. Для backend-разработчика лучше подготовить полное описание алгоритма: входные и выходные данные, правила обработки, исключительные ситуации и критерии приёмки. Для frontend-разработчика удобнее использовать пользовательские сценарии, мокапы и flow действий пользователя, включая состояния загрузки, ошибок и пустых данных.

Такое разделение связано с самой природой работы. Backend-разработчику обычно важнее точный алгоритм и граничные условия, а frontend-разработчику — последовательность действий пользователя и визуальные состояния интерфейса. Это не жёсткое правило, но такой формат постановки сокращает количество уточняющих вопросов.

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

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

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

Сразу делайте логирование в несколько уровней — DEBUG, INFO и ERROR. Это упрощает отладку и уменьшает время разработки. Middle-разработчики иногда этим пренебрегают, особенно если раньше не работали в крупных компаниях с утверждённым SLA по устранению ошибок. Но когда система уже развёрнута у заказчика, нормальные логи часто оказываются единственным способом быстро понять, что произошло.

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

Чеклист: что важно на этом этапе

• В каждой задаче описаны ожидаемый результат и критерии приёмки.
• Формат постановки учитывает специфику backend- и frontend-разработки.
• Все важные устные договорённости зафиксированы письменно.
• Ошибки сгруппированы по приоритету, а для их исправления назначены конкретные сроки.
• Настроено многоуровневое логирование, а критичная бизнес-логика покрыта unit-тестами.

Как использовать Scrum

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

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

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

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

Чеклист: что важно на этом этапе

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

Тестирование и приёмка

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

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

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

Чеклист: что важно на этом этапе

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

DevOps без отдельной большой команды

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

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

Чеклист: что важно на этом этапе

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

Два основных этапа

Фактически описанный подход сводится к двум основным этапам.

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

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

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

Чеклист: что важно на этом этапе

• Массовая разработка начинается только после завершения основных аналитических и R&D-работ.
• Требования, архитектура и способ реализации согласованы с заказчиком и командой.
• Основные технические риски проверены до подключения всей команды.
• Специалисты подключаются поэтапно и получают точно поставленные задачи.
• Техлид имеет достаточную квалификацию и временной ресурс для совмещения ключевых ролей.

Вывод

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

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

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

Этот метод не заменит нормальное финансирование крупного проекта и не позволит разработать сложную систему совсем без денег. Но для небольшого проекта с бюджетом на уровне 60–70% от необходимого он даёт шанс получить работающее решение без критической потери качества. Главное — заранее признать ограничения и строить процесс разработки с учётом их, а не надеяться, что проблема решится сама собой ближе к сдаче.