К сожалению, оценку качества работы аналитика зачастую делают люди не понимающие смысл работы и назначение аналитика.
Например аналитик при проработке решений ориентируется на задекларированные цели проекта и утвержденные рамки задачи, а нужно "искать черную кошку в темной комнате".

В точку.

К сожалению, оценку качества работы аналитика зачастую делают люди не понимающие смысл работы и назначение аналитика.
Например аналитик при проработке решений ориентируется на задекларированные цели проекта и утвержденные рамки задачи, а нужно "искать черную кошку в темной комнате".

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

lnew, качество документов и эффективность аналитика — это 4 разных человека, хотя и из одной семьи.

lnew, качество документов и эффективность аналитика — это 4 разных человека, хотя и из одной семьи.

Спасибо.
Наверное, ссылку на статью нужно было поместить куда-нибудь в другое место. Или создать новую тему.
Мне, по простоте душевной, показалось, что качество документов существенно зависит от "качества" аналитика. Наверное потому, что мне не приходилось выпускать плохих документов. Везло! Надеюсь, Вам тоже!

Давайте порассуждаем - что может влиять на качество выпускаемых документов Аналитиком и что с этом делать?

0. Отсутствие процесса тестирования документации. Если вы не ищите ошибки в документации, то зачем вы вообще документацию пишете? Она просто не нужна.

Если вы не ищите ошибки в документации, то зачем вы вообще документацию пишете? Она просто не нужна.

То есть обычно документацию пишут для того, чтобы искать ошибки? Ну что бы было кому за что официально платить зарплату? Так получается?

0. Отсутствие процесса тестирования документации. Если вы не ищите ошибки в документации, то зачем вы вообще документацию пишете? Она просто не нужна.

Пишем документы для поиска в них ошибок. Странная логика. Galogen, согласна с тобой.

Давайте порассуждаем - что может влиять на качество выпускаемых документов Аналитиком и что с этом делать?
Я вижу следующие причины (в порядке убывания влияния):
1. Профессионализм Аналитика (можно в принципе и детализировать)
2. Нехватка времени для работ Аналитика
3. Нехватка времени у Заказчика на работу с Аналитиком и согласование документов
4. Адекватность Заказчика
5. Сложность бизнеса Заказчика
6. Сложность создаваемой Системы
7. Знание ИТ Заказчиком

Шо же мы такие неструктурированные модели создаем, а? Чему учим подрастающее поколение?...

Что за формулировка "нехватка времени"?.. Не хватает времени - сиди дома, кури бамбук.

есть же такое понятие как ресурс, куда относятся преимущественно время и деньги, когда речь идет о разработке ПО.
Если мы хотим установить причинно-следственную связь, то получим "ресурсы -> качество", соотв-но п. 2 и 3 можно переформулировать (а еще лучше - объединить в один), например "Наличие ресурсов" (каких именно и у кого - можно детализировать, а можно и нет, причина все равно одна).

п. 7 аналогичен п. 1, я бы его назвала "Компетенция Заказчика" (в ИТ или не в ИТ, не имеет значения - заказчик не обязан знать ИТ, но если он профессионал своего дела, с ним легче работать).

П. 5 и 6 на качество результата прямо не влияют, см. п. 1, 2, 3 и 7.

Что такое адекватность заказчика и в каких попугаях ее измерять, я вообще не понимаю - слишком субъективное понятие. У меня был коллега, от которого пять человек не могли ничего добиться, а два могли - он был неадекватен, или все-таки к нему просто нужно было найти правильный подход?

Шо же мы такие неструктурированные модели создаем, а? Чему учим подрастающее поколение?...

Классно!
И вообще, такой вопрос можно было бы задать относительно "качества" или "эффективности" анализа.
А качество документов зависит исключительно от "качества аналитика"!!!

Я напомню, что это раздел «мозговой штурм», а тут критика идей законодательно запрещена.

И мозговой штурм как раз и начинается с вываливания идей, что Саша и сделал.

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

То есть обычно документацию пишут для того, чтобы искать ошибки? Ну что бы было кому за что официально платить зарплату? Так получается?

Пишем документы для поиска в них ошибок. Странная логика. Galogen, согласна с тобой.

Понял. Зря вырвал фразу из контекста.

...На самом деле суть вотерфола в другом — он основан на посылке, что раннее обнаружение ошибок удешевляет разработку. Для этого документы и пишут — чтобы их проверкой можно было найти ошибки тогда, когда кода еще нет. Во многих ли конторах практикуют формальные инспекции документов? То-то же. Нафига их писать, если их не проверять. Эдак их дешевле вообще не писать — результат тот же. ... (с) http://gaperton.livejournal.com/5759.html

Опять же... смотря какой аналитик пишет документ. Если пишет самый главный и опытный, то кто у него его проверит? Чаще всего аналитик при создании документа согласует его либо с разработкой, либо с главным аналитиком.

Оффтоп удалил, что будет происходить и в дальнейшем.

ida, согласен с твоей содержательной частью замечания. А еще мысли есть, кроме реструктуризации моих мыслей?
Адекватность заказчика сложно измерить, как любой другой психологический аспект. Под адекватностью я понимал:
* умение объяснять свою мысль
* толерантность
* открытость
* понимание своей зоны ответственности
Понятно, что хороший Аналитик должен уметь работать и с таким Заказчиком, но ИМХО это потенциальная причина некачественного результата.

SALar, тоже согласен с дополнением.

Улучшение качества (в том числе и качество документов) всегда связано с соответствующим увеличением производительности.

При этом, Грамотное управление (например , проектом) подразумевает увеличение производительности труда, но с обязательным сохранением, а в идеале и улучшением качества выпускаемых систем.

Соответственно, причина - неграмотное управление (со стороны руководителя проекта).

И еще все-таки желательно уточнить что подразумеваем под "выпускаемые документы Аналитика"

Продуктами работы системного аналитика являются документы требований. (Диаграммы UML – это документы в графической форме.)

Это имеется ввиду или еще какие документы?