Как стать автором
Обновить

Комментарии 22

Технически всё реализуемо.
Но вот успех в таких делах зависит только от человека.
Юлий Цезарь и Суворов без таск-менеджеров оч успешно справлялись… ;)
У Юлия Цезаря не было десятка заказчиков.
зато у него был десяток подрядчиков.
у него были тыщи подчиненных и мильоны населения… ;)
Я бы взял вместо важности объем работ. Важность, в принципе, не важна (простите за тавтологию). Если есть сроки, то важность задачи определяется сроками и объемом работ.
Объем работ оценивать надо для каждой задачи и при нормальном управлении проектами какой-то оценочный объем работ в тех же человеко-часах есть всегда.
Процент выполнения можно задавать в том же рэдмайне, а необходимый объем работ(насколько я помню — в рэдмайне этого нет) можно задать пользовательским полем, например.

Тогда получается, что определяющими приоритет переменными будут:
1. (100-процент выполнения)*объем работ
2. Дата окончания-текущая дата (тут лучше даже в часах)

Если важность не важна, то вы неправильно определили термин важности. Важность важна по определению и если это не так, то вы называете важным неважное :)
Важность может быть политическая, стратегическая и прочая. Или вот еще пример оценки важности. Допустим есть проект за 20т.р. по срокам на месяц. и есть проект за 100т.р. по срокам на пол года. И более ценным является первый, потому что приносит 20т.р. в месяц, а второй только 16,6666т.р.

В редмайне можно указывать «оцененное время» в часах, что можно вполне считать объемом работ.
Если исходить из принципа, что все задачи должны быть выполнены, то параметр важности можно не оценивать.
В любом случае, объем работ так же должен учитываться.
По-моему (и не только), логично разделять задачи по уровням — наномикро-менеджмент и обычные задачи.
Не стоит делать работу за Ваших подчиненных — отказывайтесь от микро-менеджмента, оставляйте себе действительно важные задачи (планирование, общение с заками, работа с людьми, составление программ обучения персонала) — при итеративной разработке это вполне реально. В начале каждой итерации Вы принимаете участие в планировании, а потом даете каждому сотруднику возможность работать без плотного надзора, но с координацией по «контрольным точкам».
Лично мне методика «срочность-важность» не помогла, так как дилемма приоритезации задач отбирала довольно много времени.

Вот эту проблему («дилемма приоритезации задач отбирала довольно много времени») я и пытаюсь решить в этом топике. Сама система то хороша, плохо лишь время, которое тратится на оценку по ней.
А к микро-менеджменту пока перейти нет никакой возможности. Тем более что я выполняю роль еще и менеджера проектов, который как раз и должен за исполнителей определять порядок выполнения задач.
> ежедневно приходится составлять детальный план действий не только для себя, но и для каждого исполнителя.
вот это и называется микро-менеджмент. Пусть сотрудники сами составляют себе «план действий», Ваша задача лишь определять цели и контролировать вехи на пути к ним.

> роль еще и менеджера проектов, который как раз и должен за исполнителей определять порядок выполнения задач.
для этого есть «командная работа» формализованная в подходах agile, scrum — отдайте координацию работы между персоналом — самому персоналу (но только сначала научите их необходимым приемам).

> Сама система то хороша, плохо лишь время, которое тратится на оценку по ней.
Это называется «теория встретилась с практикой». Имхо, в абстрактном виде этот подход неудобен и вреден. Посмотрите тогда в сторону GTD, что ли. Там изложены более ли менее проверенные и «рабочие» приемы оптимизации времени.
Проблема данного подхода не в том, чтобы разместить задачи в матрице Эйзенхауэра. Проблема в том, чтобы дать оценку важности, например. Вот как вы решаете, что некоторая, отдельно взятая задача, имеет оценку 8? Как показывает практика моих наблюдений, у подавляющего большинства людей во втором квадранте находятся задачи стратегического, долгосрочного характера, которые, по идее, должны быть по важности выше всех задач из первого квадранта вместе взятых. Но они, на удивления, находятся на одном уровне, а иногда даже ниже. Вот так и получается, что локальные битвы в первом квадранте мы выигрываем, а глобальную войну во втором проигрываем.
не могу не согласится — противостояние операционных и стратегических задач постоянно.
Чтобы от нее избавится, нанимают дополнительного специалиста (штат), который будет заниматься чем-то одним.
Я пока это решаю так: стратегические задачи решаются вообще отдельно, в специальные дни, часы, затем они детализируются до более мелких и конкретных задач, и таким образом попадают в список к операционным.
Как разделять стратегические и операционные задачи?
А тут, мне кажется, никакие инструменты не помогут. Нужно просто в определенные моменты, когда чувствуешь, что поглощен оперативной деятельностью, сказать «стоп» и задуматься над стратегией, направлением и прочим. Подумать, решить, и потом опять «нырять в оперативку».
Спасибо за отзыв о doit.kz! Мне очень приятно это было читать. К сожалению, сервис не развивается так, как я планировал, но не все потеряно =)
Пожалуйста!
Немного офтоп, но скажу. Мне лично было б удобно задавать задачи отдельно от графика, в таблице. Мне кажется, так более объективно можно оценить задачи. А когда смотришь на график, то оцениваешь каждую новую задачу в контексте уже существующих.
не легче ли юзать Мегаплан?
а как Мегаплан решает эту задачу?
www.youtube.com/watch?v=dVqEHxsVsBM
посмотрите этот ролик и вам станет ясно, каким делать отдавать высший приоритет, важным и срочным или важный и не срочным.
вам знаком успеватель Василия Кислого?
а вообще, как я вижу, не хватает важного момента — ответственности сотрудников
это ключевой пункт, сотрудника не надо пинать, он должен в каждый момент знать, какую задачу делать прямо сейчас (либо знать где посмотреть) и также у вас д.б. возможность увидеть его прогресс
Сычёв вам в помощь
Интересно, из 10х10 квадрата получилось 64 квадратика
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории