Як боротися з частими змінами вимог?

Я маю справу з досить напруженою (на мою думку) ситуацією на своєму нинішньому робочому місці.

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

Ось як виглядає "процес":

1. бізнес-радник розмовляє ввечері з моїм начальником протягом години-двох на месенджері Windows
2. наступного дня я отримую електронний лист із копією тієї розмови. Я повинен вибирати з цього завдання, перевіряти повідомлення про помилки (які часто не бувають помилки, просто погане тестування та забуття про минулі заклади)
3. Я впроваджую зміни, впровадження приймається, а потім через тиждень-два виявляється, що вони не хочуть (вони розмовляли з потенційним клієнтом, який бачив програмне забезпечення протягом 5 хвилин, і він запропонував зміни) - мені доведеться робити нові зміни

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

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

Я шукаю поради у вас, як вирішити цю ситуацію? Це нормальна ситуація, і я просто гіперчутливий до цього?

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

В основному, застосуйте певний цикл зворотного зв'язку, коли керівництво знає, що ви збираєтеся будувати. Напишіть свої власні документи до тих пір, поки вони не отримають повідомлення.

Карти історії

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

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

Здається, найбільша проблема тут - це той самий спеціальний спосіб управління змінами. У вас є те, що спритний / Scrum вважають "власником товару", який дає відгуки, але процес погано задокументований і погано продуманий.

Напевно, ви хочете подивитися на моделі в Scrum та їх уявлення про те, що є ефективним власником товару , щоб допомогти повідомити про наступні кроки.

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

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

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

Після схвалення відправте їм свій графік того, коли елементи будуть завершені для тестування, і наведіть їх на час проведення тестування / затвердження завершення.

Я знаю, що створення такого типу документації не є тим, що ви стали програмістом, але ви можете або ризикувати викинути ці списки, або продовжувати викидати ваш важко зароблений код.

Відсунути. Відповідальні особи повинні побачити, скільки коштують ці запити.

Зміни вимог не завжди є поганими. Головне - пам’ятати свого клієнта. Ймовірно, ваш начальник є вашим замовником у цьому випадку. Вам потрібно повідомити свого начальника про те, що ви незважаючи на те, що ці постійні зміни вимог обмежують вашу здатність виготовляти продукт, який йому найбільш корисний. Цілком можливо, що бізнес виграє від вас, постійно реагуючи на зміни. Якщо так, то це їхня бізнес-модель, і ви нічого не робите, хоча в цьому випадку рекомендую бігати за горами!

Люди, які розчаровані змінами вимог, часто оцінюються тим, наскільки добре вони управляють кожною зміною. Цей показник "достатньо оброблених змін", ймовірно, є джерелом вашої реальної неприємності. Подумайте про обговорення кращих показників з вашим начальником. Коли я стикаюся з постійно мінливими вимогами, я прагну писати вміст, який дозволяє мені адаптуватися до постійно мінливих вимог. Замість того, щоб запускати моделювання та аналізувати дані щодня, я напишу інструменти, які роблять процес запуску моделювання та аналіз даних дешевшими та отримуватимуть винагороду з часом. Якщо це все ще занадто божевільно, я можу навіть написати інструмент для написання інструментів!

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

Після того, як будуть виявлені достатньо важливі вимоги, попросіть особу, яка перебуває у Project Ownerролі, вийти на них та замкнути їх на тиждень, поки ви їх будуєте. Виділіть достатньо роботи для себе, де ви будете зайняті, і нехай повноваження знають про ваше виділення. тобто якщо за тиждень ви можете виробляти роботу на 16 пунктів, а у вас 16 пунктів роботи, то ви повністю використані за цей тиждень. (Концепція балів походить від спритного робочого потоку)

Якщо зміни відбудуться в середині тижня, вимовіть ці магічні слова:

Я можу зробити [цю нову функцію], [цю нову зміну], [тощо], але що ви не хочете зробити ?

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

Якщо вимоги змінюються частіше, ніж вам, можливо, вам доведеться домовитися про більшу стабільність у вашому оточенні.

Словосполученням "Вимоги змінюються" іноді зловживають ІТ-люди. Те, що ви описуєте, насправді є зміною вимог, але це може бути через те, що одна чи декілька з наведених нижче (я не знаю достатньо вашої справи, тому наступне може бути, а може і не застосовуватися):

1. Прагнення керівництва якомога швидше задовольнити кінцевого користувача та показати швидкий прогрес.

2. Відсутність детального аналізу. Пам’ятайте, що аналітикам потрібно задавати питання, чому не тільки що. Аналітикам потрібно "думати" з кінцевим споживачем про "рішення", а не лише приймати замовлення.

3. Відсутність формального процесу перевірки та підтвердження вимог з подальшим затвердженням.

4. Попросивши некоректну особу виконувати одну чи декілька ролей, вони не обов'язково проходять підготовку для таких ролей, як Business Analyst або System Analyst.

5. Обмежене прототипування.

6. Припущення / страх, що це потрібно зробити швидко, а якщо не його ІТ винен.

Якщо не буде вирішено належним чином все вищезазначене, відносини між ІТ та бізнесом / кінцевим користувачем будуть напруженими. Зверніть увагу, що це не означає, що зазначене вище є переконливим. Є й інші фактори, які призводять до стресових ситуацій, схожих на вашу ситуацію, але я думаю, що цей список повинен вас продовжити.

Я думаю, вам слід підійти до цього з кількох напрямків:

1. Попросіть усіх зацікавлених сторін (включаючи всю команду розробників) зустрітися (офлайн / онлайн) з бізнес-радником і спробувати разом зрозуміти домен, бачення, а потім вимоги мозкового штурму.

2. Формуйте вимоги / розповіді користувачів, оцінюючи кожне:
   a. Пріоритетність (терміновість / важливість)
   b. Зрілість (наскільки чітко визначена - зрозуміла та погоджена більшістю власників акцій *)
   c. Складність (приблизна оцінка)
   
   Вибираючи, над якою вимогою / історією користувача працювати далі, слід враховувати всі три фактори. Якщо вимога має низький термін погашення, додайте перед нею науково-дослідну місію, в якій ви зв’язуєтесь із усіма зацікавленими сторонами, досліджуйте обґрунтування вимоги та краще визначте вимогу (запишіть випадки використання та / або створіть дротяні кадри та подайте їх) перед тим, як діяти на ній.

3. Постарайтеся продумати кілька кроків вперед під час проектування перед кожною реалізацією - спроектуйте гнучку архітектуру, яка має можливість прийняти зміни.

4. Спробуйте адаптувати спритний процес розробки, наприклад, SCRUM або Kanban - це забезпечить вам набір інструментів для розробки продукту зі змінними вимогами.

Ви також повинні попросити модераторів перенести це запитання на PM.stackexchange.com (позначаючи його), оскільки, хоч це питання підходить тут, воно б там краще підходило.

(*) Власники пакетів домовленостей: бізнес, маркетинг, управління проектами, розробка та забезпечення якості.