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

Обсуждаем вопросы личной эффективности: как есть слонов, лягушек, летучих мышей...
just
Сообщения: 17
Зарегистрирован: Пн авг 22, 2016 3:53 am

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

Сообщение just »

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

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

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

Примеры проблемы
Вот банальный пример, в инбоксе есть запись: "завершить разработку ХХХ сервера" (игровой проект).
Эта запись трансформируется из входящих в список проектов. Дальше начинается самая интересная и темная часть, которая тормозит из-за непонимания алогритма все остальное.

Что я делаю:

1. Подключаю всесторонний анализ проекта "завершить разработку ХХХ сервера"

Получаются вот такие вот записи в проекте "завершить разработку ХХХ сервера" (просто пример):
- пофиксить все сообщенные игроками баги
- внедрить все игровые предложения
- запустить рекламную кампанию.

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

Собственно уже на этом этапе возникают следующие вопросы:

1. Как быть вот с таким, когда внутри проекта появляются еще проекты, а внутри этих под-проектов возможно появятся еще под-под-проекты?
2. Что делать, и как делать это по вашему?
3. Необходимо ли декомпозировать данные проекты до тех пор пока не получаться конкретные действия?
4. Куда скидывать под-под-под проекты, Где их размещать, и стоил ли их добавлять в инбокс и повторять процедуру алогоритма разбора входящих?
5. Просто Макс говорил о том, что лучше избавляться от всяких подзадач, под-под-под-проектов в своих таск менеджерах, ведь они будут только путать (и с этим я отчасти согласен)

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

1. Ну вот после проведения первого цикла всестороннего анализа проекта у нас появились дополнительные элементы которые де-факто являются сложными проектами.
2. Далее мы действуем следующим образом: (мое ПО позволяет создавать под-проекты):

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

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

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

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

4. Проекты хранятся как папки в под-папках в утилите которую использую (Todoist).
5. Еженедельно просматриваю проекты от самого декомпизированного до "родительского", т.е. от самого детализированного к более глобальному.

===========================
Прошу прощения за очень много букаф, но именно данный вопрос не дает мне уже спать с августа месяца, я очень-очень-очень много информации прочитал, задавал на других форумах, у других людей, купил книжки Алена, проштудировал блог Макса, проштудировал все видео, и презентации, но так и не нашел ответы на вопрос:

Что делать когда внутри проекта появляются элементы после брейншторма которые являются проекты, куда эти проекты деть (где их хранить) и как с ними поступать? Необходимо ли применять алгоритм разбора входящих до тех пор, пока все проекты не станут из себя представлять следующую сущность: "нечто, что не делается за один обезьяний шаг, и если больше условного 1 шага - то это проект", или нет?

Спасибо большое за то, что дочитали до конца :mrgreen:

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

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

Сообщение just »

В общем прочитал огромное количество информации и тем на этом форуме, + гуглил в интернете, и считаю важным дополнить свой пост следующим учитывая прочитанное:

1. Я принципиально не пользуюсь кучей отдельных приложений, меня мой инструмент ведения дел устраивает полностью, ведь он поддерживает опции для хранения информации там, где она и должна быть (инфа по проектам находится к комментах к проекту, инфа по задачам - в коментах к задаче, и т.п. и т.д.)
2. Я не пользуюсь mindmap / приложениями для ведения крупных проектов (а мои как раз из средних-крупных (разработка любого ПО к сожалению занятие объемное, где необходимо учитывать огромное количество деталей), следовательно все находится в приложении для ведения задач, и структурировано по темам \ категориям \ проектам, и это позволяет видеть то, что "имеет прогресс", что "не имеет прогресс", куда нужно поднажать, где нужно что-то дополнить, и самое главное - можно видеть прогресс выполненного, что так же придает некую мотивацию и позитивные эмоции при реализации дел. Следовательно этим я хочу сказать, что в текущем понимании Jedi Tech где нужно хранить весь план проекта \ структуры данных и и т.д. в mindmap / справочных материал для меня не применимо, и очень накладко и трудно. Ведь это требует особой дисциплины, внимания, да и вообще занимает слишком много времени, и иногда больше, чем реализовать то, над чем думаешь (иногда даже в разы больше).


Поэтому пожалуй сформулирую по другому, и кратко первоначальный вопрос:
1. Можно ли применять алгоритм jedi Tech разбора на атомарные действия при разборе входящих для проектов, и дополнительных появившихся под-проектов рекурсивно и в глубину до тех пор, пока каждый под-под-под проект не превратится в сущность проекта о котором говорит Максим (что мол проект это что-то, что нельзя выполнить одним действием), или нет?
2. Если можно это применять, какую тактику использовать для этого разбора и фактической декомпозиции (нарезки) крупных проектов на более-мелких и на атомарные задачи? Куда помещать получившиеся отделившиеся под-проекты, как отдельную сущность во входящие, или держать для удобства в папке с проектом еще один под-проект?

Пример иллюстрирует сохранение структуры данных при разбивки проекта на под-проекты.
проект: "долелать софт ХХХ"
под-проект: "внедрить все предложения пользователей"
под-проект: "пофиксить все баги"

Вот интересует куда эти подпроекты деть? Вновь внести во входящие и снова пройтись по ним с алгоритмом разбора входящих? и так до тех пор пока не получится много-много проектов с конкретными 1-3 шажками которые можно сделать? Или как?

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

Аватара пользователя
lazyf1sh
Сообщения: 74
Зарегистрирован: Ср мар 02, 2016 1:33 pm

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

Сообщение lazyf1sh »

Опишу свой опыт насчет декомпозиции.

Разделение делаю по проектам, которые никак не связаны между собой. Например, “Запустить личный блог” и “Написать убийцу евернота”. В пределах одного проекта сваливаю в кучу добротно сформулированные задачи. Декомпозирую сразу в формулировку задачи, а не в подпроект.

Задача должна быть сформулирована так, чтобы при прочтении возникал зуд желания ее сделать. Для этого нужно преодолеть желание бросить формулировку задачи и пойти делать и накидать себе побольше “вкусных” декомпозированных задач.

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

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

"Пофиксить все сообщенные игроками баги" - невыполнимая задача. Серия переформулировок:
* “пофиксить один сообщенный игроком баг"
* “открыть в таск-трекере первый попавшийся баг”
* “открыть часть кода, которая потенциально может приводить к данному багу и засечь один помидор”.

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

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

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

Сообщение just »

Ivan Kopylov писал(а):Опишу свой опыт насчет декомпозиции.

Разделение делаю по проектам, которые никак не связаны между собой. Например, “Запустить личный блог” и “Написать убийцу евернота”. В пределах одного проекта сваливаю в кучу добротно сформулированные задачи. Декомпозирую сразу в формулировку задачи, а не в подпроект.

Задача должна быть сформулирована так, чтобы при прочтении возникал зуд желания ее сделать. Для этого нужно преодолеть желание бросить формулировку задачи и пойти делать и накидать себе побольше “вкусных” декомпозированных задач.

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

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

"Пофиксить все сообщенные игроками баги" - невыполнимая задача. Серия переформулировок:
* “пофиксить один сообщенный игроком баг"
* “открыть в таск-трекере первый попавшийся баг”
* “открыть часть кода, которая потенциально может приводить к данному багу и засечь один помидор”.

Самым сложным в технике было начать делать регулярные обзоры и формулировать первые действия, которые иногда выглядят как написанные для идиотов.
Спасибо большое за рекомендации.
Можно вопрос?
А где вы в таком случае храните тот объем информации касательно проекта которые обязательно необходимо сделать в своей Jedi Tech системе? Ну т.е. допустим у вас есть приложение, пользователи написали кучу багрепортов и предложений которые вам нужно обработать и сделать. Какие ваши действия в этом случае? Можете описать алгоритм от сбора багов\предложений (именно интересует куда вы их складируете, в Inbox, в проект, либо в какой-то бумажный план проекта) до того момента как будете приступать к выполнению уже готовых понятных обезьяне задач. Важное уточнение, часть багрепортов в терминах David Allen являются некими средними проектами (много-много задачек нужно сделать для решения одного например Issue на Github).

Я просто пытаюсь на примерах научится, у самого к сожалению нет законченного представления касательно сбора \ обработки проекта на начальном этапе, и как это должно визуально быть. Ну т.е. вебинары смотрел, различные презентации так же, прочитал кучу-кучу материалов тут на форуме - и к сожалению так и не понял первого шага и как это будет выглядеть комплексно. Мозг рисует кучу вариантов с учетом реальных проблем которые необходимо решить, и автоматически их анализирует, и возникает масса вопросов по ряду нюансов.

Аватара пользователя
lazyf1sh
Сообщения: 74
Зарегистрирован: Ср мар 02, 2016 1:33 pm

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

Сообщение lazyf1sh »

just писал(а):Ну т.е. допустим у вас есть приложение, пользователи написали кучу багрепортов и предложений которые вам нужно обработать и сделать. Какие ваши действия в этом случае? Можете описать алгоритм от сбора багов\предложений (именно интересует куда вы их складируете, в Inbox, в проект, либо в какой-то бумажный план проекта) до того момента как будете приступать к выполнению уже готовых понятных обезьяне задач.
Если по багу/предложению нужно дать обратную связь пользователю или отчитаться перед руководством, то хранение и обработка происходит в той системе, куда поступил баг/предложение. Например, если бы пользователи слали баги в личную почту в обход фильтрации первой линией в джиру, я бы поставил письму ярлык "багрепорт", отправил письмо в архив, и поставил задачу "открыть багрепорты в почте, выбрать какой-нибудь для решения". После обзора имеющихся багов и понимания как они связаны между собой появляются новые задачи в личном трекере задач.
Если за баг не надо отчитываться (коллега указал на мою ошибку или я сам обнаружил баг), сформулирую следующее действие и удалю из той системы, в которую он попал. Если страшно, что из формулировки не будет понятно зачем это делать, можно прикрепить дополнений к формулировке: "..., чтобы ..., потому что, из-за такой-то херни ..." (обычно одного "чтобы" достаточно).

just писал(а):А где вы в таком случае храните тот объем информации касательно проекта которые обязательно необходимо сделать в своей Jedi Tech системе?
В целом - хранить в справочной информации. Я разделяю справочную информацию на понятную мне и для остальных.

На рабочем ПК в папке archive есть папка с названием проекта. В папку скидываю всё, что относится к проекту, но не требует документации для остальных людей - мои личные заметки, URLы, копипасты информации от коллег из месенджеров (сам месенджер я не рассматриваю как справочную информацию, и регулярно чищу хистори). Всё то, что может пригодиться через год. Такую папку может заменять evernote, инструменты для составления майндмап. Главное чтобы комфортно было. Очевидные вещи, которые надо знать всегда и которые составляют мой опыт как программиста, не записываю.

Для остальных документирую на локальной wiki уже с форматированием, понятными формулировками и т.д.

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

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

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

Сообщение just »

Ivan Kopylov писал(а):
just писал(а):Ну т.е. допустим у вас есть приложение, пользователи написали кучу багрепортов и предложений которые вам нужно обработать и сделать. Какие ваши действия в этом случае? Можете описать алгоритм от сбора багов\предложений (именно интересует куда вы их складируете, в Inbox, в проект, либо в какой-то бумажный план проекта) до того момента как будете приступать к выполнению уже готовых понятных обезьяне задач.
Если по багу/предложению нужно дать обратную связь пользователю или отчитаться перед руководством, то хранение и обработка происходит в той системе, куда поступил баг/предложение. Например, если бы пользователи слали баги в личную почту в обход фильтрации первой линией в джиру, я бы поставил письму ярлык "багрепорт", отправил письмо в архив, и поставил задачу "открыть багрепорты в почте, выбрать какой-нибудь для решения". После обзора имеющихся багов и понимания как они связаны между собой появляются новые задачи в личном трекере задач.
Если за баг не надо отчитываться (коллега указал на мою ошибку или я сам обнаружил баг), сформулирую следующее действие и удалю из той системы, в которую он попал. Если страшно, что из формулировки не будет понятно зачем это делать, можно прикрепить дополнений к формулировке: "..., чтобы ..., потому что, из-за такой-то херни ..." (обычно одного "чтобы" достаточно).

just писал(а):А где вы в таком случае храните тот объем информации касательно проекта которые обязательно необходимо сделать в своей Jedi Tech системе?
В целом - хранить в справочной информации. Я разделяю справочную информацию на понятную мне и для остальных.

На рабочем ПК в папке archive есть папка с названием проекта. В папку скидываю всё, что относится к проекту, но не требует документации для остальных людей - мои личные заметки, URLы, копипасты информации от коллег из месенджеров (сам месенджер я не рассматриваю как справочную информацию, и регулярно чищу хистори). Всё то, что может пригодиться через год. Такую папку может заменять evernote, инструменты для составления майндмап. Главное чтобы комфортно было. Очевидные вещи, которые надо знать всегда и которые составляют мой опыт как программиста, не записываю.

Для остальных документирую на локальной wiki уже с форматированием, понятными формулировками и т.д.

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

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

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

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

Хм, спасибо еще раз за описание вашего способа, попробую все же отделить справочную инфу от проекта и задач, и попробовать еще раз внедрить Jedi Tech.

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

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

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

just писал(а): Ну т.е. допустим у вас есть приложение, пользователи написали кучу багрепортов и предложений которые вам нужно обработать и сделать. Какие ваши действия в этом случае?
Подскажите, пожалуйста.
Зачем вам обработать сделать всю кучу багрепортов?
Вы хотите это сделать, чтобы что?

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

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

Сообщение just »

Dmytro Kostiuk писал(а):
just писал(а): Ну т.е. допустим у вас есть приложение, пользователи написали кучу багрепортов и предложений которые вам нужно обработать и сделать. Какие ваши действия в этом случае?
Подскажите, пожалуйста.
Зачем вам обработать сделать всю кучу багрепортов?
Вы хотите это сделать, чтобы что?
Интересный вопрос с ловушкой. Любой из моих ответов предполагает как минимум одно замечание со стороны, "а может еще как-то сделать это чтобы что". Но увы, багрепорты фиксятся не из любви к фиксу багов, а из мотивации удержания клиента пользоваться продуктом высокого качества, в противном случае этот самый клиент уйдет к конкурентам, у которых такого недостатка нет. Да и клиенты когда видят что их проблемы решаются и не "забивают на них болт", - выражают свою благодарность в существенно большем финансовом объеме, и что самое ценное - рекомендуют продукт своим знакомым, часть из которых так же начинает пользоваться и приносить доход. Получается некое сарафанное радио. А как мы знаем сарафанное радио - один из самых лучших методов привлечения новых клиентов. Вот и получается ответ на ваш вопрос "Что бы что", - это повысить в конечном итоге доходы от продаж, и нарастить клиентскую базу казалось бы довольно "странным" способом, который напрямую связан с качеством. Клиента можно обмануть только один раз, второго раза и клиентов для второго раза - уже не будет.

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

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

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

@just - вот именно с клиентами диссонанс сознания и происходит:

а) проблемы чьи? - клиента!

