О применении алгоритма разбора входящих для элементов проекта.

Обсуждаем вопросы личной эффективности: как есть слонов, лягушек, летучих мышей...
Аватара пользователя
lazyf1sh
Сообщения: 74
Зарегистрирован: Ср мар 02, 2016 1:33 pm

Re: О применении алгоритма разбора входящих для элементов проекта.

Сообщение lazyf1sh »

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

Изо дня в день - лишнее; напланировал на неделю и занимаешься. Со временем придет опыт сколько задач можно решить. В этом может помочь метод помидора ("я могу выполнить пять-девять помидоров в день и столько-то в неделю"). О какой картинке речь, кстати?
just писал(а):Испытываете ли вы какой-либо дискомфорт когда у вас завал дел, и вам необходимо метаться между обзором следующих конкретных шагов которые вам необходимо осуществить вот-вот сейчас, и после того как вы их сделали снова нужно лезть в справочную информацию и вычислять следующий шаг? Просто все как я понял в системе Jedi Tech отталкивается от экономии мыслетоплива, и вот данная операция лично на моем опыте ну уж очень слишком много сил отнимает (и мыслетоплива) по обдумыванию проекта и просмотра плана что, как, и где каждый раз.
Дискомфорт есть, но не сильный. Если приходится анализировать информацию по проекту и вычленять новые задачи посреди недели, значит, есть недогруз по планированию.

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

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

Что если отказаться от дробления на подпроекты глубже одного шага и сконцентрироваться на выполнении самой нужной на текущий момент фичи? А уже после ее завершения планировать исходя из ее результата? Такой способ гибче, чем спланировать всё сразу и следовать воле каркаса, постоянно "подпланировывая" в течение недели :)

Какова ваша роль на проекте, кстати?

Аватара пользователя
Roman Varianko
Сообщения: 10
Зарегистрирован: Пн окт 03, 2016 2:58 pm

Re: О применении алгоритма разбора входящих для элементов проекта.

Сообщение Roman Varianko »

Хороший вопрос прозвучал:
Ivan Kopylov писал(а):Какова ваша роль на проекте, кстати?
и я его дополню: а как вообще выглядит команда проекта (в плане ролей)?
Потому как скорее всего, вам придется учитывать/согласовывать применяемые технологии - с ними (глубже, до перечня стейкхолдеров, лезть не будем - это всё же коммент ;) )
Подход, который защитит вас (хотя бы частично) от "переизобретания велосипедов" - определиться в явном виде с применяемой методикой (как набором практик) управления проектами. Потому как GTD изначально был заточен под "револьверные" проекты (и проекты с более сложными архитектурами (назовем это так) в нем приходится обрабатывать с помощью всяческих костылей/ухищрений, что, как правило, не лучший подход), а переизобретать проектное управление - удовольствие сомнительное. Это опять же, если оставаться в "проектной парадигме" и не пытаться применить какой-нибудь Adaptive Case Management (объявив то, что вы делаете, не проектами, а кейсами) - но это тоже обсуждение не в формате комментов...
Основая мысль: сначала выбираете методику (осознанно), затем под нее "софт" (или же адаптируете уже используемый) - ибо в любой софт "вшита" какая-то методология, часто неочевидная без дополнительного разбирательства... после чего "стыкуете" с другими инструментами (управления задачами, к примеру).

just
Сообщения: 17
Зарегистрирован: Пн авг 22, 2016 3:53 am

Re: О применении алгоритма разбора входящих для элементов проекта.

Сообщение just »

Roman Varianko писал(а):Хороший вопрос прозвучал:
Ivan Kopylov писал(а):Какова ваша роль на проекте, кстати?
и я его дополню: а как вообще выглядит команда проекта (в плане ролей)?
Потому как скорее всего, вам придется учитывать/согласовывать применяемые технологии - с ними (глубже, до перечня стейкхолдеров, лезть не будем - это всё же коммент ;) )
Подход, который защитит вас (хотя бы частично) от "переизобретания велосипедов" - определиться в явном виде с применяемой методикой (как набором практик) управления проектами. Потому как GTD изначально был заточен под "револьверные" проекты (и проекты с более сложными архитектурами (назовем это так) в нем приходится обрабатывать с помощью всяческих костылей/ухищрений, что, как правило, не лучший подход), а переизобретать проектное управление - удовольствие сомнительное. Это опять же, если оставаться в "проектной парадигме" и не пытаться применить какой-нибудь Adaptive Case Management (объявив то, что вы делаете, не проектами, а кейсами) - но это тоже обсуждение не в формате комментов...
Основая мысль: сначала выбираете методику (осознанно), затем под нее "софт" (или же адаптируете уже используемый) - ибо в любой софт "вшита" какая-то методология, часто неочевидная без дополнительного разбирательства... после чего "стыкуете" с другими инструментами (управления задачами, к примеру).
> а как вообще выглядит команда проекта (в плане ролей)?
От проекта к проекту по разному. Но обычно в соло сам всем заправляю и все делаю. Была бы возможность поручить хотя бы часть своих обязательств на людей которые могут это сделать - давно бы сделал, но только к сожалению имею печальный опыт лично в моем проекте передачи решения некоторых проблем на "аутсорс", в последствии с такими вот "передачами" пришлось не только запороть сроки, а так же полностью переписать все то, что мне накодили, ну и разумеется потеря денег \ времени \ нервов \ сил \ и т.п. и т.д.

