О разработке требований

Бывало ли у вас, что непонятно, что должна делать эта фича\таска\проект ?
Бывало ли, что при чтении кода или работе с программой становилось непонятно: это бага или фича ?
Возникала ли у вас хоть раз мысль: "что этой формулировкой тут хотели сказать, %№:%№ ?!" ?
Случалось ли хоть раз, что заказчик говорил вам: "это не то, что я вам пояснял !!!" ?

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

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

В общем думаю без преувеличения можно сказать, что все это видели, видят и еще долго будут видеть в будущем =)

вот как-то так и работаем =)

К чему это я: за 30-40 лет существования более-менее коммерческой части ИТ мы научились делать сложные, большие, высоконадежные, масштабируемые, качественные системы, но до сих пор не научились понимать, ЧТО и ЗАЧЕМ надо все таки реализовать.А процент успешных проектов - так и остался на уровне 30-40 %, с небольшим ростом около 5% за последние годы.
Новые технологии не спасают, т.к. проблема так и осталась в людях - мы просто плохо представляем, что же они хотят получить от нашей системы в итоге.

Эти мысли переодически меня волнуют  и потому, чтоб чуть лучше понимать почему такое случается, и что мы все делаем не так -  прочел "Разработку требований к программному обеспечению" Вигерса.

И МНЕ ОТКРЫЛОСЬ!

Шучу конечно)) Ничего сверхестественного не открылось, но где потенциально профакапить можно стал понимать лучше)

Вобще данная книжка по праву должна считаться "настольной книгой аналитика" и скорее всего ваш аналитик читал ее, если нет - то пусть прочтет.
У вас нет аналитика ?
Но кто-то же выполняет его роль ? Разаботчики\ПМ\ПО\юзабелист\маркетолог ? 
Никто ?
А ну тогда ясно почему вам приходиться переделывать, что-то по 5 раз прежде, чем заказчик это примет.
Кто-то эту роль выполняет - если он выполняет ее неявно и тяп-ляп - вам же хуже.

И в интересах компании, чтоб кто-бы ни брал на себя обязанности аналитика, чтоб он мог сказать почему и зачем так реализована КАЖДАЯ фича в вашем продукте.


Хотя бы вскользь прочитав первую главу, вы поймете: КТО, ЧТО и ПОЧЕМУ.

Анонимные пользователи

Кто.

Это в первую очередь те для кого создается продукт(клиенты): конкретные классы пользователей, которые хотят решить свои задачи. 
И пусть один из этих классов - холодильник, использующий ваш интернет магазин для заказа еды владельцу, но у него есть свои пожелания, ограничения и требования. 
Некоторые пользователи могут быть привилегированнее других, и при конфликте требований(да такое бывает =)!) зачастую важнее решить их задачу. 
Некоторый класс пользователей можно случайно забыть и тогда счастье тотальной переделки продукта вам обеспечено, т.к. забыли спросить вон у тех товарищей, что им надо.


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


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

ЧТО ?!

Что и почему.

Что такое требования ?
Как их разрабатывать и как ими управлять?
Зачем ими заниматься ?
Почему у хороших людей могут появляться плохие требования?
Как отличить хорошие требования от плохих?
Как заметить, что какие-то требования пропустили?
Как требования разрастаются и как происходит их "золочение" ?

Если вы не можете ответить на хотя бы 1 из вопросов или возникает смутное ощещение, что вы не понимаете о чем это - значит вам надо прочитать 1ю главу, как минимум =)

Как.

Вторая глава посвящена правильной разработке требований.

В кратце я бы сказал так: если для каждой фичи и, соответствующей строчки кода, реализующей эту фичу, можно сказать какое требование пользователей они реализуют (с ссылкой на соответствующий документ и индификатор требования) и наоборот, то вы на правильном пути.
Если при этом пользователи вам говорят: "это именно, то что мы хотели и ожидали", то скорее всего можно смело закрыть эту статью и занять своими делами =)

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

На эти и тысячи других увлекательных вопросов вы сможете узнать в нашем супер-пупер издании, которое так же излечивает гемморой, головную боль. И в добавок если вы позвоните прямо сейчас, то получите ... супер приз - АВТОМОБИЛЬ!!!.

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

Куда.

Все эти полезные знания конечно хорошо, но ими еще надо как-то управлять, да еще и требования после того, как их узнали от клиентов имеют привычку периодически меняться, т.к. клиенты тоже живут своей жизнью и бизнес у них не стоит. И чтобы вам в голову не приходила мысль сделать слоеный word (вырезанный кусочек, если тему потрут). Лучше прочитать 3ю главу о том, как этими самыми требованиями управлять, связывать и прочее.

Ну а так, как к этому моменту вы поймете насколько у вас все плохо, то 4я глава расскажет вам как реализовывать этот самый процесс построения требований =)

Кроме того для лентяев и тех кому все таки лень читать книжку в ее конце есть пара приложений, с целью само проверки насколько хорошо вы управляетесь с требованиями.
Вырезка из CMMI рассказывающая, как эти самые процессы совершенствовать.
И руководство по поиску  и решению проблем, связанных с требованиями (куча таблиц, показывающих, что 90% ваших ежедневных проблем - неправильная работа с требованиями=))
Ну и естественно пример, как оно должно быть =)

Приятного чтения.