Pull to refresh

Comments 17

ИМХО, можно иметь план на месяц, на год, на несколько лет… и на день. НО, чем меньше временной промежуток, тем более детализирован должен быть план.
Абсолютно верно, аналогию можно провести с расстоянием, чем ты дальше во времени от даты тем менее детализовано ты видишь. Автор лукавит, т.к. выполняя ежедневные итерации он идет по некой дороге, а не блуждает в пустыне. В остальном мысли рабочие.
Детализированной должна быть цель, а не план.
Чтобы это доказать поменяю термины: план — это маршрут корабля, цель — это место куда нужно приплыть, приливы/отливы/ветер — внешние обстоятельства. Думаю при такой терминологии важность цели над планом очевидна.
Именно об этом сказано в книге «Peopleware» («Человеческий фактор. Успешные проекты и команды»). Цель должна быть чёткой, но план гибким.
Сейчас вспоминаю — все что мне удавалось начать и довести до логического завершения — выполнялось именно по принципам, приведенным в статье. А все что пытался планировать в деталях — провалилось.

Может, конечно, этот от человека зависит. Кто-то делает потому что нужно (дабы выполнить план, пятилетку). А кто-то делает потому что в кайф. Вот второму — детальный план иметь вредно. Делай себе в кайф — природа обо всем позаботилась, твое участие в коррекции этого плана ни к чему не приведет.
Вы только что описали GTD. В блоге GTD. Ну учите матчасть же :)
Больше похоже на «Автофокус»
В GTD еженедельный обзор
Еженедельное ревью, да, а вот задачи на день можно тасовать между собой и перемещать на другой день как угодно исходя из обстоятельств — в этом и гибкость. Автор как я понял предлагает тоже самое:
> Держите roadmap из списка, а задачи выбирайте на день.
«План — ничто, планирование — все» (генерал Д. Эйзенхауэр)
UFO just landed and posted this here
Хороший подход — относиться к задачам с точки зрения «как сделать, чтобы по-максимуму приблизить цель».
Но я бы не называл это итерацией длительностью в день. В agile продукт полученый после каждой итерации должен быть стабилен, протестирован qa, отдебажен и все таки, чем-то визуально отличаться от версии с предыдущего региза :) Но при итерации в день у нас могут возникнуть проблемы не только с завершением поставленных задач (например нового функционала, который частично запустить попросту невозможно) — попросту не хватит времени на тесты и фиксы. Так же при работе в команде, допустим от 3ех человек, возникнут проблемы согласования задач или же придется уделять больше времени ежедневным митингам, в отличии от долгих митингов и разборов полета при недельной итерации.
В общем, если применять такой подход малому количеству разработчиков и не рассматривать конечную точку каждой итерации как продукт или релиз — то это будет работать, но по-моему, например в том же scrum, при недельной итерации у нас все равно есть задачи на день, которые мы планируем на ежедневном scrum-митинге так что особой разницы я не заметил, зато убираются перечисленные выше минусы из-за присутствия недельного спринт беклога.
Использую ZTD — делаю три дела в день.
UFO just landed and posted this here
У меня планирование простое: система «три дела». Система разработана моей мамой ещё в 60-х.
За день получается решить только 3 значительные задачи. Например, сходить к зубному врачу, написать статью и сварить борщ. По опыту, всё что выходит за рамки цифры 3 и планировать не стоит чтобы не разочаровываться к концу дня.
Не согласен с пунктом 1.
Составление плана по Вашему подходу решает только тактические задачи. Но что же делать со стратегией? Почитать книгу Фаулера «Архитектура корпоративных программных приложений» никогда не «приблизит цель по-максимуму», но в перспективе, это намного более продуманное решение, чем за этот же день «набыдлокодить» еще пару модулей.
Т.е. по Вашему стоит вообще забросить на саморазвитие и самообучение, т.к. это не приносит сиюминутных прибылей?
если цель — самообучение и развитие, вполне можно поставить на сегодня «прочитать 2 главы Фаулера». главное — не ставить «прочитать все книги, которые планировал за последние два года».

стратегия складывается из набора целей, которые разбиты на задачи. они — это второй список, гораздо бОльший. и каждый раз, в идеале, выбирается задача на день, приближающая стратегически важные задачи, а не тактически (вроде быдлокодинга модулей)
Sign up to leave a comment.

Articles