Клиент & Команда разработки: как бизнес может влиять на результат
Современная разработка давно перестала быть просто процессом написания кода. Текущие реалии показали: чтобы создавать успешные 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). Он занимается не только тестированием функциональности, но и обеспечивает полноценную инфраструктуру для хранения артефактов проекта.
Зоны ответственности QA:
– занимается тестированием функциональности
– обеспечивает полноценную инфраструктуру для хранения артефактов проекта
– подсвечивает технические риски разработки и помогает выявлять недоработки в ТЗ
– Проектный менеджер (далее – ПМ). Он отвечает за соблюдение проектного треугольника (срок, бюджет, содержание). Также ПМ заботится о том, чтобы вся информация от клиента доходила до команды без искажений, а команда своевременно реагировала.
Зоны ответственности ПМ:
– выступает интегратором в команде
– контролирует сроки, бюджет и содержание на проекте– отвечает за выстраивание процесса разработки
– Аналитик. Он не только преобразовывает бизнес-требования в технические задания (ТЗ), но и прорабатывает их, покрывая важные вопросы для первого успешного релиза.
Зоны ответственности аналитика:
– отвечает на вопросы, что система должна сделать и как она это будет делать
– создает и управляет всей структурой документации, отвечает за управление изменениями в требованиях на проекте
– декомпозирует и ставит задачи для разработки, создает спецификации для реализации задач
– взаимодействует со всеми заинтересованными сторонами (ЗС), чтобы учесть все требования: функциональные и нефункциональные, бизнес и системные ограничения, отвечает за воркфлоу согласования требований со всеми ЗС продукта
Это далеко не все специалисты, присутствие которых важно для успешной реализации проекта. ПМ вместе с аналитиком могут предложить заказчику расширить команду: добавить архитектора, DevOps-инженера, специалиста по нагрузочному тестированию, дизайнеров и т.д.
Коммуникации с командой
На первых этапах важно познакомить специалистов с представителями бизнеса и владельцем продукта. Команда должна понимать источники требований, цели разработки IT-решения и портрет конечного пользователя. Впоследствии это поможет расставлять приоритеты, понимать, для чего разрабатывается та или иная фича, улучшать план тестирования и т.п.
Рассмотрим кейс, почему источник требований так важен для команды.
Один из заказчиков рассказал ПМу проекта, что 70% требований идёт со стороны их внутренней службы поддержки, так как пользователь системы – один из крупных банков. Поэтому очень важно было покрыть запросы клиента.
IT-команда моментально отреагировала на данный факт и внедрила удобную систему отслеживания ошибок, чтобы точнее понимать, с какими трудностями сталкиваются пользователи. Более того, ребята предложили устраивать предрелизные демонстрации конечному клиенту, чтобы формировать его ожидания от новых релизов.
Всё это привело к следующим результатам:
– более глубокая аналитика, благодаря пониманию источников требований
– снижение нагрузки на саппорт
– долгосрочное сотрудничество с клиентом
Коммуникации должны быть направлены на снижение рисков, связанных с долгой передачей информации о новых требованиях, изменением сроков или отсутствием обратной связи. Зачастую для этого достаточно общаться с представителями IT-команды, например ПМом, тимлидом или аналитиком – в зависимости от цели созвонов, а также внимательно изучать предоставленные отчеты.
Однако бывает, что бизнес решает усилить контроль за IT-командой, внедряя трекеры отслеживания работы и собирая всех специалистов на многочисленные созвоны без постановки цели. Такой усиленный контроль может негативно влиять на мотивацию, заставлять чувствовать напряженность и тратить рабочее время команды на прослушивание ненужной информации.
Если у бизнеса есть опасения по работе подрядчика и эффективности использования ресурсов, рекомендуем внедрить метрики. ПМ и QA помогут бизнесу определить самые эффективные из них.
Для оценки команды и результатов в реальном времени рекомендуем использовать следующие отчеты:
– Движение по дорожной карте
– Отчет «запланировано/сделано в часах»
– Отчет «план/факт по задачам
– Отчет по качеству продукта
Доверие к команде помогает установить взаимовыгодное сотрудничество и привести к нужным результатам:
- глубже прорабатывать требования
- точнее планировать тестовые сценарии
- вносить улучшения в систему
- грамотно планировать спринты
- анализировать дополнительные проблемы в безопасности и нагрузке
- работать на опережение и помогать бизнесу решать его задачи
Предлагаем воспользоваться нашим чек-листом и проверить, что вы как заказчик передаете всю важную информацию IT-команде, делая ее работу еще более эффективной.
Гибкость разработки
Обеспечение гибкой разработки – это общая работа бизнеса и IT-команды. При быстро меняющихся требованиях не последнюю роль играют коммуникации и скорость поставки новых фич на продакшн.
Так, одному из наших заказчиков в банковской сферы пришла срочная задача от инвесторов – внедрить систему мониторинга передвижения средств. Данный функционал был важен для демонстрации одному из заинтересованных лиц. В результате MVP фичи построили так, чтобы она была привлекательна для инвестора, а к дате релиза реализовали и функциональность для решения бизнес-задач.
Если при разработке не избежать внесения срочных корректировок, важно следовать следующим правилам:
- Новые требования должны быть хорошо определены. Иначе команда потратит драгоценные часы на постоянные уточнения, а функциональность не будет отвечать конечной цели.
- Добавляя срочные задачи на разработку, важно пересмотреть приоритеты всего спринта, а также определиться с задачами, которые на данный момент находятся в разработке, на тестировании или содержат дефекты.
- Спланируйте несколько промежуточных демо для оценки ключевых пользовательских сценариев и своевременной обратной связи.
- После внедрения задачи расскажите об успешности срочной разработки, удалось ли достичь бизнес-цели.
Как мы уже говорили, сейчас IT-команда должна быть интегрирована в бизнес и синхронизирована с его потребностями. И эта задача стоит перед любым высокотехнологичным проектом. Профессиональная IT-команда способна обеспечить развитие и непрерывные улучшения системы, сохраняя актуальность технологий, безопасность данных, высокое качество и успешность продукта.
Инвестируя в проектные процессы, передачу информации и налаженные коммуникации, вы обеспечиваете создание IT-решения, которое будет конкурентоспособным на рынке.
– 3-4 backend-разработчика – 2-3 frontend-разработчика
Ну почему все считают, что кроме сайтов нет больше никакой разработки?
– архитектор– тимлид
Тимлид и архитектор - разные специализации. Тимлид - people manager, а архитектор - технический специалист. Да и зачем тимлид в команде разработки? Там нужен техлид. Собственно и архитектор такой маленькой команде не особо и нужен.
Благодарим за поправку насчет архитектора и тимлида, да, это. безусловно, разные роли. При верстке статьи ,видимо, наложилось.