Андрей предлагает отказаться от жесткого планирования, привязанного ко времени, и перейти на Agile не только в управлении проектами, но и в собственном умственном труде.
Мне вообще такой подход очень близок, от идеи всем задачам ставить срок (а всем целям - количественное измерение) я отказалась очень давно и очень не люблю что-то обещать с привязкой по срокам. Но вот взаимодействовать с таким же не любителем сроков очень сложно. Хотя в докладе о скорости разработки на этот мой вопрос частично я ответ получила. Что скорость важнее 100% предсказуемых сроков.
Эффективность умственного труда - это когда из информации следует действие.По моему опыту в интернет-проектах никакие системы не работают. Скатываются к аутлук, гугл.докс, письмам, конференциям.
Что мешает?
- Высокая неопределенность
- Необходимость обучения в ходе проекте
- Команды маленькие, у всех разная скорость работы
- Никто не знает, что будет в конце, заказчик сам не знает, чего хочет
- Все должно быть очень быстро.70 процентов проектов заканчивается неудачей. И это не зависит от системы управления проектами.
Для быстрых проектов нет другого варианта, кроме использования принципов самоорганизации.
Если контроль нужен, то проекты будут медленные.
Самые отличные идеи приходят во время отпуска. Потому что так и должен работать мозг - покой и редкие всплески активности.
Чтобы дело шло быстро - люди должны хотеть, чтобы дело было сделано.
После того, как вы понимаете, что работать нужно не для того, чтобы потом не работать, вы понимаете, что работать нужно гораздо больше.
Если короткие задачи делать сразу - то все делается лучше.
Сразу - преобразование информации в решения.
Больше решений, меньше планирования.
Жесткие сроки задач нужны при нехватке времени на контроль.
Более правильно - планировать первое действие, а там будет уже следующее решение. Исходя из ситуации в проекте и вообще списка своих задач.
Негибкий План мешает использованию возможностей. Нужно принимать решения чаще.
Часть внимания - текущей задаче, часть - всему своему списку.
Часто говорят об инструментах, но их каждый подбирает под конкретно свой типичный поток задач.
Изменения в системе гтд:
Определение своей позиции для облегчения принятия решений.
Если у человека нет опыта своих проектов, доведения от идеи до результата - то постановку задачи ему надо делать очень детальноБольшинство проектов начинаются в стадии, когда не понятно что, но очень хочется.
Вопрос “Зачем” - важный.
Коммуникации в проектах с высокой неопределенностью важнее, чем планирование и контроль.
Как добиться тишины в голове? Как перестать беспокоиться? Как работать над одной задачей?
По аналогии с производством - задачи выполняются по приоритетам, блоками.
Задач должно быть больше, чем вы успеете сделать - если освободится время.
В 2 раза больше, но чтобы беспокойство не возникало. От привязки ко времени надо отказаться. Чем меньше привязок ко времени - тем больше эффективность.
Приоритеты учитывают даты отгрузки.
В последний момент больше всего информации, поэтому решения принимать и работу делать надо в последний момент.
Как использовать ГТД в управлении проектами?
- Дробление задач на отклики. То, чего вы ждете во внешнем мире, чтобы что-то делать.
- Сдерживание запуска задач следующего этапа - не давать того, что нужно сильно потом.Общая информационная база. Чтобы все могли принимать правильные решения.
Решение - превращение бесконечного количества факторов в конечное количество важных факторов.
Беспокойство - не доведенное до конца действие, информация, по которой не принято решение.
Чтобы убрать беспокойство - надо собрать все задачи.
Когда мы думаем про одну задачу - это эффективно.
Все поступающие задачи - откладываются, и решения принимаются по всем сразу.
Личная эффективность измеряется по тому, как уменьшается количество проблем.
Лиза. Почему меня так раздражает попытка научить, как жизнь ранжировать?
Общий взгляд и конкретное действие заставляет работать оба полушария.