Правила распределения задач между сотрудниками отдела аналитики(Прочитано 26459 раз)
Коллеги, поделитесь опытом каким образом вы распределяете задачи между аналитиками.
У нас следующая ситуация. В отделе 5 сотрудников. Каждый курирует несколько клиентов, и в случае возникновения каких-то доработок для клиента аналитик, работающий с ним подключается к задаче. Бывают задачи, не привязанные к конкретному клиенту. У тех и у других есть свои относительные приоритеты, и сроки. Часть сроков может быть жесткой, часть плавающей. Некоторые из аналитиков уходят в отпуск, на больничный, оставляя за собой задачи, и как правило не передавая их другим. Каждый из аналитиков работает так как считает приоритетным это для себя. Мне видится, что распределение задач должно быть немного другим.
У кого-нибудь есть опыт работе в команде аналитиков в случае наличия множества различных задач. Как вы разделяете их между друг другом? Каким образом определяете кто чем занимается в определенный временной период? Можно ли дать право самим аналитикам выбирать задачи либо это задача должна делаться консолидированно из единого пула задач выделяются только приоритетные? Как вы определяете приоритетность выполнения?



Проект (Система) один или несколько?
Пообщайтесь с вашим отделом разработки\тестирования - как они распределяют задачи.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



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

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

Так что практика переброса задач заранее порочна. И еще, хоть не совсем в тему - РП ради собственного бонуса стремятся выделить как можно меньше ресурсов аналитику. Доходило до абсурда - техническое задание на 160 листов надо было разработать за 16 ч/часов. Тут, конечно, следует отказ, собирается сборище, начинается война - аналитик размахивает пачкой ГОСТ и нормативов трудоемкости, доказывая, что в подобные сроки не то что написать ТЗ - прочитать его невозможно. Ой, какие войны были...

Лопнула та конторка, текучка кадров к концу 2005 года достигала 30 % в месяц, более-менее грамотная публика бежала первым эшелоном.

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



ИМХО, все происходит из-за отсутствия четкой линии подчиненности и структурности подразделений, а также избыточности "передаточных звеньев".

Это вообще-то противоречивые запросы. :) Чёткая линия подчинённости и структурности как раз приводит к избыточным передаточным звеньям. imho, конечно.

А бывает Scrum для аналитиков? Говорят, бывает:
http://tekezi.blogspot.com/2010/08/scrum_18.html
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Это вообще-то противоречивые запросы. :) Чёткая линия подчинённости и структурности как раз приводит к избыточным передаточным звеньям. imho, конечно.
И сам исхожу из личного опыта. Довольно долго трудился в жесткой иерархической системе, в которой (по идее) любые связи между сотрудниками подразделений должны организовываться через руководителей подразделений. Они - рулевые. Но, разумеется, были и горизонтальные связи на уровне сотрудников, при этом руководители осуществляли общий контроль и разруливали конфликтные ситуации, что позитивно влияло на рабочий процесс. Бывала, конечно, и неразбериха, но не до такой степени, которую можно наблюдать сейчас. Т.е. избыток передаточных звеньев существовал больше формально, на бумаге, согласно соответствующих разделов положений о подразделениях (классный. кстати, организационно-правовой документ), а работа велась на фактических горизонтальных связях.

А как только вышел из указанной системы, сразу же появилось ощущение полнейшего бардака. Бардак, кстати, стимулируется и open space, когда публика сидит в одном большом офисе с хлипкими перегородками. Производительность снижается процентов на 70 - опять же ИМХО :)



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

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

Похоже на слабую матрицу.

Лопнула та конторка, текучка кадров к концу 2005 года достигала 30 % в месяц, более-менее грамотная публика бежала первым эшелоном.

Вообще работать в стиле "the matrix has" достаточно сложно и для сотрудников и для руководителей конкуренция за ресурсы, сложность контроля и т.п. "радости". Но иногда организовать работу с большим объемом задач и проектов и небольшим коллективом можно только в матрице.

Так что Вам нужно в первую очередь определиться с оргструктурой. Материалов по организационному строительству много - посмотрите достоинства и недостатки и решите, что подходит вам.



Если не секрет - в чем состоит проблема, которую вы хотите решить? Что побудило вас к созданию этой темы? Какую цель вы хотите достичь?
Я не хочу знать, почему то или иное намерение неосуществимо. Нужно мыслить в направлении: что сделать, чтобы осуществить.
Истина где-то рядом...



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



Проект (Система) один или несколько?
Пообщайтесь с вашим отделом разработки\тестирования - как они распределяют задачи.

Проектов у нас много. Каждый аналитик ведет до 10-15 проектов. Проекты бывают разной длительности. От небольших доработок ПО до серьезных задач полного изменения ПО.