б) клиент чей? - фирмы!

в) а деньги видимо я и так получу ...

Вот и разрыв в мотивационной цепочке.
Кто понял жизнь - тот не спешит

Аватара пользователя
Дмитрий Неумойчев
Сообщения: 284
Зарегистрирован: Пт июл 10, 2015 10:50 am
Контактная информация:

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

Сообщение Дмитрий Неумойчев »

Джаст,
Ой, ну уж прям обмануть. Клиентов у вас сколько? А багрепортов? А сколько из клиентов видели эти баги? А среди тех кто видел, сколько считает, что это баги?
И после ответа на эти вопросы заново взглянуть на вопрос:
Зачем вам обработать сделать всю кучу багрепортов?

Непример, АФАИР ребята из 37signals писали, что базу багрепортов вести не обязательно - если баг критичный, то его берем в разработку. Если не настолько критичный, чтобы взять в разработку прямощас - в корзину его. Если он все-таки важен и часто встречается, то про него еще напишут. И на пятый раз выкидывания тот, кто выкидывает поймет, что пользователям это действительно важно и включит таки в разработку.
Такой вот модифицированный метод трех гвоздей. А закрыть все багрепорты - нереально. Максимум в программе типа ping, функционал которой уже который десяток лет не меняется. И то не факт, небось лезут баги совместимости с новыми осями.

Ответить