Як писати вимоги
Як писати вимоги
Одна з основних службових обов'язків project-менеджера (PM) - це збір вимог і оформлення їх в завдання на розробку. Замовник приносить опис якоїсь предметної області, для якої потрібно запрограмувати реалізацію. У нашому випадку це, як правило, веб-проект. З чого почати? Як донести до розробника, вірніше, до команди розробників, суть завдання і що їм потрібно зробити? Спрощено процес виглядає так: збір вимог, їх уточнення, написання техзавдання, реалізація. Поговоримо про першу частину ланцюжка - збір вимог і їх уточнення.
В ідеалі, що хотілося б отримати PMу, - це документ, в якому замовник описав все, що він знає про предметну область, то, як проект повинен бути використаний Користувачем, як би замовник хотів керувати проектом, показав дизайн, подумав про майбутній розвиток. Мріяти, як то кажуть, не шкідливо. Тому що так ніколи не буває.
Як зазвичай надходять вимоги
Вимоги можуть приходити через систему управління завданнями, поштою, по скайпу, на нараді, в розмові. Якість і деталізація описів, як правило, мізерні і вимагають уточнення. В цьому немає нічого особливого, уточнення вимог - це нормальний робочий процес. Часто від тих, хто стикається з написанням вимог вперше, можна почути таку фразу: «я писати ТЗ не вмію, тому вимоги від мене не просите». Тут потрібно розділити техзавдання і вимоги.
Замовник - не програміст, ТЗ писати не вміє, від нього цього не потрібно. Що потрібно від замовника, який прийшов із завданням, - це знати свою предметну область і відповідати на питання для уточнення вимог. Трапляється, що домогтися відповіді досить проблематично.
Які бувають затики
Замовник не в курсі чи не до кінця в курсі, що від нього хоче роботодавець / топ-менеджер, і, відповідно, не може сформулювати вимоги по завданню. В цьому випадку до розробників із завданням краще не приходити, нічого хорошого в такому проекті не вийде. Краще йти у зворотний бік і отримувати інформацію від першоджерела. Замовник недостатньо компетентний в області розробки і соромиться викладати свої думки простою мовою. Такі складності швидко вирішуються, тому що завдання PMа - розговорити співрозмовника, задати навідні запитання і вивудити інформацію. До речі, опис вимог на простому, «цивільному» мовою - тільки вітається. Набагато гірше, коли спеціальні терміни застосовуються не по справі.
Чому ми не можемо «зробити як-небудь»
Якщо у замовника виникають вищеописані затики, він пропонує зробити «як-небудь», «на ваш розсуд». Білі плями в вимогах і пропозиції «зробити як-небудь» - це зло. Алгоритм «як-небудь» не напишеш, в ньому все має бути строго. Молодий розробник, дивлячись на такий опис, зробить здивовані очі, а досвідчений розробник запрограмує по-своєму. У першому випадку завдання не буде виконано, у другому - буде виконана не так, як потрібно бізнесу.
Як нам зробити, щоб всім було добре
Потрібна швидка зворотний зв'язок, щоб уточнювати вимоги і приймати рішення. У житті не завжди виходить отримати швидку зворотний зв'язок, наприклад, коли замовник - топ і до нього складно достукатися.
Вимоги потрібно деталізувати до такої міри, поки у розробників не залишиться питань. Звичайно, вони з'являться в процесі кодування, але вимоги ми зафіксуємо саме в тому стані, коли розробнику в перший раз стало все по ним зрозуміло. Деталізація вимог - це спільна робота PMа і замовника. Приклад з життя: початкові вимоги, що надійшли від замовника на одній сторінці (з двома картинками на ній же), після уточнення перетворилися в 19 сторінок. Тобто 18 сторінок інформації було витягнуто отримано від замовника в процесі затвердження вимог, які були доведені до тієї міри деталізації, яка була потрібна для початку розробки.
Не потрібно в вимогах проектувати архітектуру. Є прокачані замовники 80 рівня. які заглиблюються в тему настільки, що у вимогах починають проектувати додаток або будувати схему бази даних. Це зайве. На стороні групи розробки завжди є людина, яка придумає архітектуру і буде за неї відповідати. А ось відповідати за нав'язану їм з боку архітектуру ці люди не люблять.
Обов'язково потрібно фіксувати домовленості. Перевірений термін життя інформації в перевантажених різними проектами головах - два тижні. Після цього незафіксована завдання забувається, деталі губляться або з'являються нові фантазії, завдання починає звучати по-іншому. Хороший інструмент для фіксування вимог - Google Docs, там завжди видно актуальна версія, можна налаштувати права, подивитися історію змін.
Приносьте ваші вимоги, будемо разом їх уточнювати :)