Рецензія на книгу «Розробка вимог до програмного забезпечення» Карла Вигерса і Джой Бітті

У 2018-му році перевидали книгу «Розробка вимог до програмного забезпечення». Колеги прислали мені посилання на видання. Автори додали прийоми для роботи в agile-проектах, визначення ролі аналітика та рекомендації по автоматизації. У Мережі ходять вкрай суперечливі відгуки. Замовив книгу і розібрався в питанні.

Плюси

Розписано все

Новачки отримають повне уявлення про роботу аналітика. Профі згадають те, з чим стикалися самі. Розібрані всі стадії створення специфікацій. В додатку Б-посібник, складений за принципом «проблема — рішення». Саме зміст виступає в ролі підказки. Докладні чек-листи містяться майже в кожній главі. Наприклад, шаблон специфікації включає 8 пунктів, підпункту 24 та два додатки. Вичерпне керівництво.

Легко знайти інформацію

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

Для всіх, хто в ІТ

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

Пояснення термінів

З незвички складно читати керівництво, але після 700-ої сторінки стає легше 🙂 По ходу викладу у кожного поняття наводиться в дужках його оригінал англійською. Це зручно, тому що перекладач не завжди точний і можна відкрити Вікіпедію англійською. В кінці книги розміщується словник термінів з поясненнями. Правда, там не всі поняття, які зустрічаються в керівництві. Щоб доповнити список, довелося дописати від руки 50 нових фраз і номери сторінок.

Мінуси

Багатослівність

Автори зловживають довгими пропозиціями і непотрібною інформацією. З-за цього сенс вловити складніше.

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

«… методи спілкування можуть забезпечити ефективну синхронізацію у часі і просторі всередині команди».
А на форзаці написано, що це керівництво, а не філософський трактат.

«Діаграма станів для стану замовлень страв».
Автори два рази не повторюють, не повторюють.

«Стівен Уитхолл (Stephen Withall, 2007) описує багато схем для точного документування даних (які також називають інформацією)».
Дані = інформація. А в цьому щось є!

І такий смисловий шум по всій книзі. Виникає підозра, що авторам платили за рядка.

Граматичні помилки

По ходу читання нарахував їх більше 160. Всі помилки в рамках шкільної програми. Наприклад: пропускаються слова, використовується «-ться» замість «-ться», повторюються пропозиції в одному абзаці, зустрічаються банальні помилки, пропускаються коми, плутаються поняття, які пишуться схожим чином.

Перша помилка зустрічається, як тільки відкриваєш книгу. У Кріс немає манії величі, просто її переплутали з Карлом, який присвятив їй книгу. Вони подружжя.

А як вам така фраза?
«Перепроектувати систему для більш якісної обробки мінливих бізнес-правил, які було складні проект підтримки».

Product placement

По ходу викладу автори неодноразово згадують продукти Microsoft. Вони настільки відомі, що немає сенсу писати про них. А коли треба назвати системи управління вимогами (ДОБУ), то автори про них мовчать. Я ж лише заради них цю главу і читав. Просто книгу випускала Microsoft Press, а у «мелкомягкіх» немає повноцінної ДОБУ. Лояльність компанії переважила професійний обов’язок.

Недомовленість

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

Або вказано, що система повинна дозволяти клієнту вказувати метод оплати. Але не написано про підтвердження оплати. Який сенс вказувати, як ти хочеш оплатити, якщо оплату не можна підтвердити? Пропущена заключна стадія.

Інші етапи прописані в додатку досить детально. На їх фоні пропущені ланки в ланцюжку варіантів залишають відчуття недомовленості. Зрозуміло, що додатки даються для прикладу, але все ж.

Що актуально для Росії?

Перед прочитанням думав приблизно так: «Що американець може порадити нам? У них все в цифрі, і немає ніяких проблем». З’ясувалося, що проблеми приблизно однакові.

Немає культури поваги до вимог

Як сказав знайомий розробник, «я не читаю ТЗ, а відразу пишу код». Це не збалансований підхід. Реалізація не узгоджується із зацікавленими особами, не вивчаються додаткові варіанти, упускаються з виду зв’язки з іншими елементами. Збільшується ризик помилки і її ціна. Якщо користувач виявляє помилку після релізу, то її ціна зростає в 21 раз. На стадії ТЗ усунути її набагато дешевше. Але поки в компаніях серйозно не ставляться до специфікації, буде «хотіли, як краще, а вийшло, як завжди».

Не виробляються бізнес-вимоги

Бізнес-вимог (business requirements) описують, чому організації потрібна система, тобто цілі, які компанія має намір досягти з її допомогою. Але якщо подивитися на середні російські компанії, то створюється дивне враження. Одні незрозуміло навіщо роблять, а інші незрозуміло навіщо купують. Зате роздуваються амбіції і робиться ставка на котиків в Instagram. Буває, спілкуєшся з черговим генієм з «Сколково», а він пассионарно нав’язує клієнтам вигадані потреби. В результаті компанія виглядає як овоч, а бюджет – як діряве відро.

«Прив’язуються» до дизайну

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

Немає розуміння специфіки роботи аналітика

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

Не використовується інструментарій

Один начальник хотів, щоб ті, хто працює з ТЗ, знали їх близько до тексту. Це нереально. У компанії кілька десятків ТЗ, і їх число збільшується. Якщо ти сам закінчив складати ТЗ місяць тому, ти все одно його забуваєш, бо потім поринаєш у 2-3 нових. Проблема вирішується не за рахунок пам’яті, а за рахунок впровадження систем управління вимогами (ДОБУ). Вони підтримують виявлення, управління, відстеження та висновок вимог. Але за них треба платити, і роботодавці вважають за краще працювати по-старому, як у приказці:

Два солдата з будбату замінюють екскаватор.
А один з ВДВ замінює їх подвійно.

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

Висновок

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