В наших отделах разработки\тестирования работает scrum, да, он действительно работает. Но есть вопрос:
.применим ли скрам на отдел аналитики, особенно в условиях того, что часть задач не может быть распределена между аналитиками, и у одного специалиста в связи с его спецификой может быть переизбыток задач, в то время у другого недостаток, и самое сложное, что передать то задачи невозможно... хотя, опять же как на это посмотреть. Может действительно надо продумать механизмы взаимозаменяемости.


А бывает Scrum для аналитиков? Говорят, бывает:
http://tekezi.blogspot.com/2010/08/scrum_18.html
Ну и что от того, что у нас есть scrum, он НЕ РАБОТАЕТ. Вернее на данный момент никто не заинтересован в том, чтобы он заработал.
Конечно меня это не останавливает. Но хотелось бы прежде чем что-то менять понять, в каком направлении действовать.

Если не секрет - в чем состоит проблема, которую вы хотите решить? Что побудило вас к созданию этой темы? Какую цель вы хотите достичь?

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



«Каждый из аналитиков работает так, как считает нужным»

Милада, какова ваша роль в организации?
Если аналитики работают, как считают нужным, то к каким последствиям для бизнеса это приводит?

В чём по-настоящему заключается ваша проблема в данной теме, что у вас болит? (То, что вы перечислили — это интересы, а не проблемы). Если проблем 5, выберите одну, наиболее важную, опишите причины.

Сейчас как минимум непонятно, какое отношение имеют перечисленные интересы к заданному в начале ветки вопросу. (На этот вопрос отвечать не стоит, прежде, чем вы расскажете про вышеперечисленное).



«Каждый из аналитиков работает так, как считает нужным»
Милада, какова ваша роль в организации?
Если аналитики работают, как считают нужным, то к каким последствиям для бизнеса это приводит?
В чём по-настоящему заключается ваша проблема в данной теме, что у вас болит? (То, что вы перечислили — это интересы, а не проблемы). Если проблем 5, выберите одну, наиболее важную, опишите причины.

По поводу роли в организации
В ближайшей перспективе - руководство отделом аналитиков.
Последствия для бизнеса.
1. Отсутствие аналитиков (по причине болезни) приводит к замораживанию выполнения задач по клиентам "висящим" на аналитике.
2. Не все задачи выполняются в срок по причине большого кол-во задач на одном специалисте и не всегда корректной приоритезации их выполнения. Каждый аналитик для себя сам выбирает какими задачами когда заниматься. верно ли отдавать на откуп специалиста планирование или все же это задача ПМ-а решать кто чем занимается и контролировать работу?
Вообще, как можно контролировать работу аналитика?
3. Отсутствие процессов взаимодействия между аналитиками приводит к ошибкам (которые могли бы не быть, если бы была обратная связь в рамках работы над проектом, т.е. к примеру один аналитик имел возможность, цель, желание и время посмотреть (пусть даже не углубляясь до последних подробностей) постановку, как показывает опыт при коллективном обсуждении находится больше дыр, чем когда задачу рассматривает один специалист.
4. Если покопаться, можно привести еще несколько моментов, которые хотелось бы исправить и изменить. Но, начнем с самого важного с 1. по 3.



Болезни и отпуска

Задача руководителя — составить график отпусков. Он есть? С каким горизонтом?
Задача руководителя — при планировании работы аналитика на проектах учесть отпуска и риски, связанные с болезнями и форс-мажорами (например, в форме поправочных коэффициентов плановой месячной выработки). Они учтены?

Думаю, что с вашим соотношением количеством проектов и аналитиков выработать эффективное правило подмены будет трудно. Но сначала надо выяснить как распределены предметные области и продукты между аналитиками.



Болезни и отпуска

Задача руководителя — составить график отпусков. Он есть? С каким горизонтом?
Задача руководителя — при планировании работы аналитика на проектах учесть отпуска и риски, связанные с болезнями и форс-мажорами (например, в форме поправочных коэффициентов плановой месячной выработки). Они учтены?

Думаю, что с вашим соотношением количеством проектов и аналитиков выработать эффективное правило подмены будет трудно. Но сначала надо выяснить как распределены предметные области и продукты между аналитиками.

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



Соблюдение сроков и приоритезация

Если при планировании не учтены поправочные коэффициенты, то срыв сроков будет всегда.

Как вообще соотносятся ПМы и аналитики? У ПМа — по аналитику, у ПМа — по несколько аналитиков, на одного аналитика бывает несколько ПМов?
Если несколько ПМов — то понятно, что «ошибки» в приоритезации будут всегда, потому что «мой проект самый важный».



Если постоянно уходят на больничный — это хороший повод включить Human Management )

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

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

Отправьте самых болезных в отпуск минимум на 2 недели, но обязательно на тёплое море. Это наверняка будет разумным вложением, даже если отпуск внеплановый.




 

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