- Київ
- +380 (98) 543 13 33
Створенням технічних вимог професійно займаються бізнес-аналітики. Ця тема вже стала на стільки обширною, що потребує вивчення протягом багатьох років, і деякі українські ВНЗ вже готують спеціалістів за цією спеціальністю. І навіть якщо взяти до уваги той факт, що технології еволюціонують кожні пʼять років, написати технічні вимоги, — задача, що під силу більшості офісних працівників.
Можу припустити, що Ваша цікавість до теми може бути зумовлена однією з причин: робоча задача, або Ви розмірковуєте над зміною професії. Тому я вирішив написати цикл статей, в яких Ви знайдете відповіді на обидва питання, але про все по порядку.
Як працювати з бізнес-процесами
Як і будь-яка інша сфера людської діяльності, розробка програмного забезпечення починалась з задоволення потреби. Технічні вимоги (як документ) заслужили свою популярність в якості зручного способу формалізації потреб замовників. Оскільки останні часто можуть бути непередбачуваними, дискутувати значно простіше, навколо документу.
З розвитком та ускладненням технологій, компанії почали використовувати технічні вимоги для оцінки тривалості та складності робіт, а для постановки задач розробникам почали використовувати технічне завдання.
Тож в чому полягає різниця між технічними вимогами та технічним завданням? — Це рівень деталізації. Документи створюються для різних учасників процесу: технічні вимоги формують та обговорюють ТОП-менеджери компаній, а технічні завдання, — адміністратори та користувачі майбутніх програм.
Технічні вимоги на розробку програми — це документ, в якому зібрані основні правила та обмеження, яким має відповідати програмне забезпечення.
Щоб краще зрозуміти сутність цього документу, розглянемо його використання під час реалізації програмного продукту. Процес розробки або оновлення програмного забезпечення виглядає наступним чином:
Після того як ідентифікована проблема і прийняте рішення про те, що вона буде вирішуватись оновленням програмного забезпечення, один або декілька аналітиків починають працювати над її вирішенням. Незалежно від складності проблеми, технічні вимоги або технічне завдання, і будуть планом її вирішення. Інколи активна фаза розробки починається ще до завершення формування всіх технічних вимог, але вони обовʼязково узгоджуються з усіма ключовими співробітниками. Після узгодження описової частини, розробники програмного забезпечення починають реалізовувати це рішення, а тестувальники перевіряють їх роботу. Оскільки кожна задача може мати декілька способів вирішення, то план може змінюватись. Це призведе до зміни та повторного узгодження технічних вимог.
Після закінчення активної фази розробки, кількість робітників над проектом зменшується, і наступає фаза підтримки проекту. На цьому етапі можуть виникнути помилки повʼязані з нестандартною поведінкою системи або користувачів, але оскільки рівень розробників зазвичай нижчий, ніж в активній фазі, то для оперативного вирішення питань, потрібна вичерпна технічна документація.
Як Ви вже могли зрозуміти, протягом всього життєвого циклу продукту, з технічними вимогами працює багато людей. Компанії часто схильні визначати їх вплив через посади в трудових книжках, але для опису загальної картини краще відштовхуватись від ролей, які вони виконують.
| Роль | Опис ролі | Особливості ролі |
| Автор технічних вимог | Займається дослідженням робочого процесу, опитуванням користувачів, консолідацією інформації, та створенням технічних вимог. | Для ефективної роботи знадобляться знання в наступних напрямках:Знання предметної області, в якій працює підприємство.Класичні бізнес-процеси: маркетинг, продажі, бухгалтерія, і так далі.Базові знання з психології допоможуть краще розбиратись в страхах користувачів та будувати комунікації.Принаймні теоретичні знання архітектури програмного забезпечення та баз даних. |
| Головний замовник | Власник, або генеральний директор компанії, який зацікавлений в збільшенні ефективності роботи компанії за рахунок нового програмного забезпечення. | Цінують свій час та розмовляють мовою цифр, тому нову інформацію варто подавати у вигляді зрозумілих презентацій. |
| Замовники | ТОП-менеджери компанії, які приймають активну участь в розробці програмного забезпечення та мають власне бачення нового продукту. | В маленьких компаніях вони схожі на головних замовників, а в великих, – можуть бути дуже вибагливими. |
| Адміністратори системи | Менеджери середньої ланки, які мають досвід роботи з подібними системами, або колишні користувачі системи. | Найбільш зацікавлені в функціоналі адміністративної частини програмного забезпечення: звіти, дашборди, гнучкість налаштувань, додавання нових користувачів, і так далі. |
| Користувачі системи | Робітники які обслуговують, або відповідають за виконання основного бізнес-процесу. | Зацікавлені в зручності обслуговування бізнес-процесу без додаткових затрат часу: валідації та автозаповнення полів форм, вивід на екран корисної інформації, і так далі. |
| Адміністратори команди розробки | Люди, відповідальні за ефективність робочого процесу розробки програмного забезпечення. | Зацікавлені в системному підході до процесу розробки нової програми, та в максимально чіткому формулюванні технічних вимог. |
| Аналітики | Перетворюють технічні вимоги в чіткі та однозначні задачі для розробників. | Виходячи з власного досвіду, можуть пропонувати кращі рішення для вирішення Ваших задач, або ж переконувати, що запропоноване рішення є найкращим. |
| Програмісти та інші інженери | Виконавці, які перетворюють технічні вимоги та технічні завдання в готовий програмний продукт. | Відповідають за те, щоб програма працювала стабільно та без збоїв, а не була зручною для користувачів. |
| Тестувальники | Виконавці, які перевіряють якість роботи програмістів. | Дуже схожі на програмістів, але дивляться на програму з іншої точки зору. |
В світі вже існує дуже багато гарного матеріалу на тему того, як створювати технічні вимоги: статті, реферати, доклади, книжки, і так далі. В цій літературі ідеально описана утопічна структура документу, яку Ви маєте отримати на виході. Нажаль, вона не має нічого спільного із внутрішнім ринком України, і навряд знадобиться Вам при досягненні цілей, про які ми говорили на початку цієї статті. Можливо ми порефлексуємо на цю тему в одному з наступних матеріалів серії, але зараз нам краще зосередитись на створенні життєздатного документу. Тому я пропоную до Вашої уваги наступну структуру документу, яка охоплює кожну роль на проекті.
| Розділ вимог | Опис розділу |
| Бізнесові вимоги | Мають бути оголошені головним або іншими замовниками якомога раніше. Як правило, це опис проблеми, яку має вирішити нове програмне забезпечення. Наприклад, це може бути збільшення продажів, або зменшення вартості доставки товару за рахунок оптимізації логістики.Рекомендую узгоджувати з замовниками цілі, які можна легко порахувати як до моменту створення нової програми, так і після її впровадження. |
| Загальний опис програмного забезпечення | Потрібен замовникам та менеджерам проекту для того, щоб оцінити тривалість та складність робіт. В цей розділ варто додати опис всіх бізнес-процесів та інтеграцій з іншими системами. Для оцінки майбутнього навантаження, варто описати кількість майбутніх користувачів, та кількість дій в системі, які вони будуть виконувати.Також загальний опис системи буде корисним для інженерів, оскільки вони зможуть знайти найкраще рішення тільки тоді, коли будуть бачити картину повністю. |
| Функціональні вимоги | Опис функціоналу, який варто узгоджувати з адміністраторами та користувачами майбутньої системи. У випадках, коли користувачі задіяні в більш ніж одному процесі, варто розділяти їх на групи, і працювати з кожною групою окремо.Під час обговорення функціональних вимог, у аналітиків-початківців може виникнути додаткова потреба в аргументації, чому деякі задачі, які не допомагають досягти бізнес-цілей, не можуть бути виконані одразу. |
| Вимоги до даних / таблиць даних / баз даних | На кожному великому проекті є інженери з розробки баз даних. І цей розділ призначений для них. Але оскільки їх досвід роботи з архітектурою баз даних буде більшй за Ваший, то я б радив краще приділити більше уваги опису бізнес-процесів і розрахунку навантаження на систему. В залежності від цих даних, інженери будуть проектувати оптимальну архітектуру. |
| Нефункціональні вимоги | Один з найбільш обширних і неоднозначних розділів технічних вимог. До нього відносять все, що не впливає на користувачів та адміністраторів: безпека, швидкодія, та відмовостійкість системи, логування дій користувачів, швидка локалізація, і так далі.Як правило, більшістю цих питань займаються девопси та архітектори майбутнього програмного забезпечення. |
| Вимоги до дизайну | В літературі цей пункт часто відносять до нефункціональних вимог, але я вважаю, що сьогодні настав час підвищити його значимість. Люди купують очима.Так само як варто делегувати відповідальність за структуру баз даних відповідним інженерам, відповідальність за зручність у користуванні та зовнішній вигляд майбутньої програми краще делегувати дизайнеру.Немає сенсу вдаватись в деталізацію вимог до рівня опису полей форм. Достатньо передбачити реалізацію інтерфейсів для людей з порушенням зору. |
| Функції, які працюють без впливу користувачів | Це дії майбутньої системи, які будуть виконуватись автоматично. Наприклад, це може бути оновлення довідників, або резервне копіювання. Можливо, його було б доцільніше розмістити в розділі функціональних вимог, проте Ви можете це зробити після його фіналізації.Функціонал, описаний в цьому розділі, також потребуватиме витрат часу інженерів на його реалізацію, тому не варто про нього забувати при плануванні ресурсів. |