Одне з моїх улюблених і, мабуть, найболючишіх питань у девелопмент командах: Що робити, коли вимоги дуже швидко змінюються? Коли Замовник/Продакт Оунер “передумав” чи “придумав краще” - це стандартна історія. Тут не треба вигадувати велосипед, робимо Change Request (CR) і починаємо спочатку. Проблема виникає тоді, коли вимоги змінюються дуже часто. У мене був випадок, коли за день надходило до трьох різних і, я б сказала радикальних, змін до однієї задачі. Як же працювати в таких умовах? В даній статті я не розглядаю роботу з CR, а хочу розповісти як побудувати роботу в таких складних умовах.
Перше, що ми маємо зробити - це визначити, чи є закономірність? Можливо, вимоги стрімко починають змінюватись після якихось бізнес мітингів? Можливо після івентів/певних періодів? Чим довше працюєш з замовником - тим легше знайти закономірності.
Якщо закономірностей не виявлено/виявити неможливо, тоді переходимо до аналізу цих “нових ввідних”. Якщо це стосується текстів, кольорів, іконок, формі кнопок (фронтових змін) - можна не припиняти роботу над логічною частиною, і внести ці зміни вже на кінцевому етапі розробки.
Коли зміни стосуються логіки то, залежно від етапу розробки, можна запропонувати виконати реліз того, що вже розробили. А далі, задля слідування скрам процесам, в новий спрінт взяти правки, що найдішли. Якщо все відбулось ще на етапі технічного дизайну - то уточнюємо чи потрібно цю задачу робити “якнайшвидше” чи почекаємо устаткованих вимог і тоді додамо в найближчий можливий реліз (таке теж інколи буває).
І, наостанок, порада по найчастішому випадку що бувало у мене в практиці: коли приходить задача від замовника, який часто грішить “я все передумав, давайте інакше” виконуємо технічний дизайн і вже зразу оцінюємо які параметри можуть змінюватись і виносимо їх у конфіг/адмінку зразу. Щоб на будь-якій стадії змінити параметри, чи видимість блоків, чи доступність функціоналу. Виручало мене дуже багато разів.
Ось такі прості поради. Успішних всім проектів!
