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

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

Давайте подробнее разберём каждую из этих проблем.

Требования

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

Проблемы, которые могут возникнуть при плохих требованиях:
  • Разработчику приходится тратить больше времени на задачи, которые по оценкам должны выполняться быстрее
  • Множество пересмотров уже выполненных задач из-за несогласия тестировщиков с реализацией
  • Даже если тестировщики приняли задачи, заказчик может потребовать переделок, потому что функционал не соответствует его ожиданиям
Как решить:

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

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

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

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

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

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

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

Главное — следить за ходом выполнения плана. Если на разработку функционала было отведено две недели, а результат не готов, процесс можно скорректировать.

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

Управление изменениями

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

Что может пойти не так, если этого не делать:
  • Менеджер соглашается на изменения, но не обновляет план разработки и оценки. Заказчик может подумать, что стоимость и сроки разработки останутся прежними.
Как решить: 

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

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

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

Подбор и управление командой разработки

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

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

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

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

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

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

Приоритеты

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

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

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

Мы используем метод MoSCoW для определения приоритетов. Он включает четыре уровня приоритетов:

  • Приоритет 1 – Must Have требования: минимальный набор функций, без которых запуск продукта невозможен
  • Приоритет 2 – требования «Should Have»: функции, которые так же важны, как и приоритет 1, но разработка которых менее срочная и может быть отложена
  • Приоритет 3 – требования типа «Could Have»: функции, которые могут улучшить продукт, но не так важны, как приоритеты 1 и 2
  • Приоритет 4 – Would Like: функции, которые, скорее всего, не попадут в финальную версию, но могут быть реализованы в будущем

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

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

Тестирование

Тестирование — это важно. Проект без минимального тестирования сильно рискует провалиться.

Проблемы из-за отсутствия тестирования на проекте:
  • Большое количество багов у клиента и у пользователей, что негативно сказывается на пользовательском опыте
Как решить:

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

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

Мы используем автоматизированное тестирование. После завершения задачи разработчик проверяет её в dev-окружении. Затем задача переходит в тестовое окружение для тщательного тестирования. Если ошибок не обнаружено и задача работает корректно, её можно отправить в demo-окружение.

Архитектура

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

Проблемы из-за плохой архитектуры:
  • Новые функции и изменения могут вызывать баги и проблемы
  • Систему становится всё сложнее поддерживать
Как решить:

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

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

Подводим итоги

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

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

Забронируйте звонок или напишите нам

Подробно про аудит системы можно почитать здесь

  • Вопросы клиентов