Как читать требования
Заказчик на объекте принимает работу у подрядчика. Тот подводит его к выкопанной шахте диаметром 3 метра и глубиной 50 метров, заглядывают туда, на дне горит прожектор.
Заказчик - что за херня???
Подрядчик - вот же чертеж!! по нему и сделали.
Заказчик - (переворачивая чертеж на 180 градусов) - это маяк!!!
Что ни говори, а требования надо уметь читать.
"Обеспечить формирование произвольных отчётов" - это что значит? Произвольных из списка? Или надо дать возможность конструировать отчёты самостоятельно?
"Работать под управлением любых современных операционных систем". Включая QNX, MorphOS и AmigaOS?
"Не содержать интерпретируемого кода". Компиляция из MSIL в native код во время выполнения считается в вашем клубе за интерпретацию или только reflection? А если я внутри кода сам компилирую вызовы getters и setters, чтобы не связываться с reflection - это тоже интрепретация? Как нет? Я же получаю имена с помощью
GetType().GetProperties()[0].PropertyType
И таких нюансов каждый может придумать с десяток за минуту. Как же быть, чтобы не построить маяк?Мы перепробовали много методик. В том числе и заказчик on-site, как это практикуется в XP. Трудно сказать, каков должен быть идеальный путь выяснения настоящего смысла требований, но я могу рассказать про тот, который работает у нас.
- Как это ни смешно, но требования надо получить в письменном виде с расстановкой приоритетов.
- Взять таймаут на составление вопросов по требованиям. В зависимости от проекта это может занять как 1, так и 14 дней (говорю о типичных величинах для обычных проектов; если вам заказали написание сервера баз данных или компилятор для операционки новейшего автономного пылесоса с функцией барокамерного холодильника - я пас). Все вопросы, от серьёзных (полное непонимание), до ерундовых (почти всё понятно - и это самое опасное) тщательно запротоколировать.
- С блокнотом вопросов, диктофоном, ангельским терпением и колодой визиток выдвинуться в расположение заказчика, заранее предупредив его о том, что есть вопросы. В наши цели не входит беседовать с парнем, который только второй день работает или которого пригнали отдуваться из-за того что он не успел спрятаться.
- Объясните, чего вы хотите и непременно убедитесь, что сидящий напротив понимает, о чём идёт речь. А то будет как с полотёром Басова в "Шагаю по Москве". Это сильно портит настроение и плюс к тому это зря потраченное время: придётся то же самое спрашивать повторно.
- Делайте, что хотите, но обязательно расположите к себе собеседника. Учтите, что в то время, пока вы выполняете одну работу, интервьюируете, он - две. Отвечает вам и по-прежнему обязан делать то, за что ему платят в организации деньги: заниматься основными средствам, ругаться по поводу капитального ремонта труб или обеспечивать выборы своего директора в местную думу. Нам везло и особых сложностей не возникало - достаточно было за сутки узнать номер телефона выделенного человека, чтобы фазу знакомства сделать менее жёсткой.
- Задайте кумулятивный вопрос ("для чего вам нужна эта программа?")и слушайте, включив диктофон. Не перебивайте. Некоторые люди обладают настоящим даром - объяснить сложнейший процесс, такой, как остановка и запуск котельной, своими словами так, что всё поймёт и ребёнок.
- Уйдите на перерыв.
- Вцепитесь в человека, обрушив на него все вопросы, которые только у вас есть.
- Повторяйте пункт 8, пока вопросов больше не останется. Если это длится больше пары дней - дело нечисто. Или требования не соответствуют тому, что нужно сделать, или вы не в состоянии понять, чего от вас хотят. Первое - очень плохо. Второе - ужасно. Попросите в таком случае себя заменить.
- Ответы у вас есть, можно согласовывать план реализации требований
Логично и правильно, что выяснением требований занимаются специально обученные люди, аналитики. Но кто в небольшой организации может себе позволить ребят, уволившихся из какого-нибудь Капитал-Инвеста (название вымышленное, и любые совпадения случайны) с оклада в 150 тысяч рублей в месяц? Это не могут сделать и более крупные организации, чем ваш (и наш) гаражный кооператив из пяти человек. Поэтому нацеливайтесь на то, что требованиями вы будете заниматься самостоятельно. Для того, чтобы потом писать лучший код.
И ради бога, помните про маяк!
2 комментария:
по-хорошему, есть еще кучи-кучи-кучи ньюансов. Но, в общем, все так и есть.
: работайте с требованиями постоянно, подтверждайте и перепроверяйте все свои знания и сомнения.
Короче, в этой области (работа с заказчиком) хорошо получается использовать практики ХР. У меня по этому поводу есть несколько хороших книжек - например, Кента Бека "ХР: Планирование" и еще одна... Playing to win, не помню авторов.
Практики XP? Это которое же? Чтобы представитель заказчика постоянно присутствовал в команде разработки?
Бек сам не верит, в то, что пишет. С чего бы верить мне, который пробовал?
Отправить комментарий