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

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

Если обратная связь слабая - значит, все хорошо.

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

Если обратная связь слабая - значит, все хорошо.

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

Я тоже так думала, пока не увидела релиз.

А при чем тут релиз?
Если программисты криворукие (или кривомозгие), это не ваша ответственность

А при чем тут релиз?
Если программисты криворукие (или кривомозгие), это не ваша ответственность

Хороший аналитик пишет спецификацию не для идеальных программистов, а для тех, которые есть.
В противном случае, нет шансов достичь главного критерия качества работы аналитика, о котором упомянул Salar:

Главная проверка - если заказчик сказал "Вах, это то, что я хотел" два раза: один читая документ, второй - после работы с программой, - то есть шанс, что документ был неплох.

Другими словами, если ваша работа не привела к выходу продукта ожидаемого качества -- значит вы делали не то, что нужно. Независимо от того, много ли вы работали, насколько устали, и кого считаете виноватым в провале.
Программисты, вообще говоря, en masse люди довольно образованные. Если у вас есть основания считать какого-то из своих программистов кривомозгим, попросите заменить его на другого, предложений на рынке программистских услуг достаточно, в течение 3 дней можно решить эту проблему.

Хороший аналитик пишет спецификацию не для идеальных программистов, а для тех, которые есть.

Вы мне рассказываете, как работают аналитики?.. Может вы меня еще рожать поучите?

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

Программисты, вообще говоря, en masse люди довольно образованные.

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

предложений на рынке программистских услуг достаточно, в течение 3 дней можно решить эту проблему.

а потом месяц интегрировать его в команду и продукт.

Хороший аналитик пишет спецификацию не для идеальных программистов, а для тех, которые есть.

Своим подходом вы сразу определяете в аналитике "козла отпущения" за провал любого проекта.

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

Программисты, вообще говоря, en masse люди довольно образованные.

Аналитики, вообще говоря, тоже бывают с мозгами 

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

Где-то, что-то подобное я уже читал, типа "каждая кухарка может управлять государством". В задачи аналитика не входит управление ресурсами проекта и тем более увольнение и прием нового персонала.

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

Так и в разработке ПО -  пришел человек работать аналитиков, а тут на него задачи РП спихивают, вешают ответственность за код программиста, да и еще и тестировшиком иногда заставляют работает. 

А что у вас не так? Где работала - везде аналитик виноват.

Такая интересная дискуссия получилась. И очень актуальная. =)

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

А что у вас не так? Где работала - везде аналитик виноват.

Нет не так. У каждой специализации есть своя зона ответственности. Есть формальные признаки качества выполняемой работы. В частности свои требования к формату постановки задачи на разработку выдают разработчики. Аналитики готовят документы в соответствии с согласованными форматами. И никто ни на кого "бочки" не катит 

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

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

В общем, печальное зрелище.

Глаза бояться, а руки делают.
И все будет хорошо. 

Хороший РП может вытащить проект даже из самой глубокой пятой точки

Да, согласна, случается иногда такая реанимация

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

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

Вопрос был задан следующий:

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

Я на него ответила (см. выше).
Автор темы, судя по последнему комментарию, в целом удовлетворена.

А какую потребность сейчас пытаетесь удовлетворить вы?...

аналитик виноват когда себя поставил в команде как козёл отпущения 
по теме же, вы всё смешали в одну большую кучу, где перемешались заказчики и программисты, в то время как существуют разные документы, предназначенные для:
1. заказчика
2. для имплементации бизнес-логики в системе.
3. сношений с тестированием
4. приёмок и прочего.
любой документ имеет цель: согласовать бизнес логику проекта, согласовать архитектуру разрабатываемого решения, согласовать низкоуровневые архитектурные моменты как методы и интерфейсы взаимодействия, сценарии приёмочных тестирований и прочее.
общая мысль следующая: каждый документ имеет цель, и от неё нужно плясать. для заказчика писать доки в удобном для него формате, для разрабов - в удобном им формате. никогда не будет одного документа, эффективно читаемого как заказчиком, так и разработкой, потому что и те, и другие имеют под собой инкрементную природу (количество согласующих имеет свойство постоянно увеличиваться с обеих сторон)
вопрос формализации обсосан очень и очень много раз. может, конечно, я не правильно понял вопрос темы.

а что до взаимных обвинений в кривомозгости, то я с вами не соглашусь - в ЛЮБОМ сложном проекте с внешним заказчиком, наступает момент таких обвинений. он обусловлен рамками реализации и бюджета. заказчик хочет побольше, а денег заплатить поменьше, подрядчик же, наоборот. обвинения - это элемент торга :-) вариант кранча, если в терминах теории переговоров.