Требования в аутсорсинговых проектах

Главные идеи#

Чем отличаются такие проекты#

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

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

Требования — это контракт#

Заказчик выпускает запрос предложений (RFP) со спецификацией требований и критериями приёмки; поставщик оценивает работу, и стороны договариваются; поставщик создаёт и передаёт ПО и документацию. Без ежедневного контакта подрядчик не реализует требования, которые вам казались слишком очевидными, чтобы их записывать. Поэтому разрабатывайте требования раньше по графику и подробнее. Тщательность, которая внутри компании могла бы показаться избыточной, здесь становится достоинством.

Чтобы смысл дошёл#

• Визуальные модели преодолевают языковые барьеры и позволяют разработчикам проверить своё толкование, но только если подрядчик знает нотацию.
• Неоднозначные слова вроде «поддерживать» (support) вызывают настоящую путаницу, когда работа идёт на разных языках. Авторы описывают проект, где именно это слово её и вызвало. Избегайте также идиом, жаргона и культурных отсылок, явно указывайте форматы дат, единицы измерения и порядок частей имени.
• Для требований к качеству авторы советуют Planguage — структурированную нотацию для их точной формулировки.

Совместная работа#

• Запланируйте несколько циклов ревью. В некоторых культурах рецензенты избегают открыто критиковать чужую работу; выясните это заранее и скорректируйте подход.
• Авторы описывают провальный проект: в плане была неделя семинаров по требованиям, но не было времени на то, чтобы документировать, проверить и доработать спецификацию. При медленной связи на большом расстоянии график рухнул, а спор дошёл до суда.
• Поставляйте небольшими инкрементами, чтобы недопонимание всплывало рано.
• Записывайте каждый вопрос подрядчика и ответ на него в требования, в системе, доступной обеим сторонам.
• Некоторые поставщики соглашаются на невозможное, чтобы угодить заказчику, или стесняются сказать «я не понимаю». Задавайте открытые вопросы и договоритесь о явных правилах взаимодействия.
• Распределите нагрузку: заказчик предоставляет полную информацию, поставщик спрашивает, а не додумывает.
• Авторы описывают и офшорную команду, которая реализовывала каждое требование буквально, по одному, не понимая целого. В итоге заказчику пришлось самому переделать большую часть работы.

Изменения и приёмка#

Используйте единый процесс изменений и общие инструменты для запросов на изменение и дефектов, где бы ни находились участники. В контракте должно быть указано, кто платит за какой вид изменений: за новую функциональность или за исправления исходных требований. Определите критерии приёмки и включите их в RFP («начинайте, представляя конечную цель», как говорит Кови), а требования утвердите до передачи.

Проведение тендера#

Курс Корнипаева описывает сторону заказчика. Организации проводят тендер, когда им не хватает мощностей или экспертизы или когда привлекательным выглядит готовый продукт. Этапы: изучение рынка → запрос информации (RFI) → RFP → решение.

Со стороны участника тендера Корнипаев отмечает риск: вопросы, заданные во время тендера, могут дойти до конкурентов. Участник может не обращать внимания на проблему, сделать задокументированное допущение или всё-таки спросить. Участникам стоит сохранять все материалы тендера, включая допущения и незаданные вопросы: подписание контракта может затянуться, а проектная команда часто не совпадает с той, что готовила заявку.