Если бюджет на проекте вышел за рамки и начинает казаться, что вы переплачиваете за разработку, то, по нашему опыту, проблемы могут возникать из-за:
- плохо проработанных требований и отсутствия четкого плана разработки
- неправильно расставленных приоритетов или неэффективного управления командой
- плохого тестирования и неправильно составленной архитектуры
Давайте более подробно поговорим о каждой из этих проблем.
Требования
Требования - это основа любого проекта. Без них невозможно начать разработку. Но просто наличие требований не гарантирует успешного их выполнения. Если требования плохие – недостаточно ясные или детализированные – это может привести к проблемам на всех этапах проекта.
Проблемы, которые могут возникнуть, если требования плохие:
- Разработчику приходится тратить больше времени на задачи, которые по всем оценками должны быть сделаны за меньший срок
- Множество пересмотров уже выполненных задач из-за несогласия с реализацией со стороны тестировщиков
- Даже если тестировщики приняли задачи, заказчик может потребовать переделок, так как функционал не соответствует его ожиданиям
Как решить:
Если разработка еще не начата, то следует уделить больше времени формированию требований. Если проект уже запущен, а требования оказались неидеальными, нужно начать с их пересмотра.
Важно иметь детальное описание требований с пользовательскими историями и списком всех возможных частных случаев использования функционала. Нужно также описать критерии соответствия, которые покажут, что задача выполнена в соответствии с ожиданиями заказчика. Затем обновить черновой прототип (вайрфрейм/wireframe) или создать его с нуля, если он еще не был сделан.
Только после этого требования можно передавать разработчикам. Такой подход повышает вероятность того, что разработчики сразу правильно реализуют требования и смогут дать более точные оценки.
План разработки
План разработки создается на основе требований. Но иногда его не составляют, потому что кажется, что достаточно пользовательских историй, чтобы разработчик справился.
Проблемы, которые могут возникнуть, если плана нет:
- Неоптимальная последовательность в решении задач, что приведет к ненужным задержкам или переделкам при изменении требований.
- Возможные простои в работе из-за отсутствия необходимых функций; неготовности дизайнов; отпусков разработчиков; или неготовности серверной части, когда уже нужен пользовательский интерфейс
- Нарушение сроков сдачи проекта или, хуже, неопределенность сроков завершения проекта
Как решить:
Менеджер проекта должен составить план разработки с четким описанием каждого этапа, учитывая загруженность команды и необходимость дополнительных ресурсов. Это позволяет предусмотреть отпуска членов команды без ущерба для проекта.
Главное – следить за ходом выполнения плана. Если на разработку функционала было отведено две недели, а результат не готов, можно корректировать процесс.
План разработки также помогает информировать о прогрессе не только заказчика, но и команду, поддерживая мотивацию и боевой дух.
Управление изменениями
В процессе работы над проектом заказчик часто предлагает новые идеи и функции. Однако менеджеру проекта важно уметь оценивать эти изменения и фильтровать их при необходимости.
Проблемы, которые могут возникнуть, если этого не делать:
- Менеджер соглашается на изменения, но не обновляет план разработки и оценки. У заказчика может сложиться впечатление, что стоимость и время разработки никак не изменится.
Как решить:
Менеджеру проекта необходимо адекватно оценивать предложенные изменения заказчика. Прежде всего нужно узнать, точно ли эта функциональность нужна, и дать примерную оценку того, сколько займет её реализация. Если после предварительной оценки заказчик подтверждает необходимость изменений, менеджер должен определить их приоритет.
Если задача имеет высокий приоритет, требуется обновить все требования: детально описать пользовательскую историю, обновить прототип и прописать частные случаи использования функционала. После этого изменения должны пройти тестирование, а разработчики – оценить их реализацию. Затем менеджер проекта сообщает об изменениях клиенту: сколько времени займет разработка новой функции, насколько увеличился бюджет, как сильно сдвинутся сроки релиза. Только после того, как заказчик одобрил изменения, задача попадает в план разработки.
Если проект уже имеет процесс управления изменениями, то проблем с добавлением новых функций, вероятно, не будет. В противном случае, необходимо внедрить процесс управления изменениями, уведомляя клиента о каждом изменении в стоимости и сроках, чтобы отсеивать несущественные задачи.
Подбор и управление командой разработки
Подбор и управление командой разработки - это настоящее искусство. Не всегда необходимо формировать команду из опытных специалистов с многолетним стажем. Например, если проект связан с созданием видеочата, разумнее выбрать разработчика, имеющего опыт работы с видео и соответствующими технологиями. От правильного подбора разработчиков зависит многое.
Проблемы от неправильно собранной команды:
- Появление багов и их постоянное исправление, что приводит к увеличению сроков и стоимости проекта
- Невыполнение разработчиками сроков задач и проекта, даже при минимизации ошибок
- Возможные проблемы с квалификацией разработчиков
Как решить:
Решение не всегда заключается в полной смене команды. Важно также правильно управлять этой командой.
Назначить опытного разработчика в качестве консультанта. Он не является членом команды разработки, но будет привносить “свежий взгляд”: осуществлять ревью кода, следить за архитектурой проекта и выбором технологий. Также в его задачи будет входить обратная связь с менеджером проекта. Если на проекте возникнут проблемы с производительностью, именно опытный разработчик сможет определить их и предложить варианты решения.
Внедрить систему менторинга, как это сделали мы. Для каждого нового сотрудника мы назначаем ментора, который помогает адаптироваться к рабочим процессам, оценивает исходные технические навыки и предлагает план развития для новичка. Менторы также помогают принимать решения о назначении сотрудников на проекты, так как хорошо знают сильные и слабые стороны каждого.
Оптимизировать систему подбора. Более строгий отбор минимизирует риск попадания неквалифицированных сотрудников на проект.
Приоритеты
Чем меньше бюджет проекта, тем важнее тщательно выбирать функции для разработки в первую очередь. Но и при неограниченном бюджете значимость приоритетов не уменьшается.
Проблемы из-за неправильно выставленных приоритетов:
- Команда тратит время на второстепенные задачи, вместо того чтобы завершить ключевые функции. Например, вместо окончания работы над функцией регистрации пользователей, разработчики занимаются внесением косметических изменений.
- Основные функции проекта, делающие его уникальным, не готовы к запланированному релизу.
Как решить:
Часто проблема связана с отсутствием понимания командой того, что действительно важно для бизнеса. В таких случаях необходимо объяснить команде бизнес-цели проекта и ввести систему приоритетов.
Мы пользуемся методом MoSCoW для присвоения приоритетов. Он включает в себя четыре типа приоритетов:
- Приоритет 1 – Must Have требования: минимальный набор функций, без которых запуск продукта невозможен
- Приоритет 2 – Should Have требования: функции, которые так же важны, как и приоритет 1, но разработка которых не такая сочная и может быть отложена
- Приоритет 3 – Could Have требования: функции, которые могут улучшить продукт, но не столь критичны, как приоритеты 1 и 2
- Приоритет 4 – Would Like: функции, которые, скорее всего, не будут включены в финальную версию, но могут быь разрабоатны когда-нибудь в будущем
При разработке системы сначала реализуются задачи первого приоритета, затем второго, третьего и четвертого.
Важно объяснить клиенту разбивку на приоритеты и соотнести его требования с каждым типом. Только после того, как клиент утвердит приоритеты для каждой функции и их соответствие бизнес-целям, начинается разработка.
Тестирование
Тестирование – это важно. Проект, лишенный минимального тестирования, подвергается серьезному риску провала.
Проблемы из-за отсутствия тестирования на проекте:
- Большое количество багов для клиента и для пользователей, что негативно влияет на пользовательский опыт
Как решить:
Решение проблемы заключается во внедрении тестирования, желательно как можно раньше. В идеале, еще на этапе формирования требований. Аналитик и разработчик ищут правильное решение для работы функции. Тестировщик же ищет множество неверных решений: что может пойти не так при использовании продукты пользователями.
В процессе разработки тестировщик ускоряет процесс, выполняя тестирование параллельно с разработкой: как только разработчик закончил задачу, он отдает её тестировщику и приступает к следующей. Это позволяет выявить и исправить ошибки быстрее.
Мы используем автоматизированное тестирование. После завершения задачи разработчик проверяет ее в dev-окружении. Затем задача переходит в тестовое окружение для тщательного тестирования. Если ошибок не обнаружено и задача работает корректно, она может быть отправлена в demo-окружение.
Архитектура
Правильно спланированная архитектура играет ключевую роль в избежании множества проблем, которые могут возникнуть на более поздних этапах разработки: баги, сложности с масштабируемостью, поддержкой и обновлением компонентов. Все эти факторы можно предусмотреть на этапе создания архитектуры, что обходится гораздо дешевле, чем их исправление в уже почти готовом продукте.
Проблемы из-за плохой архитектуры:
- Новые функции и изменения приводят к багам и проблемам
- Систему становится все сложнее поддерживать
Как решить:
Если архитектура изначально оказалась неудачной, переделка её после начала разработки может быть сложной и затратной. В случае стартапа лучше будет доделать и выпустить продукт, как есть. Позже, если продукт станет успешным у пользователей, можно будет выпустить версию 2.0 с улучшенной архитектурой.
Для избежания плохой архитектуры мы используем "защиту архитектуры": детально прорабатываем и описываем предполагаемую архитектуру, затем представляем её опытным разработчикам, не входящим в команду разработки. Они делятся своими замечаниями и предложениями по улучшению. После этого команда обновляет архитектуру и использует её для дальнейшей разработки. Этот процесс минимизирует риски неправильной реализации.
Подводим итоги
Превышение бюджета может быть вызвано множеством причин. У каждого проекта они свои и требуют персонального подхода.
Поэтому если у вас похожие трудности на проекте – мы предлагаем бесплатный аудит системы с подробным отчетом и персональными рекомендациями по решению имеющихся проблем.
Забронируйте звонок или напишите нам
Подробно про аудит системы можно почитать здесь
Комментарии