Довгобуд в розробці: про проблеми управління вимогами

Чим загрожує довгобуд у розробці і з якими труднощами доведеться зіткнутися на цьому шляху? Як бізнес-аналітик компанії, яка 15 років займається розробкою і підтримкою одного продукту (СЕД), я вирішила поділитися своїми думками та прикладами з практики. Проблематика управління вимогами в будь-яких програмних продуктах з тривалим періодом реалізації – актуальне питання для аналітиків, керівників проектів і власників продуктів. І, можливо, для безпосередніх партнерів та замовників Docsvision, які очікують виходу нових версій і зацікавлених у появі нової функціональності.



До чого призводять гонки за термінами і коли гнучкі методології не підходять
Чому серед компаній-вендорів поширена тенденція відмовлятися від короткострокових проектів (у нашому розумінні це продукти з періодом випуску до 1 року) і політики частих релізів, а також гнучких методологій в розробці?
Наочно дає відповідь на питання картинка, на якій можна вибрати лише одне перетин:



Як правило, в короткостроковому проекті немає можливості реалізувати великий обсяг нової функціональності при підтримці належного рівня якості, тому найчастіше замовники не бачать для себе вигоди в переході на нову версію (будь-яке оновлення містить певну частку ризику, і вони замислюються, чи варто це того?). А для вендора будь-реліз — дороге задоволення, оскільки повноцінна версія – це комплект інсталяції, документації, проведення тестів продуктивності, регрессионное тестування, тестування оновлення і сумісності і ще цілий комплекс заходів, які потрібно встигнути порівняно невеликі терміни. Повертаючись до картинці вище, ми потрапляємо на перетину Якісно-Швидко або Швидко-Дешево. Оскільки ресурси не безмежні, це буде саме друге перетин (читай, криво). Напрошується висновок: часте оновлення версії продукту невигідно обом сторонам.

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

Так чи інакше, багато вендори, що знаходяться на ринку не перший рік, приходять до подібних рішень: цей підхід використовується і в компаніях такого масштабу, як Microsoft і Adobe. Але на етапі розвитку або через малих масштабів, у ряді продуктів від політики частих релізів відмовлятися не варто.

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

Я не відкрию Америку, якщо скажу, що в чистому вигляді ту чи іншу методологію ніхто не використовує. Що стосується проекту розробки Платформи, то можу сказати, що останнім часом у нас використовується своя власна, змішана методологія. Це може стати темою для окремої статті, в рамках даної варто відзначити, що це в якійсь мірі Waterfall з елементами Agile (так, буває і таке!): з одного боку, чітко визначені стадії проекту у довгостроковій перспективі, є детальна проектна документація для кожного етапу, якість має першочерговий пріоритет порівняно з ресурсами і часом, і все це – невід'ємні риси каскадної моделі розробки. Це дозволяє нам упорядкувати виробничий процес і зробити його більш контрольованим. З іншого боку, є рухливий список вимог, управління змінами, що властиво гнучкої методології.

Політика накопичувальних оновлень дає можливість надати готову функціональність до моменту релізу основної версії. Залучення кінцевих замовників у процес дозволяє вносити зміни у версію на підставі отриманих даних. Ми не змогли б собі цього дозволити, використовуючи класичний Waterfall, адже в ньому вимоги жорстко задані і кінцевий користувач отримує працюючий продукт тільки після релізу версії. На перший погляд, ми використовували переваги кожного з підходів, при найближчому розгляді – отримали і проблеми.

Проблеми довгобуду
1. Велика кількість вимог, кінцевий список яких спочатку не затверджений
З одного боку, збільшивши терміни реалізації, можна збільшити і кількість вимог, що включаються у версію. Трохи цифр: короткостроковий (в середньому, піврічний цикл) реліз ми випускали близько 35 фіч у версії, в останній версії з довгостроковим періодом поки заявлено близько 100. При цьому за 10 років в базі вимог було зафіксовано майже 1600 потенційних фіч, які замовники очікують побачити в продукті, і список запланованого на найближчу версію поступово зростає. Закономірне питання: до яких пір це триватиме?

2. Визначення пріоритетів та оцінки
Вирішення питання, озвученої у попередньому пункті – в розстановці пріоритетів серед відібраних власником продукту вимог з урахуванням отриманих оцінок (розробки, тестування, документування та ризиків), які робляться на підставі наданої аналітиком специфікації. У кожної компанії свої підходи до розстановці пріоритетів. Це може бути вивчення статистики запиту про реалізацію тієї або іншої фічі, результати конкурентного аналізу, партнерські зобов'язання, так і здоровий глузд ніхто не відміняв. Ми регулярно проводимо опитування серед замовників і партнерів, намагаємося отримати максимум інформації ззовні (наприклад, у нас відкрито портал «Ідеї і пропозиції», де кожен може залишити заявку або проголосувати за вже існуючі пропозиції). Способами отримання інформації є також семінари, вебінари та інші громадські заходи. На підставі всіх отриманих даних встановлюються пріоритети, але вони можуть змінюватися, за цим доводиться стежити в реальному часі. У нашій практиці найбільший вплив на позицію фічі в списку вимог виявляє критичність її проектів і загальна затребуваність: перш за необхідне, потім вже бажане. Підвищення пріоритету може сприяти загальний ефект від реалізації функціональності – мова про wow/killer фичах.
Наприклад, в одній з версій Docsvision була заявлена функціональність з управління статусом в системі (активний/відпустці/у відрядженні) самим співробітником із зазначенням періоду відсутності й заступника. Тобто співробітник, йдучи у відпустку в понеділок наступного тижня, може вказати в п'ятницю час своєї відсутності і працівника, що його заміщує. Останній при роботі в системі, починаючи з понеділка, отримує повідомлення про те, що він в означений період призначений заступником. Ця фіча в підсумку отримала більш високий пріоритет, ніж необхідна багатьом користувачам функціональність з контролю унікальності реєструються в системі документів.

