Первый крупный проект я отдал на сторону с лёгким сердцем: бриф на две страницы, созвон на час, аванс, оптимизм. Через полтора месяца у нас была половина функционала, счёт за переработки и подрядчик, который тихо пропал из чата. С тех пор я пересмотрел подход и сформулировал семь правил, которые спасали меня не раз. Делюсь ими как есть, без красивых теорий.
Правило первое: говорите о результате, а не о технологиях. Подрядчику важно понимать, какую задачу решает продукт, кто платит, за что и почему возвращается. Когда вместо списка модных фреймворков я описываю сценарии пользователя и бизнес-эффект, оценка становится честнее, а спорить о вкусах приходится заметно меньше.
Правило второе: всё, о чём договорились, должно быть на бумаге. Объём работ, критерии приёмки, что считается готовым этапом, что входит в поддержку и что оплачивается отдельно. Устные обещания живут ровно до первого конфликта, а нормально составленный документ экономит недели нервной переписки и взаимных обид.
Правило третье: не исчезайте, но и не влазьте в каждую строку. Я прошу короткое демо каждую неделю, пусть даже на кривом тестовом стенде, и держу доступ к задачам и обсуждениям. Плюс правило четвёртое: инфраструктура на моей стороне. Репозиторий, домен, хостинг, доступы к платежам и рассылкам оформляю на свою компанию. Это не недоверие, а страховка: если отношения испортятся, код и продукт останутся у меня, а не превратятся в заложников чужого аккаунта.
Правило пятое: платить по этапам, а аванс держать скромным. Большой предоплатой вы покупаете не скорость, а риск. Небольшой старт, оплата за принятый результат и понятный график дальнейших платежей держат проект в тонусе и заказчика, и исполнителя.
Правило шестое: на вашей стороне нужен свой человек. Это продакт-овнер, который принимает решения без десяти согласований, и технический советник, который раз в неделю смотрит код и задаёт неудобные вопросы. Не обязательно нанимать сеньора в штат, но кто-то должен уметь отличать работающую систему от красивой презентации.
Правило седьмое: думайте о передаче с первого дня. Документация, инструкции по развёртыванию, тесты и внятные имена в коде — это не бюрократия, а ваша возможность сменить команду без переписывания проекта с нуля. Делегирование не значит выключить голову: оно значит управлять результатом, а не писать каждую строку самому. У меня эти семь правил превратили подрядчиков из источника стресса в надёжных партнёров, и проекты наконец стали выходить в срок.
А расскажите, как у вас: какие приёмы помогли вам отдать разработку на сторону и при этом не потерять ни контроль, ни нервы?
Правило первое: говорите о результате, а не о технологиях. Подрядчику важно понимать, какую задачу решает продукт, кто платит, за что и почему возвращается. Когда вместо списка модных фреймворков я описываю сценарии пользователя и бизнес-эффект, оценка становится честнее, а спорить о вкусах приходится заметно меньше.
Правило второе: всё, о чём договорились, должно быть на бумаге. Объём работ, критерии приёмки, что считается готовым этапом, что входит в поддержку и что оплачивается отдельно. Устные обещания живут ровно до первого конфликта, а нормально составленный документ экономит недели нервной переписки и взаимных обид.
Правило третье: не исчезайте, но и не влазьте в каждую строку. Я прошу короткое демо каждую неделю, пусть даже на кривом тестовом стенде, и держу доступ к задачам и обсуждениям. Плюс правило четвёртое: инфраструктура на моей стороне. Репозиторий, домен, хостинг, доступы к платежам и рассылкам оформляю на свою компанию. Это не недоверие, а страховка: если отношения испортятся, код и продукт останутся у меня, а не превратятся в заложников чужого аккаунта.
Правило пятое: платить по этапам, а аванс держать скромным. Большой предоплатой вы покупаете не скорость, а риск. Небольшой старт, оплата за принятый результат и понятный график дальнейших платежей держат проект в тонусе и заказчика, и исполнителя.
Правило шестое: на вашей стороне нужен свой человек. Это продакт-овнер, который принимает решения без десяти согласований, и технический советник, который раз в неделю смотрит код и задаёт неудобные вопросы. Не обязательно нанимать сеньора в штат, но кто-то должен уметь отличать работающую систему от красивой презентации.
Правило седьмое: думайте о передаче с первого дня. Документация, инструкции по развёртыванию, тесты и внятные имена в коде — это не бюрократия, а ваша возможность сменить команду без переписывания проекта с нуля. Делегирование не значит выключить голову: оно значит управлять результатом, а не писать каждую строку самому. У меня эти семь правил превратили подрядчиков из источника стресса в надёжных партнёров, и проекты наконец стали выходить в срок.
А расскажите, как у вас: какие приёмы помогли вам отдать разработку на сторону и при этом не потерять ни контроль, ни нервы?