05 июня 2012

GTD: Границы применимости

Стал перечитывать Getting Things Done Дэвида Аллена и столкнулся с интересным моментом.
Каждый проект по Аллену должен иметь конечную цель, которая должна быть определена в начале проекта (тут из-за кулис выпрыгивает Стивен Кови, размахивая вторым навыком высокоэффективного человека).
А проектом считается все, для реализации чего необходимо более 2 шагов.
Далее имеем проблему - нужно поддерживать конфигурацию тестовой среды в таком состоянии чтобы тесты проходили за время Х.

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








3 комментария:

  1. Этот комментарий был удален автором.

    ОтветитьУдалить
  2. Я подобные вещи сую в мыслесхему с текущим контекстом, которую регулярно просматриваю (раз в неделю, не реже).

    ОтветитьУдалить
    Ответы
    1. А вот про текущий контекст можно поподробнее ??? То есть у тебя одна карта на неделю/месяц/квартал ??? Чем определяется текущий контекст????

      Удалить