К сожалению, со временем, я все более и более осознаю что проблема не в алгоритмах разбора входящих, либо в алгоритмах следованию методике, проблема исключительно психологическая, и вызвана "вылетом из потока на длительное время", а за время когда отсутствовала любая активность - энтузиазм и мотивация пропали, отсюда и нет прогресса никакого. Причем если объективно посмотреть на ситуацию критически, то даже банальным деланием хотя бы что-то по 1-2 задачи в день (а не по 20-30 как раньше) за тот срок, который я ничего вообще ничерта не делал - существенно помогло. Но увы и ах, мотивации что-либо делать, даже организовать список входящих и преобразовать в дела, и отсортировать и структурировать как-то - не хватает. Ощущается состояние перегорания, которое усиливается виденьем полной картины мира, и того, что предстоит сделать, это безумно давит на мозг, и усугубляет и без того никакую мотивацию делать хотя бы что-то. Вот и получается ситуация замкнутого круга: дел дохрена, и никто ничего не делает, а нужно, ну и стресс растет в связи с не сделанными делами, и постоянно увеличивается. Ну и отсюда вылазят всякие тараканы которые пытаются найти волшебную пилюлю в методиках различных с надеждой что эти самые методики за меня все порешают:) Глупо, наивно, но это так. Отсюда вот такая ужасная придирчивость к каждому элементу системы:) Короче не знаю что делать, но дел реально очень дохрена, возможно однажды напишу тут пост как выбрался из этой ситуации и как порешал это все, а возможно и нет:))) В любом случае всем большое спасибо за советы, которые очень ценны для меня. ;)

Аватара пользователя
Dmytro Kostiuk
Сообщения: 38
Зарегистрирован: Пн сен 12, 2016 10:03 pm
Контактная информация:

Re: О применении алгоритма разбора входящих для элементов проекта.

Сообщение Dmytro Kostiuk »

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

Lomelind
Сообщения: 1235
Зарегистрирован: Ср июл 01, 2015 5:11 pm

Re: О применении алгоритма разбора входящих для элементов проекта.

Сообщение Lomelind »

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

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

И третий помогающий мне способ, потасканный в жж - временный мораторий на новые дела.
На конкретный конечный срок (мне удобно - на лунный месяц, или на неделю) принимается сознательное решение не браться ни за какие новые дела кроме совсем аварийных (пожар тушить всё же надо, если случилось). Возникшие идеи записываются в отдельное место и в обзорах до конца периода не участвуют. Пришедшие с целью поручить какое-то дело спрашиваются, не пожар ли у них, и если нет, то отправляются либо в будущее, либо к истокам всего сущего.
Жизнь в таком режиме отдельно интересна выслеживанием источников дел. Иногда можно много нового узнать о себе. Так, любой принесённый в дом предмет - это уже какое-то дело - и при покупке приходится думать не только о цене, но и о том, сколько времени и внимания этой штуке понадобится дома (и вместо картошки покупаем рис - его не надо чистить). Бывает, что разговор с конкретным человеком всегда порождает кучу новых дел - и это тоже повод задуматься, как так получается (у меня так получается при договорённостях с конкретным человеком - человек привык делать всё основательно и качественно, "как положено", и то, что я воспринимаю как общее дело на полчаса, у него может оказаться общим проектом на весь день). Точно порождает кучу новых дел попытка работать из состояния "там две обезьяны", если им под лапы попалась не совсем обезьянья работа.

Аватара пользователя
Петр Руденко
Сообщения: 5
Зарегистрирован: Пт окт 07, 2016 8:36 pm
Контактная информация:

Re: О применении алгоритма разбора входящих для элементов проекта.

Сообщение Петр Руденко »

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

В истоках стоят зверушки: "Контролировать окружающее! - Ученый заяц", "Это обязательно пригодится! - Хомяк", "Надо все успеть! - Лиса".
Ученый заяц пытается из любого дела сделать проект. Хомяк гребет любую инфу, которая может пригодиться в каждом из проектов. Лиса каждый день набирает кучу новых дел.
Вот эти три друга и мешают жить. Проблема не в том, что входящая информация бесполезна, проблема в том, что надо давать по лапам каждому из зверушек иначе они съедят все мыслетопливо.
Сейчас лапы зайца придерживает принцип "Проектом может быть только то, на что накопилось достаточно различного материала".
Лапы хомяка "Искать, читать, сохранять информацию только по текущей и следующей задаче".
Лапы лисы "Приоритеты задач выставляются один раз в неделю и не меняются".

Учусь дрессировать своих зверушек и вам желаю того же)) А классическая обезьянка Макса у меня больше всего любит шептать на ухо: "Тебе надо прилечь на 5 мин, передохнуть, музычку послушать". Ее хитрость в том, что 5 мин всегда становятся 30ю а то и часом))

Lomelind
Сообщения: 1235
Зарегистрирован: Ср июл 01, 2015 5:11 pm

Re: О применении алгоритма разбора входящих для элементов проекта.

Сообщение Lomelind »

Зверушки супер:)

Аватара пользователя
Андрей Титов
Сообщения: 207
Зарегистрирован: Ср сен 23, 2015 2:24 pm
Откуда: Калуга
Контактная информация:

Re: О применении алгоритма разбора входящих для элементов проекта.

Сообщение Андрей Титов »

А где змея, которая от всего ускользает?

Где слон - который просто прёт на пролом?

Где медведь - которому всё по фиг?

Где волк - который вгрызается в задачи и разрывает их?

Ну и где стрекоза и муравей?
Кто понял жизнь - тот не спешит

Женя С
Сообщения: 137
Зарегистрирован: Вт мар 29, 2016 10:49 pm

Re: О применении алгоритма разбора входящих для элементов проекта.

Сообщение Женя С »

Видимо, эти звери не работают с входящими.

Lomelind
Сообщения: 1235
Зарегистрирован: Ср июл 01, 2015 5:11 pm

Re: О применении алгоритма разбора входящих для элементов проекта.

Сообщение Lomelind »

Напролом - это скорее бегемот:)
бегемот плохо видит, но при его весе это уже не его проблема:))))

Ответить