Кто составляет ТЗ?

#документация

В организации есть аналитик. Он соглашается составить документ с описанием требований
от заказчика. Но не хочет писать ТЗ для программиста. 

Требования к ТЗ - составить таблицу, где будет описаны типы полей, формат ввода,
видимость на этапах, тексты уведомлений и логику изменения данных по каким-то событиям.
Аналитик хорошо знает возможности системы (речь о SharePoint). 

Аналитик сообщает что составлять ТЗ должен программист. Я этот программист. И по-моему
что-то пошло не так.
    

Ответы

Ответ 1

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

Задача аналитика - проанализировать производственный процесс и на основе своего анализа
выдать технические задания или рекомендации, если он сам не уполномочен выдавать технические
задания, а, допустим, это делает другой уполномоченный сотрудник. 

Описание требований от заказчика - это работа секретаря, а не аналитика. 

Для аналитика требования заказчика - это всего лишь входные данные, на основе которых
он должен выдать выходные данные, которыми являются технические задания. Грубо говоря
работа аналитика заключается в следующем. Он должен указать: вот - что требует заказчик,
и вот - что надо сделать.

А для программиста ТЗ - это входные данные, а программа - это выходные данные. 

В противном случае программисту придется дублировать аналитика. А зачем тогда такой
аналитик нужен?!

Фактически, в этом случае аналитик снимает с себя всякую ответственность за свою
работу, так как если конечный продукт не будет устраивать заказчика, то аналитик просто
скажет, что это вы написали неправильно ТЗ. То есть он полностью обрубил с вами обратную
связь и тем самым, подымаясь по цепочке вверх от вас до заказчика, чтобы оценить результат
работы и, например, оценить, что было сделано не так, как предполагалось, и на каком
этапе, то в этом процессе распределения ответственности аналитик уже участвовать не
будет.:) 

Как происходит процесс верификации результата работы?

Если задания спускаются сверху вниз, то верификация результата производится снизу вверх.

Результат работы программиста - это программа. Ее правильность сверяется с техническим
заданием.

Результат работы аналитика - это техническое задание. Его правильность сверяется
с требованиями заказчика.

Ну, а если требования заказчика сами по себе не корректны или неадекватны, то заказчику
никого кроме себя винить не придется.:)


Ответ 2

А еще бывает себе полезно иногда задавать вопрос - "ЗАЧЕМ?". И этих зачем здесь достаточно. 

Например, "Зачем мне сопротивляться составлению ТЗ...", - ведь я хочу получить этот
опыт и двигаться в сторону аналитика/архитектора, тогда мягко оттирая текущего аналитика
в сторону, выстраивай прямую коммуникацию с заказчиком, делай все лучшим образом и
не забывай периодически освещать свою новую роль перед руководством. 

Или например, зачем компании такой аналитик, тогда тоже делай все без него, а потом
поставь вопрос "Зачем нам такой аналитик..." ребром перед начальством. 

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


Ответ 3

Насколько я знаю, обычно это делается так:


(Бизнес-)аналитик собирает требования от заказчика.
(Бизнес-)аналитик пишет функциональную спецификацию для команды. В ней описано, как
всё должно работать с точки зрения пользователя — то есть список фич. Функциональная
спецификация может быть в формате use-case'ов или, если команда работает по Scrum,
user-story.
Системный аналитик или техлид пишет техническую спецификацию. В ней описано, как
всё должно быть реализовано внутри. Архитектура, технологии, стиль кодирования, используемые
инструменты. 
По технической спецификации работают программисты, тестировщики, системные администраторы,
администраторы баз данных и прочая техническая братия.


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

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

Определите, кто является заказчиком документации, т.е. человеком, который оценивает
её готовность и принимает работу. Скорее всего, это будет ваш аналитик. Сверяйте документ
с ним, пока он не скажет, что его всё устраивает. Потом пусть ставит подпись, что документ
принял. Обязательно подключите к процессу тестировщика, который будет с вами работать
над этим проектом.