Как заказчику работать с внешней командой разработки

Последнее время с завидной регулярностью убеждаюсь в том, что культура заказа разработки у внешних команд не только в России, но и в других странах отсутствует напрочь. За последние 2 недели к нам в Progress Engine пришли 2 компании, которые не только не имели доступа к тому, за что они заплатили, но и более того — не имели ни малейшего понятия о том, что и когда им должны были отдать аутсорсеры. В связи с этим решил написать краткий гайд для наших (и не только наших) клиентов, чтобы они чётко понимали за что они платят, что они должны получить в итоге и как организовать все процессы разработки и внедрения нового продукта. Несмотря на то, что некоторые вещи могут показаться кому-то очевидными — мне встречаются люди, которые про них даже не слышали.

Хочу развеять один популярный стереотип, который звучит как “клиент всегда прав”. Некоторые заказчики мотивируют его тем, что они платят деньги и имеют полное право на то, чтобы любое их решение считалось единственно верным и не требовало обсуждения. К сожалению — это не так. Как клиент вы точно также заинтересованы в разработанном продукте, как и разработчик — в вашем заказе. Любая из сторон имеет полное право выйти из контракта, если его что-то не устраивает и если заказчик начнёт вести себя как мудак, то адекватным исполнителям ничего не останется кроме как прекратить сотрудничество. В таком случае клиенту придётся искать других разработчиков, уедут сроки, будут потрачены лишние деньги и так далее. Вы в этом заинтересованы? Уверен, что нет.

Все знают, но мало кто делает, но на каждый чих надо подписывать документы. Я не устаю это повторять. Должен быть договор, перечень работ, техническое задание, счёт на оплату и акт. В ряде случаев было бы неплохо подписать NDA, но в России его применимость под очень большим вопросом.

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

Я встречал разные договоры, самые интересные наблюдения из того, что я видел:

Один из первых вопросов, который задают нам “А у вас есть бриф для заполнения?” или “В каком формате присылать ТЗ?”. В разных компаниях подходы разные, но в большинстве своём компании-аутсорсеры не думают над тем, кто и как будет пользоваться продуктом, сваливая ответственность за неудачные продуктовые решения на заказчика. Мы в Progress Engine пошли другим путём — под каждый проект выделяется свой продукт-менеджер, который помогает клиенту понять, что он хочет, как и кто будет этим продуктом пользоваться. Если мы видим, что клиент не совсем корректно формулирует требования к продукту – мы стараемся ему помочь, отталкиваясь от нашего опыта и опыта коллег по рынку. Если же разработчики не участвуют в анализе продукта и не подвергают критике каждое некорректное решение заказчика, то это – халтурная работа.

Идеальный вариант перед началом работ заказать продуктовую аналитику у тех, кто в этом специализируется. Результатом будут:

На предыдущем этапе мы определились с роадмапом. Теперь нам важно выстроить таким образом процесс разработки, чтобы она шла максимально эффективно. Пара ключевых моментов: