Що замовник має отримати після discovery мобільного продукту

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

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

Навіщо етап узагалі потрібен

Коротко, бо без цього критерії приймання висять у повітрі.

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

Другий сенс менш очевидний. Discovery це дешевий спосіб дізнатись, що продукт робити не варто. Виявити це за два тижні краще, ніж за півроку розробки, і замовник за таку відповідь теж заплатив не дарма.

Сім артефактів і критерій приймання кожного

Це основний перелік. Колонка з критерієм важливіша за колонку з назвою, бо саме вона відрізняє документ від файлу.

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

Сім артефактів discovery з критерієм приймання для кожного.

Чому межі важливіші за список функцій

Тут головна думка матеріалу.

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

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

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

Оцінка без діапазону це не оцінка

Друга за частотою проблема.

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

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

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

Ризики без цифри марні

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

Ризик стає корисним, коли в нього є три частини: у чому він полягає, скільки коштує в днях або грошах, якщо настане, і що ми робимо в цьому випадку.

Тоді замовник може ухвалити рішення заздалегідь. Наприклад, узгодити запасного провайдера до початку розробки, а не тоді, коли перший відмовив.

Скільки це триває й скільки коштує

Без конкретних цін, бо вони залежать від проєкту, але з орієнтирами за часом.

Для невеликого продукту з одним основним сценарієм discovery це зазвичай від одного до двох тижнів. Для продукту з ролями, платежами й інтеграціями два-чотири тижні.

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

Окреме питання, яке варто ставити до старту: чи входить вартість discovery в подальшу розробку. Обидві відповіді нормальні, але знати її краще заздалегідь.

Чого ми не стверджуємо

Кілька меж.

Цей перелік для мобільного продукту середньої складності. Для прототипу на два екрани половина документів надлишкова, для корпоративної системи їх буде більше.

Ми не описуємо дизайн. Discovery може включати прототип, може не включати, і це питання домовленості, а не правило.

І сам факт наявності всіх семи документів не гарантує, що продукт вийде вдалим. Він гарантує лише те, що ви розумієте, за що платите далі.

Часті питання

Чим discovery відрізняється від технічного завдання?

Discovery відповідає на питання, що робити й скільки це коштує. Технічне завдання відповідає, як саме це буде зроблено.

Чи можна пропустити етап?

Можна, якщо ви готові до оцінки з дворазовим розкидом і до переговорів про обсяг уже під час розробки.

Що робити, якщо після discovery оцінка не вкладається в бюджет?

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

Кому належать документи після оплати?

Вам, якщо це прописано в договорі. За замовчуванням права не переходять автоматично.

Як перевірити якість discovery?

Уявіть, що розробку робить інша команда. Якщо вона зможе почати з ваших документів, етап відпрацював.

Підсумок

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

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

Перевірка якості одна. Візьміть результат і уявіть, що завтра проєкт веде інша команда. Якщо їй доведеться з'ясовувати те саме заново, ви купили зустрічі.

Матеріал підготували Євгеній Чиж, засновник Chyzh Agency, і Сергій Колодинський, Head of Mobile Development.