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

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

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

Книга дает советы и рекомендации. Советы тем, кто только поднимается в гору аналитики, и рекомендации тем, кто стратегически размышляет и думает. На 118 страницах текста дается описание того, что в большой аналитической науке охватывает несколько областей знаний (об областях знаний см. BABOK). В книге целенаправленно не приводятся термины со ссылкой на умный трактат, при этом на доступном уровне раскрываются определения, которыми часто пользуется специалист в данной области. Книга состоит из 4-х основных глав, в которых последовательно дается изложение простого на понятийном уровне, но непростого в практической плоскости, процесса получения удовольствия от проекта. В данном случае под проектом понимается деятельность, направленная на получение удовлетворительного для заинтересованных сторон результата.
С первых страниц постепенно погружаешься в недра и особенности работы аналитика, в процессе разработки требований. При этом данное погружение происходит незаметно. Принято считать, что человек в среднем запоминает 7 объектов. В книге сначала в лоб дается 7 простых истин, а далее число 7 превращается в 2 области. И как говориться, одна мало, три много, а две в самый раз. Данные области легко запоминаются, но нелегко реализуются. Поэтому не спешите прыгать из области проблем в области решений, прежде всего, подумайте. А подумав, доведите ваши предложения до проектной команды.
Для чего все это нужно? Книга дает ответ и на этот вопрос: управляй ожиданиями Заказчика. Т.е. с первых моментов взаимодействия с Заказчиком, если есть такая возможность, формируйте согласованное понимание того что будет сделано за какие сроки, и за какой бюджет. При этом сформировав представление, помните о том, что приоритеты могут измениться.
Что или кто же может менять приоритеты? Ответ: заинтересованные стороны. При этом работа аналитика, участвующего в разработке ПО, выявить эти стороны и попытаться «спроектировать будущее», сохраняя свою «независимость». Каждая сторона может выдвигать свои пожелания, т.е. быть источником требований.
Стороны-источники условно разделены на 4 группы: люди, документы, системы, новые технологии. С каждым из источников надо работать. Как, кого и что выбрать или на что уделить внимание, какие методы использовать — все это можно почерпнуть из книги.
Люди бывают разные, со своими знаниями и умениями. Вроде ничего не значащие слова, но и из данного подхода аналитик может почерпнуть выгоду для проекта, а руководитель на первоначальном уровне оценить проектную команд. Как не странно, но с людьми надо общаться, т.е. коммуницировать. И это одна из основных задач аналитика. Общий подход к решению задач по коммуникации заключается в выполнении нескольких шагов: подготовка, проведение, заключение. Т.е. как бы это громко не звучало, нужен простой, но в тоже время комплексный подход при общении.
Также при работе с источниками необходимо помнить, а самое главное не забыть спросить про смежные системы и документы.
Вопросы заданы, информация собрана, можно и на печке полежать. А не тут то было. Встаем и начинаем работать с собранными требованиями. Основная цель работы это в структурированном виде представить собранные знания, при этом, не забыв подстелить себе соломку, а лучше перину. Т.е. соблюсти баланс удобство чтения — удобство работы.
Структурировать можно по-разному. Один из способов это сформировать документ. Помните, театр начинается с вешалки, а документ с введения. И в этом, на первый взгляд не важном месте в документе, надо по возможности кратко раскрыть, зачем и для кого представлена информация, и что можно узнать из документа. Уважая чужое время желательно в начале документа также разместить и полезную информацию (о полезной информации более подробно в третьей главе книги). Кроме введения также важны и структура, и сам текст документа. Основной совет: ориентируйтесь на культуру организации, в которой Вы работаете или используйте шаблоны, приведенные в книге. Лаконичность и четкость изложения, вот те подходы, к которым надо стремиться.
Структурировав, надо решить, а что же делать? Т.е. определить этапность и очередь работ. Важность и приоритет помогут в решении задачи оценки требований.
Не ошибается тот, кто ничего не делает. Поэтому сделав, проверь. Собрав требования, выполни проверку текста каждого требований, отвлекись от своего творения и заново выполни проверку законченного набора требований. Не пугайтесь, всего две проверки, а может и три или больше, как пойдет.
Вот и законченно погружение, пора всплывать. Точнее подвести итоги и ознакомиться со списком литературы на 117 странице. Если будет желание, почитайте, иногда полезно.
Подводя итог, делаешь однозначный вывод — книга полезна, тем, кто еще не дошел до четвёртого уровня знаний и умений.
Используя сведения указанные в книге кроме расширения своих знаний, можно попытаться совместить области знаний и необходимые к прочтению книги. А то и решиться на выпуск многотомного издания, или других частей в качестве продолжения книги.

Источник: http://qualificationloop.blogspot.ru/