О применении алгоритма разбора входящих для элементов проекта.
Добавлено: Вс окт 23, 2016 7:24 pm
Добрый вечер, пытаюсь основательно завести работу мозга (уже в который раз), и сдвинутся с мертвой точки, но пока безуспешно.
Проблема:
Вот собрали мы все все все входящие, и начали разбирать их по элементам. У нас появились очень простенькие задачки, справочная информация, список конкретных действий, но вот понять логику проектов не могу, а именно что делать, когда в проекте появляются под-проекты.
Т.е. давайте объясню, тут многие сразу поймут что я имею в виду, - я у мамы недопрограммист, и к сожалению у меня не получается из-за своей профессии применить Jedi Tech до конца (сконвертировать проблемы в список задач) из-за детализации проектов к физических действий при естественном планировании и разборе входящих. Для жизненных каких-то штук не относящихся к разработке ПО Джедайская Техника - работает, а вот для разработки ПО - как-то не очень у меня получается.
Примеры проблемы
Вот банальный пример, в инбоксе есть запись: "завершить разработку ХХХ сервера" (игровой проект).
Эта запись трансформируется из входящих в список проектов. Дальше начинается самая интересная и темная часть, которая тормозит из-за непонимания алогритма все остальное.
Что я делаю:
1. Подключаю всесторонний анализ проекта "завершить разработку ХХХ сервера"
Получаются вот такие вот записи в проекте "завершить разработку ХХХ сервера" (просто пример):
- пофиксить все сообщенные игроками баги
- внедрить все игровые предложения
- запустить рекламную кампанию.
Ну и там дальше всякая такая вот ерунда. Но для того, что бы не получалось очень много букаф в тексте - то эти элементы (де-факто под-проекты) не будут тут опубликоваться. Как вы видите выше, эти записи уже добавлены в проект, и отсортированы в нужном порядке их выполнения. Но они не смогут быть сделаны за один присест или пару помидорок, это проекты, причем количеством элементом внутри там так же может быть разное, и внутри этих проектов могут быть и другие проекты.
Собственно уже на этом этапе возникают следующие вопросы:
1. Как быть вот с таким, когда внутри проекта появляются еще проекты, а внутри этих под-проектов возможно появятся еще под-под-проекты?
2. Что делать, и как делать это по вашему?
3. Необходимо ли декомпозировать данные проекты до тех пор пока не получаться конкретные действия?
4. Куда скидывать под-под-под проекты, Где их размещать, и стоил ли их добавлять в инбокс и повторять процедуру алогоритма разбора входящих?
5. Просто Макс говорил о том, что лучше избавляться от всяких подзадач, под-под-под-проектов в своих таск менеджерах, ведь они будут только путать (и с этим я отчасти согласен)
Мысли которые вертятся в голове (возможно ошибочны, поэтому и спрашиваю тут на форуме у людей которые уже внедрили техники):
1. Ну вот после проведения первого цикла всестороннего анализа проекта у нас появились дополнительные элементы которые де-факто являются сложными проектами.
2. Далее мы действуем следующим образом: (мое ПО позволяет создавать под-проекты):
а) создаем под-проект "пофиксить все сообщенные игроками баги", ну и запускаем всесоторонний анализ. Нагенерим кучу идей, соберем всю инфу, и получим список всякой каши из ссылок на баги в багтрекере, а так же информацию различную.
б) Дальше обрабатываем нагерерированную чушь так же, как и обрабатываем инбокс (тот же алгоритм разбора), но при этом мы ничего никуда не перемещаем, все элементы остаются в под-проекте "пофиксить все сообщенные игроками баги". Допустим у нас уже больше при декомпозиции проекта нет более мелких проектов, и в этом под-проекте мы трансформировали все что было в конкретные задачи и добавили в список задач в проект.
в) выходим из цикла "пофиксить все сообщенные игроками баги", и залетаем в новый созданный проект: "внедрить все игровые предложения" и делаем так то же самое что и в а) и б), и так повторяем для всех всех под-проектов до тех пор пока не получим конкретные обезъяньи шаги.
3. Ну вот мы получили после глубокого разбора по алгоритму обезьяньи шаги, ну и делаем теперь дела как описано у Макса (три коробочки, сегодня, на неделе, потом, выбираем что будем делать на неделе, каждый день чекаем что сегодня будем делать, и что будем доставать из надеделю, + еженедельные обзоры, и т.п. и т.д)
4. Проекты хранятся как папки в под-папках в утилите которую использую (Todoist).
5. Еженедельно просматриваю проекты от самого декомпизированного до "родительского", т.е. от самого детализированного к более глобальному.
===========================
Прошу прощения за очень много букаф, но именно данный вопрос не дает мне уже спать с августа месяца, я очень-очень-очень много информации прочитал, задавал на других форумах, у других людей, купил книжки Алена, проштудировал блог Макса, проштудировал все видео, и презентации, но так и не нашел ответы на вопрос:
Что делать когда внутри проекта появляются элементы после брейншторма которые являются проекты, куда эти проекты деть (где их хранить) и как с ними поступать? Необходимо ли применять алгоритм разбора входящих до тех пор, пока все проекты не станут из себя представлять следующую сущность: "нечто, что не делается за один обезьяний шаг, и если больше условного 1 шага - то это проект", или нет?
Спасибо большое за то, что дочитали до конца
Проблема:
Вот собрали мы все все все входящие, и начали разбирать их по элементам. У нас появились очень простенькие задачки, справочная информация, список конкретных действий, но вот понять логику проектов не могу, а именно что делать, когда в проекте появляются под-проекты.
Т.е. давайте объясню, тут многие сразу поймут что я имею в виду, - я у мамы недопрограммист, и к сожалению у меня не получается из-за своей профессии применить Jedi Tech до конца (сконвертировать проблемы в список задач) из-за детализации проектов к физических действий при естественном планировании и разборе входящих. Для жизненных каких-то штук не относящихся к разработке ПО Джедайская Техника - работает, а вот для разработки ПО - как-то не очень у меня получается.
Примеры проблемы
Вот банальный пример, в инбоксе есть запись: "завершить разработку ХХХ сервера" (игровой проект).
Эта запись трансформируется из входящих в список проектов. Дальше начинается самая интересная и темная часть, которая тормозит из-за непонимания алогритма все остальное.
Что я делаю:
1. Подключаю всесторонний анализ проекта "завершить разработку ХХХ сервера"
Получаются вот такие вот записи в проекте "завершить разработку ХХХ сервера" (просто пример):
- пофиксить все сообщенные игроками баги
- внедрить все игровые предложения
- запустить рекламную кампанию.
Ну и там дальше всякая такая вот ерунда. Но для того, что бы не получалось очень много букаф в тексте - то эти элементы (де-факто под-проекты) не будут тут опубликоваться. Как вы видите выше, эти записи уже добавлены в проект, и отсортированы в нужном порядке их выполнения. Но они не смогут быть сделаны за один присест или пару помидорок, это проекты, причем количеством элементом внутри там так же может быть разное, и внутри этих проектов могут быть и другие проекты.
Собственно уже на этом этапе возникают следующие вопросы:
1. Как быть вот с таким, когда внутри проекта появляются еще проекты, а внутри этих под-проектов возможно появятся еще под-под-проекты?
2. Что делать, и как делать это по вашему?
3. Необходимо ли декомпозировать данные проекты до тех пор пока не получаться конкретные действия?
4. Куда скидывать под-под-под проекты, Где их размещать, и стоил ли их добавлять в инбокс и повторять процедуру алогоритма разбора входящих?
5. Просто Макс говорил о том, что лучше избавляться от всяких подзадач, под-под-под-проектов в своих таск менеджерах, ведь они будут только путать (и с этим я отчасти согласен)
Мысли которые вертятся в голове (возможно ошибочны, поэтому и спрашиваю тут на форуме у людей которые уже внедрили техники):
1. Ну вот после проведения первого цикла всестороннего анализа проекта у нас появились дополнительные элементы которые де-факто являются сложными проектами.
2. Далее мы действуем следующим образом: (мое ПО позволяет создавать под-проекты):
а) создаем под-проект "пофиксить все сообщенные игроками баги", ну и запускаем всесоторонний анализ. Нагенерим кучу идей, соберем всю инфу, и получим список всякой каши из ссылок на баги в багтрекере, а так же информацию различную.
б) Дальше обрабатываем нагерерированную чушь так же, как и обрабатываем инбокс (тот же алгоритм разбора), но при этом мы ничего никуда не перемещаем, все элементы остаются в под-проекте "пофиксить все сообщенные игроками баги". Допустим у нас уже больше при декомпозиции проекта нет более мелких проектов, и в этом под-проекте мы трансформировали все что было в конкретные задачи и добавили в список задач в проект.
в) выходим из цикла "пофиксить все сообщенные игроками баги", и залетаем в новый созданный проект: "внедрить все игровые предложения" и делаем так то же самое что и в а) и б), и так повторяем для всех всех под-проектов до тех пор пока не получим конкретные обезъяньи шаги.
3. Ну вот мы получили после глубокого разбора по алгоритму обезьяньи шаги, ну и делаем теперь дела как описано у Макса (три коробочки, сегодня, на неделе, потом, выбираем что будем делать на неделе, каждый день чекаем что сегодня будем делать, и что будем доставать из надеделю, + еженедельные обзоры, и т.п. и т.д)
4. Проекты хранятся как папки в под-папках в утилите которую использую (Todoist).
5. Еженедельно просматриваю проекты от самого декомпизированного до "родительского", т.е. от самого детализированного к более глобальному.
===========================
Прошу прощения за очень много букаф, но именно данный вопрос не дает мне уже спать с августа месяца, я очень-очень-очень много информации прочитал, задавал на других форумах, у других людей, купил книжки Алена, проштудировал блог Макса, проштудировал все видео, и презентации, но так и не нашел ответы на вопрос:
Что делать когда внутри проекта появляются элементы после брейншторма которые являются проекты, куда эти проекты деть (где их хранить) и как с ними поступать? Необходимо ли применять алгоритм разбора входящих до тех пор, пока все проекты не станут из себя представлять следующую сущность: "нечто, что не делается за один обезьяний шаг, и если больше условного 1 шага - то это проект", или нет?
Спасибо большое за то, что дочитали до конца