В предыдущей статье мы обсудили, как важно организовать эффективное взаимодействие со стейкхолдерами на разных этапах заказной разработки ПО.
Теперь наша новая статья сосредотачивается на важности правильного взаимодействия между подрядчиком и заказчиком в самом начале проекта. Мы рассмотрим, какие шаги нужно предпринять, чтобы у обеих сторон сложилось согласованное понимание требований к будущему программному продукту, как выбрать модель разработки и финансовую модель взаимодействия. Будут описаны типичные подходы Ауриги в ситуациях, когда требования к проекту недостаточно определены, слишком общие или отсутствует формальное описание.
До старта проекта
Перед стартом проекта по заказной разработке ПО важно пройти несколько ключевых этапов, обеспечивающих его успешность и удовлетворение потребностей пользователей. Возможно, вы находитесь на стадии согласования технических требований или оценки проекта. Наши рекомендации помогут вам оценить профессионализм вашего подрядчика. Эти рекомендации основаны на стандартном процессе, используемом в Ауриге:
Анализ Потребностей: удостоверьтесь, что подрядчик провел глубокое собеседование с вами для понимания ваших потребностей, целей и ожиданий от продукта.
Идентификация Стейкхолдеров и Пользователей: убедитесь в том, что были определены ключевые стейкхолдеры и конечные пользователи, и учтены их требования и ожидания в проекте.
Согласование Требований: проверьте, что подрядчик детально собрал и документировал все требования к ПО, включая функциональные и нефункциональные аспекты, и согласовал их с вами.
Оценка и Планирование: совместно с подрядчиком проведите оценку предстоящих работ, включая разработку плана действий, выбор технологий, определение рисков, планирование этапов, выделение бюджета и план взаимодействия с ключевыми стейкхолдерами.
Разработка Договора: убедитесь, что все организационные вопросы были согласованы и договор четко определяет обязательства сторон, модель разработки, сроки, этапы, процесс отчетности, условия приемки и оплаты.
Начало Разработки: проверьте, что все предыдущие этапы были завершены перед началом разработки.
Следование этим рекомендациям обеспечит гладкий старт вашего проекта и его успешное выполнение.
Проект пошел не так: наиболее распространенные проблемы
Разберёмся, с какими непредвиденными вызовами вы можете столкнуться на различных этапах проекта, если упустить из виду критически важные моменты, о которых мы упоминали ранее. Вот, с нашей точки зрения наиболее существенные из них.
Разработанный программный продукт не удовлетворяет требованиям конечных пользователей:
На начальной стадии формирования бизнес-требований часто возникает ситуация, когда у заказчика ещё не полностью сформировано видение целей и задач будущего программного продукта, или при составлении документации пропущены ключевые аспекты. Это приводит к тому, что исходные документы, предоставленные заказчиком, могут содержать ошибки или быть неполными. Если до начала проекта не произойдет тщательной проработки и согласования технического задания, в процессе разработки могут возникать ситуации, когда результаты проекта не удовлетворяют заказчика, который, в свою очередь, отказывается принимать и оплачивать выполненные работы.
Мы часто сталкиваемся с ситуациями, когда по различным причинам на начальном этапе проекта невозможно детально проработать все требования. В таких случаях решением становится применение итерационного подхода к разработке, основанного на принципах Agile методологии. Этот подход позволяет гибко адаптироваться к изменениям в требованиях и постепенно совершенствовать продукт, учитывая обратную связь от заказчика
Неэффективное планирование и управление:
Подобные ситуации часто возникают, если до начала проекта не были проработаны основные аспекты взаимодействия, была выбрана не эффективная модель разработки, план работ не учитывал нюансов, связанных с управлением проекта, проектными рисками, либо не все ключевые стейкхолдеры были вовлечены в процесс планирования. В результате это приводит к неэффективному управлению и потере контроля над сроками и бюджетом проекта.
Для примера, допустим, что проект разрабатывается итерационным методом с применением методологии Scrum. Однако на этапе планирования спринта представители конечных пользователей не были вовлечены, и, следовательно, их интересы и требования не были учтены. Это приводит к возникновению проблем и неудовлетворенности на этапе демонстрации результатов спринта, что, в конечном итоге, может вызвать отказ заказчика в приеме результатов работы.
Недостаточная прозрачность и отсутствие обратной связи:
Некоторые подходы к разработке, такие как Agile, акцентируют внимание на тесном взаимодействии с заказчиком и постоянной обратной связи, в то время как другие модели, например, Waterfall, предполагают более ограниченное взаимодействие. Ошибочный выбор модели разработки может привести к недостаточной прозрачности ведения проекта и ограниченной обратной связи между командой разработки и заказчиком.
Компания Аурига сталкивалась с ситуациями, когда наши непосредственные контактные лица на стороне заказчика, такие как владелец продукта или руководитель проекта, не всегда передавали информацию верно и вовремя вышестоящим руководителям и владельцам бюджета, иногда искажая её намеренно или по недоразумению. Поэтому для обеспечения нормального хода проекта и учета интересов всех заинтересованных стейкхолдеров, важно с самого начала устанавливать постоянные коммуникации с вышестоящими руководителями, включая генерального директора и владельцев бюджета.
Давайте приведем ещё один пример. Если на момент старта проекта с заказчиком не были обговорены детали и условия приемо-сдаточных испытаний, и процесс не был согласован со всеми ключевыми стейкхолдерами, это как правило, приводит к затяжным и непредсказуемым этапам приемки результатов проекта, что, в конечном итоге, отражается на сроках и бюджете проекта.
Невозможность адаптации к изменениям:
Практика показывает, что в процессе выполнения проекта у заказчика могут возникать новые потребности и требования, которые изначально было сложно предсказать. В начале проекта невозможно с полной уверенностью определить, какие дополнительные функции будут необходимы. Методологии разработки, основанные на Agile (например, Scrum и Kanban), оказываются более гибкими и способствуют успешной адаптации к изменяющимся требованиям заказчика. В случае выбора каскадной или итерационной модели разработки в начале проекта процесс внесения изменений в требования может быть менее гибким и потребует дополнительных временных и финансовых ресурсов.
Аурига: наш подход
Давайте рассмотрим несколько типовых подходов, которые компания Аурига предлагает своим клиентам для эффективного управления проектами и снижения рисков.
Анализ и Уточнение Требований:
Один из ключевых подходов заключается в проведении на предварительном этапе дополнительного анализа и уточнения требований, особенно если исходные бизнес-требования недостаточно детализированы. На этом этапе системный аналитик Ауриги совместно с ключевыми стейкхолдерами разрабатывает частное техническое задание (ЧТЗ). Это позволяет убедиться в полном понимании требований и согласовать их с заказчиком. После этого производится переоценка трудозатрат и бюджета проекта, и готовится уточненное технико-коммерческое предложение (ТКП).
Итерационный Agile Подход:
Второй подход основывается на разработке ТКП на основе верхне-уровневого описания бизнес-требований (CRS), предоставленного заказчиком. Здесь предлагается выполнять проект итерационно с использованием Agile методологии, такой как Scrum или Kanban, и финансовой модели Time & Material. Это обеспечивает гибкость в адаптации к изменяющимся требованиям заказчика, и заказчик регулярно получает промежуточные результаты проекта для уверенности в соответствии с его ожиданиями.
Разработка Бизнес-Требований «С Нуля»:
Ещё один интересный подход предлагает Аурига клиентам, у которых нет формальных требований к будущему ПО, но есть определенные потребности и проблемы. На этом этапе представитель компании (менеджер продуктов или бизнес-аналитик) общается с ключевыми стейкхолдерами, выявляет их боли, проблемы и задачи, и разрабатывает начальную версию CRS (customer requirement specification). Этот документ затем подвергается нескольким итерациям ревью со всеми заинтересованными сторонами, и после согласования используется для разработки ЧТЗ. Процесс включает активное взаимодействие с заказчиком и учет всех пожеланий и потребностей клиента.
Эти подходы позволяют Ауриге успешно управлять проектами, адаптироваться к изменяющимся требованиям и удовлетворять потребности клиентов на разных этапах проектов.
Заключение
В данной статье мы детально рассмотрели важные аспекты организации взаимодействия между подрядчиком и заказчиком перед стартом проекта по разработке ПО на заказ. Мы выявили несколько ключевых шагов, которые являются основой для успешного выполнения проекта. Также мы рассмотрели примеры типовых подходов к управлению проектами, включая подробный анализ требований, использование Agile методологии и гибких финансовых моделей. Эти подходы позволяют адаптироваться к изменяющимся требованиям заказчика и обеспечивать прозрачность ведения проекта.
В заключение, следует подчеркнуть, что компания Аурига всегда стремится к индивидуальному подходу к каждому клиенту, предлагая оптимальные решения для успешной реализации проектов. Наша цель — разработка программных продуктов, которые в полной мере удовлетворяют запросам пользователей и достигают поставленных целей.