«Доктор, который ничего не знает»

По мотивам книги «Требования для программного обеспечения:

рекомендации по сбору и документированию»

Начну с того что любая книга - это труд. Поэтому огромное спасибо Илье Корнипаеву за проделанную работу. Приобретая книгу, Вы получаете издание 2013 года, в мягком переплете, размером 148 x 210 мм, весом около 168 грамм.

И вот она в руках. Хочется подтвердить слова автора, что для меня это удачный формат книги. Небольшая, белого цвета и главное удобная для прочтения в дороге.

Книга дает советы и рекомендации. Советы тем, кто только поднимается в гору аналитики, и рекомендации тем, кто стратегически размышляет и думает. На 118 страницах текста дается описание того, что в большой аналитической науке охватывает несколько областей знаний (об областях знаний см. BABOK). 

В книге целенаправленно не приводятся термины со ссылкой на "умный трактат", при этом на доступном уровне раскрываются определения, которыми часто пользуется специалист в данной области. Книга состоит из 4-х основных глав, в которых последовательно дается изложение простого на понятийном уровне, но непростого в практической плоскости, процесса получения удовольствия от проекта. В данном случае под проектом понимается деятельность, направленная на получение удовлетворительного для заинтересованных сторон результата.

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

Для чего все это нужно? Книга дает ответ и на этот вопрос: управляй ожиданиями Заказчика. Т.е. с первых моментов взаимодействия с Заказчиком, если есть такая возможность, формируйте согласованное понимание того  что будет сделано за какие сроки, и за какой бюджет. При этом сформировав представление, помните о том, что приоритеты могут измениться.

Что или кто же может менять приоритеты? Ответ: заинтересованные стороны. При этом работа аналитика, участвующего в разработке ПО, выявить эти стороны и попытаться "спроектировать будущее", сохраняя свою "независимость". Каждая сторона может выдвигать свои пожелания, т.е. быть источником требований.

Стороны-источники условно разделены на 4 группы: люди, документы, системы, новые технологии. С каждым из источников надо работать. Как, кого и что выбрать или на что уделить внимание, какие методы использовать - все это можно почерпнуть из книги.

Люди бывают разные, со своими знаниями и умениями. Вроде ничего не значащие слова, но и из данного подхода аналитик может почерпнуть выгоду для проекта, а руководитель на первоначальном уровне оценить проектную команд. Как не странно, но с людьми надо общаться, т.е. коммуницировать. И это одна из основных задач аналитика.  Общий подход к решению задач по коммуникации заключается в выполнении нескольких шагов: подготовка, проведение, заключение. Т.е. как бы это громко не звучало, нужен простой, но в тоже время комплексный подход при общении.

Также при работе с источниками необходимо помнить, а самое главное не забыть спросить про смежные системы и документы.

Вопросы заданы, информация собрана, можно и на печке полежать. А не тут то было. Встаем и начинаем работать с собранными требованиями. Основная цель работы это в структурированном виде представить собранные знания, при этом, не забыв подстелить себе соломку, а лучше перину.  Т.е. соблюсти баланс "удобство чтения - удобство работы".

Структурировать можно по-разному. Один из способов это сформировать документ. Помните, театр начинается с вешалки, а документ с введения.  И в этом, на первый взгляд не важном месте в документе, надо по возможности кратко раскрыть, зачем и для кого представлена информация, и что можно узнать из документа. Уважая чужое время желательно в начале документа также разместить и полезную информацию (о полезной информации более подробно в третьей главе книги). Кроме введения также важны и структура, и сам текст документа. Основной совет: ориентируйтесь на культуру организации, в которой Вы работаете или используйте шаблоны, приведенные в книге. Лаконичность и четкость изложения, вот те подходы, к которым надо стремиться.

Структурировав, надо решить, а что же делать? Т.е. определить этапность и очередь работ. Важность и приоритет помогут в решении задачи оценки требований.

Не ошибается тот, кто ничего не делает. Поэтому сделав, проверь. Собрав требования, выполни проверку текста каждого требований, отвлекись от своего творения и заново выполни проверку законченного набора требований. Не пугайтесь, всего две проверки, а может и три или больше, как пойдет.

Вот и законченно погружение, пора всплывать. Точнее подвести итоги и ознакомиться со списком литературы на 117 странице. Если будет желание, почитайте, иногда полезно.

Подводя итог, делаешь однозначный вывод - книга полезна, тем, кто еще не дошел до четвёртого уровня знаний и умений.

Используя сведения указанные в книге кроме расширения своих знаний, можно попытаться совместить области знаний и необходимые к прочтению книги. А то и решиться на выпуск многотомного издания, или других частей в качестве продолжения книги.