Ви замовляєте розробку, поки екран порожній, бюджет погоджений, а редактор ще ніхто не відкривав. Саме зараз кожне рішення коштує розмови на пів години. Те саме рішення, прийняте після першого деплою, коштує рефакторингу, міграції або нової збірки.

Розробник закриває прогалини, бо порожнечу все одно треба на щось перетворити: на екран, поле чи запис у базі. Хто власник акаунтів. Що беремо готовим, а що пишемо своїм. Куди потрапляє заявка. Що вважається прийнятим. Хто вправі сказати «ні». За замовчуванням відповідає той, хто пише код, і потім ви платите за зміну цієї відповіді, хоча спершу ціна здавалася формальністю. Речення в документі міняється безкоштовно, запис у базі ні.

Щоб цього уникнути, не потрібна специфікація на п'ятдесят сторінок. Достатньо шести рішень, записаних по кілька речень кожне, і перший рахунок залишиться близьким до оцінки. Поки екран порожній, вони майже нічого не вартують, а щойно з'являється код, саме вони стають найдорожчими рядками в рахунку.

1. Що беремо готовим, а що своє

Частину першої версії взагалі не треба писати. Вхід і відновлення пароля, надсилання листів, платежі, зберігання файлів, пошук: це вже роблять стандартні сервіси, і хибний вибір тут коштує скасованої передплати. Своїм лишається те, що покупець може назвати причиною платити, плюс межа між двома клієнтами. Критерій вміщується в одне речення: якщо хибний вибір це скасована передплата, беріть готове; якщо хибний вибір це переробка збережених записів, пишіть своє.

Кожному готовому рішенню все одно потрібен рядок: що взято, в кого і скільки коштує вихід, де лежать дані і хто їх вивантажує. Десять сервісів, про які ніхто не записав, стають другим проєктом: людина, яка їх налаштувала, йде, і ніхто не може назвати, від чого взагалі залежить продукт. Цей список лежить на тій самій сторінці, що й інші рішення, і новий розробник читає його без жодного запитання.

Протилежна помилка: писати рутинну роботу заради контролю. Форма платежів, зібрана руками, або самописна черга листів це не функція. Це рахунок за підтримку, який починається з другого місяця, за задачу, яку вже хтось вирішив і підтримує. Питання даних за цими рішеннями, кому належить рядок і що змінює другий клієнт, розказані в сусідньому рішенні як вибрати стек для нового SaaS.

2. Акаунти й домен мають бути вашими з першого дня

Домен, хостинг, хмарний проєкт, платіжний провайдер, відправник листів, репозиторій коду. Реєструйте все це на компанію, з корпоративною поштою та карткою, якою керує компанія. Зараз це година роботи, а без цієї години ви отримаєте переговори, коли підрядник зайнятий, або продукт, який неможливо перенести, бо акаунт реєстратора належить людині, що вже пішла.

Одразу виріште і те, як розробник отримує доступ: іменне запрошення до кожного сервісу, яке можна відкликати одним кліком, краще за пароль, скинутий у чат. Запишіть, хто тримає кожен акаунт і хто може забрати доступ. Якщо акаунт уже оформлений на особисте ім'я, перенесіть його до старту збірки, а не після першої суперечки про рахунок.

До акаунтів належить і шлях грошей. Назвіть платника на боці платіжного провайдера та людину, яка може змінити рахунок для виплат. Якщо продажі йдуть через акаунт на особисте ім'я, день, коли ця людина піде, стане днем, коли зупиниться виручка. Це не гіпотетичний випадок. Перенесення це форма, а не проєкт. Зробити його треба до першого справжнього платежу.

3. «Прийнято» це набір кліків, а не відчуття

До першого рядка коду назвіть п'ять-десять перевірок, за якими вирішується, чи оплачується робота. Оформіть одне замовлення і змініть ціну з акаунта працівника. Надішліть тестову заявку і знайдіть її. Відкрийте другу мову, якщо ви її купили. Кожну перевіку має пройти людина, яка не брала участі в чатах, і без ваших пояснень.

Окремо запишіть, чого приймання не включає. Нового логотипа, ідеального балу від інструмента, якого ніхто не встановлював, і текстів, які розробник дописав, щоб закрити прогалину. Зафіксований письмово обсяг захищає обидві сторони, приклад такої фіксації є в матеріалі як письмова фіксація обсягу береже обидві сторони. Написані зараз, ці перевірки коштують двадцяти хвилин. Написані після збірки, вони вже стають суперечкою про те, що всі мали на увазі.

