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

Продовжуємо розпочатий розмову.

Зміни вимог

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

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

Погано, якщо це - думка замовника. Тут знадобиться кропітка робота по витягування з нього обгрунтування такої думки. Але, якщо ви з замовником з самого початку привчилися працювати від цілей і вибудовувати логічні обгрунтування досяжності/недосяжності по дереву цілей і кейсів або картками фіч (якщо юзаєте FDD) або якогось іншого способу візуалізації зв'язків «мета - шлях її досягнення», то процес внесення змін у вимоги стає менш емоційним і більш науковою, бо прийняття рішення про зміну пріоритетів чи контексту завдань без явного або не дуже «техніко-економічного обгрунтування» - не обходиться. Також, коли у команди кермо в способах верифікації досягнення цілей, то прогнозування змін стає менш інтуїтивним.

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

нефункціональні вимоги

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

Що можна зробити, якщо говорити мовою бізнес-цілей? Можна позначити нефункціональні вимоги як цілі, яких потрібно досягти. Отримуємо ситуацію, що нефункціональні вимоги до кейсам у нас транслюються від нефункціональних вимог/цілей більш високого рівня і декомпозіруется в кінцеві завдання.

Сплячі кейси

Характерно для складних процесів з відкладеними завданнями - раз на рік звіт згенерувати, перевірка станів об'єктів при настанні подій і т.д. Такі дії теж підкоряються певним бізнес-цілям і якщо в ході роботи над вимогами вони не спливли - вони не потрібні. Тим, хто займається автоматизацією бізнес-процесів - такі речі можуть періодично ускладнювати життя. Особливо, за наявності товстих тролів на стороні замовника, готових роздути з цього проблему термінів, бюджету та готовності проекту до приймання.

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

Розпухання вимог і функціональні перекоси

Коли ніхто не працює з цілями проекту, то витягають принципи забуваються і починається наталківаніе фіче-листів чим попало - такий собі фіче-Центрик підхід. Потрібність фічі НЕ рулить - рулить її наявність.

Якщо йти від цілей, то розмова про те, чи потрібна ця фіча чи ні саме зараз - спрощується. Якщо фіча відповідає непріоритетної мети або співвідношення «пріоритет мети - ціна фічі» порушена - в сад. Якщо у фічі немає конкретної мети - тим більше в сад.

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

Для боротьби з цим потрібно дуже ретельно виписати ієрархію цілей і пріорітізовать мети верхніх рівнів безпосередньо з ЧДПР - тоді у всіх активних овнеров будуть відмінні зручні гробики коридори, за які ступити вони можуть тільки ескаліруя питання наверх. З досвіду, два цих геморою часто ходять поруч. Боротися, ІМХО, з ними краще разом, ніж окремо - методи ті ж самі.

Далі буде.

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

SEO Блог