Разработка требований к программному обеспечению

В чем не соврали — в том не соврали: в книге действительно очень подробно рассказывают по требованиям к программному обеспечению (далее — ПО). Почему они нужны и зачем про это писать кирпич на 700+ страниц и поговорим.

Думаю, очевидно, что один человек не может построить целый многоквартирный дом, место для проживания сотен людей. Строительство дома разбито на определенные этапы, и какие-то из этих этапов незыблемы для строительства уже многие тысячи лет — например тот факт, что дом строим снизу-вверх, а не наоборот. Строительства дома — работа для сотен, если не тысяч людей, а чтоб каждый из этих людей выполнил свою работу как надо, и дом не развалился — на обучение некоторых уходят тысяч часов, а некоторых — десятки тысяч часов. Архитектор занимается планом дома — помимо этого планом дома еще занимаются и конструкторы, и инженеры-технологи. Проект состоит из большого количество слоев — каждый слой проверяет, вступает ли он в конфликт с другими слоями, есть лица, занимающиеся проверкой корректности расчетов (сейчас с помощью программ). И только когда документация готова — начинается стройка, которая уже совсем другая история, но без которой тоже дома не получится.

Аналогично с ПО — если вам кажется, что что-то работает легко, удобно, быстро и понятно — это всего лишь означает, что кто-то приложил титанические усилия для того, чтоб это таким сделать. Многие не понимают сложностей, и им кажется, что дом — он физический, большой, сложный — там фундамент не перезалить. А программа — ерунда. Поставить лишнюю запятую, и все заработает. Именно данному вопросу и посвящена эта книга — объяснить читателям, что требования к ПО — это как требования к дому. И если вы построили шестнадцатиэтажный дом, не получится перестроить его в атомную электростанцию только потому, что кто-то что-то забыл сказать на стадии проектирования.

Авторы с дотошностью маньяков постарались алгоритмизировать (правда представили текстом, а не схемой) всю работу, которую необходимо провести перед тем, как приступать к разработке ПО. Попутно объясняя, почему при разработке ПО нужно ТАКОЕ количество разные специалистов — инженеры, бизнес-аналитики, системные аналитики, программисты, разработчики, руководители рабочих групп, руководитель проекта, дизайнеры, психологи и пр. (Можно ли обойтись без них? Можно, конечно — можно и здание построить своими силами, без проекта. Только потом не обижайтесь.) Главная цель — подвести к мысли, озвученной Людмилой Прокофьевной Калугиной из х/ф «Служебный роман»: «Делом нужно заниматься серьезно, или не заниматься им вообще». Ну и, конечно, корпоративные товарищи знают — построить ПО может быть совсем не дешевле, чем построить офис, где сидит вся фирма. А заработать на ПО можно значительно больше, чем на другом, «более материальном» объекте.

Что в книге раздражает — гигантское количество воды. Авторы не хотели «декларативно» писать, и пытались убедить в каждом своем тезисе своего читателя — причем, для надежности, сделать это несколько раз (итеративная модель убеждения). В результате даже самые безобидные тезисы растягиваются на десятки страниц. Не спорю — эффект есть, я действительно верю авторам, что так надо (правда, я и до этого верил), но в результате этого бесконечного повторения теряется основная мысль, и читатель неминуемо тонет в мелких частностях. Собственно, толщина этой книги — это главная претензия к ней — её спокойно можно было бы сократить вполовину, и на качество изложения это нисколько бы не повлияло. Но авторы захотели иначе. Ну что поделать.

Книгу я бы порекомендовал к прочтению, но не целиком, а «по диагонали» — выбирая основные мысли. Целиком это прочитать не будет ни времени, ни сил. Кому?

1. Студентам, которые учатся на информационных-аналитических направлениях, чтоб они не путали «разработчика» и «программиста»;

2. Лицам, которые хотят у себя что-то внедрить (я понимаю, что это бесполезно — в России лица, принимающие решения, слишком горды для этого);

3. Непосредственно самим разработчикам/программистам, чтоб они понимали, где их ждут чудовища в этом лесу, и какие проблемы сэкономят им силы и нервы, а заказчику — деньги.

А так книга стоящая, но перетянутая.

Очень узкоспециализированная книга, но для своей целевой аудитории очень нужная и полезная. Назвала бы её настольной книгой бизнес-аналитика в АйТи компаниях. Очень подробно про выявление, описание, согласование и управление требованиями к программному обеспечению. Вплоть до того в каких случаях какие вопросы стоит задать заказчику и где какие способы визуализации требований лучше подходят. Много практических советов. Так что специалистам необязательно изобретать велосипед, можно открывать книгу, искать подходящую ситуацию и изучать инструменты и механизмы, которые для неё подходят. А дальше уже можно их совершенствовать и модернизировать под себя. Так что эта книга - база, на основе которой можно смело дальше развиваться. Помимо бизнес-аналитиков её конечно же необходимо знать руководителям проектов и руководящему составу компаний. По диагонали можно почитать системным аналитикам, возможно для них тоже найдётся полезный материал. Ну и какие-то блоки неплохо бы знать представителям заказчиков, которые отвечают за создание, реализацию и приемку ПО. Чтобы люди во всяком случае понимали, что требуется с их стороны, и чего они могут ждать от исполнителей.
А ещё мне очень понравилась следующая фраза

это хорошо подходит не только для профессиональной сферы, но и для жизни.