Он ее обосновывает.
Первый вопрос заказчика, перед подписанием, уверен будет "во что мне это станет". Врядли он подпишет ТЗ, если ответ будет "может тыщщу, может сто". Результат же работы аналитика не просто написаное ТЗ, а подписанное обоими участниками процесса.

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

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


Как Вы, наверняка, обратили внимание, первый вопрос разработчика - 



ТЗ можно считать добротным, если ни заказчик ни разработчик на всем жизненном цикле проекта (от подписания ТЗ до утилизации) не столкнулись с рисками, не прописанными в ТЗ (обычно в разделе "прочее"). Потому как именно для того оно и пишется.


Это сообщение отредактировал(а) Zloxa - 6.9.2009, 00:49

Я к этому и веду, просто, возможно, достаточно извилистой дорогой 


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


Аналитик не считает деньги (кроме своего гонорара). Для этого есть другие роли.


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


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

А я-то никак не могла понять, почему столько внимания к этому моменту.

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

Это сообщение отредактировал(а) ida - 6.9.2009, 12:35

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


Это сообщение отредактировал(а) Zloxa - 8.9.2009, 09:04

Нет, так не пойдет.
Если разработчик неправильно оценил свои возможности  - значит, он обладает недостаточным опытом.

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

Мой опыт, кстати, демонстрирует, что именно разработчики ошибаются в оценке, хотя по ТЗ у них никаких вопросов нет. Т.е. попросту (оптимизм + отсутствие дисциплины) = заваленный проект.

Это сообщение отредактировал(а) ida - 8.9.2009, 23:24

Да. В первом случае виноват, как правило, аналитик, во втором случае заказчик.  Бывают исключения, но редко. Только доказать это не возможно. Да и кому доказывать то?

То что заказчик может быть не последователен, словоохотлив не по теме, противоречив, и отказывается сегодня подписывать то, что декларировал вчера, вовсе не умоляет Ваших качеств как аналитика. Вам приходится работать с этим материалом, потому как он Вам платит деньги а не Вы ему. Ровно как и разработчик вынужден брать в работу ТЗ, в котором нет ничего технического, исключительно по той же причине. Он либо возьмет это ###, либо будет ждать золото и сосать лапу. Тоже и со сроками. Либо он пойдет на не реальные сроки, либо проект уйдет другим, не погнушавшимся слукавить, мол сроки - реальные. 

Если мы начинаем делить ответственность, искать причины срыва проектов, то следует учитывать что позиция разработчика, всегда более уязвима. С  точки зрения заказчика аналитик свою работу сделал, бабос проплачен, если он признает что ТЗ ###, ему придется признать что он лох. Тем более, что объективно оценить качество ТЗ, в отличии от программного продукта, - не возможно. От того во всех разборках все гнездюли достаются разрабам, при активной поддержке аналитиками. Истину "Кто последний тот и папа" пока еще не отменили.


Через меня, кстати, не проходило ни одно ТЗ, не нуждавшееся в доработке. Если бы всякое уточнение сопровождалось бы доработкой ТЗ и переоценкой сроков, я никогда бы не срывал сроки. ;) Но кто пойдет к заказчику переподписывать ТЗ и сдвигать сроки? Аналитик? Чтобы его заказчик по мордасам да штрафами? А потом обоих нафик с проекта как некомпетентных. Это ведь придется признавать свою вину. Он ведь аналитик а не самоубийца. Потому заметенное под коврик аналитиком приходится выносить разработчику.


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

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

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

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

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

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

Если такие найдутся - поработаем.

Это сообщение отредактировал(а) ida - 9.9.2009, 21:55

Прошу прощения, действительно чтото разнылся.
Но первый наброс фекала на разрабов таки был за Вами.