Форум Сообщества Аналитиков

×


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

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



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

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



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

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


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



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



А при чем тут релиз?
Если программисты криворукие (или кривомозгие), это не ваша ответственность
Хороший аналитик пишет спецификацию не для идеальных программистов, а для тех, которые есть.
В противном случае, нет шансов достичь главного критерия качества работы аналитика, о котором упомянул Salar:
Главная проверка - если заказчик сказал "Вах, это то, что я хотел" два раза: один читая документ, второй - после работы с программой, - то есть шанс, что документ был неплох.
Другими словами, если ваша работа не привела к выходу продукта ожидаемого качества -- значит вы делали не то, что нужно. Независимо от того, много ли вы работали, насколько устали, и кого считаете виноватым в провале.
Программисты, вообще говоря, en masse люди довольно образованные. Если у вас есть основания считать какого-то из своих программистов кривомозгим, попросите заменить его на другого, предложений на рынке программистских услуг достаточно, в течение 3 дней можно решить эту проблему.



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

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

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

предложений на рынке программистских услуг достаточно, в течение 3 дней можно решить эту проблему.
а потом месяц интегрировать его в команду и продукт.
« Последнее редактирование: 07 Ноября 2012, 11:52:18 от ida »



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

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

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

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

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



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



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



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



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

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

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

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



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



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



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

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

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



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

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





 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19