«А как назвать картину, в которой на задачу, требующую от 5 до 50 человеко-дней работы, руководитель просит назвать срок работ ещё до начала её выполнения?»
Уверен, что львиную часть подобных задач возможно структурировать и разбить на менее масштабные, которые будет проще оценить более точно.
Как говорил один мой знакомый разработчик в ответ о требовании он-лайн обновлений данных:
«Он-лайн? А 24 раз в сутки будет достаточно? Вот! А инженерная задача совсем другая!»
Доброе утро, господа.
Не могу назвать себя опытным менеджером, я как раз отношусь к начинающим.
Во-первых хочу поблагодарить за статью. Уверен, мне будет полезно применить данную информацию на практике.
Во-вторых, по делу. Я работаю в достаточно крупной организации, у которой, как это обычно и бывает, уже давным давно есть инструменты стандартизации и систематизации. Собственно, о них я и хотел рассказать в рамках этого комментария.
1. ОМП — отчет менеджера проекта. Это документ, отражающий периодический результат деятельности проектной команды, согласованный как исполнителем, так и заказчиком. Предоставляется для обзора как руководителям обеих сторон. Документ простой, но очень важный. Обычно, в нем просто перечисляются открытые вопросы и принятые решения, а так же влияние результатов периода на реальные сроки выполнения задач. Скажу честно, многие, даже опытные менеджеры проектов игнорируют этот инструмент контроля, а зря. Именно благодаря нему, можно:
а. Вовремя обозначить негативное/позитивное влияние внешних факторов на ход проекта в целом;
б. В корне пресечь все споры/недопонимания исполнителя и заказчика.
2. Координационный комитет. Это фактически «планерка» из статьи, за исключением нескольких факторов. При идеальном стечении обстоятельств и объективно возникших изменениях в ходе проекта подобный комитет является результатом того самого «поднятого флажка» и позволяет перенести ответственное решение с плеч менеджера проекта на уровень вышестоящих руководителей (владельцев бизнеса).
Безусловно, в ходе работы возникают проблемы, однако каждую проблему можно классифицировать и согласовать её решение как с заказчиком, так и с руководителем. Возможно, действительно не стоит с каждой проблемой идти к руководителю, однако при недостаточном опыте, я всегда ставлю руководство в известность о том или ином решении, в котором ощущаю не 100% компетентность.
контекст этой штуки простой, допустим в вашем модуле есть несколько методов init, load,save etc, и вы хотите дать другим модулям возможность выполнять какие то действия до или после кода метода (onSaving, onSaved etc), вот что бы хранить набор пользовательских функций которые будут вызываться и удобно их добавлять удалять этот код оказался очень удобен
а некоторые регисрировали и по 1200 и по 2500 и сколько там еще платили за приоритетную регистрацию, в общем кто то хорошо нагрелся
считаю что теперь надо ввести новый, теперь например.РО и еще стока же поднять: Р
Уверен, что львиную часть подобных задач возможно структурировать и разбить на менее масштабные, которые будет проще оценить более точно.
Как говорил один мой знакомый разработчик в ответ о требовании он-лайн обновлений данных:
«Он-лайн? А 24 раз в сутки будет достаточно? Вот! А инженерная задача совсем другая!»
Не могу назвать себя опытным менеджером, я как раз отношусь к начинающим.
Во-первых хочу поблагодарить за статью. Уверен, мне будет полезно применить данную информацию на практике.
Во-вторых, по делу. Я работаю в достаточно крупной организации, у которой, как это обычно и бывает, уже давным давно есть инструменты стандартизации и систематизации. Собственно, о них я и хотел рассказать в рамках этого комментария.
1. ОМП — отчет менеджера проекта. Это документ, отражающий периодический результат деятельности проектной команды, согласованный как исполнителем, так и заказчиком. Предоставляется для обзора как руководителям обеих сторон. Документ простой, но очень важный. Обычно, в нем просто перечисляются открытые вопросы и принятые решения, а так же влияние результатов периода на реальные сроки выполнения задач. Скажу честно, многие, даже опытные менеджеры проектов игнорируют этот инструмент контроля, а зря. Именно благодаря нему, можно:
а. Вовремя обозначить негативное/позитивное влияние внешних факторов на ход проекта в целом;
б. В корне пресечь все споры/недопонимания исполнителя и заказчика.
2. Координационный комитет. Это фактически «планерка» из статьи, за исключением нескольких факторов. При идеальном стечении обстоятельств и объективно возникших изменениях в ходе проекта подобный комитет является результатом того самого «поднятого флажка» и позволяет перенести ответственное решение с плеч менеджера проекта на уровень вышестоящих руководителей (владельцев бизнеса).
Безусловно, в ходе работы возникают проблемы, однако каждую проблему можно классифицировать и согласовать её решение как с заказчиком, так и с руководителем. Возможно, действительно не стоит с каждой проблемой идти к руководителю, однако при недостаточном опыте, я всегда ставлю руководство в известность о том или ином решении, в котором ощущаю не 100% компетентность.
причем столько существующих зачетных персанажей есть: Р
считаю что теперь надо ввести новый, теперь например.РО и еще стока же поднять: Р