Comments 23
Вот ещё одна проблема в дополнение описанным в статье.
Часто бывает так, что в плане проекта на некоторые работы невозможно назначить в данный момент определённого сотрудника, но из типа работы понятно, кому её предстоит делать. Например, написание документации предстоит делать одному из сотрудников Отдел технической документации. Но начало этой работы только через 3 месяца и сейчас трудно указать, кто конкретно её будет писать. При этом есть и другие проекты, в которых заняты писатели. Хочется иметь в плане агрегирующий ресурс, который привязан к списку конкретных сотрудников и позволяет проверить есть ли у какого-нибудь сотрудника (не важно, какого именно) из данного списка свободное время в интересующий период времени и произвести выравнивание плана в соответствии с предполагаемой загрузкой.
Мне не попадались системы управления проектами, в которых я мог бы решить эту задачу. По крайней мере, сделать это просто.
Часто бывает так, что в плане проекта на некоторые работы невозможно назначить в данный момент определённого сотрудника, но из типа работы понятно, кому её предстоит делать. Например, написание документации предстоит делать одному из сотрудников Отдел технической документации. Но начало этой работы только через 3 месяца и сейчас трудно указать, кто конкретно её будет писать. При этом есть и другие проекты, в которых заняты писатели. Хочется иметь в плане агрегирующий ресурс, который привязан к списку конкретных сотрудников и позволяет проверить есть ли у какого-нибудь сотрудника (не важно, какого именно) из данного списка свободное время в интересующий период времени и произвести выравнивание плана в соответствии с предполагаемой загрузкой.
Мне не попадались системы управления проектами, в которых я мог бы решить эту задачу. По крайней мере, сделать это просто.
Я буду груб но это (цитата):
Я мечтаю об инструменте, позволяющем управлять набором прецедентов, компонентов, требований, задач и исполнителей в едином информационном пространстве, с наложением на шкалу времени, с учетом занятости сотрудников и зависимостей между задачами
несостоятельное утверждение. Так как нет на самом деле управления. Есть только контроль. Всё что делает менеджер в большинстве случаев это контроллирует деятельность, более ни-че-го. Продумывают внутренности — техспециалисты, реализуют — техспециалисты, тестируют — техспециалисты. Менджер только контроллирует.
Я мечтаю об инструменте, позволяющем управлять набором прецедентов, компонентов, требований, задач и исполнителей в едином информационном пространстве, с наложением на шкалу времени, с учетом занятости сотрудников и зависимостей между задачами
несостоятельное утверждение. Так как нет на самом деле управления. Есть только контроль. Всё что делает менеджер в большинстве случаев это контроллирует деятельность, более ни-че-го. Продумывают внутренности — техспециалисты, реализуют — техспециалисты, тестируют — техспециалисты. Менджер только контроллирует.
Мне очень грустно развеивать Ваши заблуждения, но управление на самом деле бывает. Действительно, специалисты решают конкретные технические задачи, а менеджеры контролируют их деятельность. Но кроме них еще существуют руководители, которые весь этот бардак пытаются вести в некотором направлении. И при отсутствии управления все почему-то очень быстро превращается в иллюстрацию к басне «Лебедь, рак и щука». Случается, конечно, такое чудо, как самоуправляемые команды, но это очень большая редкость.
Если комманда «встанет в позу», то менеджер тутже понимает, что он ничего не управляет (увы и такое тоже бывает). И Вы сами правильно сказали «менеджеры КОНТРОЛЛИРУЮТ их деятельность».
Если команда под управлением менеджера становится в позу, то это означает только одно — надо гнать в шею либо команду, либо менеджера. А контроль — это не цель. Это лишь один из инструментов управления.
Ага. А если автомобиль «встанет в позу» (да хоть кончится бензин), то водитель тут же понимает, что он «ничего не управляет» :)
Соглашусь — у меня те же запросы, уже много лет постоянно изучаю рынок на предмет предлагаемых решений — пока тишина и спокойствие.
В дополнение к вышесказанному могу предложить возможность автоматизировать проведение налога «покера» в scrum: после установки задачи в системе плонирования было бы неплохо, если бы разработчики смогли выставить свои субъективные оценки сроков, не видя оценок других. Это позволило бы руководителю для больших команд лучше выбирать исполнителей и полуавтоматически выделять зоны риска — если для какой-то задачи сильно разнятся оценки сроков или большая часть разработчиков не готовы ее вообще выполнять — значит там явно сконцентрированы риски.
В дополнение к вышесказанному могу предложить возможность автоматизировать проведение налога «покера» в scrum: после установки задачи в системе плонирования было бы неплохо, если бы разработчики смогли выставить свои субъективные оценки сроков, не видя оценок других. Это позволило бы руководителю для больших команд лучше выбирать исполнителей и полуавтоматически выделять зоны риска — если для какой-то задачи сильно разнятся оценки сроков или большая часть разработчиков не готовы ее вообще выполнять — значит там явно сконцентрированы риски.
спасибо за статью. не могли бы вы перечислить системы управления проектами, которые вы использовали в своей работе?
близко имел дело с:
MS Project (+MS Project Server)
Jira
TFS
Basecamp
Trac
Asana
Издалека смотрел на Redmine, Мегаплан, LiquidPlanner.
Много читал про разные другие системы (конкретных названий уже не скажу, все смешалось, уж больно они все похожи).
Не упоминаю разнообразные персональные органайзеры, которые претендуют на управление проектами.
MS Project (+MS Project Server)
Jira
TFS
Basecamp
Trac
Asana
Издалека смотрел на Redmine, Мегаплан, LiquidPlanner.
Много читал про разные другие системы (конкретных названий уже не скажу, все смешалось, уж больно они все похожи).
Не упоминаю разнообразные персональные органайзеры, которые претендуют на управление проектами.
А чем, если не секрет, не подошла JIRA?
JIRA — это issue tracker в своей сущности. Для управления проектов еще меньше подходит чем MS Project.
Я из всего этого не использовал TFS, Trac и Asana. Но и остальные быстро демонстрировали свои узкие места, из-за которых использовать их не удавалось кроме как для узких задач. Применимость в широком круге задач более или менее возможна у MS Project, но не слишком удобна. В какой-то момент приходится подстраивать все процессы под ограничения системы и выдумывать лишние сущности, чтобы скомпенсировать систему управления проектами. Она начинает не помогать, а мешать.
Я из всего этого не использовал TFS, Trac и Asana. Но и остальные быстро демонстрировали свои узкие места, из-за которых использовать их не удавалось кроме как для узких задач. Применимость в широком круге задач более или менее возможна у MS Project, но не слишком удобна. В какой-то момент приходится подстраивать все процессы под ограничения системы и выдумывать лишние сущности, чтобы скомпенсировать систему управления проектами. Она начинает не помогать, а мешать.
в свое время, я тоже рассматривал некоторые системы, т.к. это всегда головная боль digitalmanagers.ru/blog/software/9.html
Между системами управления задачами и системами управления проектами в самом деле есть серьезная разница: наименьшая единица управления у первых — действия (задачи), а у вторых — результаты действий (артефакты).
Из-за этого в системах управления проектами может использоваться 100% rule, а в системах управления задачами новые задачи прибывают неожиданно и в самый неподходящий момент.
Из этого следует такой вывод: из системы управления задачами невозможно сделать годную систему планирования в принципе — там просто нет нужной информации. Я видел разные попытки реализовать планирование на базе анализа истории (сколько в среднем такие задачи занимали раньше, насколько разработчики ошибались в оценках и т.п.), но ИМХО все это пустое. Проблема не в том, что мы неверно оцениваем длительность известных задач, а в том, что мы не можем предсказать количество и темп появления неизвестных задач.
Несколько подробнее об этом писал тут
www.trackstudio.ru/ms-project-issue-tracking.html
maximkr.livejournal.com/11192.html
Из-за этого в системах управления проектами может использоваться 100% rule, а в системах управления задачами новые задачи прибывают неожиданно и в самый неподходящий момент.
Из этого следует такой вывод: из системы управления задачами невозможно сделать годную систему планирования в принципе — там просто нет нужной информации. Я видел разные попытки реализовать планирование на базе анализа истории (сколько в среднем такие задачи занимали раньше, насколько разработчики ошибались в оценках и т.п.), но ИМХО все это пустое. Проблема не в том, что мы неверно оцениваем длительность известных задач, а в том, что мы не можем предсказать количество и темп появления неизвестных задач.
Несколько подробнее об этом писал тут
www.trackstudio.ru/ms-project-issue-tracking.html
maximkr.livejournal.com/11192.html
На самом деле, важно смотреть не только на то как мы оценивали задачи, а смотреть в динамике на изменение планируемого срока окончания работ. Пока у нас нет таких данных мы ни о чем не можем говорить, но у меня есть устойчивое ощущение, что скорость движения планируемого «хвоста» проекта (т.е. даты окончания) — величина достаточно стабильная. В частности, подобные наблюдения были сделаны в процессе анализа множества проектов, управляемых по методике освоенного объема. Было замечено, что коэффициент эффективности вложений (по сути отношение фактического результата к планируемым затратам) сильно не меняется после отметки 20% завершения. Это позволяет использовать эту величину для корректирования планируемого срока. Но беда это методики в том, что она требует очень точного расчета всех затрат, что почти невозможно когда проекты не очень большие и их много. Мне кажется, что оценка скорости движения хвоста проекта приведет к тем же результатам при существенно меньших затратах на получение этой оценки.
MS Project не стоит воспринимать как систему управления проектом, фактически это средство для построения графика проекта и ничего более. Не стоит ждать помощи в определении «какие задачи планируются к выполнению». Впрочем Вы здесь же приводите и решение «после того как мы посмотрели на проект со всех точек зрения и убедились, что ничего не забыли — мы получаем довольно пристойный план».
Многие из приведённых Вами проблем решены в российском Spider Project: удобное сравнение различных вариантов графика, с комментированием, назначение ролей ресурсов (когда непонятно кто из отдела будет выполнять задачу), отличное отслеживание состояния.
Из моего опыта scheduling: самое важное — знать на что способен (и не способен) выбранный инструмент, и применять его в соответствии. Лучше необходимый минимум, чем хаотический максимум.
Вы правы, уповать на программы в управлении людьми не приходится. Должно ведь быть наоборот ;)
Многие из приведённых Вами проблем решены в российском Spider Project: удобное сравнение различных вариантов графика, с комментированием, назначение ролей ресурсов (когда непонятно кто из отдела будет выполнять задачу), отличное отслеживание состояния.
Из моего опыта scheduling: самое важное — знать на что способен (и не способен) выбранный инструмент, и применять его в соответствии. Лучше необходимый минимум, чем хаотический максимум.
Вы правы, уповать на программы в управлении людьми не приходится. Должно ведь быть наоборот ;)
MS Project вполне можно использовать как систему управления проектом. Его сложно рассматривать как систему управления задачами, это верно. Тут уже можно обходиться личным общением или использовать TFS, Jira или любой другой трэкер.
Давно уже мечтаю создать свою систему управления проектами. По тем-же причинам. Много всего перепробовал — все не то.
Вы знаете, а я не хочу создавать систему управления проектами. Есть куча систем, которые с этой задачей справляются. Мне хочется создать инструмент планирования, который позволит создать приемлемый план, а потом скормить задачи из полученного плана в какой-нибудь issue-tracker типа Jira и отслеживать их выполнение. Мне кажется, что это в несколько раз проще, чем делать очередную систему управления проектами, и при этом даст заметный эффект.
На мой взгляд, эта «куча» справляется не очень хорошо. Т. е. вообще никак. Task-manager или issue-tracker — это далеко не все управление, поддающееся автоматизации, да Вы и сами об этом пишите. А планировать можно маркером на доске, в гугл-доксах, в календаре или на салфетках в баре которые можно инстаграммить с определенными хэш-тегами. Инструментов тоже достаточно, при наличии фантазии. Но нет простого и понятного инструмента для объединения всех управленческих задач в одну систему, хотя в этом также нет ничего особенно сложного. Я придумал как сделать такую штуку и мне моя идея кажется достаточно остроумной.
а что мешает скрестить Jira и MSProject посредством плагина?
Насколько помню к Jira был платный плагин для MSP, позволявший практически привязать задачи проекта в задачи Jira с миграцией в обе стороны.
Насколько помню к Jira был платный плагин для MSP, позволявший практически привязать задачи проекта в задачи Jira с миграцией в обе стороны.
Скрестить ничего не мешает, как видите, это даже кто-то уже сделал.
Только толку от этого, к сожалению, немного :-(.
Если Jira вообще не является системой планирования, то MS Project, конечно, пытается это делать, но до того туманным способом… Вспоминается цитата из Р.Хайнлайна — «Демократия плохая система. Её единственное достоинство — она в 8 раз лучше любой другой.» Т.е. большинство достоинств Project кроются в недостатках других систем, он лучше их. Но не становится от этого хорошей системой.
Только толку от этого, к сожалению, немного :-(.
Если Jira вообще не является системой планирования, то MS Project, конечно, пытается это делать, но до того туманным способом… Вспоминается цитата из Р.Хайнлайна — «Демократия плохая система. Её единственное достоинство — она в 8 раз лучше любой другой.» Т.е. большинство достоинств Project кроются в недостатках других систем, он лучше их. Но не становится от этого хорошей системой.
Sign up to leave a comment.
Критика современных систем управления проектами