Коллеги, есть желание обсудить тему на ЛАФ-11?

Коллеги, есть желание обсудить тему на ЛАФ-11?

Есть

А у многоуважаемых Denis'a Beskov'a и bas есть желание с нами поделиться?

У многоуважаемого есть.

Денис предлагал вести Круглый стол “Организация обмена практиками в отделе”. Или хоца именно КС про построение отдела? У Дениса был уже такой доклад на первом Рек Лабс.

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

Ну если уже заявлена такая тема, то это отлично. Форма может быть любой, как хозяин данной темы захочет.

Тема заявлена другая — Управление отделом в целом и Обмен практиками это совершенно разные масштабы.

Интересно рассмотреть данные вопросы в компании, занимающейся разработкой ПО.
Вопросы:
1. Как определить количественный состав аналитиков? Так как отдел аналитики часть департамента, то хотелось бы определить количественный состав относительно других отделов.
2. Как делить  работу между аналитиками? По проекту, по функционалу, по сложности.
3. Как внутри отдела организовать взаимодействие? Кто- то не хочет делиться знаниями, кто то не дотягивает до среднего уровня отдела.
4. Как организовать взаимодействие с заказчиком. Ситуация: когда заказчик сам выбирает аналитика - идти на поводу или отстаивать свои интересы.
5. Обучение аналитиков. Нужно ли отправлять на обучение или обучать внутри компании в зависимости от проекта?

Можно отредактировать данный список, добавить свои или убрать неудобные

Интересно рассмотреть данные вопросы в компании, занимающейся разработкой ПО.
Вопросы:
1. Как определить количественный состав аналитиков? Так как отдел аналитики часть департамента, то хотелось бы определить количественный состав относительно других отделов.

На каждого ПМа в среднем по одному аналитику.

2. Как делить  работу между аналитиками? По проекту, по функционалу, по сложности.

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

3. Как внутри отдела организовать взаимодействие? Кто- то не хочет делиться знаниями, кто то не дотягивает до среднего уровня отдела.

На уровне руководителей групп — еженедельные встречи как минимум (1/8 отдела).
На уровне ведущих специалистов — ежедвунедельные встречи методического совета (1/4 отдела).
На уровне всех — ежемесячный внутренний семинар, вики-система, форум.
Тем, кто успешно выступает на внутренних семинарах в качестве поддержки можно платить увеличенную премию.

Тех, кто не дотягивает до среднего уровня, должны вести и растить старшие специалисты. Если человек не растёт, его надо увольнять.

4. Как организовать взаимодействие с заказчиком. Ситуация: когда заказчик сам выбирает аналитика - идти на поводу или отстаивать свои интересы.

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

В целом на вопрос «или делать как просят или делать как надо нам» ответ простой из практики переговоров и сотрудничества — выяснить взаимные интересы, выяснить цели, попытаться их совместить, выбрать подход по методу «первый подходящий»: 1) сотрудничество; 2) компромисс; 3) отжим; 4) уступка.

5. Обучение аналитиков. Нужно ли отправлять на обучение или обучать внутри компании в зависимости от проекта?

И так и так. В основном (80%) лучше обучать в проектах примером более опытных специалистов. Иногда отправлять на конференции или лекции, которые рентабельнее прослушать один раз.

Очень содержательно и емко. Спасибо. Редко встречаешь такие ответы.
1. Т.е. аналитик=ПМ, а разработка тут вообще никаким боком?
2. А правильно ли если роль ведущего аналитика  (когда в проекте из более 3) ведет ПМ?

И все таки на ЛАФ планируется ваше выступление?

1. Т.е. аналитик=ПМ, а разработка тут вообще никаким боком?

Я привёл самую простую эвристику. Все остальные соотношения типа «1 аналитик на 2-х тестеров», «1 аналитик на 5-х разработчиков» слишком зависят от истории развития компании, сложившихся практик, точек зрения топ-менеджмента.

2. А правильно ли если роль ведущего аналитика  (когда в проекте из более 3) ведет ПМ?

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

И все таки на ЛАФ планируется ваше выступление?

Пока я не очень хочу выступать. Мне проще ответить на вопросы хоть здесь, хоть там на месте.

и все таки так хочется  послушать примеры "из жизни"

и все таки так хочется  послушать примеры "из жизни"

Найдите меня на ЛАФе, расскажу.