Project management

Это мой первый пост на пикабу, так что приветствую любую рациональную критику как по форме, так и по содержанию поста )

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

Много лет, я изучал и пытался применить методики и инструменты для эффективного тайм-менеджмента. Pomodoro, GDT, Google Calendar и десятки других были мной изучены, применены и... забыты уже через несколько дней. Заполненные давно забытыми проектами и задачами они и сейчас пылятся где-то в дальних уголках Интернета.

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

Чего собственно я хотел добиться:

1. Возможность быстро выгрузить дело из головы, чтобы до поры до времени о нем забыть. Именно выгрузить, а не вытеснить в подсознание, чтобы оно там ворочалось и разъедала мой мозг стрессом и неврозом. (Спасибо идеологии GTD)

2. Возможность легко планировать и перепланировать день в любой момент. Все эти страшные повторяющиеся дела, запланированные с 11:00 до 11:30 по вторникам и четвергам заставляют меня закрывать все органайзеры-календари сразу после того как я их добавляю. Вид размножившихся до конца времен одинаковых дел, да еще в одинаковое время - ужасен.

3. Возможность выделять участок работ на день. Представьте себе, что вам нужно высечь статую сфинкса в Египте. Вы берете долото, молоток, выбираете подходящую гору и с энтузиазмом начинаете её долбить. Через час, вы довольные отходите от горы и видите маленькую насечку. Руки опускаются. В общем слона надо есть по частям и это прописная истина, о которой говорят все методики тайм-менеджмента

4. Возможность быстро оценивать сколько времени у меня уйдет на работу и на сколько я уже сделал. Это мотивирует больше, чем рыть траншею от забора и до обеда )

5. Возможность легко отказаться от выполнения дела )

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

ЭТАП 1. Усекаем осетра

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

ЭТАП 2. Вдумываемся в детали

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

A - короткие задачи минут на 10 (позвонить заказчику, отправить документ и др)

B - задачи минут на 20 (составить короткий документ, поставить задачу сотруднику)

C - задача минут на 40 (что-то запрограммировать, провести брифинг, найти исполнителя, набросать мини-ТЗ)

D - задача на 1,5-2 часа (серьезно поработать)

задач большего объема в моей идеологии нет. Вместо этого, ставится задача "Сесть и разбить проект на задачи помельче"

Если я решаю сегодня заняться задачей, то я нажимаю кнопку "В план" и задача устанавливается в список дел на сегодня. Можно еще и на другой день, но это уже bad practice для сиюминутного лентяя - жить нужно сегодняшним днем. ) В следующий понедельник планируем только деловые встречи.

ЭТАП 3. Мелкими шажками

Закончив отбор дел на сегодня, мы оказываемся один на один со списком выбранных дел. Которые абсолютно не хочется делать. Вот тут в дело вступают дела типа A (минут на 5). Скажите себе, сейчас я сделаю все короткие дела и перенесу все оставшиеся на завтра.

Делаете первое дело нажимаете кнопку слева. Дело зачеркивается, а сверху начинает закрашиваться прогресс-бар. Делаете второе и... обнаруживаете, что прошло 4 часа, и вы почти заполнили этот прогресс бар. Планирую себе еще разных всплывающих мотивашек сделать, типа "Ты сделал уже три дела класса A, для следующего достижения нужно набрать 5" или "Ты уже работаешь почти столько, сколько и вчера, 75%".

Если дело активно не нравится или терпит или вообще силы кончились, верните его откуда взяли, нажмите кнопку "Вернуть" и не беспокойтесь ни о чем, ведь завтра вы сможете взять его в работу еще раз ) Даже если вы не "вернули" какие-то дела, ровно в полночь, они станут тыквой вернутся в пул задач сами

В блокноте это конечно не так удобно, но если пост заинтересует, расскажу как я делал это на бумаге.

UPDATE. Судя по комментариям мне придется допилить и выложить этот проект на общественное поругание ) Готов сделать это до конца следующей недели

Методология Agile. Топ 10 ошибок при использовании Agile.

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

1. Вашей команде не хватает свободы передвижения.

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

2. Игнорирование обратной связи от клиентов.

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

3. Отсутствие доверия.

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

4. Отсутствие коммуникаций.

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

5. Отсутствие соответствующего планирования.

В agile методологии планирование - это постоянная составляющая реализации всего проекта. Успешные Agile-команды, как правило, затрачивают не менее 20% имеющихся у них рабочих часов на работы по планированию.

6. Недостаточное тестирование.

Методология Agile предназначена для разработки высококачественного продукта, в определенные сроки и бюджет. Тестирование должно быть неотъемлемой частью разработки продукта и построения процесса, а не только после того как первая версия продукта уже готова.

7. Непродуманная структура команды.

Характеристика отличных agile команд - стабильность состава и многофункциональность. Руководству необходимо поддерживать стабильность команды в течение год, квартала, или даже месяца.

8. Не предупреждать людей, что сопротивление бесполезно.

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

9. Недостаток должной оценки своих возможностей.

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

10. Отсутствие обсуждения после поставки первой версии продукта.

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

/Консалтинговая компания по управлению проектами GANTBPM

Консалтинговые услуги