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