Клиент & Команда разработки: как бизнес может влиять на результат

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

Какие шаги предпринять заказчикам, чтобы на выходе получить эффективный, постоянно развивающийся продукт, отвечающий всем требованиям рынка? Как настроить взаимодействие с командой и почему так важно доверять тем, с кем работаете? Подробнее об этом руководитель QA-отдела SimbirSoft Галина Яшина рассказывала на недавней конференции IFin-2023. В статье приведем основные моменты.

Чтобы ответить на поставленные вопросы, рассмотрим следующие аспекты разработки.

Риски на проекте

Чаще всего на разработку продукта влияют.

• Bus factor (риски, возникающие при временном или постоянном отсутствии любого из членов команды). Характерны для сложных длительных проектов, когда информации становится много. При этом важные данные хранятся в головах главных аналитиков и разработчиков, уход которых может стать катастрофой для всего проекта.
• Неполная команда на старте. Может привести к непроработанным требованиям и отсутствию инфраструктуры для тестирования и хранения информации о проекте.
• Отсутствие коммуникаций между бизнесом и IT-командой: несвоевременная обратная связь команде, отсутствие понимания целей проекта, проблемы в коммуникациях, избыточный контроль. В итоге разработка тратит время на низкоприоритетные задачи и не знает о потребностях бизнеса, что может отразиться на качестве IT-решения.
• Часто меняющиеся требования к IT-продукту. Постоянное изменение требований, добавление новых задач в спринт, изменение приоритетов – все это влияет на время и бюджет разработки.

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

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

Продуктивная команда

Правильный состав команды поможет снизить сразу ряд вышеупомянутых рисков.

На примере MVP-разработки рассмотрим, как может выглядеть команда проекта:

• проектный менеджер
• 2 аналитика
• SDET
• архитектор
• тимлид
• 3-4 backend-разработчика
• 2-3 frontend-разработчика
• 2-3 QA-инженера во главе с QA-лидом

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

Помимо разработчиков, мы рекомендуем включать следующие роли:

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

• занимается тестированием функциональности
• обеспечивает полноценную инфраструктуру для хранения артефактов проекта
• подсвечивает технические риски разработки и помогает выявлять недоработки в ТЗ

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

• выступает интегратором в команде
• контролирует сроки, бюджет и содержание на проекте
• отвечает за выстраивание процесса разработки

— Аналитик. Он не только преобразовывает бизнес-требования в технические задания (ТЗ), но и прорабатывает их, покрывая важные вопросы для первого успешного релиза.

• отвечает на вопросы, что система должна сделать и как она это будет делать
• создает и управляет всей структурой документации, отвечает за управление изменениями в требованиях на проекте
• декомпозирует и ставит задачи для разработки, создает спецификации для реализации задач
• взаимодействует со всеми заинтересованными сторонами (ЗС), чтобы учесть все требования: функциональные и нефункциональные, бизнес и системные ограничения, отвечает за воркфлоу согласования требований со всеми ЗС продукта

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

Коммуникации с командой

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

Коммуникации должны быть направлены на снижение рисков, связанных с долгой передачей информации о новых требованиях, изменением сроков или отсутствием обратной связи. Зачастую для этого достаточно общаться с представителями IT-команды, например ПМом, тимлидом или аналитиком – в зависимости от цели созвонов, а также внимательно изучать предоставленные отчеты.

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

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

Для оценки команды и результатов в реальном времени рекомендуем использовать следующие отчеты:
— Движение по дорожной карте
— Отчет «запланировано/сделано в часах»
— Отчет «план/факт по задачам
— Отчет по качеству продукта

Доверие к команде помогает установить взаимовыгодное сотрудничество и привести к нужным результатам:

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

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

Гибкость разработки

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

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

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

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

Инвестируя в проектные процессы, передачу информации и налаженные коммуникации, вы обеспечиваете создание IT-решения, которое будет конкурентоспособным на рынке.