У голові у вас продукт, а на папері немає жодного числа. Ви питаєте трьох, скільки коштує перша версія, і отримуєте три відповіді, які розходяться сильніше за самі брифи. Хтось із трьох просто вгадує. Найчастіше ви чуєте: вартість назвемо після огляду. Це чесна відповідь, але планувати з нею не можна. Тож цей текст про сам механізм: із чого складається число, чому дві оцінки за одним брифом не збігаються і коли число стає передбачуваним, ще до першого рядка коду.
Жодної суми тут немає, і це зроблено навмисно. Одне число без міркування за ним — це вгадування з крапкою. Натомість ви можете отримати механізм: короткий список того, що названо заздалегідь, порядок оплати, де кожен крок окремий, і питання, які виявляють різницю між двома пропозиціями. Передбачувано не означає дешево. Це означає, що ви знаєте, що рухає число, і домовилися про це до старту.
Кожна оцінка складається з тих самих частин, і частини ці нудні. Сценарії. Модель даних. Зовнішні системи, яких торкається продукт. Люди, які дають доступи й матеріали. Навчіться їх рахувати, і ви зможете читати будь-яку пропозицію, навіть слабку.
1. З чого насправді складається число
Почніть зі сценаріїв. Сценарій — це те, що людина доводить до кінця: лід стає клієнтом, замовлення перетворюється на оплату, а потім на відправлення, співробітник надсилає запит, який керівник погоджує. У кожного сценарію ланцюжок екранів, правил, станів і прав доступу.
Сценарії, схожі на слайді, рідко бувають однаковою роботою. Правила за ними різні, а саме правила з'їдають дні. Тому перелік із презентації нічого не вирішує: рахувати треба ланцюжки.
Далі модель даних. Це те, що існує, як частини пов'язані між собою і що ніколи не має потрапити не тій людині. Якщо два клієнти бачать чужі рядки, це рішення, прийняте до першої таблиці, а не баг, який знайдуть потім. Текст чому дані орендарів треба відокремлювати варто прочитати саме до першої таблиці. Продукт, що тримає документи однієї компанії подалі від документів іншої, влаштований інакше, ніж інструмент на один акаунт, і оцінка мусить знати, який із двох ви будуєте.
Ролі все множать. Один екран адміністратора перетворюється на кілька, коли керівник, менеджер і бухгалтер дивляться різні версії з різними обмеженнями. Кожна роль — окремі екрани, окремі правила, окремі перевірки. Те саме зі станами, яких немає на слайді: повернення, скасування, дублікат запису, погодження, яке відкликано. Перша версія може містити мало таких випадків, але назвати їх мусить, бо саме вони визначають, що вважати готовим.
2. Зовнішній світ дорожчий за внутрішній
Екрани ваші. Платежі, пошта, SMS, телефонія, рахунки, бухгалтерська система, API кур'єра, стара CRM: усе це не ваше. Кожна система, до якої доходить продукт, — окрема робота зі своїми доступами, своїм тестовим середовищем, своєю документацією і своїм уявленням про помилку.
Платіж, який на схемі виглядає одним квадратом, насправді ланцюжок із повторами, вебхуками, поверненням і станом, коли гроші пішли, а база — ні. Кожен такий зв'язок доводиться перевіряти окремо, і саме ці перевірки вилазять назовні вже після старту.
Чекання теж входить у вартість. Рахунок у платіжній системі йде на перевірку. Сторонній сервіс відповідає на запит про документацію раз на тиждень. Увесь цей час ніхто не друкує, а календар рухається. Оцінка, яка припускає, що всі доступи прийдуть у перший день, — це інша оцінка, ніж та, де названо, які рахунки відкриваєте ви і хто їх випитує. А ще запитайте, скільки продукту розмовляє зі зовнішнім світом: сповіщення — це вже пошта, доставка і журнал помилок, а вивантаження в чужу систему — відповідальність за розклад, яким ви не керуєте. Рахувати доведеться з'єднання, а не сторінки.
3. Хто постачає матеріали, міняє число
Частина роботи ваша: доступи, облікові записи, контент, дизайн і людина, яка може сказати «так». У кожної з цих речей є дата. Дизайн прийшов пізно, збірка чекає, і оцінка, яка закладала дизайн на перший день, насправді оцінювала інший проєкт. Те саме зі текстами, правилами продукта і правом ухвалювати рішення. Оцінка без названої людини, яка вирішує, — це оцінка з відкритим кінцем.
Вкладення, які роблять старт передбачуваним, пишуться просто: результат одним реченням, сценарії, які входять, сценарії, які не входять, перевірки, за якими ви приймете роботу, і хто що постачає. Список є в матеріалі що прикласти до старту розробки. Письмова форма тієї самої домовленості й порядок дій, коли вона змінюється, описані в тексті як зафіксувати обсяг до збірки. Обидва тексти існують для того, щоб перше число, про яке ви домовилися, усе ще описувало ту роботу, яку ви отримаєте.
4. Чому дві оцінки за одним брифом розходяться
Два розробники читають один бриф і повертають різні числа, і зазвичай обидва чесні. Один спитав про ролі, інший — ні. Один оцінив щасливий шлях, інший — те, що стається, коли платіж не пройшов.
Один заклав готовий інтерфейс, інший — дизайнера. Один порахував сценарії, які ви написали, інший — ті, які мали на увазі, але не перелічили. Обидва описують різні продукти, хоча читають один аркуш.
Різницю можна знайти. Спитайте, що кожна оцінка включає, а корисніше — що вона виключає. Число, довкола якого нічого не названо, — це надія з датою. Питання, які відокремлюють одну пропозицію від іншої, завжди про зовнішні системи, ролі, матеріали, яких бракує, і стани, де щось пішло не так. Відповідайте на них один раз письмово, і далі будь-які пропозиції порівнянні, бо відповідають вони на ті самі питання.
5. Як робота оплачується насправді
Оплата йде по одному зрізу за раз. Не одним числом за весь продукт, погодженим один раз і яке потім місяцями відстоюють. У кожного зрізу свій обсяг і своя цифра, погоджена до того, як ви на нього погодилися, і кожен зріз закінчується тим, що можна відкрити й перевірити. Якщо наступний зріз виявився не таким, як його уявляли обидва, рухається тільки цей зріз. Ви ніколи не сперечаєтеся про суму, яку написали раніше, ніж хтось зрозумів модель даних.
Так число стає передбачуваним, але не фіксованим. Ви знаєте ціну наступного кроку до того, як він почався. Можна зупинитися після будь-якого зрізу і залишити собі те, що вже працює. Зміна стає новим рядком зі своєю цифрою, а не переглядом усієї роботи. І перша версія лишається маленькою навмисно: в production йде один сценарій, архітектура вирішується до коду, і решта лягає поверх того, що працює.
6. Питання, які роблять число передбачуваним
Задайте їх до того, як хтось щось пообіцяє, письмово, і тримайте відповіді поруч із пропозицією:
Розробник, який поки не відповідає на них, повідомляє вам корисну річ: огляду ще не було, а назване число — заглушка. Покличте того, хто відповість на ці питання, до порівняння пропозицій, а не після підписання. Питання коштують однієї розмови. Хибна перша версія коштує переробки.
Послуги включають огляд, який перетворює бриф на той самий список сценаріїв, ролей і з'єднань. Обрані роботи показують той самий механізм на продуктах, які вже працюють, із операцією поруч із результатом. Якщо ви хочете, щоб першу версію спланували й зібрали зрізами так само, розробка продукту з нуля — те, з чого це починається, і можна написати мені. Паролі й клієнтські дані в перший лист класти не варто.