Внезапно, проблемы коснулись только «честных» брокеров, которые выводят сделки клиентов своим контрагентам. «Кухни» могут себе позволить простить клиентам их долги. А если брокер вывел твою сделку, по которой ты ушел в минус, с него контрагент потребует деньги — и брокер будет вынужден заплатить. Стрясти же деньги с конечных клиентов, ушедших в минус — намного сложнее.
Нет, PMBoK не говорит, кто конкретно должен выполнять тот или иной процесс. Но по косвенным признакам (очень подробное описание, не BABoK, конечно, но все же) можно судить, что авторы хотели сказать, что менеджер проектов как минимум не должен говорить «а, в команде нет и не предвидится аналитика, ну значит и на требования можно забить».
Не могли бы вы пояснить, в чем разница? Интуитивно я, наверное, понимаю, но с трудом могу себе представить, как можно собрать требования, не описав их. На выходе процесса Collect Requirements из PMBoK, кстати, стоят Requirements Documentation и Requirements Traceability Matrix.
Я довольно часто сталкивался с тем, что на небольших проектах, особенно, когда не нужно писать многотомные ТЗ, а достаточно краткого описания требований, этим описанием занимается PM. И не стал бы так категорично говорить, что написание требований — задача исключительно аналитика.
Если заглянуть, например, в PMBoK, в нем есть целый раздел, посвященный scope management. И в нем очень подробно описано, как собирать требования. Авторы явно намекают, что зачастую сбор и описание требований — работа PM. Так что я не был бы так категоричен.
Проблема решается примерно одинаково что с помощью диаграммы Ганта, что с помощью MindMap. Вы добавляете зависимость между задачей «дизайн кнопки» и задачами, которые зависят от нее. Отслеживать что там, что там будет не очень — в Ганте (говорю Гант, имею в виду MS Project) обычно не ведут задачи такого низкого уровня; в обоих инструментах будет мешать куча стрелочек.
Если говорить конкретно про ваш кейс, возможно, просто нужен некоторый список задач, которые блокируют другие задачи, отсортированный по количеству/суммарной оценке блокированных задач. Это просто немного другой инструмент.
Насчет новизны вы, пожалуй, правы. Другое дело, что в целом сложно назвать какие-то радикально новые вещи в управлении проектами. «Мифический человеко-месяц» был написан в 1975, с тех пор мало что изменилось — те же проблемы, примерно те же способы их решения. Scrum'у, который в последние несколько лет набирает популярность, порядка 25 лет.
Мы точно знаем, что есть люди, которые тоже используют майндмепы для ведения проектов и согласны с нами в том, что это удобно. Но таких людей пока мало, поэтому мы и делимся опытом в надежде, что больше оценит удобство и простоту такого подхода.
Mindjet мы используем, собственно, все скриншоты в статье — из него. Проблема в том, что он никак не интегрируется с таск-трекерами вроде Redmine или JIRA, а перевозить всех разработчиков в Mindjet Project Director мы не готовы.
Да, спасибо, я хотел написать примерно то же самое.
Декомпозиция в нашем случае завязана на отдельные функции приложения, интересные заказчику. Как описывалось в статье, задачи первого (и иногда второго) уровня — это те строчки, которые клиент видит в смете. Если декомпозиция сделана плохо даже на этом уровне, проект обещает быть веселым =)
В принципе, многие mind map инструменты позволяют задавать произвольные связи между элементами, не только связь «родитель-потомок». Структура, которую привел в пример S_A, больше ориентирована на задачи; возможно, для нее как раз больше подошла бы диаграмма Ганта — если важно планировать задачи по времени и знать критический путь.
Мы отталкиваемся больше от разбиения всего scope на функциональные компоненты, которые интересны и понятны как заказчику, так и участникам проекта.
Не стоит забывать, что и тот, и другой вариант — просто вопрос группировки одних и тех же сущностей (задач). Над набором задач можно построить сколько угодно таких группировок — кому-то удобнее смотреть в разрезе задач и групп задач, кому-то — в разрезе функций приложения.
Майндмапы — это только начало. Нам видится, что довольно много менеджеров используют их для визуализации статуса проекта, а плагинов для популярных трекеров, которые позволяют использовать майндмапы, нет. В целом же круг проблем, которые мы собираемся решить, немного шире.
Не могли бы вы привести пример разбивки проекта по делам?
Спасибо за комментарий. Мы пока только экспериментируем с ценником, скорее всего, в первой версии продукта будет бесплатная версия.
Насчет Asana — я думаю, что альтруизм здесь ни при чем. Есть мнение, что при большом количестве активных клиентов (а у Асаны, по слухам, их больше 100 тысяч) можно ввести практически любую бизнес-модель — и она будет приносить прибыль. Оказание бесплатных услуг можно расценивать как инвестиции в рост клиентской базы. Но для такого подхода нужные серьезные инвестиции, которые были у Асаны (в компанию суммарно вложили более 35 миллионов долларов), и которых не будет у нас. Поэтому мы вынуждены выбирать другой подход и сразу оказывать платные услуги.
Я довольно часто сталкивался с тем, что на небольших проектах, особенно, когда не нужно писать многотомные ТЗ, а достаточно краткого описания требований, этим описанием занимается PM. И не стал бы так категорично говорить, что написание требований — задача исключительно аналитика.
Если говорить конкретно про ваш кейс, возможно, просто нужен некоторый список задач, которые блокируют другие задачи, отсортированный по количеству/суммарной оценке блокированных задач. Это просто немного другой инструмент.
Мы точно знаем, что есть люди, которые тоже используют майндмепы для ведения проектов и согласны с нами в том, что это удобно. Но таких людей пока мало, поэтому мы и делимся опытом в надежде, что больше оценит удобство и простоту такого подхода.
Mindjet мы используем, собственно, все скриншоты в статье — из него. Проблема в том, что он никак не интегрируется с таск-трекерами вроде Redmine или JIRA, а перевозить всех разработчиков в Mindjet Project Director мы не готовы.
Декомпозиция в нашем случае завязана на отдельные функции приложения, интересные заказчику. Как описывалось в статье, задачи первого (и иногда второго) уровня — это те строчки, которые клиент видит в смете. Если декомпозиция сделана плохо даже на этом уровне, проект обещает быть веселым =)
Мы отталкиваемся больше от разбиения всего scope на функциональные компоненты, которые интересны и понятны как заказчику, так и участникам проекта.
Не стоит забывать, что и тот, и другой вариант — просто вопрос группировки одних и тех же сущностей (задач). Над набором задач можно построить сколько угодно таких группировок — кому-то удобнее смотреть в разрезе задач и групп задач, кому-то — в разрезе функций приложения.
Не могли бы вы привести пример разбивки проекта по делам?
Насчет Asana — я думаю, что альтруизм здесь ни при чем. Есть мнение, что при большом количестве активных клиентов (а у Асаны, по слухам, их больше 100 тысяч) можно ввести практически любую бизнес-модель — и она будет приносить прибыль. Оказание бесплатных услуг можно расценивать как инвестиции в рост клиентской базы. Но для такого подхода нужные серьезные инвестиции, которые были у Асаны (в компанию суммарно вложили более 35 миллионов долларов), и которых не будет у нас. Поэтому мы вынуждены выбирать другой подход и сразу оказывать платные услуги.