Аутсорсинг разработки: 7 правил управления для владельца без технических знаний

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

Аутсорсинг разработки: что на самом деле контролирует владелец

Вы не управляете тем, как пишется код. Хорошая компания по разработке сама предложит такие правила. Вы управляете четырьмя вещами: кто имеет доступ к работе, что считается готовым, как часто вы видите работающий результат и как оцениваются изменения. Всё остальное служит этим четырём. Если вы ещё выбираете партнёра, начните с наших 12 вопросов при выборе компании по разработке, а потом возвращайтесь сюда.

Семь правил управления аутсорсингом разработки

Правила 1–3: доступы, критерии, демо

1. Держите ключи у себя. Репозиторий кода, трекер задач, хостинг, домен и облачные аккаунты должны быть оформлены на вашу компанию, а подрядчик приглашён как пользователь. Посмотрите роли в репозитории GitHub, чтобы понимать, что может каждая роль.
2. Пропишите критерии приемки до начала работ. Для каждой функции простыми словами напишите, что сможет сделать пользователь, когда она готова. В Scrum Guide для этого есть термин: определение готовности. Это самая дешёвая защита от споров.
3. Требуйте живое демо раз в одну-две недели. Работающий экран, по которому можно кликать, лучше презентации. Если демо перенесли дважды, считайте это новостью.

Правила 4–6: статус, изменения, собственная проверка

1. Ведите недельный статус на одной странице с одними и теми же пятью строками. Они в таблице ниже.
2. Правило простое: оценка изменений составляется письменно. Новая идея получает заметку о времени и стоимости, и пока вы не согласуете, работа не начинается.
3. Проверяйте сами на тестовой версии сайта. Попросите тестовый стенд и короткий сценарий, что нажимать, а затем сообщите, что увидели.

Строка статуса	Что в ней должно быть	Тревожный признак
Сделано за неделю	Функции со ссылками на демо	Только усилия, нет результата
План на неделю	Три-четыре названных пункта	Расплывчатые планы
Блокеры	Что ждёт кого	Всегда пусто
Решения от вас	Вопросы со сроком	Сюрпризы в конце
Бюджет и срок	Потрачено против плана	Нет цифр

В аутсорсинге разработки эта страница главный документ. Добавьте к ней один этап в месяц, чтобы видеть дату, а не только усилия.

Правило 7: заметьте красные флаги в первые недели

• Демо переносят или заменяют слайдами.
• В статусе перечислена активность, но нет ссылок на работающие функции.
• У вас нет доступа к репозиторию или к трекеру задач.
• Одна и та же функция «почти готова» несколько недель.
• Люди в вашем проекте меняются без объяснений.
• Изменения идут без оценки, а счет удивляет.

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

Как модель договора меняет вашу роль

Опытные заказчики ведут аутсорсинг разработки с названным ответственным на своей стороне, пусть тот тратит на это час в неделю. Доверять аутсорсингу разработки можно, когда есть кому проверять результат. Когда аутсорсинг идёт хорошо, владелец видит ход разработки без технических терминов. Цена аутсорсинга разработки складывается из часов и рисков, поэтому её тоже нужно видеть. При фиксированной цене главный риск расплывчатый объем, поэтому критерии приемки важнее всего. При оплате за время вы платите за усилия, поэтому недельный статус и оценки изменений держат бюджет на виду. Обе модели мы сравнивали в материале фиксированная цена или оплата за время. Для подрядчиков, которые работают спринтами, понятным ориентиром о том, как выглядят регулярные обзоры, служат рекомендации британского правительства по гибкой разработке.

Что делать, если проект расползается

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

Заказать помощь с аутсорсингом разработки

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