Нотатки по роботі з вимогами з претензією на методичку. Частина 1-а

У рамках підготовки до гри OpenTalk # 5 «Бізнес-аналіз, управління вимогами, проектування» , я обіцяв в скайп-групі і розсилці підготувати методичне керівництво для допомоги як новачками, так і для тих, хто неодноразово був на моїх семінарах/виступах/тренінгах/дискусіях. Нижче я постараюся тезово викласти основні граблі моменти, на які ми всі натикаємося. Зрозуміло, що це поки збірник нотаток, який не дотягує до систематизованої методички - буду покращувати:) Отже, поїхали ...

Навичка «нуль»

На жаль, не придумано поки способу швидко і легко перетворити списку бажань замовника, безглузду й нещадну велику і жахливу, перетворити в робочий код. Доводиться закопуватися в предметні області, вивчати бізнес-моделі, спілкуватися з тими, хто здійснює бізнес процеси в цих моделях і т.д. І перше, що вам завадить в цьому - відчуття «помилкової професійної гордості», яке перешкодить вам задати зайве питання або зізнатися, що не зрозумів. Це ж почуття, до речі, потім завадить зізнатися, що ви з чимось «пролетіли» і десь не встигаєте. Після чого, прогнозовано, по кривій Макконелла ваші витрати полетять у небо, а отриманий результат буде явно дисонувати з витраченими зусиллями. Воно вам треба? Ставити запитання і правильно визнаватися в нерозумінні дуже залежить від обставин. Але прагнення задавити в собі погану звичку надувати щоки і робити вигляд, що все зрозуміло - вже добре, половина проблеми вирішена:)

Командна робота

У неї відмінно «встромляються» всі, кому не лінь. Колеги, в команді не може не бути лідера. Я розумію, що «формінг-нормінг-...», але при формуванні команд я поділяю вас так, щоб були в команді люди з яскраво вираженими лідерськими здібностями. Не треба фокусуватися тільки на технічному рішенні задач, я розумію, що вам хочеться бути в числі перших і прийнятті бізнес-рішень, і в технічних питаннях, але якщо ви реально можете допомогти команді організуватися і не заважати один одному - до біса двері зробіть це. Можливість показати свою крутість як аналітика і архітектора при цьому від вас не піде. Не забувайте, що залік як в іграх, так і в реальному житті - командний. Згадайте OpenTalk # 4, як все прибили не тільки в технічну складову, а й у командну:)

Підміна постановки задачі рішенням

Дуже часто, при обговоренні того, що потрібно зробити, замість запитань «навіщо?» і «чого ми повинні досягти?», ми задаємо питання «як?» або «що саме?». В результаті, потрапляємо в залежність від власного або чужого рішення або бачення рішення, геть відкинувши спектр можливих рішень, які могли б більше підійти в даній ситуації. При цьому, багато потім говоримо про правильному абстрактному проектуванні, відірваному від конкретної реалізації:)

Мова спілкування - мова цілей

Мова бізнесу недоступний розробникам софту і навпаки. Тому, з'являється каста шаманів в особі бізнес-та інших аналітиків, які, володіючи мовою замовника, переводять мова бізнесу на якийсь технічний або наближений до технічного і це служить вхідними даними для розробників. При цьому, дуже часто, виникає ризик втрати зворотного зв'язку - як в будь-якій системі з додатковими передавальними ланками, кожна з яких говорить своєю мовою. Як вихід - розробникам навчитися говорити мовою замовника і бізнес-аналітиків. Тому, в реальному життєво важливо об'єднати бізнес-аналіз і проектування - щоб аналітики подивилися, як і в чому вони можуть допомогти розробникам і навпаки. У наших іграх ми будемо робити те ж саме:) Отже ...

Щоб говорити на одній мові - говорите мовою бізнес-цілей. У чому плюси:

Замовник легко оперує бізнес-цілями - це його світ.
Замовник легко пріорітізірует бізнес-цілі.
Бізнес-цілі легко иерархизирует і декомпозіруется - із загальних шляхів досягнення мети легко, як правило, виділяються цілі нижнього рівня і т.д.
Правильно декомпозирована бізнес-цілі дуже короткі за формулюваннями і легко осмислюються.
Ієрархія бізнес-цілей дає нам ієрархію кінцевих користувальницьких фіч/кейсів/сценаріїв/історій/...
Розуміння суті автоматизується процесу розробником робить його роботу осмисленої - мотивація, фан, всі справи:)
Мова бізнес-цілей описує кінцеві процеси. Нескінченних проектів не буває. Дивись вище про мотивацію, фан, всі справи:)
Оперування цілями процесу замість шляхів їх досягнення - відмінний засіб застосувати витягаючі підходи та принципи і здешевити проект при поліпшенні його інтегрального якості.
Оперування цілями процесу замість шляхів їх досягнення - відмінний засіб отримати однакове з замовником розуміння «готове»: до побачення розмін багів на фічі та інші «гойдалки» і «віджимання» з замовником.
І т.д. Буду описувати в міру написання:)

