Постановка задачі це половина успіху. Звучить як банальність із методички, але за роки роботи з командами розробки я переконався, що це ще й дуже дорога банальність. Формулювання «зроби гарно» не працює. «Зроби як у конкурента» теж не працює. «Ну ти ж розумієш, що я маю на увазі» працює найгірше, бо програміст у цей момент чесно киває і справді розуміє. Тільки щось своє.
Я багато разів бачив ту саму сцену. Менеджер у пʼятницю ввечері пише задачу в один рядок, у понеділок програміст приносить результат, менеджер дивиться на нього з жахом, програміст з образою, а клієнт з калькулятором. Тиждень роботи пішов на те, щоб зʼясувати, що всі говорили про різні речі. І винного тут немає, є лише погано передана думка.
Програміст не читає думки, він їх компілює
Уявіть, що Ви замовляєте в коваля меч і кажете йому: «Потрібен добрий меч». Коваль зробить добрий меч. За своїми уявленнями про добре. Він може виявитися важким дворучником, а Вам була потрібна легка шпага для фехтування в залі. Коваль не винен, він зробив чудову річ. Просто не ту.
З програмістом усе ще цікавіше. Код це буквальна річ. Компʼютер не вміє «домислювати», він виконує рівно те, що написано. І програміст, перекладаючи Вашу задачу в код, змушений ухвалювати десятки дрібних рішень, про які Ви навіть не подумали. Що робити, якщо поле порожнє? Що бачить користувач без прав? Що відбувається, якщо замовлення скасували на півдорозі? Кожне таке місце без відповіді програміст заповнить сам, за своєю логікою, а не за логікою Вашого бізнесу. Саме в цих щілинах потім і живуть баги, переробки та взаємні претензії.
Тому добра задача не та, у якій багато слів. Добра задача та, у якій найменше місця для чужих здогадок.
Анатомія задачі, яку роблять з першого разу
У заготовці цієї статті в мене був короткий чек-лист, і він досі правильний. Але за кожним пунктом стоїть своя історія, тож розгорну.
Заголовок. Він відповідає на питання «що саме потрібно змінити». Не «Проблема із замовленнями», а «Додати скасування замовлення клієнтом до моменту відвантаження». За заголовком людина має через пів року знайти задачу в трекері й зрозуміти, про що вона, не відкриваючи її. Якщо заголовок не можна прочитати вголос на планірці без пояснень, він поганий.
Опис і контекст. Тут пишеться не лише «що», а й «навіщо». Це найбільш недооцінений пункт. Коли програміст розуміє, яку бізнес-проблему він розвʼязує, він сам помічає половину крайніх випадків і пропонує рішення простіші й дешевші, ніж Ви б вигадали. Якось клієнт попросив нас зробити складний фільтр із двадцятьма параметрами для звіту. Ми спитали навіщо. Виявилося, що бухгалтер раз на місяць шукає три конкретні типи платежів. Зробили три кнопки. Зекономили клієнтові два тижні розробки, а бухгалтерові нерви.
Логіка роботи. Кроки сценарію очима користувача: відкрив, натиснув, побачив, отримав. Плюс розгалуження: що, як даних немає, як сталася помилка, як у користувача інша роль. Це не треба писати прозою на три сторінки, вистачить нумерованого списку.
Критерії приймання. Як ми перевіримо, що задачу виконано? Це пункт, який перетворює суперечку «мені здається, не готово» на факт, що піддається перевірці. Наприклад:
- клієнт бачить кнопку «Скасувати» лише в замовлень зі статусом «Нове» та «Підтверджене»;
- після скасування менеджер отримує сповіщення протягом хвилини;
- скасоване замовлення не потрапляє у звіт із продажів, але лишається в історії клієнта.
Якщо критерії приймання написані, програміст сам може перевірити себе ще до того, як віддасть роботу. Це дешевше за будь-якого тестувальника.
Макети та скриншоти. Якщо в задачі є візуальна частина, одна картинка замінює сторінку тексту. Це не обовʼязково має бути дизайн із Figma. Скриншот поточного екрана з червоною стрілкою й підписом «сюди кнопку» вже працює краще, ніж найдокладніший словесний опис. Свого часу я малював схеми кульковою ручкою на серветці й фотографував. Працювало.
Помилки, які я бачу найчастіше
Перша: задача-матрьошка. «Зробити особистий кабінет». Усередині реєстрація, відновлення пароля, профіль, історія замовлень, сповіщення та ще кілька всесвітів. Таку задачу неможливо оцінити, неможливо перевірити, і вона ніколи не закінчується. Якщо задачу не можна зробити за один-три дні, її треба різати. Великі шматки живуть у плані проєкту, а в трекер ідуть маленькі, завершені шматочки, які можна перевірити.
Друга: рішення замість проблеми. «Додай у таблицю колонку з датою». Добре, додамо. Але навіщо? Може, насправді треба було сортувати за датою, і колонка взагалі не потрібна. Описуйте, яку проблему Ви розвʼязуєте, а спосіб пропонуйте як варіант, а не як наказ. Досвідчений програміст часто знає коротший шлях.
Третя: задача в месенджері. Голосове повідомлення на чотири хвилини, потім три уточнення в іншому чаті, потім дзвінок, на якому «домовилися», але ніхто не записав. Через тиждень ніхто не памʼятає, про що домовилися. Задача має жити в одному місці, а всі уточнення дописуватися в її опис. Це нудно. Це працює.
Четверта: мовчазне приймання. Програміст здав, менеджер подивився, нічого не сказав, а за місяць зʼясувалося, що «взагалі-то не так». Зворотний звʼязок потрібен одразу. Інакше помилка встигає обрости новим кодом, як мушлями, і її виправлення коштує в рази дорожче.
Діалог замість наказу
Є ще одна річ, про яку рідко пишуть в інструкціях. Постановка задачі це не одностороння дія, а коротка розмова. Добрий програміст, прочитавши задачу, ставить питання. Якщо питань немає зовсім, це не завжди ознака ідеальної задачі. Іноді це ознака того, що людина соромиться спитати або вже все вигадала за Вас.
Я прошу свої команди після прочитання задачі переказати її своїми словами у двох-трьох реченнях. Це займає хвилину і виловлює більше непорозумінь, ніж будь-який регламент. Якщо переказ збігається з тим, що було у Вас у голові, можна починати. Якщо ні, Ви щойно зекономили тиждень.
І ще одне правило: оцінку термінів дає той, хто робить. Менеджер може спитати, може поторгуватися, може урізати обсяг. Але призначити термін згори, не спитавши виконавця, це як призначити погоду на вихідні. Можна, тільки нічого не зміниться.
Що робити завтра
Візьміть останні пʼять задач, які Ви поставили, і перечитайте їх очима людини, що не була на Ваших дзвінках. Чи зрозуміло з тексту, що зробити, навіщо і як перевірити результат? Якщо хоча б в одній із них немає критеріїв приймання, допишіть. Це найдешевше покращення процесу розробки, яке я знаю.
Заведіть собі шаблон задачі з пʼяти полів: заголовок, контекст, логіка, критерії приймання, макет. Не обовʼязково заповнювати всі поля в кожній задачі, але порожнє поле має бути свідомим рішенням, а не забудькуватістю.
Ми в Ingello Systems пішли в цьому ще далі: значну частину типових задач ми взагалі не ставимо словами, а описуємо систему формально, схемами даних та екранів, і генератор Fractal перетворює цей опис на код. Коли опис точний, сперечатися про те, «що малося на увазі», просто нема про що. Але навіть якщо до генерації коду Вам далеко, точне формулювання задачі вже на третину наближає Вас до цього світу. Код, як і меч, починається з креслення.
