Що ви думаєте про рівень деталізації вимог? Чи відчуття, що ще мало деталей, ще щось пропустили, ще не всі питання команди покриті вже є повсякденним в роботі? І часу нема, ще стільки деталей треба встигнути з'ясувати та опрацювати. Всім нам відомо, як важливі деталі у вимогах. А що якщо я вам скажу, що деталі можуть відвести вас в протилежну від цілі сторону? Звучить абсурдно?
Зазвичай, проєкт не складається з однієї-двох користувацьких історій, та навіть з однієї - двох функцій. А якщо у вас вже більше 3-х фіч та кожна розкладається на окремі історії користувача, то уявіть, скільки в нас в цілому деталей. Ці деталі затягують увагу, як болото. Але концентрація уваги тільки на деталях без аналізу і складання бачення загальної картинки не дає нам можливості бачити деталі інших фіч, що вони мають спільного, які залежності між ними, як вони доповнюють одна одну і як складають продукт в цілому. А саме головне, чи вирішують ті деталі головну бізнес потребу. Та це своєю чергою породжує виявлення нових (втрачених) вимог або деталей під час розробки, тестування, демо. Аналітик потрапляє в коло постійних дрібних змін.
Тому дуже важливо спочатку побудувати бачення продукту в цілому.
Ще будучи початківцем у Бізнес-аналізі, я відчувала цю потребу – зрозуміти місце нового функціоналу в існуючий системі. Та після того, як я занурилася у BABOK на курсі Дениса Гобова😁, це набуло назви Strategy analysis.
Так ось, згідно BABOK, Strategy Analysis містить такі дії, як виявлення реальної потреби й контексту; розуміння поточної ситуації, в якій ця потреба з'явилася, і чого ми хочемо досягнути; побудову ефективної стратегії переходу від поточного до майбутнього стану і реалізації потреби.
Звучить логічно і здається очевидним, всі так роблять. Але буває не так. Маючи бажання мотивувати мого читача на побудову цього процесу як постійної частини Бізнес-аналізу, я б хотіла навести причини, чому планування та увага цілісній картинці може пропускатися. Сподіваюся, це приверне увагу та допоможе усвідомити причину цього.
Я стикалася з декількома причинами:
Потреба клієнта, продукт і шлях його побудови здаються зрозумілими без додаткового аналізу і не вартими часу для фіксування в якомусь вигляді (артефакт).
Уявить, що ви дивитеся, як хтось готує. Ви також думаєте: “Все зрозуміло, логічно, все запам'ятав, не буду записувати.” А потім на наступний день стаєте самі готувати. Чи все буде пам'ятати, чи все так само зрозуміло?
Ні.
А якби ви записали, та й ще поки писали, виникли питання і ви вже маєте на них відповіді? Зовсім інша справа.
Тож не варто нехтувати цим часом, він окупиться та у вас же буде шпаргалка.
Із самого початку проєкту стартує розробка й потреба наповнювати Backlog стає самоціллю, ви уходите в деталі, які затягують, і повернутися на рівень Big picture стає дуже важким.
Так хочеться вірити, що всі вже таки досвідчені, що таке минають. Але якщо так сталося, я б аргументувала потребу в часі на аналіз. В моєму досвіді були таки ситуації, завжди домовлялися, вирішували по-різному: або залучали додаткових аналітиків на Design фазу, щоб розподілити роботу по планування та по наповненню беклогу та роботу з командою, або перенаправляли розробників на технічні роботи, поки планування не буде завершено.
Відсутність зафіксованих бізнесових потреб, як відсутність компаса, унеможливлює перевірку деталей з загальними цілями, ви не бачите, що йдете не туди, а відповідно далі відчуваєте, що все ок і без стратегії. Стається таке собі коло, яке важко розірвати без стороннього втручання.
Якщо у вас маленький проєкт та гнучкі дедлайни, можна так гратися. Але я люблю усвідомлену роботу, а не метод проб та помилок. Якщо великий, то це може перетворитися ось в ті проєкти по 4-5 років. Гірше, якщо дедлайни жорсткі, бо тут є ризик занепаду проєкт. Я б поступала, як в попередньому пункті.
Цей комплекс дій вважається характерним для “Waterfall”, і тому пропускається, або робиться поверхнево.
Тут суперечність SDLC, бо він передбачає аналіз та планування, ну або дизайн. А Strategy analysis цим і є.
Здебільшого, всі ці причини можуть бути пов'язані з бажанням все зробити вчасно. Сприйняттям, що планування - то не робота, то марна трата часу, давайте вже працювати та розробляти, ось розробка - то робота. Але без планування і бачення куди і як нам йти, ми збільшуємо свій шлях, нарікаємо його на плутанину й хаос, та й на ризик не отримати результат в призначений час (порушити дедлайн). Треба будувати карту, бачити на ній орієнтири, зменшувати невизначеність, додавати впевненості й передбачуваності.
А тепер відчуймо себе без планування на більш життєвому прикладі. Уявіть, вам потрібно зібрати пазл з 1000 частинок, а ви не бачите цілої картинки. Або бачили її раз, та не маєте постійно перед очима. Чи в такій ситуації вам буде легше чи складніше зібрати пазл, довше чи швидше? Скільки кроків буде з картинкою і без?
Неможливо побудувати щось ефективно, не маючи уявлення про це, не маючи план, схему, карту, Roadmap, Scope перед очима. Це дозволить більш свідомо працювати з деталями, через те, що є розуміння, де вони на загальній картинці.
Підсумовуючи, хочу підкреслити, що це – дуже важливий етап. І бажано його мати зафіксованим у будь-якому зручному для вас артефакті. Але це не відміняє необхідність мати детальні вимоги, а тільки дає базу для розуміння їх місця. Як нитка для намистин.
Впроваджуйте це, вашій команді сподобається бачити цілі та розуміти продукт в цілому. Вам сподобається бути капітаном, який бачить шлях та показує його команді.