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

(Reply) (Thread)

вы не ответили на 2-й вопрос автора. почему?

(Reply) (Parent) (Thread)

Денис, спасибо за замечание.
Не ответил, потому что лениво было отвечать. :)

Теперь по делу: аналитиками пытаются изолировать сферы ответственности заказчика и разработчика. Ведь каждый из них при наличии аналитика может сослаться на "Так написано в ТЗ".

Что конкретно ими подразумевается:
- заказчиком = "я так понял ТЗ, написанное _вашим_ аналитиком. Что, вы не можете с ним обсудить детали? Я ему всё разжевал до мелочей"
- разработчиком = "мне так аналитик сказал сделать, вот даже в ТЗ написано. И вы его согласовали"

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

(Reply) (Parent) (Thread)

не увидел в ответе фразы «я нужен команде для того, чтобы»

из вашего ответа не понятно, отвечаете ли вы про себя или просто рассуждаете про ситуацию.

кажется, мы тут имеем дело с интересным феноменом

(Reply) (Parent) (Thread)

Один из вариантов, как в недавно увиденном фильме:
" - По какому праву вы делаете такой выбор?!
- Потому, что больше некому."

В зависимости от размера команды, аналитики правда бывают не нужны.
И техписы не нужны.
А некоторым командам и РП не нужен.

(Reply) (Thread)

Вы не ответили на 2-й вопрос автора. Почему?

(Reply) (Parent) (Thread)

На мой взгляд аналитики нужны, чтобы делать работу, которую не делают другие члены команды. Содержание работы может быть разным. На моей практике, аналитики и пишут требования, и тестируют, и сдают заказчику, и ведут документацию по ГОСТу, и планируют работы.
Часть работ в более многочисленных командах относится к:
1. РП
2. Отделу тестирования
3. Техническим писателям
4. Отделу продаж

Вот такая, получается, прокси-роль.

(Reply) (Parent) (Thread)

Спасибо!

Кстати, вы заметили, что не ответили на мой вопрос? :)

(Reply) (Parent) (Thread)

Нашел вас через фэйсбук, но отвечу тут.

"Так вот, аналитики! А вы вообще уверены, что нужны своей команде?".
Когда как. Тут всё зависит от умений разработчика, размера команды, задач и т.д.

"А зачем?"
Быть связующим звеном между заказчиком и разработчиком. Сглаживать острые углы, вычленять требования, успокаивать. В общем - аналитик нужен как буфер на который льется всё говно.

(Reply) (Thread)

Какой-то очень грустный итог :(

(Reply) (Parent) (Thread)

1) Да, уверен что нужен в текущем проекте. И сам бывал в проектах, когда аналитик был не нужен (я был разработчиком).
2) Аналитик нужен чтобы описывать формы и функции системы, т.е. держать в голове схему всей системы. Еще нужен чтобы копать нормативку, работать фильтром требований заказчика, сводить необходимости бизнеса и возможности разработки.

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

(Reply) (Thread)

А что использовали вместо ТЗ на маленьких проектах?

(Reply) (Parent) (Thread)

На одном проекте (РП+3 программиста) РП почти каждый вечер по часу общался с заказчиком по телефону, обсуждая функции системы и состав данных. Потом информацию рассказывал нам уже в сжатом виде. Причины для такой схемы работы я сейчас уже не помню, но не помню и каких-то резких изменений в общей логике системы. Набор объектов и параметров в системе скорее всего фиксировался по почте.
На другом проекте (РП+консультант+1-2 программиста) делали систему по закону госзакупок. В этом случае очень многое было подробно описано в самом законе - логика, объекты, наборы атрибутов и контролей. И я, будучи разработчиком, знал этот закон не хуже консультанта или РП. Дополнительные уточнения были в письмах.
На небольших проектах часто постановка задачи проводилась в письмо или даже в устной форме.

(Reply) (Parent) (Thread)

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

(Reply) (Parent) (Thread)

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

(Reply) (Parent) (Thread)