Работа в офисе клиента: Коммуникации и бизнес-требования

Статьи

Работа в офисе клиента: Коммуникации и бизнес-требования

Ноябрь 20, 2018

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

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

Коммуникации

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

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

Наш совет клиенту: Заложите время на коммуникации при планировании (а лучше напишите коммуникационный план), выделите своего человека (Product Owner или Project Manager), который поможет инженерам подрядчика найти нужную информацию или свяжет с нужными экспертами в компании, установите режим встреч и совещаний, а также круг лиц, которые должны на них присутствовать, ознакомьте инженеров с системой эскалации в вашей компании.

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

Бизнес-требования

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

Хотя это, до некоторой степени, может быть удобно самому заказчику, с этим удобством связан реальный риск изменения (усложнения) требований и затягивания сроков сдачи всего проекта. Наша компания выполнила достаточно много он-сайт проектов для заказчиков из разных индустрий, поэтому мы выработали практики и процессы, которые позволяют управлять этим риском:

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

Наш совет клиенту: Документируйте бизнес-требования заранее – сами или с помощью специалистов, либо привлеките к написанию документа инженеров компании-подрядчика.

Что это дает? С одной стороны, это позволяет сократить время на разработку подробного технического задания, а с другой – поможет вам в будущем описывать требования более понятным для инженеров языком.

В следующей части я рассмотрю такие особенности он-сайт проектов, как работа по процессам клиента и использование IT-инфраструктуры и оборудования заказчика. Следите за обновлениями в блоге Ауриги!

— Александр Плесков, Менеджер проектов, Аурига

Похожие новости

Новости

Пять достижений Ауриги в 2018 году

Пять достижений Ауриги в 2018 году

Начало нового года – волшебная пора, когда люди загадывают желания и строят планы на будущее. Вместе с тем, это самое время остановиться и обернуться на

С Новым Годом и Рождеством!

Поздравляем Вас с Новым Годом и Рождеством! Пусть в наступающем 2019 году Вам сопутствует неиссякаемая удача и впечатляющие достижения! Самые теплые пожелания счастья и благополучия...

Auriga Baltics вновь получила сертификат “The Strongest in Lithuania”

Auriga Baltics, инженерный центр Ауриги в Вильнюсе, снова получил сертификат «The Strongest in Lithuania». Вот уже в третий раз Auriga Baltics признана одной из наиболее...

Признанный лидер услуг по разработке ПО:
управление командами и проектами;
разработка новых продуктов, сопровождение, тестирование