Понад 35 років я вивчав, застосовував і навчав тому, як команди з розробки програмного забезпечення можуть покращити те, що вони розробляють і як керувати вимогами до своїх продуктів ефективніше. Я помітив шість тем, пов’язаних із вимогами, які стосуються кожного проєкту, незалежно від того, що ви створюєте або як виконуєте проєкт. Пам’ятайте про наведені нижче теми, вибираючи практики вимог для використання у своїх проєктах і адаптуючи їх відповідно до кожної ситуації.
-
Розробка вимог вимагає поступового та ітераційного підходу. Дуже малоймовірно, що хтось подумає про всі вимоги до початку розробки, і що всі вони залишаться статичними. Люди отримують більше інформації, мають свіжі ідеї, згадують речі, які вони не помітили одразу, і змінюють свою думку. Вимоги — і команди — повинні адаптуватися до мінливих ділових і технічних реалій. Усе це показує цінність поступового вдосконалення попередніх вимог до відповідного рівня деталізації перед початком розробки, але незадовго до цього.
До теми: ВІГЕРСОПЕДІЯ – Основні практики для успішного бізнес-аналізу
-
Незалежно від того, як ви будете менеджити вимоги, метою всіх дій щодо специфікації є чітка та ефективна комунікація. Артефакти, які створює бізнес-аналітик, власник продукту або менеджер продукту, мають кілька аудиторій. Ці аудиторії можуть забажати бачити інформацію, представлену в різних формах і на різних рівнях деталізації. Подумайте, як спілкуватися з різними аудиторіями, коли ви створюєте вимоги.
-
Розробка вимог є процесом співпраці. Вимоги стосуються всіх зацікавлених сторін. Багато людей можуть надавати вхідні дані для вимог, багато людей виконують роботу на їх основі, і багато людей використовують отримане рішення. Залучення клієнтів є потужним фактором успішного результату. Аналітик повинен працювати з людьми, які можуть точно представити потреби різноманітних спільнот зацікавлених сторін. Більшість рішень щодо вимог залучають кількох учасників з різними, іноді суперечливими, інтересами та пріоритетами.
-
Зміни відбуваються. Зусилля щодо розробки рішення переслідують постійно рухому ціль. Потреби бізнесу, технології, ринки, правила та користувачі змінюються. БА має йти в ногу з мінливими потребами та переконатися, що зміни чітко розуміються, погоджуються, реєструються та повідомляються тим, кого вони стосуються. Але не використовуйте реальність змін і здатність адаптуватися як виправдання для того, щоб заощадити на попередньому дослідженні вимог. Мислення швидше і дешевше, ніж перекодування.
-
Потужним способом підвищення продуктивності розробки є мінімізація кількості непотрібних переробок, які має виконати команда. Тому намагайтеся просувати якісну діяльність на передню частину циклу розробки — тобто раніше, а не пізніше. Кращі вимоги окупаються меншою кількістю незапланованих, дорогих доопрацювань пізніше в розробці або після доставки.
-
Думайте про ризики, щоб вирішити, які практики вимог застосовувати, коли їх виконувати, скільки деталей необхідно та коли можна зупинитися. Наприклад, ризик неправильного спілкування та марних зусиль є більшим, якщо розробку передано аутсорсингу або команди працюють віддалено, ніж коли учасники працюють поруч. Тому плануйте писати вимоги до таких проєктів точніше і детальніше, ніж тоді, коли розробники зможуть швидко отримати відповіді від оточуючих.
Ці шість тем можуть допомогти будь-якій програмній групі виявити, проаналізувати, уточнити, перевірити та ефективніше керувати своїми вимогами.
Оригінальна стаття – Six key themes about software requirements, переклад Олександра Серебрянська (Business Analysis Community Kyiv), ревью – Іван Вільчавський. Оригінальне фото від Annette з сайту Pixabay