Все це чудово дозволяє управляти ризиками - ризиками підміни постановки задачі рішенням, пріоритизації, верифікації, зміни вимог та багатьох інших. ЗИ: Шкода, що тільки ось ваші бізнес-аналітики в цьому не сильно іноді зацікавлені - якщо всі будуть вміти бити в бубон, то шаман не потрібен:) УбіватьУбірать з проекту таких аналітиків.

Розстановка пріоритетів

Одна з найбільших життєвих проблем автоматично транслюється на вимоги:) Неправильна розстановка пріоритетів приведе до того, що буде виконана некритична робота і не виконана критична. Дуже часто, неправильна розстановка пріоритетів випливає з незнання/нерозуміння/небажання застосовувати «витягають» принципи замість «заштовхують». Іншими словами, замість того, щоб робити тільки те, що заважає використовувати проект найближчим часом або прямо зараз, ми займаємося дурницями з розряду «а що б нам ще такого увіткнути в проект, щоб він став кльовим?». Замість боротьби з перешкодами, ми отримуємо смоляну яму власної невпевненості і жадібність.

Також, правильній розстановці пріоритетів дуже сильно заважає прокрастинація - відкладання важливих справ «на потім». Зрозуміло, що при оперуванні деревом бізнес-цілей ви не зможете (хоча немає нічого недоступного для місцевих майстрів:) відкласти на потім ті завдання, які заважають досягненню цілей.

Робота на випередження

Фактично, плануючи, ми намагаємося заглянути в майбутнє і визначити шлях, яким наша поточний стан проекту перетвориться на бажане. Управляючи ризиками - ми теж заглядаємо в майбутнє і намагаємося передбачити всілякі камені на цьому шляху. При роботі з вимогами теж треба управляти ризиками. Наприклад, з'явилося розуміння, як домогтися якоїсь мети. Очевидно ж, що слідом піде питання про вартість шляхи досягнення. Бо вимоги - це, в деякій мірі, дзеркало потреб замовника. А потреба замовника - або отримати максимальну якість за прийнятну ціну або отримати прийнятну якість за мінімальну ціну. Тому - треба готуватися до питань «скільки коштує?», «Як здешевити?» Ще на етапі аналізу вимог. Тому що ви ще не продумали реалізацію, а замовник вже пріорітізірует. Так навіщо робити зайву роботу - випередите його та приєднуйтеся до нього в цьому процесі:) Те ж саме і по іншим аспектам.

Верифікація

Вимоги - продукт життєдіяльності, як і код:) І їх потрібно тестувати, як і код. Безумовно, що терміни «повнота», «несуперечність», «реалізація» і «тестованого» дуже добре звучать і дають уявлення про критерії якості вимог. Але, в реальному житті, повнота вимог дуже часто залежить не від бізнес-аналітика, а від замовника. Навіть самий кваліфікований аналітик може не встигнути зануритися в бізнес замовника настільки, щоб з дуже великим ступенем ймовірністю перевірити якість вимог. Є, правда, рецепт у вигляді перекладання відповідальності за вимоги на замовника, але всі ми знаємо, що замовник не завжди доступний або здатний зрозуміти і протестувати всі вимоги проекту. Про банальні людські помилки і неуважність в оцінці повноти і трасуванні вимог може призвести до того, що з часом проект стане «іншим», а пристойну кількість грошей буде списано за принципом quick fail-а.

Оперування бізнес-цілями дозволяє легко верифікувати із замовником вимоги - цілі (як мінімум верхнього рівня) викладені мовою замовника. Верифікація результату теж спрощується - спільні шляхи досягнення головних теж викладені мовою замовника.

Далі в програмі (якщо встигну до четверга:)

нефункціональні вимоги
Сплячі кейси
Розпухання вимог
Зміни вимог
витягаючі принципи

Посилання по темі

Опубліковано: 28/06/11 @ 08:38
Розділ Різне

SEO Блог