Комментарии 27
Ах вон как, майндмапы. Я думал что-то помощнее.
Всегда использую майндмапы для управления проектами. Только вот пишу не по компонентам — а по делам.
Прикрутите сроки и переход мапы в таймлайн (гантт) — и будет вообще чудесная вещь.
Всегда использую майндмапы для управления проектами. Только вот пишу не по компонентам — а по делам.
Прикрутите сроки и переход мапы в таймлайн (гантт) — и будет вообще чудесная вещь.
Майндмапы — это только начало. Нам видится, что довольно много менеджеров используют их для визуализации статуса проекта, а плагинов для популярных трекеров, которые позволяют использовать майндмапы, нет. В целом же круг проблем, которые мы собираемся решить, немного шире.
Не могли бы вы привести пример разбивки проекта по делам?
Не могли бы вы привести пример разбивки проекта по делам?
Например
Проект
— Дела с клиентом
— — Встречи
— — Документы
— Периодические активности
— — Отчетность
— — Контроль задач
— Вопросы на контроле
— — Тут конкретика о каких-нибудь поставках ПО/железа
— — Риски
— Текущая неделя
— — Исполнитель 1
— — — Задачи
— Решения
— — Собственно история решений/изменений по проекту
Ну и всё в таком духе. Видно с первого взгляда, если помечать флажками, где затыки и к чему они ведут.
Проект
— Дела с клиентом
— — Встречи
— — Документы
— Периодические активности
— — Отчетность
— — Контроль задач
— Вопросы на контроле
— — Тут конкретика о каких-нибудь поставках ПО/железа
— — Риски
— Текущая неделя
— — Исполнитель 1
— — — Задачи
— Решения
— — Собственно история решений/изменений по проекту
Ну и всё в таком духе. Видно с первого взгляда, если помечать флажками, где затыки и к чему они ведут.
спасибо!
Мне кажется очень большой уровень абстракции у вас и вы эту схему за счет этого применяете почти под любой проект. Не понятна перекрестная зависимость, например вопросы на контроле и задачи, если таковые возникают.
С одной стороны есть ощутимый плюс: при множестве одновременно ведомых проектов вы в рамках разных проектов работаете по одному плану, но как я уже написал мне не понятно как вы выстраиваете зависимости между подобными делами.
С одной стороны есть ощутимый плюс: при множестве одновременно ведомых проектов вы в рамках разных проектов работаете по одному плану, но как я уже написал мне не понятно как вы выстраиваете зависимости между подобными делами.
В принципе, многие mind map инструменты позволяют задавать произвольные связи между элементами, не только связь «родитель-потомок». Структура, которую привел в пример S_A, больше ориентирована на задачи; возможно, для нее как раз больше подошла бы диаграмма Ганта — если важно планировать задачи по времени и знать критический путь.
Мы отталкиваемся больше от разбиения всего scope на функциональные компоненты, которые интересны и понятны как заказчику, так и участникам проекта.
Не стоит забывать, что и тот, и другой вариант — просто вопрос группировки одних и тех же сущностей (задач). Над набором задач можно построить сколько угодно таких группировок — кому-то удобнее смотреть в разрезе задач и групп задач, кому-то — в разрезе функций приложения.
Мы отталкиваемся больше от разбиения всего scope на функциональные компоненты, которые интересны и понятны как заказчику, так и участникам проекта.
Не стоит забывать, что и тот, и другой вариант — просто вопрос группировки одних и тех же сущностей (задач). Над набором задач можно построить сколько угодно таких группировок — кому-то удобнее смотреть в разрезе задач и групп задач, кому-то — в разрезе функций приложения.
Это не карта продукта как такового, а карта именно управленческих дел. Зависимости можно указывать стрелками, задачи при желании можно перенести мышкой в вопросы на контроле. Не проблема. Это такой общий набросок я привел, в каждом проекте мапа уникальна.
Интересная вещь, буду следить за развитием.
PS: На сайте не работает подписка, исправьте, пожалуйста.
PS: На сайте не работает подписка, исправьте, пожалуйста.
Спасибо. А можно скриншот или описание того, что не работает. Мы пробуем — все ок.
Эммм… я сейчас из-за этой же ошибки 7 раз зарегистрировался. Сообщение «Спасибо за регистрацию» сразу не появляется. Как итог у меня в ящике 7 одинаковых писем «SNAP registration» и я думаю в случае запуска проекта я получу в этот ящик 7 одинаковых приглашений. =) Сделайте проверку на подписку пользователя.
В конечном счете, у вас просто декомпиляция задач в виде Миндмапа. Признаться, я не понимаю, как у вас проекты не разваливаются. Даже в Ганте есть порядок работ, что позволяет увидеть риски. У вас же все задачи как бы одноуровневые. Уже этого достаточно, чтобы не называть все это «системой».
Я, признаться, тоже не понимаю что вы имеете ввиду под «у вас все задачи одноуровневые»?
По вашим схемам все задачи могут быть выполнены в любой последовательности и не зависят одна от другой. Например, UI магазина сделать сейчас, а UI офиса через месяц, а потом сделать API или еще что-то. При этом, где нибудь есть одна ключевая задача без которой весь проект будет считаться нерабочим и которая может существенно влиять на весь проект, но мы этого из ваших схем никогда не узнаем.
Как я понял, цель не в том что бы отслеживать линейность процесса, а в том что бы отслеживать общую завершенность проекта. Фактически это полезная инфографика для PM, более удобная нежели диаграмма Ганта, только из-за того что оно представлено иначе. Другой вопрос, что декомпозицию проекта для такого представления нужно провести правильно, иначе можно сделать только хуже.
Да, спасибо, я хотел написать примерно то же самое.
Декомпозиция в нашем случае завязана на отдельные функции приложения, интересные заказчику. Как описывалось в статье, задачи первого (и иногда второго) уровня — это те строчки, которые клиент видит в смете. Если декомпозиция сделана плохо даже на этом уровне, проект обещает быть веселым =)
Декомпозиция в нашем случае завязана на отдельные функции приложения, интересные заказчику. Как описывалось в статье, задачи первого (и иногда второго) уровня — это те строчки, которые клиент видит в смете. Если декомпозиция сделана плохо даже на этом уровне, проект обещает быть веселым =)
Теперь понял, спасибо.
1. Многие не планируют, а точнее планируют по итерациям или на дэйли скрам митингах задачи и таким образом вполне реализуют свои проекты. т.е. по моему скромному ИМХО — это сравнение теплого и мягкого: планировать критический путь проекта в каком-либо инструменте и причины по которым проекты могут разваливаться.
2. Вы в каком то смысле очень правы, если мы возьмем задачи из таск-трекера и просто декомпилируем их в виде MindMap, то получим скорее всего плоский список :). Наш подход как раз предлагает начинать «заводить» задачи в проект используя графическое представление, и как показывает уже практика, задачи имеют от 2-х до 5 уровней.
3. Вы утверждаете что используя Ганта, вы решаете задачу, чтобы проект не развалился. И, соответственно, мы не отрицаем, что структурируя проект в Ганте, в обычном виде в таск-трекере или в виде MindMap нужно думать и структурировать проект так, чтобы каждая «корневая ветка» могла считаться законченным функционалом.
4. И есть немаловажное отличие между Гантом и структурой проекта в MindMap. Планируя проект в Ганте, вы можете функционал одного экрана, например «Экран личного кабинета пользователя», «физически» разбить… отдельно на APi, на UI, на разработку и т.д. т.к. эти задачи действительно паралелятся и делаются разными командами. Вы действительно, можете спланировать работу так, что сделаете проект за минимальный календарный срок. Но при этом, если у вас отдельный Гант (или группа в рамках одного Ганта) для серверных разработчиков, для дизайнеров и для фронтенда, то, очень сложно понять готов ли функционал. Структура в виде MindMap, предлагает описать бизнес фичу и видеть, на сколько она готова. Т.е. одно другому не мешает, можно представлять проект в виде MindMap и видеть «законченность» фич, при этом имея даты старта и окончания задач, планировать их паралельное выполнение.
1. Многие не планируют, а точнее планируют по итерациям или на дэйли скрам митингах задачи и таким образом вполне реализуют свои проекты. т.е. по моему скромному ИМХО — это сравнение теплого и мягкого: планировать критический путь проекта в каком-либо инструменте и причины по которым проекты могут разваливаться.
2. Вы в каком то смысле очень правы, если мы возьмем задачи из таск-трекера и просто декомпилируем их в виде MindMap, то получим скорее всего плоский список :). Наш подход как раз предлагает начинать «заводить» задачи в проект используя графическое представление, и как показывает уже практика, задачи имеют от 2-х до 5 уровней.
3. Вы утверждаете что используя Ганта, вы решаете задачу, чтобы проект не развалился. И, соответственно, мы не отрицаем, что структурируя проект в Ганте, в обычном виде в таск-трекере или в виде MindMap нужно думать и структурировать проект так, чтобы каждая «корневая ветка» могла считаться законченным функционалом.
4. И есть немаловажное отличие между Гантом и структурой проекта в MindMap. Планируя проект в Ганте, вы можете функционал одного экрана, например «Экран личного кабинета пользователя», «физически» разбить… отдельно на APi, на UI, на разработку и т.д. т.к. эти задачи действительно паралелятся и делаются разными командами. Вы действительно, можете спланировать работу так, что сделаете проект за минимальный календарный срок. Но при этом, если у вас отдельный Гант (или группа в рамках одного Ганта) для серверных разработчиков, для дизайнеров и для фронтенда, то, очень сложно понять готов ли функционал. Структура в виде MindMap, предлагает описать бизнес фичу и видеть, на сколько она готова. Т.е. одно другому не мешает, можно представлять проект в виде MindMap и видеть «законченность» фич, при этом имея даты старта и окончания задач, планировать их паралельное выполнение.
Я понимаю, что основная ваша фишка — это увидеть законченность отдельных функций в проекте, причем, как можно нагляднее. Но это задачи инфографики. Предположим, что вы хотите еще дать упрощенный доступ к аналитической информации по проекту. Но тогда сам выбор формата Миндмапа для меня странный.
Например, я легко могу представить, что все ваши ветки красные, потому что какие то проблемы с UI (некая сквозная задача, которая затрагивает все функции — «перекрасить все кнопки в красный цвет, а дизайнер забухал»). Но сам формат Миндмапа сложен, чтобы наглядно оценить насколько эти проблемы критичны для всего проекта.
Например, я легко могу представить, что все ваши ветки красные, потому что какие то проблемы с UI (некая сквозная задача, которая затрагивает все функции — «перекрасить все кнопки в красный цвет, а дизайнер забухал»). Но сам формат Миндмапа сложен, чтобы наглядно оценить насколько эти проблемы критичны для всего проекта.
А как вы решаете проблему «перекрасить все кнопки в красный цвет, а дизайнер забухал» в целом или при помощи того же Ганта? :)
Вопрос в том: Будет ли ваша «система» как-то решать такие задачи? :) Как я понимаю — никогда не будет.
Гант я лично использую только для оценки проекта (сроков и бюджета). Управление проектом уже вне его делается. И для целей оценки прекрасно используется JCVGantt + MindManager. Вы же берете Mindmanager и выдумываете что-то несусветное (уж простите меня за такую оценку), при этом убеждая себя, что в этом есть какой то смысл. Ну ладно, мне лень переходить на новую версию MIndManager, но вы могли бы посмотреть оригинальную реализацию использования миндмапов для ведения бизнеса http://www.mindjet.com/mindmanager/features/business-project-tools/.
На мой скромный взгляд, вы просто изобретаете новую форму колеса. В принципе, если вам за это деньги платят, то вы вообще в шоколаде. Работы бесконечно много, но в идее нет ничего нового и интересного.
Гант я лично использую только для оценки проекта (сроков и бюджета). Управление проектом уже вне его делается. И для целей оценки прекрасно используется JCVGantt + MindManager. Вы же берете Mindmanager и выдумываете что-то несусветное (уж простите меня за такую оценку), при этом убеждая себя, что в этом есть какой то смысл. Ну ладно, мне лень переходить на новую версию MIndManager, но вы могли бы посмотреть оригинальную реализацию использования миндмапов для ведения бизнеса http://www.mindjet.com/mindmanager/features/business-project-tools/.
На мой скромный взгляд, вы просто изобретаете новую форму колеса. В принципе, если вам за это деньги платят, то вы вообще в шоколаде. Работы бесконечно много, но в идее нет ничего нового и интересного.
Насчет новизны вы, пожалуй, правы. Другое дело, что в целом сложно назвать какие-то радикально новые вещи в управлении проектами. «Мифический человеко-месяц» был написан в 1975, с тех пор мало что изменилось — те же проблемы, примерно те же способы их решения. Scrum'у, который в последние несколько лет набирает популярность, порядка 25 лет.
Мы точно знаем, что есть люди, которые тоже используют майндмепы для ведения проектов и согласны с нами в том, что это удобно. Но таких людей пока мало, поэтому мы и делимся опытом в надежде, что больше оценит удобство и простоту такого подхода.
Mindjet мы используем, собственно, все скриншоты в статье — из него. Проблема в том, что он никак не интегрируется с таск-трекерами вроде Redmine или JIRA, а перевозить всех разработчиков в Mindjet Project Director мы не готовы.
Мы точно знаем, что есть люди, которые тоже используют майндмепы для ведения проектов и согласны с нами в том, что это удобно. Но таких людей пока мало, поэтому мы и делимся опытом в надежде, что больше оценит удобство и простоту такого подхода.
Mindjet мы используем, собственно, все скриншоты в статье — из него. Проблема в том, что он никак не интегрируется с таск-трекерами вроде Redmine или JIRA, а перевозить всех разработчиков в Mindjet Project Director мы не готовы.
Еще немного потревожу вас. Коль вы взялись за проект, то, наверное, лучше, как мне кажется, сделать понятный проект меньшего размера, чем огромный, но с невнятной аудиторией и функционалом.
Вы пытаетесь охватить «оценку, планирование, контроль, риски». Мне кажется, что если вы сконцентрируетесь только на оценке, то ваш результат окажется более значительным. Вы сами пишете, что для вас было важно «составление структуры» и «оценка». Если этот этап сделан грамотно, то вероятность, что дальше все будет хорошо, сразу сильно повышается. Т.е. сама по себе этот этап имеет ценность. Причем, я не знаю какой либо системы или сервиса, который бы помогал это сделать.
У больших компаний есть свои базы знаний, которыми они используют для таких работ (декомпиляция, оценка, риски), но они строго охраняются – все это область коммерческой тайны. Маленьким же компаниям создать полномасштабную базу не по силам, у них просто нет достаточного объема работ и примеров для этого. Т.е. потенциальная аудитория есть и она шире, чем просто любители Миндмапов. Заметьте, мы сократили функционал, но добавили аудиторию не пожертвовав ценностью продукта. Таким продуктом могли бы воспользоваться и продукт менеджеры больших студий для быстрой первичной оценки и студии, которые работают с каким-нибудь Битриксов и возможно люди не связанные с программированием – декомпозировать и оценивать можно все, но лучше это разносить по разным площадкам. (Хотя хрен его знает, у вас будут эксперты на кэмпе у них спросите, что они думают).
В итоге для сервиса нужно будет сделать: декомпиляция проекта, коллективная база знаний для типовых проектов/задач, работа в виде онлайн сервиса. Визуализировать, раз вам это нравится, можно в виде Миндмапов. Ну, еще понадобиться какой-нибудь вариант экспорта – в TXT, WORD, JPEG, PDF для начала подойдет.
По прошествию времени вашей сильнейшей стороной станет база знаний. А ее скопировать гораздо труднее, если вообще возможно, чем техническое решение, которое не защищено патентом.
Вариантов монитизации будет больше, чем сейчас, география, если захотите, шире, потенциал развития огромный. Ну, мне так кажется. Если вам или экспертам Яндекса покажется иначе – ну извините. Была бы у меня под руками команда разработки, сам бы занялся таким проектом.
Вы пытаетесь охватить «оценку, планирование, контроль, риски». Мне кажется, что если вы сконцентрируетесь только на оценке, то ваш результат окажется более значительным. Вы сами пишете, что для вас было важно «составление структуры» и «оценка». Если этот этап сделан грамотно, то вероятность, что дальше все будет хорошо, сразу сильно повышается. Т.е. сама по себе этот этап имеет ценность. Причем, я не знаю какой либо системы или сервиса, который бы помогал это сделать.
У больших компаний есть свои базы знаний, которыми они используют для таких работ (декомпиляция, оценка, риски), но они строго охраняются – все это область коммерческой тайны. Маленьким же компаниям создать полномасштабную базу не по силам, у них просто нет достаточного объема работ и примеров для этого. Т.е. потенциальная аудитория есть и она шире, чем просто любители Миндмапов. Заметьте, мы сократили функционал, но добавили аудиторию не пожертвовав ценностью продукта. Таким продуктом могли бы воспользоваться и продукт менеджеры больших студий для быстрой первичной оценки и студии, которые работают с каким-нибудь Битриксов и возможно люди не связанные с программированием – декомпозировать и оценивать можно все, но лучше это разносить по разным площадкам. (Хотя хрен его знает, у вас будут эксперты на кэмпе у них спросите, что они думают).
В итоге для сервиса нужно будет сделать: декомпиляция проекта, коллективная база знаний для типовых проектов/задач, работа в виде онлайн сервиса. Визуализировать, раз вам это нравится, можно в виде Миндмапов. Ну, еще понадобиться какой-нибудь вариант экспорта – в TXT, WORD, JPEG, PDF для начала подойдет.
По прошествию времени вашей сильнейшей стороной станет база знаний. А ее скопировать гораздо труднее, если вообще возможно, чем техническое решение, которое не защищено патентом.
Вариантов монитизации будет больше, чем сейчас, география, если захотите, шире, потенциал развития огромный. Ну, мне так кажется. Если вам или экспертам Яндекса покажется иначе – ну извините. Была бы у меня под руками команда разработки, сам бы занялся таким проектом.
Проблема решается примерно одинаково что с помощью диаграммы Ганта, что с помощью MindMap. Вы добавляете зависимость между задачей «дизайн кнопки» и задачами, которые зависят от нее. Отслеживать что там, что там будет не очень — в Ганте (говорю Гант, имею в виду MS Project) обычно не ведут задачи такого низкого уровня; в обоих инструментах будет мешать куча стрелочек.
Если говорить конкретно про ваш кейс, возможно, просто нужен некоторый список задач, которые блокируют другие задачи, отсортированный по количеству/суммарной оценке блокированных задач. Это просто немного другой инструмент.
Если говорить конкретно про ваш кейс, возможно, просто нужен некоторый список задач, которые блокируют другие задачи, отсортированный по количеству/суммарной оценке блокированных задач. Это просто немного другой инструмент.
Хм, Вы тоже перешли на шаблоны с ТемФорест? )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание системы управления проектами на Yandex Tolstoy Camp. Часть 2