3. Загальне і приватне



Ця проблема вперше виникає в будь-якому продукті на момент формування списку вимог, незалежно від періоду його реалізації. На відміну від проектного рішення, де рух йде від загального до приватного, в продукті все навпаки. Ми отримуємо ззовні окремі побажання, при цьому замовники часто описують кожен свою специфічну задачу, і побажань за схожою темі може бути кілька. Ключове завдання — звести і врахувати їх усі в конкретну вимогу. Але проблема може виникнути і повторно, і за той період, що розробляється версія (здрастуй, довгобуд), зацікавлені сторони можуть пропонувати нові рішення або уточнювати нюанси. Іноді доводиться вносити корективи з урахуванням цих пропозицій у вигляді запитів на зміну, що може викликати в результаті зрушення точки Stop Development. Не завжди виходить звести це просто до запису «1601-го побажання до розвитку системи».

Мені як бізнес-аналітику продукту в кожному такому випадку доводиться шукати компроміс — універсальне рішення, яке б влаштувало всіх.
Наведу приклад: сценарій по обробці негативних рішень (відмов) при узгодженні документів. Спочатку в системі була реалізована проста логіка, коли при отриманні негативного рішення від одного з учасників узгодження просто йшло далі, до інших узгоджувальних особам. Потім реалізували можливість при отриманні відмови повертати узгодження в стан підготовки, щоб у співробітника-ініціатора була можливість внести корективи в документ і почати узгодження заново. Після прийшли пропозиції по доробках: «зробіть так, щоб узгодження при цьому тривало, але можна було внести зміни в документ, запустивши при відмові консолідацію», «а нам потрібно, щоб тільки при відмові ген. директора скасовувалося узгодження». У результаті з'явилася настройка-перемикач різних режимів обробки негативного рішення, при цьому цю настройку можна використовувати по-різному для кожного окремого етапу.

4. Проблема айсбергів



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

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

Або в разі спрощення варіанти реалізації: якщо потрібно для початку зробити необхідний мінімум, а решту запланувати на майбутнє.
Приклад, коли вимога можна розділити.
Початкове вимога: «Підтримати інтеграцію з Microsoft Lync 2013 в контролах карток з можливістю збереження історії діалогів».
Після поділу: «Підтримати інтеграцію з Microsoft Lync 2013 в контролах карток» та «Реалізувати можливість збереження історії діалогів Microsoft Lync 2013 в картці».

Приклад, коли вимога краще не ділити, незважаючи на те, що допрацьовуються різні об'єкти.
«Необхідно зробити відображення за розрядами контролах Число і Ціле. Наприклад, замість 1230000 показувати 1 230 000. По можливості зробити такі ж доопрацювання і для Таблиці».
Реліз близько
Уявімо, що всі вимоги реалізовані, виправляються останні помилки, ось-ось буде готова документація, і всі з нетерпінням очікують завершення проекту і релізу. На цьому етапі ми можемо окинути поглядом результати своїх праць і підвести підсумки. Основне завдання заключного етапу – визначити допущені помилки проектування і недоліки «по гарячих слідах», переглянути повторно реалізацію всіх вимог, особливо взаємопов'язаних, а також реалізованих на самому початку проекту. Для довгострокових проектів цю об'ємну задачу краще розбити на ітерації. Це і буде попереднім прийманням продукту. У нас роботи за попередньою приймання виконуються аналітиком і власником продукту. Частина недоліків розробники виправляють помилки (до основного приймання продукту і релізу), а суттєві недоробки та помилки проектування можуть бути зафіксовані як вимоги на наступні версії (з перспективою включення у накопичувальне оновлення). Таким чином, у міру наближення до дати релізу і початку офіційної приймання продукту керівництвом і технічною підтримкою ми отримуємо комплексну оцінку результатів і частково список вимог на наступну версію.

Спасибі за увагу, шановні читачі! У цій статті я озвучила основні проблеми, з якими ми стикаємося при управлінні вимогами в довгострокових проектах, але це далеко не повний список. А з якими проблемами доводилося мати справу вам?

Ганна Курманова, бізнес-аналітик Docsvision.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.