Pull to refresh

Comments 6

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

Т.е. руководитель сам выбирает кому что делать и переклеивает (переносит) стикер? Или сам себе берешь, исходя из наличия своей фамилии в «специалисты, способные выполнить...»?

Часто зеленые магниты висят на специалистах, для которых на определенный момент нет подходящей задачи, и мы бы очень хотели занять их сразу, как только такая задача найдется.
Т.е. все-таки руководитель (менеджер, планировщик) распределяет?
Все верно, я имел ввиду, что руководитель (или руководитель проекта) решает кто и чем займется. Цель не только в наблюдении за процессом, но и в управлении, т.е. в какой-то момент можно ускорять один и замедлять другой проект. Но в ваших словах, я тоже вижу альтернативный вариант ведения проектов, когда можно положится на опыт и самосознание специалистов. Думаю, тут все зависит от внутренних правил и готовности коллектива.
Не заметил приоритета у тикетов — его нет? Из очереди забераем первый, под руку попавшийся тикет, или по принципу — первый пришёл — первый ушёл? (как тогда быть первому специалисту?)

Если тикет «замораживается» — то куда он «выбрасывается»?

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

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

Избыток микроменеджмента можно убрать, если курировать проект будет конкретный специалист. Тут все зависит от команды, например если у вас много новичков, или же наоборот у вас все специалисты с большим стажем.
Проблема в том, что по сути, в Вашей модели, вы руководите 4-мя проектами и 7-ю камандами. Я Вам завидую — я вряд ли смог бы.

Ваша система более-менее вменяема, для небольшой фирмы, где есть 5-6 программистов, поток задач «сделать сайт визитку» и «поправить прошлый проект». Т.е. По сути, в одном проекте задействованно 1-2 специалиста на проект, и никто кроме них этот проект не знает. И главное — проекты небольшие (небольшой риск смены исполнителя).

В большом проекте, такой подход приводит к проблемам:
1) Вы постоянно перемешиваете очереди (они расходуются с разной скоростью), или же многие спецы остаются неудел.
2) Пропажа одного специалиста — довольно большая проблема (нужно перенаправить его задачи, что ломает планы других спецов. К тому же они впервые видят задачу)
3) Задачи, даже паралельные могут быть с разным приоритетом. Это нужно учитывать.
Все верно, подход именно ориентирован на маленькие команды, и больше всего на классические IT отделы не IT компаний.
Sign up to leave a comment.

Articles