AppTractor

Приложение на заказ: как заказчику работать с внешней командой

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

Клиент не всегда прав

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

Приложение на заказ: Работа с документами

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

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

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

Приложение на заказ: Работа над продуктом и ТЗ

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

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

Приложение на заказ: Разработка

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

TL;DR или итоговый чеклист

Если у вас есть сомнения в ваших разработчиках — приходите к нам в Progress Engine!

Exit mobile version