02 марта 2023

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

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

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

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

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

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

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

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

схема.jpg

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

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

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

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

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

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

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

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

    Зоны ответственности QA:

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

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

    Зоны ответственности ПМ:

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

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

    Зоны ответственности аналитика:

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

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

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

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

 galina.png

Галина, руководитель отдела QA: 
«Рассмотрим кейс, почему источник требований так важен для команды. Один из заказчиков рассказал ПМу проекта, что 70% требований идёт со стороны их внутренней службы поддержки, так как пользователь системы – один из крупных банков. Поэтому очень важно было покрыть запросы клиента. IT-команда моментально отреагировала на данный факт и внедрила удобную систему отслеживания ошибок, чтобы точнее понимать, с какими трудностями сталкиваются пользователи. Более того, ребята предложили устраивать предрелизные демонстрации конечному клиенту, чтобы формировать его ожидания от новых релизов.
Всё это привело к следующим результатам:
— более глубокая аналитика, благодаря пониманию источников требований
— снижение нагрузки на саппорт
— долгосрочное сотрудничество с клиентом».

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

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

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

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

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

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

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

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

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

 galina.png

Галина, руководитель отдела QA: 
«Так, одному из наших заказчиков в банковской сферы пришла срочная задача от инвесторов – внедрить систему мониторинга передвижения средств. Данный функционал был важен для демонстрации одному из заинтересованных лиц. В результате MVP фичи построили так, чтобы она была привлекательна для инвестора, а к дате релиза реализовали и функциональность для решения бизнес-задач».

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

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

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

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

Если остались вопросы, напишите нам в ВК или Telegram. Больше кейсов – здесь.

Галина
Руководитель отдела QA
Понравилась статья?
Подпишитесь на рассылку SimbirSoft! Пришлём письма о лайфхаках в разработке, поделимся опытом управления командами и компанией, а также расскажем о новых ивентах SimbirSoft.

Другие статьи

Вебинар «Красиво vs Качественно. Какие метрики вашего бизнеса зависят от Frontend-разработки?»
12 марта 2024
На форуме Seymartec Energy эксперты SimbirSoft поделятся опытом использовании ИИ в энергетике
07 марта 2024
WMS для управления складом: что такое и как выбрать
07 марта 2024
Написать нам
Оставьте контакты, чтобы обсудить проект и условия
сотрудничества, или позвоните: 8 800 200-99-24
Прикрепить файл до 10Мб
Файл выбран
Можно прикрепить один файл в формате: txt, doc, docx, odt, xls, xlsx, pdf, jpg, jpeg, png.

Размер файла до 10 Мб.
Оставьте свои контакты
SimbirSoft регулярно расширяет штат сотрудников.
Отправьте контакты, чтобы обсудить условия сотрудничества.
Прикрепить резюме, до 10 Мб
Файл выбран
Можно прикрепить один файл в формате: txt, doc, docx, odt, xls, xlsx, pdf, jpg, jpeg, png.

Размер файла до 10 Мб.
Написать нам
Расскажите, какие задачи сейчас на вашем проекте.
Проконсультируем и предложим подходящих специалистов, а также сориентируем по ставкам на аутстаф.
Направление
Количество специалистов
Middle
TeamLead
Senior
TechLead
Прикрепить файл до 10Мб
Файл выбран
Можно прикрепить один файл в формате: txt, doc, docx, odt, xls, xlsx, pdf, jpg, jpeg, png.

Размер файла до 10 Мб.
Экспресс-консультация
Заполните все поля формы.
Эксперт свяжется с вами в течение рабочего дня.
Тематика
Прикрепить файл до 10Мб
Файл выбран
Можно прикрепить один файл в формате: txt, doc, docx, odt, xls, xlsx, pdf, jpg, jpeg, png.

Размер файла до 10 Мб.
Порекомендуйте друга — получите вознаграждение!
  • Middle Fullstack QA Engineer (Mobile)
  • Python-paзработчик
  • Java-разработчик
  • Angular-разработчик
  • Аккаунт-менеджер IT-проектов
  • Системный аналитик
  • QA Engineer Fullstack (Python)
  • C#-разработчик
  • Инженер по нагрузочному тестированию
  • Golang-разработчик
  • DevOps-инженер
  • 1С-аналитик
  • 1C QA Engineer
  • Юрист
  • Разработчик на C++
  • 1С-разработчик
  • DWH-разработчик
  • Разработчик Bitrix24
  • Data Scientist
  • Маркетолог
  • Менеджер по продажам IT SaaS
  • QA Engineer Fullstack (Java/Kotlin)
  • C# /.NET-разработчик
  • Бизнес-аналитик
  • Аналитик DWH
  • Team Lead Java
  • Специалист по адаптации персонала
  • Менеджер проектов 1С
  • Vue-разработчик
  • Руководитель отдела Backend
  • SDET (Java)
  • Менеджер по продажам IT продуктов на иностранное направление
  • Менеджер по продажам IT продуктов
  • Team Lead Python
  • SAP-аналитик
Прикрепить резюме, до 10Мб
Файл выбран
Можно прикрепить один файл в формате: txt, doc, docx, odt, xls, xlsx, pdf, jpg, jpeg, png.

Размер файла до 10 Мб.