Тримайте перевірки настільки короткими, щоб ви їх справді проходили. П'ять хороших перевірок кращі за двадцять, які ви пропустите. Покладіть їх у той самий документ, де зафіксовано обсяг, і поставте дату. Коли збірка прийде, проходьте список по порядку і записуйте, яка перевірка не пройшла. Невдача вказує на рядок, а відчуття вказує на переробку.

4. Куди має потрапити заявка

Форма зі словом «дякуємо» ще не є готовою функцією. Вирішіть, куди потрапляє надіслана заявка: на яку пошту, в яку CRM, до якої таблиці й до черги якої людини. Визначте, хто надсилає першу відповідь і з якою швидкістю, бо якщо план «розберемося на тижні запуску», інтеграція вже лежить у вашій оцінці як непрорахована робота.

Місце призначення варто описати як шлях, а не як назву. «Йде у відділ продажів» це не місце призначення. «Надіслана форма створює картку в канбані продажів, етап Новий, прикріплена до чергового менеджера, з телефоном у першому полі» це вже місце призначення, і розробник може зробити такий крок першого дня й перевірити його одним надсиланням.

Пройдіть один реальний приклад до того, як приймати роботу. Повний шлях від форми до відсутнього рядка описаний у матеріалі чому заявка не доходить. Місце призначення, вирішене першого дня, це кілька рядків конфігурації. Те саме місце, вирішене на другому місяці, означає читання кожного повідомлення, яке не дійшло. Доводиться перебудовувати процес навколо інструмента, який команда вже перестала відкривати.

5. Де можна перевіряти роботу

Тепер скажіть, де роботу перевірятимуть, перш ніж її побачать клієнти. Це може бути окрема копія, локальна установка або прев'ю під паролем. Назвіть, хто тестує і на яких даних. Копія з реалістичними даними знаходить те, що ховає порожня база: довгі назви, дубльовані поштові адреси, клієнт з двома адресами та одним рахунком.

Якщо це рішення ніхто не прийме, тестовим середовищем випадково стане живий сайт, і кожна перевіка проходитиме перед вашими клієнтами. Чому такі речі закінчуються погано, пояснює матеріал чому не варто правити живий сайт без перевірки. Середовище варто визначити до старту збірки, а його створення вважати частиною роботи, а не затримкою.

6. Вирішує одна людина, а «ні» записане

Назвіть єдину людину, яка відповідає за продукт, коли обидва варіанти виглядають добре. Не комітет і не «вирішуємо разом». Там, де вибір треба зробити і ним ніхто не володіє, за замовчуванням його робить той, хто пише код, і ця відповідь тихо стає продуктом. Потім ви платите за зміну рішення, яке ніхто не пам’ятає, як ухвалив. Це може бути власник, продакт-менеджер або один із засновників. Важливо, що кожен на проєкті називає цю людину одним реченням.

Окремо вирішіть, як записується «ні». Датований рядок, відкинутий варіант і рядок причини поруч із зафіксованим обсягом. Не повідомлення в чаті і не протокол зустрічі, який ніхто не відкриє вдруге. Короткий письмовий список відмов найдешевший захист від обсягу, який росте за дружньою ініціативою, і саме його ви перечитаєте на другому місяці, коли хтось запропонує функцію, відкинуту на першому тижні.

І одразу вирішіть, скільки коштує запізніле «так». Додавання після погодженої оцінки це нове рішення з новою датою, а не дрібна правка, і в документі про це варто написати одним рядком. Саме це речення тримає перший рахунок поруч із оцінкою, і воно дорожче за будь-яке речення про години.

Послуги охоплюють планування першої версії та перевірку плану, який у вас уже є, щоб відкриті питання закрилися до підписання оцінки. Обрані роботи показують ті самі шість рішень поруч із продуктом, який працює, а не на слайді. Якщо ви замовляєте збірку і хочете спланувати її до першого рядка, починайте з розробки продукту з нуля або напишіть мені. Достатньо одного речення про те, що в першу версію входить, а що заведомо ні, і ви одразу побачите, чи збираєте ви один проєкт чи три. Паролі та дані клієнтів у повідомлення не додавайте.