Любой IT-компании, которая занимается разработкой программного обеспечения (ПО) на заказ, довольно часто приходится выполнять проекты, в которых инженеры работают на территории заказчика. Это обычно называется работать он-сайт – в офисе клиента. Как правило, такого подхода требуют проекты, где важно, чтобы участники команды могли регулярно общаться с представителями бизнес-подразделений заказчика, разработчиками и руководителем проекта со стороны клиента, либо в проекте используется специфическое аппаратное или программное обеспечение, доступ к которому невозможен (или малоэффективен) из офиса компании-аутсорсера.
В этой серии статей я хотел бы рассмотреть особенности работы инженеров в офисе заказчика и связанные с этим риски, с которыми приходится сталкиваться как заказчикам, так и подрядчикам, а также предложить некоторые способы митигации этих рисков, принятые в Ауриге.
Коммуникации
Работая в офисе клиента, инженерам приходится намного чаще взаимодействовать с различными представителями заказчика – бизнес-пользователями, владельцем продукта, руководителем проекта и другими разработчиками со стороны клиента. Я имею в виду и личное общение, и телефонные звонки, и online-сессии в мессенджерах, и переписку в почте. При этом у инженеров появляется больше самостоятельности при взаимодействии с заказчиком и принятии решений, что, безусловно, способствует развитию их коммуникационных навыков. Однако, с этим могут быть связаны и определенные проблемы. Очевидно, что из-за большого количества митингов с клиентом у инженеров может оставаться меньше времени непосредственно на кодирование. Связана ли эта проблема с проектным риском, который можно нивелировать?
Уменьшить количество времени на митинги с клиентом мы вряд ли сможем в случае, когда инженеры работают в офисе клиента и проект выполняется по процессам заказчика. Более того, многолетний опыт нашей компании свидетельствует в пользу того, что, чем детальнее требования, чем больше проведено промежуточных демо и чем регулярнее обратная связь от заказчика, тем меньше замечаний при сдаче ПО. Поэтому наши руководители проекта всячески стимулируют дополнительные коммуникации инженеров с заказчиками.
Наш совет клиенту: Заложите время на коммуникации при планировании (а лучше напишите коммуникационный план), выделите своего человека (Product Owner или Project Manager), который поможет инженерам подрядчика найти нужную информацию или свяжет с нужными экспертами в компании, установите режим встреч и совещаний, а также круг лиц, которые должны на них присутствовать, ознакомьте инженеров с системой эскалации в вашей компании.
Что это дает? Коммуникации облегчают жизнь, позволяют выявить потенциальные проблемы на ранних стадиях и, в результате, помогают получить качественный продукт в установленные сроки и с меньшим количеством дефектов.
Бизнес-требования
Другая особенность он-сайт проектов связана с тем, что в условиях работы у заказчика изначальные бизнес-требования обычно сформулированы в слишком общем виде, без конкретики и технических деталей, которые помогли бы точно оценить трудозатраты и составить расписание проекта. Как правило, недостаточная четкость требований на старте таких проектов вызывается тем фактом, что инженеры будут работать у заказчика в офисе и он в любой момент сможет обсудить возникающие у них вопросы и уточнить требования с непосредственными исполнителями.
Хотя это, до некоторой степени, может быть удобно самому заказчику, с этим удобством связан реальный риск изменения (усложнения) требований и затягивания сроков сдачи всего проекта. Наша компания выполнила достаточно много он-сайт проектов для заказчиков из разных индустрий, поэтому мы выработали практики и процессы, которые позволяют управлять этим риском:
- При планировании проекта мы обычно закладываем дополнительное время на выяснение с клиентом детальных требований и документирование технических требований силами наших инженеров. Полученный документ описывает требования с точки зрения инженеров-разработчиков и должен быть согласован с клиентом на начальной фазе разработки.
- По результатам всех встреч с представителями заказчика, где обсуждаются технические требования, их изменения, замечания и доработки, мы готовим протоколы и рассылаем их всем участникам проекта.
- В некоторых случаях у заказчика нет достаточной практики в написании подробных технических заданий проекта. Наши эксперты используют и демонстрируют заказчику лучшие примеры описаний технических требований, выполненных ранее в рамках других, успешных проектов.
Наш совет клиенту: Документируйте бизнес-требования заранее – сами или с помощью специалистов, либо привлеките к написанию документа инженеров компании-подрядчика.
Что это дает? С одной стороны, это позволяет сократить время на разработку подробного технического задания, а с другой – поможет вам в будущем описывать требования более понятным для инженеров языком.
В следующей части я рассмотрю такие особенности он-сайт проектов, как работа по процессам клиента и использование IT-инфраструктуры и оборудования заказчика. Следите за обновлениями в блоге Ауриги!
— Александр Плесков, Менеджер проектов, Аурига
