Документы, с которыми мы работаем

Волей случая (не самого приятного, надо отметить) я ознакомился с несколькими документами, на основе которых у нас ведется разработка. Увиденное вдохновило меня на этот опус.

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

Начну от печки. Для чего мы пишем всю эту литературу? В первую очередь, чтобы показать клиенту, что мы понимаем, чего он от нас хочет. Это естественно. После того, как клиент убедился, что его требования где-то записаны, встает второй вопрос: нужно договариваться о цене/стоимости. Оценка производится опять же по документации, ранее утвержденной с клиентом. Ну, и наконец, надо бы изготовить эту игрушку. Поскольку для небольших проектов очень редко удается получить время на разработку архитектуры, разработка ведется все по той же документации. Думаю, картина ясна.

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

Что в на входе? Разработчики хотят подробностей реализации. Заказчик тоже гораздо охотнее делится своими соображениями по поводу отдельных формочек и кнопочек, чем глобальным видением продукта. А многие этого видения просто не имеют, поскольку начинают бизнес “по образу и подобию”, не представляя зачастую всей бизнес-модели. Им кажется, что взяв сайт “как у Васи” и улучшив “ту кнопочку” и “эту формочку”, они тут же вырвутся вперед Васи и вобще планеты всей. Да и зачем разработчикам знать, откуда ноги растут? Клиент ведь уже знает все формочки и кнопочки, он все сам расскажет. Аналитик, поставленный в нужную позу этими двумя лагерями и подгоняемый жестким оценочным цейтнотом (где ваше предложение? мы уже получили миллион предложений от ваших конкурентов!), идет на поводу у обстоятельств и выдает документ с подробным списком формочек и описанием работы кнопочек на каждой из них, построенный на материалах допросов заказчкиа.

Что в результате? Во-первых у всех участников забега создается иллюзия полноты требований. Еще бы, ведь каждая кнопочка расписана! Благодаря этому заказчик считает, что анализ закончен, и очень удивляется необходимости в дальнейшем отвечать на вопросы. Благодаря этому же разработчик дает оценку, предполагая, что все требования уже устаканены и забывая, что нет ничего постоянного в этом мире. Во-вторых, когда приходит время обобщать и рисовать архитектуру, выясняется, что документ, прекрасно понимаемый в частях (в пределах описания одной формочки на паре страниц), совершенно не пригоден для понимания в целом. Выясняется, что для разработки архитектуры требуется несколько иная форма представления, а это требует дополнительного анализа, а времени уже нет: заказчик торопит, он уже хочет видеть те самые формочки, которые ему обещали. И, наконец, в четвертых! Самое главное! Читать медленно! Клиент склонен забывать о том, что он говорил, и, если у нас нет задокументированной концепции продукта, нам хана! Что будет стоить поменять положение кнопочки на форме? Или даже добавить кнопочку? Или перекрасить? А что будет стоить добавить новую роль, о которой клиент умолчал, потому что считал ее наличие само собой разумеющимся, или потому что забыл, но он ведь об этом не скажет. Или что будет стоить добавить/изменить целый процесс, который не был затронут (ведь, как правило, описание формочки затрагивает только часть процесса)? Это может вылиться с десятки формочек и сотни кнопочек! Причем я не утрирую!

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

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

Что делать? Вывод напрашивается сам собой - двигаться последовательно, как рекомендует великий UP (да и другие процессы тоже). Поэтому ниже я позволю себе дать несколько рекомендаций начинающим аналитикам в плане последовательности построения документов. Сразу оговорюсь, что мои рекомендации неприменимы на этапе “быстрой оценки”. Речь идет только о случаях, когда мы уговорили клиента сделать подробный анализ требований.

Продолжение следует...