УСУНЬТЕ КЛЮЧОВІ ПРОБЛЕМИ, З ЯКИМИ СТИКАЮТЬСЯ БІЗНЕС-АНАЛІТИКИ ПІД ЧАС КЕРУВАННЯ СКЛАДНИМИ ПРОЄКТАМИ З РОЗРОБКИ ПРОДУКТУ
З кожним роком складність проєктів зростає. Середній документ вимог становить понад 100 сторінок і змінюється 20 разів у процесі розробки. Це жорстоко. Це означає, що як бізнес-аналітик або керівник проєкту ви, швидше за все, витрачаєте години на передавання, редагування та відстеження змін у великому документі вимог з надією, що ваша команда не втратить ентузіазм та прочитає його. Звучить оптимістично, правда?
Старий спосіб роботи вимагає божевільної героїчності, і передбачає керування за допомогою Word, Excel та електронної пошти, як у страшному сні. Ваш час цінніший за це.
Проблема полягає не в самому документі вимог. Проблема полягає у використанні документа як місця для керування вимогами. Якщо ви сподіваєтеся встановлювати очікування, передавати деталі проєкту та відстежувати зміни протягом усього процесу за допомогою документів – що ж, нехай щастить!
Везіння вам точно знадобиться!
Отже, що ми можемо зробити? Що ж, ми можемо сказати вам одну річ. Ми не можемо продовжувати працювати старим чином й очікувати іншого результату. Як люди, які відповідають за те, щоб усі розуміли, що ми створюємо і чому (тобто, розуміли вимоги), ми маємо вдосконалювати свою роботу. Ми повинні засвоювати нові техніки та інструменти, щоб знайти кращий спосіб пояснювати вимоги та створювати правильні рішення, при цьому роблячи процес максимально приємним. Ми не говоримо, що існує єдине рішення для всіх проблем. Реалізація проєкту – не така проста річ.
Ми зібрали 5 найпопулярніших розчарувань на основі того, що ми пережили або бачили в роботі інших протягом багатьох років. І ми додаємо підказки, як боротися з кожним із них. Усі ці поради сприяють новому, більш спільному способу роботи, який більше зосереджується на людях і спілкуванні, необхідному для успіху, а не на документах. Ми вважаємо, що управління вимогами полягає не в управлінні документами, а в тому, щоб тримати вашу команду в узгодженості щодо цілей проєкту та втіленні в життя того, що потрібно створити.
Розчарування №1: В останній момент….
Керівник приходить до вас в останню хвилину з відгуком, який вам був потрібен три тижні тому.
Це обов’язкова зміна чи зміна, яку бажано б мати? Чи Ви посуваєте терміни? Чи ви негайно відбиваєтеся, кажучи: «Дякую, але ми додамо це у наступний реліз?» Можливо, ви знову підете додому після роботи допізна і сядете в 30-й раз дивитися фільм «Офісний простір», намагаючись висміяти свою напругу, щоб наступного дня не зірватися на свого боса.
ПОРАДА: БУДЬТЕ ВІДКРИТИМИ
Давайте керівництву кращу видимість і безперервний зворотний зв’язок, щоб розв’язувати проблеми до того, поки не стало надто пізно.
Чесно кажучи, ми були по обидва боки цього розчарування. Неприємно бути ні нападником, ні жертвою. Реальність така, що менеджери зайняті вирішенням мільйона різних проблем, і правильно це чи ні, вони зазвичай зосереджуються на найнагальнішому. Крім того, ідеї приходять до керівництва та інших зацікавлених сторін після того, як вони бачать прототипи й розуміють, що те, що було зазначено в початковій версії документа вимог місяць тому, зараз не є найкращим рішенням.
Щоб запобігти правкам “в останній момент”, ви повинні бути прозорими та відкритими для зворотного зв’язку на всіх етапах проєкту, а також часто звірятися з командою, щоб отримати відгуки завчасно. Якщо ваша команда та виконавчий персонал фізично знаходяться в одному офісі, це легше зробити. Розмістіть на видному місці дошку або спеціальну ууууууустіну, на якій відображені останні дизайни. Кожен день вони проходитимуть повз і матимуть можливість відреагувати на побачене. Більшість людей, щоб зрозуміти досвід користувача, краще реагують на візуальні елементи, ніж на написані слова.
Якщо ви є командою, що працює в декількох місцях, як це зазвичай буває сьогодні, тоді допоможе спеціалізований інструмент, який надає кожному центральний пункт, де зібрані вимоги проєкту, відповідні дизайни й відгуки в реальному часі. Вони бачитимуть, що відбувається, в міру розвитку проєкту, незалежно від того, де вони знаходяться, і ви зможете тримати руку на пульсі, щоб застрахуватися від будь-яких розбіжностей чи потенційних неприємних сюрпризів у майбутньому.
Розчарування №2: Повторне проговорення рішень
Проведення нескінченних зустрічей, на яких половина часу витрачається на перегляд старих рішень або розтлумачення їх тим, хто відстав
Визнаємо, що це бісить. Ми не любимо зустрічі. Але ми особливо не любимо зустрічі, які здебільшого є проговоренням уже прийнятих рішень. «Чому ми вирішили змінити функціональність цього елементу?» «Коли ми це схвалили?» «Брюса не було минулого тижня, чи можемо ми переглянути план, щоб він наздогнав?» Болісно, неефективно, розчаровує.
ПОРАДА: БУДЬТЕ ЗРОЗУМІЛИМИ
Надавайте повний контекст рішень, які приймаються, щоб усі зрозуміли обсяг проєкту та чому були прийняті рішення. Людям потрібні ясність і розуміння, щоб працювати якнайкраще.
Зверніть увагу: П’ять сильних книг для бізнес-аналітиків
Це стосується як ваших зацікавлених сторін і клієнтів, аби вони розуміли, що вони отримують, так і ваших команд проєктування, розробки та контролю якості, аби вони знали що саме потрібно побудувати та протестувати належним чином. Як варіант розв’язання проблеми, існують сучасні інструменти для співпраці, які допоможуть вам зафіксувати здорові дебати та поточні дискусії, які природно відбуваються навколо вимог, і вони не вимагають проведення додаткових зустрічей. Люди можуть додавати свої відгуки в будь-який час і бачити, що кажуть інші, погоджуватися чи не погоджуватися, схвалювати чи відхиляти, або пропонувати зміни для покращення рішення.
Крім того, рішення, які приймаються на зустрічах, не так легко відстежити в документах, а у пам’яті людей вони з часом стираються. Скільки разів ви виходили з наради, почуваючись чудово і думаючи, що всі на одній хвилі, лише щоб через кілька тижнів знову опинитися в ситуації обговорення того, що було вирішено? Якщо ця проблема характерна для вашої організації, почніть фіксувати відповідні рішення паралельно з вимогами та зробіть їх доступними для перегляду членами команди в будь-який час. Це усуне двозначність і гарантує, що рішення щодо проєкту будуть цілком зрозумілими.
Розчарування №3: “Податок” на зміни
Надсилання оновлень всім вручну, коли відбулися якісь зміни, вбиває третину вашого дня.
Кожного разу, коли ви робите щось вручну, запитайте себе: «Чи можемо ми це автоматизувати?» Завдяки сучасним інструментам відповідь часто «так». Коли ви виконуєте складний проєкт, зміни — це просто те, що обов’язково станеться. І часто з поважних причин. Коли ви глибше заглиблюєтеся в дизайн і розробку проєкту, ви знаєте більше, ніж на початку. Таким чином, ви та ваша команда будете думати про кращі способи створення бажаного продукту, коли ви повертатиметеся до вимог на цьому шляху. Якщо ви спробуєте керувати версіями, відстежуючи зміни в документах Word, ви відчуєте величезний “податок” на свій час. Майже неможливо написати ідеальний документ вимог з першого разу. Тому перестаньте вважати це метою.
ПОРАДА: БУДЬТЕ ІТЕРАТИВНИМИ (ПОВТОРЮВАЛЬНИМИ)
Прийміть зміни з розумінням, збираючи інформацію до купи, швидко оцінюючи вплив і автоматично доносячи зміни до потрібних людей.
Ми не можемо говорити про вимоги без розмов про зміни. І ми не можемо говорити про зміни не кажучи про те, що треба бути гнучкими, тобто працювати за agile підходом.
Причина №1 для впровадження agile у вашій організації — створити гнучку культуру, яка дозволить вашій команді швидко й ефективно реагувати на мінливі вимоги. Таким чином, повторюючи ітерації на шляху.
Не зациклюйтеся на ярликах або дебатах про те, чи краще Scrum чи Kanban. Не існує остаточного, універсального процесу. Agile — це перш за все культура мислення, а не приписний процес розвитку.
Ваша мета – щоб уся Ваша організація відчула повноваження запропонувати зміни, якщо вони знайдуть краще рішення. Якщо ви переходите від більш традиційного каскадного підходу (Waterfall), ваше завдання з переходом на agile полягає в тому, щоб не перейти від однієї крайності до іншої. Існує міф про те, що agile передбачає відсутність плану, і просто створення на льоту – що не правда у більшості організацій. Розумні agile команди дотримуються щодо вимог найкращих практик, запозичених із традиційних методів, таких як: простежуваність, аналіз впливу та управління змінами, щоб вони могли зрозуміти накопичувальний вплив зміни на решту проєкту. Це балансування між гнучкістю та формальним контролем. Деякі називають це гібридним підходом. Знову ж таки, назви не мають значення. Головне — знайти поєднання технік, яке найкраще підходить для вашої команди, щоб ви могли виконувати проєкти без проблем. Ось що має значення.
Розчарування №4: Дефіцит уваги
Створення детального плану на 200 сторінок, який ніхто не встигає прочитати один раз, не кажучи вже про кожну зміну.
Отже, Ви це зробили. Ви щойно завершили місячну роботу, отримавши відгуки від 50 зацікавлених сторін і написавши найкрасивіший документ вимог у своєму житті. З точки зору CMMI або BABOK, це чиста поезія shall-тверджень і варіантів використання. Гаразд, насолоджуйтесь цим моментом близько 30 секунд, тому що він швидко зміниться страхом того, чи хтось коли-небудь прочитає ваш документ.
Прочитайте також: User Story та Acceptance Criteria: пишемо чіткі та зрозумілі вимоги
Зі зростанням складності проєкту, як Ви можете сформулювати план, не створюючи документа-монстра? Це важко. Проблема може бути не в довжині повного документа специфікації. Проблема в тому, що ви намагаєтеся донести весь план до всіх, хто використовує цей документ. Насправді більшість людей працюють і піклуються лише про конкретні частини плану в певний момент часу.
Коли змінюється один елемент, а ви надсилаєте нову версію всього документа вимог, це водночас і перевантаження інформацією, і білий шум. Ми не можемо очікувати, що люди будуть вишукувати, що змінилося, і щоразу визначати, актуально це для них чи ні. Цей старий спосіб неймовірно неефективний, і люди просто перестають звертати увагу.
ПОРАДА: БУДЬТЕ АКТУАЛЬНИМИ
Прийміть філософію, що всі просто занадто зайняті, щоб засвоїти весь документ. Бо так буквально і є. Щоб уникнути розчарування через дефіцит колективної уваги вашої організації, ключовою є актуальність.
Це та область, де інструменти можуть допомогти вам розбити великі, складні проєкти на менші керовані частини, і дозволити людям фільтрувати те, що важливо їм. Ми рекомендуємо вам керувати обсягом проєктів поелементно, щоб виконати роботу. Якщо вам цікаво, що ми маємо на увазі під словом «елемент», то вимога — це елемент. Варіант використання – це елемент. Тестовий випадок – це елемент. Дефект – це елемент.
До теми – ВІГЕРСОПЕДІЯ – Шість порад як писати однозначні вимоги — або будь-що інше.
Люди природно працюють над списком із кількох пунктів одночасно. Так працює наш мозок, і таким чином ми більш продуктивні. Розбиваючи на елементи обсяг ваших проєктів за допомогою інструменту з реляційною базою даних, Ви дозволите людям зосередитися на конкретних елементах, над якими вони працюють, зберігаючи при цьому контекст загального проєкту. Потім, якщо потрібно для узгодженої версії, релізів або етапів роботи, ви можете згрупувати елементи та підсумувати проєкт за допомогою звітів або документа специфікації для цілісного перегляду.
Розчарування №5: Невідповідні очікування
Зацікавлена сторона думає, що він отримує X, Y і Z, а насправді отримує X, A і B. Це відчувається як удар нижче пояса. Ви та ваша команда вклали свою кров, піт і сльози в реалізацію проєкту лише для того, щоб після запуску дізнатися, що кінцеві користувачі незадоволені. Що трапилось? Як ми промахнулися? Чому існує розрив в очікуваннях?
ПОРАДА: БУДЬТЕ ПРОАКТИВНИМИ
У людей вибіркова пам’ять. Ми всі пам’ятаємо те, що хочемо почути. Про що зацікавлені сторони забувають, так це про додаткові речі, які вони додають у ході розвитку проєкту, або про зміну пріоритетів елементів функціональностей у міру того, як обсяг змінюється з часом. X стає X+1, а Y стає Y+2, а Z незабаром виходить з гри, і натомість пріоритет переходить до A і B, але не всі зрозуміли компроміси, які були зроблені, оскільки рішення приймалося телефоном після пізньої нічної розмови з клієнтом.
Намір був правильний, команда працювала гнучко, але чого не вистачало, так це зафіксованого спілкування із зацікавленими сторонами, із документуванням запитів, домовленостей та погоджень із відповідними зацікавленими сторонами.
Наступного разу отримайте підтримку пріоритетів та зафіксуйте обґрунтування того, що входить в обсяг проєкту, а що поза ним, щоб переконатися, що всі мають однакові очікування. Не додаючи багато непотрібних додаткових витрат, сучасні інструменти пропонують можливість фіксувати перевірки, погодження та електронні підписи для змін обсягу проєкту як частину природного робочого процесу.
Таким чином кожен може бути впевненим, що знає справжній план, а команда може відчувати задоволення від того, що виконує обіцяне. Ви заслуговуєте на те, щоб запуск продукту був святкуванням, а не допитом про те, що пішло не так.
Оригінальна стаття – TOP FIVE FRUSTRATIONS OF REQUIREMENTS & TIPS TO AVOID THEM від Jama Software, переклад Олександра Дідух, ревью – Іван Вільчавський, зображення від Elisa Ventur з сайту Unsplash.