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

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

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

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

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

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

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

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

• Договор, составленный из копипаста статей ГК РФ. Таким образом договор не защищал никого (ни разработчика, ни заказчика), более того — юридически было возможно разработчику получить предоплату и ничего не делать, а заказчик отправлял бы правки, которые можно было отвергать, ссылаясь на недостаток информации. Не имея возможности изменить этот договор (юристы компании тупо отказались его править) нам пришлось отказаться от этого клиента, хотя проект был достаточно интересный
• Договор, по которому заказчик имеет право в одностороннем порядке уменьшить стоимость работ. Вот тут признаюсь честно — я налетел на грабли. Нам повезло, что стоимость контракта была небольшой, но из-за того, что на стороне заказчика был далеко не самый профессиональный менеджер — нам затянули сроки с предоставлением информации и в результате чего мы сорвали сроки и пришлось вернуть предоплату (согласно договору они уменьшили его стоимость. Позже я обсудил с другим юристом — технически мы могли отказаться от возврата)
• Договор с нереальными сроками, но с “вкусным” ценником. Ну тут комментарии излишни — вписываться в такой проект, когда ты рискуешь влететь на штрафы вменяемый человек не захочет. Мы отказали этому клиенту.
• Договор, в котором права на выполненные работы остались у разработчиков. Помните — вы платите за то, что продукт пишется ДЛЯ ВАС. Эта компания потом конкурировала с аутсорсерами, которые получили деньги за то, что писали клиенту код.

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

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

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

• Техническое задание — описание того, что вы получите и по которому разработчики будут делать приложение на заказ
• Дорожная карта (Roadmap) — планирование этапов разработки
• Декомпозиция проекта по задачам с приблизительной оценкой стоимости каждого этапа (это позволит улучшить планирование бюджета разработки)
• Интерактивный прототип, с помощью которого вы сможете заранее пощупать ваш продукт

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

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

• В идеале на вашей стороне должен быть хоть один человек, разбирающийся в технологической части проекта. Не обязательно крутой разработчик, но опыт управления проектами и знание используемого стека технологий у него быть должны
• Раз в неделю необходимо созваниваться с разработчиками и получать статус и давать обратную связь.
• Раз в неделю или максимум раз в 2 недели разработчики должны закрывать очередной этап разработки. Итогом будет работающий продукт с определёнными заранее функциями.
• Весь код должен быть регулярно передан вам, например отправлен в ваш репозитарий на GitHub
• У вас должно быть как минимум 3 окружения (проще говоря — сервера). Development — окружение, где будут “резвиться” разработчики. Staging — на котором вы как заказчик будете принимать работы. Production — боевое окружение, к которому имеют доступ ваши пользователи.
• После завершения каждого этапа (спринта) у вас должен быть подписан акт, что вы не имеете претензий к разработчикам, а они передают вам исключительные права на код

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

• Выбирать разработчиков, отталкиваясь не от цены, а от качества предоставляемых ими услуг. В ряде случаев имеет смысл работать с ними по схеме time and material (почасовая оплата) — вы оплачиваете только то время, которое они выработали и имеете возможность гибко управлять объёмом работы
• Выбирать разработчика, которые будут думать с вами о том, как пользователи будут использовать этот продукт и будут советовать как его улучшить. Качество советов определяет ценность разработчиков.
• Подписать рамочный договор, защищающий интересы обеих сторон
• Подписать приложение к рамочному договору, в котором чётко прописаны работы, их стоимость и критерии приёмки
• Проверить, что все права на выполненные работы принадлежат вам и это прописано в договоре
• Разбить работы на этапы, определить стоимость каждого этапа
• Проводить оплату работ не единоразовым платежом, а оплачивать каждый этап. Это позволит вам быстро сменить разработчика в случае проблем с ним, а он не будет расслабляться, зная, что у него все деньги уже на счету и можно работать расслабленно.
• Проведите продуктовое исследование. На выходе вы получите ТЗ, Roadmap, декомпозицию с предварительной оценкой стоимости и интерактивный прототип
• Все заведённые для проекта аккаунты должны быть оформлены на вашу компанию — почтовые ящики в вашем домене, оплата с корпоративного счёта, руководство имеет доступ, в случае если ответственный человек на стороне заказчика решит уволиться
• Должны быть еженедельные конференц-коллы с разработчиками, которые должны сообщать вам статус и отчитываться о выполненной работе.
• Раз в 1–2 недели разработчики должны закрывать перед вами очередной этап разработки. По результату код должен быть “отгружен” вам в систему контроля версий
• Должно быть 3 окружения — development, staging, production
• Весь код должен быть протестирован не только разработчиками, но и вами. Идеально — если будут написаны автоматические тесты

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