Статья в тему в сегодняшней рассылке citforum.

Построение эффективного IT-отдела. 12 простых правил.
http://citcity.ru/16882/

Правило 1. Убедитесь, что состав группы соответствует задаче

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

Я бы еще напомнил уважаемым коллегам про матричную модель распределения ролей Белбина.
Почитайте, например,  здесь

Я бы еще напомнил уважаемым коллегам про матричную модель распределения ролей Белбина.
Почитайте, например, здесь http://mindmix.ru/accountancy/167-933-stat-ja-roli-v-komande-rossiiskii-variant-read.shtml

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

2 greesha

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

Про участие в команде профессионального психолога в приведенной статье ничего не сказано. И тем более про необходимость рассчета коэффициентов корреляции. Авторы исследовали вопрос и что-то считали в своих целях. Методика Белбина защищена патентами вплоть до фамилии автора. Публиковать ее прямо и открыто нельзя. Возможно лишь косвенное, опосредованное изложение. Именно поэтому такой текст в качестве ссылки.

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

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

Да разве кто-то исследовал, сколько подходов используется на практике... IMHO, сколько людей, столько и подходов.
Вон Эля изложила свой подход - разве он стандартный?

А кто - нибудь расскажет, как правильно организовать отдел анализа?

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

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

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

А кто - нибудь расскажет, как правильно организовать отдел анализа?

Спустя 2 с лишним года после заданного вопроса я, думаю, расскажу в ноябре на Req Labs Насчёт «правильно» не уверен (тут могут быть разные точки зрения + я это делаю в первый раз, в отличие от некоторых), но как прецедент и опыт думаю будет интересно.

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

А РЖД - ну о-о-очень большая компания. Предполагаю, что многих заинтересованных лиц в такой компании выявить непросто. Они прячутся очень глубоко под водой и выныривают только чтобы схватить добычу.

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

И еще - очень помогает диктофон и фот.
Аналитический отдел это два человека - первый готовит результаты и ездит на встречи, второй - технический писатель.

Спустя 2 с лишним года после заданного вопроса я, думаю, расскажу в ноябре на Req Labs Н

Рассказали? Почитать где -нибудь можно?

Рассказали? Почитать где -нибудь можно?

Презентация: http://www.slideshare.net/maieutic/building-systems-analysts-office

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

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

Как благородно с Вашей стороны
Денис,а за это время Вы ещё и ник поменяли?

Быстро накидал свои мысли по поводу построения отдела анализа:
https://docs.google.com/document/pub?id=1sx7wD61yF2npaNiE2-zny2y6MPUlc_y-ShWAbg7lwLE

Денис,а за это время Вы ещё и ник поменяли?

Раз 14, да.