Выбор порядка задач (переработано)

[gaperton]

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

Ой! Ну, то есть, я хотел сказать, есть еще очень много полезных и важных вещей, конечно :) Но. Если Вы будете следовать приведенным правилам (при этом

Comments

[b0rg]

так все таки непонятные задачи делать вначале, а понятные откладывать на конец? Имея при этом более-менее реалистичный график работ на понятные задачи?

[red_manul]

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

Хотя я и сама люблю в первую очередь браться за те решения, которые понятны. На школьных олимпидах, помнится, проповедовали правило "Делай в первую очередь то, что знаешь как делать". Видимо, по инерции это переходит и на задачи в проектах:)

[b0rg]

да я вот тоже обычно вычищаю свой todolist с понятных и коротких задач...

[gaperton]

> Поэтому непонятные задачи и нужно делать в первую очередь.

Совершенно верно. Но только для критичных задач.

> Хотя я и сама люблю в первую очередь браться за те решения, которые понятны. На школьных олимпидах, помнится, проповедовали правило "Делай в первую очередь то, что знаешь как делать". Видимо, по инерции это переходит и на задачи в проектах :)

И это правильное правило. Оно и должно использоваться для некритичных задач.

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

У Мюррея Кантора это называется "квадрат риск-приоритет". Я применяю более эффективное правило "risk-value-cost", которое учитывает еще и затраты. Так получается гораздо лучше.
http://gaperton.livejournal.com/28186.html

[skyer]

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

[gaperton]

Это откладывание - частный случай обоих принципов. Оно само собой так получится.

Если нечто не является критичным, и имеет высокий риск и трудозатраты (пессимистичная оценка = оптимистичная оценка + риск) - оно будет отложено на потом. Если является критичным - то откладывать нельзя.

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

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

[skyer]

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

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

Не знаю как правильно - пронизать весь план учетом рисков вяглядит правильно, но по-человечески это путь к структурированному хаосу. Один директор системного интегратора рассказал - внедрили у себя SAP, а теперь он компьютер утром включать не хочет: начнет приставать с учетом рабочего времени, согласованием срочных планов, без которых другие подразделения зависли. Аналогия не идентичная, просто иногда хочется отделить мух от котлет и наслаждаться ими раздельно.

[zigel]

Второй пункт напоминает о совете Александреску и ко. о вреде преждевременной оптимизации.

[vasbur]

Второй принцип - частный случай "метода вытягивания" производственной системы Тойоты. В свое меня это принцип сильно удивил и заставил задуматься.

[gaperton]

Хм. Как интересно. Не дадите ссылку на описание системы?

[vasbur]

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

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

[gaperton]

Статья в википедии - отстой, видимо, надо читать оригинал. Но! Кажется неплохой статья про "бережливое производство", на которую есть ссылка и данной вами статьи. Она существенно более информативна. За одно это:

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

Ее надо добавить в закладки :). Короче, спасибо за толковую ссылку.

[d_ao]

Ко второму принципу в пару бы еще такой: "Не забывай делай то, что необходимо делать сейчас", поэтому я бы сформулировал этот принцип так: "Делай сейчас только то, что нельзя отложить на потом, и не более того".

[gaperton]

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

[gaperton]

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