Комментарии 38
Добавлю, что многое зависит от того, кому этот флажок предназначен. Одни руководители видят проблему, когда кто-то из подчиненных ещё только собирается поднять флажок и помогают разобраться, другие — демонстративно отворачиваются, даже видя целую процессию с флагами с транспарантами.
Добавлю — от таких статей будет толк, если авторы приведут конкретный живой пример, по возможности — наиболее характерный и демонстративно-показательный.
Creadone — смените имена организаций и менеджеров, но расскажите, пожалуйста, живой пример из вашей практики того, о чем вы пишете. А лучше два — отрицательный и положительный.
Creadone — смените имена организаций и менеджеров, но расскажите, пожалуйста, живой пример из вашей практики того, о чем вы пишете. А лучше два — отрицательный и положительный.
Примеров много, но приводить их не стоит по ряду причин:
1. Не все компании готовы к публичному обсуждению своих процессов ведения проектов.
2. Приведенный пример — это выжимка из ряда случаев. Я постарался синтезировать наиболее объективный пример, чтобы не уводить читателя в обсуждение качеств конкретного человека, проекта или компании.
3. В реальных случаях проблема может быть в другом. Например, во взаимоотношении заказчика и исполнителя.
Я вас услышал, спасибо. В следующий раз попробую взять реальную историю и обезличить.
1. Не все компании готовы к публичному обсуждению своих процессов ведения проектов.
2. Приведенный пример — это выжимка из ряда случаев. Я постарался синтезировать наиболее объективный пример, чтобы не уводить читателя в обсуждение качеств конкретного человека, проекта или компании.
3. В реальных случаях проблема может быть в другом. Например, во взаимоотношении заказчика и исполнителя.
Я вас услышал, спасибо. В следующий раз попробую взять реальную историю и обезличить.
Со статьей не согласен. Не отношу себя к числу неопытных сотрудников, но последний месяц нахожусь в постоянном кризисе по срокам. Статья не учитывает внешние факторы в ресурсах. Для желающих примеров:
1. Заказчик просит на последнем этапе консолидировать данные полученные в ходе работы скрипта, с его БД. Учитывая жесточайшее описание формата выходных данных, я подразумеваю, что данные для консолидации будут иметь тот же формат. — не верно. Тратим еще 6 часов на чистку и приведение к общему знаменателю.
2. Заказчик ответственен за доступ к данным, в итоге доступ дается на 3 дня позднее указанного срока. При этом пересчета сроков проекта не происходит.
3. Проект входит в стадию отладки, на этапе отладки вносятся коррективы от заказчика, которые уже начал тестовую эксплуатацию проекта и теперь начинается доточка. При этом доточка, которая по сути является доработкой функционала проекта (не относится к основному циклу разработки) входит во время проекта. (тут безусловно ошибка моего менеджера не прописавшего верно контракт, но легче от этого не становится).
1. Заказчик просит на последнем этапе консолидировать данные полученные в ходе работы скрипта, с его БД. Учитывая жесточайшее описание формата выходных данных, я подразумеваю, что данные для консолидации будут иметь тот же формат. — не верно. Тратим еще 6 часов на чистку и приведение к общему знаменателю.
2. Заказчик ответственен за доступ к данным, в итоге доступ дается на 3 дня позднее указанного срока. При этом пересчета сроков проекта не происходит.
3. Проект входит в стадию отладки, на этапе отладки вносятся коррективы от заказчика, которые уже начал тестовую эксплуатацию проекта и теперь начинается доточка. При этом доточка, которая по сути является доработкой функционала проекта (не относится к основному циклу разработки) входит во время проекта. (тут безусловно ошибка моего менеджера не прописавшего верно контракт, но легче от этого не становится).
«Не отношу себя к числу неопытных сотрудников, но последний месяц нахожусь в постоянном кризисе по срокам.»
А вы лучше относите себя к неопытным — поверьте, так намного проще смотреть на вещи :) Не нужно считать себя мега-искушенным во всех и вся, пока лет за двадцать не проведете несколько десятков проектов разного масштаба.
> «1. Заказчик просит на последнем этапе консолидировать данные полученные в ходе работы скрипта, с его БД. Учитывая жесточайшее описание формата выходных данных, я подразумеваю, что данные для консолидации будут иметь тот же формат. — не верно. Тратим еще 6 часов на чистку и приведение к общему знаменателю. „
Сразу несколько моментов — вы точно не представляли, каким будет формат. Кроме прочего — изначально не было учтено таких ситуаций — скорее всего промашка в работе с заказчиком Вот и “неопытность». Но главное — не думать, что такая «неопытность» — плохо. Это обычная рабочая ситуация, и знать все заранее (особенно всех «тараканов» заказчиков) невозможно.
> «2. Заказчик ответственен за доступ к данным, в итоге доступ дается на 3 дня позднее указанного срока. При этом пересчета сроков проекта не происходит. „
Почему не подумали об этом заранее, и, зная срок завершения проекта, не вытрясли данные из заказчика? Стратегическая промашка. Снова “неопытность». Не нужно говорить, что «это все заказчик» — вот так точно делают новички, опытные ребята умеют брать на себя ответственность.
> «3. Проект входит в стадию отладки, на этапе отладки вносятся коррективы от заказчика, которые уже начал тестовую эксплуатацию проекта и теперь начинается доточка. При этом доточка, которая по сути является доработкой функционала проекта (не относится к основному циклу разработки) входит во время проекта. (тут безусловно ошибка моего менеджера не прописавшего верно контракт, но легче от этого не становится).»
Не до конца оговорен/утвержден/внедрен регламент работы с заказчиком. Именно, что — безусловно ошибка какого-то менеджера, но нельзя подставлять под удар себя. Но опять же — все это абсолютно реальная рабочая ситуация.
В общем, вывод один — не стоит преувеличивать свою Всемогущесть. Мега-опытные менеджеры, конечно же, есть, но, как мне кажется, для этого должен пройти не один десяток лет. Молодые же, мега-амбициозные менеджеры, у которых все идет по маслу и получается с первого раза, бывают только в кино.
А вы лучше относите себя к неопытным — поверьте, так намного проще смотреть на вещи :) Не нужно считать себя мега-искушенным во всех и вся, пока лет за двадцать не проведете несколько десятков проектов разного масштаба.
> «1. Заказчик просит на последнем этапе консолидировать данные полученные в ходе работы скрипта, с его БД. Учитывая жесточайшее описание формата выходных данных, я подразумеваю, что данные для консолидации будут иметь тот же формат. — не верно. Тратим еще 6 часов на чистку и приведение к общему знаменателю. „
Сразу несколько моментов — вы точно не представляли, каким будет формат. Кроме прочего — изначально не было учтено таких ситуаций — скорее всего промашка в работе с заказчиком Вот и “неопытность». Но главное — не думать, что такая «неопытность» — плохо. Это обычная рабочая ситуация, и знать все заранее (особенно всех «тараканов» заказчиков) невозможно.
> «2. Заказчик ответственен за доступ к данным, в итоге доступ дается на 3 дня позднее указанного срока. При этом пересчета сроков проекта не происходит. „
Почему не подумали об этом заранее, и, зная срок завершения проекта, не вытрясли данные из заказчика? Стратегическая промашка. Снова “неопытность». Не нужно говорить, что «это все заказчик» — вот так точно делают новички, опытные ребята умеют брать на себя ответственность.
> «3. Проект входит в стадию отладки, на этапе отладки вносятся коррективы от заказчика, которые уже начал тестовую эксплуатацию проекта и теперь начинается доточка. При этом доточка, которая по сути является доработкой функционала проекта (не относится к основному циклу разработки) входит во время проекта. (тут безусловно ошибка моего менеджера не прописавшего верно контракт, но легче от этого не становится).»
Не до конца оговорен/утвержден/внедрен регламент работы с заказчиком. Именно, что — безусловно ошибка какого-то менеджера, но нельзя подставлять под удар себя. Но опять же — все это абсолютно реальная рабочая ситуация.
В общем, вывод один — не стоит преувеличивать свою Всемогущесть. Мега-опытные менеджеры, конечно же, есть, но, как мне кажется, для этого должен пройти не один десяток лет. Молодые же, мега-амбициозные менеджеры, у которых все идет по маслу и получается с первого раза, бывают только в кино.
Я не говорил, что я крут-крут-крут. Я говорю о том, что если закладывать все риски в срок проекта, то на выходе получится огромный срок, поэтому считается все-таки по среднему. Теперь по пунктам:
1. В начале специально уточнялся вопрос о соответствии формата во всех трех источниках. Более того, с точки зрения заказчика он реально соответствовал, все поля содержали требуемые данные, но… Я думаю нет смысла объяснять на сколько неудобно на этапе консолидации иметь в источниках город Москва, Москва и г. Москва. На взгляд обывателя (коим заказчик и является) все ок. С точки зрения программиста — время на приведение всего к единому виду. Я затрудняюсь определить как подобные вещи можно предусмотреть.
2. Подумали, указали косвенные сроки, вот только снова возвращаемся к восприятию. Заказчик на ифы не смотрит, он видит конечный срок неделя. А на объяснения, что 2 дня с момента получения данных это не 2 дня с момента начала работы в итоге тратится еще час.
3. По этому проекту я лично с заказчиком не контактирую, но по косвенным наблюдениям со стороны заказчика менеджеры будут на порядок опытнее. Почему они в свою очередь не учитывают этот факт, хотя я более чем уверен, что отлично все понимают — загадка.
В общем резюмируя я еще раз повторю суть коллапса:
1. На старте невозможно предусмотреть все риски. Единственным решением является балансировка сроков после каждого меилстоуна.
2. Если пытаться просчитать все временные затраты на старте, то на выходе получится абсолютно космическое число часов.
3. Разработка проекта это диалог между заказчиком и исполнителем, если кто-то уходит в жесткий отказ, то с большой долей вероятности проект погибнет.
4. Еще одна проблема в том, что на разных этапах мы оперируем разной стоимостью изменений. Если послать исполнителя на старте это «дешево», то перебросить проект на кого-то другого на этапе отладки — целое состояние, как по деньгам, так и по времени. Здесь уже приходится искать компромиссы. Причем средства для шантажа друг друга есть и у одной и у другой стороны.
5. Неопытностью можно оправдать любые ошибки, но как правило за каждой конкретной проблемой стоит конкретная ситуация, факты, решения. Поэтому называть это одним понятием «нехватка опыта у менеджера» я бы не стал.
ЗЫ На счет кино +100500
1. В начале специально уточнялся вопрос о соответствии формата во всех трех источниках. Более того, с точки зрения заказчика он реально соответствовал, все поля содержали требуемые данные, но… Я думаю нет смысла объяснять на сколько неудобно на этапе консолидации иметь в источниках город Москва, Москва и г. Москва. На взгляд обывателя (коим заказчик и является) все ок. С точки зрения программиста — время на приведение всего к единому виду. Я затрудняюсь определить как подобные вещи можно предусмотреть.
2. Подумали, указали косвенные сроки, вот только снова возвращаемся к восприятию. Заказчик на ифы не смотрит, он видит конечный срок неделя. А на объяснения, что 2 дня с момента получения данных это не 2 дня с момента начала работы в итоге тратится еще час.
3. По этому проекту я лично с заказчиком не контактирую, но по косвенным наблюдениям со стороны заказчика менеджеры будут на порядок опытнее. Почему они в свою очередь не учитывают этот факт, хотя я более чем уверен, что отлично все понимают — загадка.
В общем резюмируя я еще раз повторю суть коллапса:
1. На старте невозможно предусмотреть все риски. Единственным решением является балансировка сроков после каждого меилстоуна.
2. Если пытаться просчитать все временные затраты на старте, то на выходе получится абсолютно космическое число часов.
3. Разработка проекта это диалог между заказчиком и исполнителем, если кто-то уходит в жесткий отказ, то с большой долей вероятности проект погибнет.
4. Еще одна проблема в том, что на разных этапах мы оперируем разной стоимостью изменений. Если послать исполнителя на старте это «дешево», то перебросить проект на кого-то другого на этапе отладки — целое состояние, как по деньгам, так и по времени. Здесь уже приходится искать компромиссы. Причем средства для шантажа друг друга есть и у одной и у другой стороны.
5. Неопытностью можно оправдать любые ошибки, но как правило за каждой конкретной проблемой стоит конкретная ситуация, факты, решения. Поэтому называть это одним понятием «нехватка опыта у менеджера» я бы не стал.
ЗЫ На счет кино +100500
Да я с вами полностью согласен. Мой ответ просто длинный получился, будто я придираюсь к чему-то :) Вовсе нет, и вот что верно — «называть это одним понятием «нехватка опыта у менеджера» я бы не стал», но и «не-неопытностью» тоже не стал бы. В конце концов, где граница опытный/неопытный нам неизвестно, ибо даже самые крутые профи ошибаются. И компромиссы приходится искать во всем — тут вы на миллион процентов правы.
Я, вообще, на самом деле, за то, чтобы менеджерам-специалистам в своем деле начали чуток больше доверять, позволяя быть более гибкими и «адаптивными», а не требуя спланировать все-все-все детали проекта до начала и подбить под всем этим фикс-прайс (по крайней мере, касательно ИТ-проектов).
Я, вообще, на самом деле, за то, чтобы менеджерам-специалистам в своем деле начали чуток больше доверять, позволяя быть более гибкими и «адаптивными», а не требуя спланировать все-все-все детали проекта до начала и подбить под всем этим фикс-прайс (по крайней мере, касательно ИТ-проектов).
С чем именно не согласны? Насколько я понял, речь в статье о том, что не нужно молчать о проблемах. Внезапки, вроде смены форматов или трудности с доступом к данным случаются. Вопрос в том, что дальше. Очень часто проблему можно решить оперативным вмешательством более опытных сотрудников. Главное, как можно раньше о ней узнать.
>Внезапки, вроде смены форматов или трудности с доступом к данным случаются. Вопрос в том, что дальше.
Это по большому счету вообще не проблема, это изменение объема работ, просто обе стороны должны отчетливо это понимать и адекватно находить решения сложившейся ситуации. Если допустим заказчик понимает, что неверно сформулировал задачу на этапе постановки, то он должен быть готов к изменению сроков. Если программист видит ошибку в логике заказчика, то он должен сообщить об этом заказчику, иначе в дальнейшем в результате молчания может нажить себе кучу проблем.
О статье смотри пункт 5 выше.
Это по большому счету вообще не проблема, это изменение объема работ, просто обе стороны должны отчетливо это понимать и адекватно находить решения сложившейся ситуации. Если допустим заказчик понимает, что неверно сформулировал задачу на этапе постановки, то он должен быть готов к изменению сроков. Если программист видит ошибку в логике заказчика, то он должен сообщить об этом заказчику, иначе в дальнейшем в результате молчания может нажить себе кучу проблем.
О статье смотри пункт 5 выше.
Ребята ниже правильно ответили: нужно фиксировать границы проекта, а новые требования выносить в отдельный этап или (если они критичны для запуска проекта) увеличивать время и ресурсы. Нельзя в литровую банку налить два литра воды, это законы физики.
Посоветовать конкретную книжку не могу, но рекомендую поискать литературу по фразе «управление изменениями в проекте».
Посоветовать конкретную книжку не могу, но рекомендую поискать литературу по фразе «управление изменениями в проекте».
Очень просто возлагать «опытному» руководителю все проблемы на неопытность его подчиненных. А как назвать картину, в которой на задачу, требующую от 5 до 50 человеко-дней работы, руководитель просит назвать срок работ ещё до начала её выполнения? Назовёшь 50 — пошлют,- слишком долго, назовёшь 5 — сам пролетишь. Вот часто от такого прессинга сотрудники и ломаются, называют срок типа 20 дней, а потом находятся в постоянном стрессе, потому что задача по факту занимает 30. И каждый из этих 10 дней «неопытного» менеджера пилит «опытный» руководитель — когда, мол, когда? Скажете, неопытность состоит в том, что такая большая результирующая разница в оценке сроков? А что, ни у кого не было задач, которые никто до этого не делал? Так что флажок поднимать очень часто мешают собственные амбиции и самолюбие «правильных» руководителей.
«Так что флажок поднимать очень часто мешают собственные амбиции и самолюбие «правильных» руководителей.»
Подпишусь-ка под каждым словом :)
Подпишусь-ка под каждым словом :)
а тут важно правильно оценивать сроки. Agile подход как раз подсказывает, что задачу нужно разбить на подзадачи таким образом, чтобы каждую мелкую подзадачу можно было бы оценить с высокой степенью достоверности. Иначе говоря, разбить задачу до такого уровня, когда разработчик скажет, вот тут я точно в 2 дня уложусь, потому что я знаю, как это сделать и делал это раньше, плюс можно добавить 1 день, если он все же ошибся :) Опять же в scrum методике есть оценка сроков выполнения задачи коллективно, когда группа разработчиков решает, сколько нужно будет потратить времени.
По существу топика. Есть руководители, которые неправильно оценивают свою роль в управлении проектами и просто давят на менеджеров. Давление может быть в устной форме, в форме удержания доли зп, в форме — я тебя уволю, если не уложишься в срок и т.д. Тогда конечно, при таком руководителе будет текучка кадров, а менеджеры будут просто боятся что либо сказать. Тут скорее уже психологические проблемы, хотя они так же относятся к управлению :)
По существу топика. Есть руководители, которые неправильно оценивают свою роль в управлении проектами и просто давят на менеджеров. Давление может быть в устной форме, в форме удержания доли зп, в форме — я тебя уволю, если не уложишься в срок и т.д. Тогда конечно, при таком руководителе будет текучка кадров, а менеджеры будут просто боятся что либо сказать. Тут скорее уже психологические проблемы, хотя они так же относятся к управлению :)
«А как назвать картину, в которой на задачу, требующую от 5 до 50 человеко-дней работы, руководитель просит назвать срок работ ещё до начала её выполнения?»
Уверен, что львиную часть подобных задач возможно структурировать и разбить на менее масштабные, которые будет проще оценить более точно.
Как говорил один мой знакомый разработчик в ответ о требовании он-лайн обновлений данных:
«Он-лайн? А 24 раз в сутки будет достаточно? Вот! А инженерная задача совсем другая!»
Уверен, что львиную часть подобных задач возможно структурировать и разбить на менее масштабные, которые будет проще оценить более точно.
Как говорил один мой знакомый разработчик в ответ о требовании он-лайн обновлений данных:
«Он-лайн? А 24 раз в сутки будет достаточно? Вот! А инженерная задача совсем другая!»
2. Нужно при любом затруднении обращаться к более опытным коллегам – это не стыдно, стыдно не обращаться и все завалить;
— совет, как перестать профессионально развиваться
— совет, как перестать профессионально развиваться
НЛО прилетело и опубликовало эту надпись здесь
Отлично. А то по тексту из статьи складывается ощущение, что при срыве сроков проекта, неоптный сотрудник должен обратиться к опытному, тот даст ему волшебный пендаль, который каким то образом заставит проект выполниться в первоначально запланированные сроки.
И сколько вы лично завалили проектов, пока это поняли?
Опытный сотрудник явно переиграл в стратегии… Задачи реальной программистской жизни так легко «единицах ресурсов» не оценишь.
- Этап № 1: требуется пять единиц ресурсов и три единицы времени;
- Этап № 2: требуется две единицы ресурсов и шесть единиц времени;
- Этап № 3: требуется одна единица ресурсов и две единицы времени;
- Этап № 4: требуется семь единиц ресурсов и семь единиц времени;
Если задача поставлена четко и проблемы с нехваткой информации нет, то ее можно оценить достаточно корректно. Кроме того, оценку по достижению первой контрольной точки можно скорректировать.
Кстати, если существует проблема с оценкой — это тоже флажок :)
Кстати, если существует проблема с оценкой — это тоже флажок :)
Хорошо, а что такое в вашем понимании «ресурс»?
Грубо говоря, это, например, количество человек, свободных кабинетов, компьютеров, бумажных листов, телефонных номеров, пропускная способность каналов — все то, что расходуется на проекте и оценивается в количественных характеристиках.
Интересно, часто вы оцениваете число бумажных листов, необходимое для выполнения задачи? У меня в офисе всегда стоит ящик бумаги. Когда подходит к концу, заказывают новый. С кабинетами вообще неясно, людей всегда можно уплотнить, а, когда возможности у фирмы появятся, арендовать новый офис. Вы правда-правда кабинеты считаете? Пропускная способность каналов нужна для каких-то узких задач в процессе девелопмента и, как правило, она нужна «чем больше, тем лучше». Тоже натянуто.
А считать штуки человек можно разве что, если у вас есть бригада из 10 грузчиков и пять вагонов с углём и семь вагонов с зерном. Программисты все очень разные, кто-то в одном компоненте хорошо разбирается, кто-то — в другом. Нельзя складывать Дейва, который шарит в UI, но не шарит в DB, с Джоном, который на ура пишет алгоритмы на графах, но шарахается от джаваскрипта, и Сьюзи, которая вообще ни в чём не разбирается, но когда она сидит в комнате, у остальных загадочным образом повышается работоспособность. Потому я и говорю, что писать «пять единиц ресурсов» тупо. Опытный менеджер скажет на самом деле «Макс крут, он бы один сделал это за три дня, но у него сейчас в другом проекте затык, потому посадим в пару Джорджа и Рика, они вдвоём дня за четыре наколбасят. Если будет тяжко, добавим им Саймона, который тоже любит GUI программить; всё равно он сейчас на второстепенном проекте». Нужно знать свою команду и мыслить конкретными людьми, а не «ресурсами».
А считать штуки человек можно разве что, если у вас есть бригада из 10 грузчиков и пять вагонов с углём и семь вагонов с зерном. Программисты все очень разные, кто-то в одном компоненте хорошо разбирается, кто-то — в другом. Нельзя складывать Дейва, который шарит в UI, но не шарит в DB, с Джоном, который на ура пишет алгоритмы на графах, но шарахается от джаваскрипта, и Сьюзи, которая вообще ни в чём не разбирается, но когда она сидит в комнате, у остальных загадочным образом повышается работоспособность. Потому я и говорю, что писать «пять единиц ресурсов» тупо. Опытный менеджер скажет на самом деле «Макс крут, он бы один сделал это за три дня, но у него сейчас в другом проекте затык, потому посадим в пару Джорджа и Рика, они вдвоём дня за четыре наколбасят. Если будет тяжко, добавим им Саймона, который тоже любит GUI программить; всё равно он сейчас на второстепенном проекте». Нужно знать свою команду и мыслить конкретными людьми, а не «ресурсами».
Ок. Да, такая практика реально используется и даже больше — она работает. Естественно, бумагу мы не считаем, этим занимается отдел материального обеспечения.
> Вы правда-правда кабинеты считаете?
На текущем реальном проекте мне нужно провести совещание со всеми экспертами от бизнес-подразделений и принять решение по ряду продуктов. Экспертов больше 40-ти человек.
На одно совещание в среднем уходит 3 часа. В день можно проводить не более двух совещаний, потому что на подготовку уходит до 30 минут и банально это очень тяжело — люди всегда остаются людьми и принятие решение иногда растягивается на два-три совещания.
У меня в наличии 3 переговорные комнаты. Две вмещают по десять-пятнадцать человек, а одна — пять. Переговорные нужно бронировать за неделю, потому что если не забронировать, их займут другие люди. Также нужно учесть, что у всех экспертов свой график и открытые окна могут не совпадать.
Вам дальше расписывать или уже понятно, что ваш пример будет работать только с очень ограниченными рамками?
Вы правда думаете, что я в силах не только запомнить их имена, а еще и понять что они любят и чем хотят заниматься?
> Вы правда-правда кабинеты считаете?
На текущем реальном проекте мне нужно провести совещание со всеми экспертами от бизнес-подразделений и принять решение по ряду продуктов. Экспертов больше 40-ти человек.
На одно совещание в среднем уходит 3 часа. В день можно проводить не более двух совещаний, потому что на подготовку уходит до 30 минут и банально это очень тяжело — люди всегда остаются людьми и принятие решение иногда растягивается на два-три совещания.
У меня в наличии 3 переговорные комнаты. Две вмещают по десять-пятнадцать человек, а одна — пять. Переговорные нужно бронировать за неделю, потому что если не забронировать, их займут другие люди. Также нужно учесть, что у всех экспертов свой график и открытые окна могут не совпадать.
Вам дальше расписывать или уже понятно, что ваш пример будет работать только с очень ограниченными рамками?
Вы правда думаете, что я в силах не только запомнить их имена, а еще и понять что они любят и чем хотят заниматься?
> Естественно, бумагу мы не считаем, этим занимается отдел материального обеспечения.
Тогда зачем вы её упомянули? Мы же про менеджмент проектов.
> Вы правда думаете, что я в силах не только запомнить их имена, а еще и понять что они любят и чем хотят заниматься?
Все эти эксперты — ваши прямые подчинённые?
Ну окей, окей, вам виднее. Я просто грешным делом подумал, что мы тут про программирование говорим :-)
Тогда зачем вы её упомянули? Мы же про менеджмент проектов.
> Вы правда думаете, что я в силах не только запомнить их имена, а еще и понять что они любят и чем хотят заниматься?
Все эти эксперты — ваши прямые подчинённые?
Ну окей, окей, вам виднее. Я просто грешным делом подумал, что мы тут про программирование говорим :-)
Доброе утро, господа.
Не могу назвать себя опытным менеджером, я как раз отношусь к начинающим.
Во-первых хочу поблагодарить за статью. Уверен, мне будет полезно применить данную информацию на практике.
Во-вторых, по делу. Я работаю в достаточно крупной организации, у которой, как это обычно и бывает, уже давным давно есть инструменты стандартизации и систематизации. Собственно, о них я и хотел рассказать в рамках этого комментария.
1. ОМП — отчет менеджера проекта. Это документ, отражающий периодический результат деятельности проектной команды, согласованный как исполнителем, так и заказчиком. Предоставляется для обзора как руководителям обеих сторон. Документ простой, но очень важный. Обычно, в нем просто перечисляются открытые вопросы и принятые решения, а так же влияние результатов периода на реальные сроки выполнения задач. Скажу честно, многие, даже опытные менеджеры проектов игнорируют этот инструмент контроля, а зря. Именно благодаря нему, можно:
а. Вовремя обозначить негативное/позитивное влияние внешних факторов на ход проекта в целом;
б. В корне пресечь все споры/недопонимания исполнителя и заказчика.
2. Координационный комитет. Это фактически «планерка» из статьи, за исключением нескольких факторов. При идеальном стечении обстоятельств и объективно возникших изменениях в ходе проекта подобный комитет является результатом того самого «поднятого флажка» и позволяет перенести ответственное решение с плеч менеджера проекта на уровень вышестоящих руководителей (владельцев бизнеса).
Безусловно, в ходе работы возникают проблемы, однако каждую проблему можно классифицировать и согласовать её решение как с заказчиком, так и с руководителем. Возможно, действительно не стоит с каждой проблемой идти к руководителю, однако при недостаточном опыте, я всегда ставлю руководство в известность о том или ином решении, в котором ощущаю не 100% компетентность.
Не могу назвать себя опытным менеджером, я как раз отношусь к начинающим.
Во-первых хочу поблагодарить за статью. Уверен, мне будет полезно применить данную информацию на практике.
Во-вторых, по делу. Я работаю в достаточно крупной организации, у которой, как это обычно и бывает, уже давным давно есть инструменты стандартизации и систематизации. Собственно, о них я и хотел рассказать в рамках этого комментария.
1. ОМП — отчет менеджера проекта. Это документ, отражающий периодический результат деятельности проектной команды, согласованный как исполнителем, так и заказчиком. Предоставляется для обзора как руководителям обеих сторон. Документ простой, но очень важный. Обычно, в нем просто перечисляются открытые вопросы и принятые решения, а так же влияние результатов периода на реальные сроки выполнения задач. Скажу честно, многие, даже опытные менеджеры проектов игнорируют этот инструмент контроля, а зря. Именно благодаря нему, можно:
а. Вовремя обозначить негативное/позитивное влияние внешних факторов на ход проекта в целом;
б. В корне пресечь все споры/недопонимания исполнителя и заказчика.
2. Координационный комитет. Это фактически «планерка» из статьи, за исключением нескольких факторов. При идеальном стечении обстоятельств и объективно возникших изменениях в ходе проекта подобный комитет является результатом того самого «поднятого флажка» и позволяет перенести ответственное решение с плеч менеджера проекта на уровень вышестоящих руководителей (владельцев бизнеса).
Безусловно, в ходе работы возникают проблемы, однако каждую проблему можно классифицировать и согласовать её решение как с заказчиком, так и с руководителем. Возможно, действительно не стоит с каждой проблемой идти к руководителю, однако при недостаточном опыте, я всегда ставлю руководство в известность о том или ином решении, в котором ощущаю не 100% компетентность.
Просили конкретный живой пример.
Работаю руководителем IT компании.
Подтверждаю, обозначенные проблемы существуют и я встречаю их, в том числе, у коллег-руководителей из других областей. Что интересно, В IT компании процесс понимание того, что руководитель — это не злой дядька, который бьет тебя кнутом, а сам ест пряник, приходит быстрее, чем в других сферах (может, кто-то не согласится, но я такое замечал из опыта).
Руководитель должен знать, что происходит в проекте, до мелочей. Когда сотрудник вовремя сообщает о проблеме, над ее устранением уже начинает думать несколько человек.
Как «договорится с сотрудниками» об этих «флажках»? Прежде всего, хорошо, если руководитель до текущей должности сам «бывал в той же шкуре». Это поможет разъяснить ситуацию на личном примере (а личный пример — один из лучших методов организации, на мой взгляд). Раньше я работал в нескольких компаниях рядовым/старшим сотрудником. Что ж, могу сказать, что почти все вещи, описанные в топике — частенько пробегали у меня в голове, но со мной никто не общался по этому поводу, поэтому, описанные ситуации все повторялись и повторялись.
Тут, помимо описанных причин, пробегает еще одна. Возникает проблема и сотрудник пытается ее решить. Проходит час, два. «Ну, еще немного, щас точно смогу ее победить». Проходит еще день. И т.д. Потом выясняется, что провал по срокам получился из за того, что «я устранял появившуюся проблему». Почему не сказал, что проблема есть? Или что ты потратил на нее уже час и это стало для тебя сигналом к тому, что пора сообщить руководителю. И так далее.
Общение с сотрудниками. Поднятие этого вопроса на планерках, дейли-скрам-митингах и т.п. Замечание возникновения таких «просрочек» на ранних этапах и указание на эту ситуацию по факту сотруднику. Эти вещи помогут в борьбе с этой распространенной проблемой.
Ну а через какое-то время это станет политикой компании и все новые сотрудники будут уже «въезжать» сразу вначале работы на новом месте. Надеюсь, информация была полезна.
P.S> Если у кого-то есть желание пообщаться на эту тему/обменяться опытом — только за. Скайп svscorp — стучитесь.
Работаю руководителем IT компании.
Подтверждаю, обозначенные проблемы существуют и я встречаю их, в том числе, у коллег-руководителей из других областей. Что интересно, В IT компании процесс понимание того, что руководитель — это не злой дядька, который бьет тебя кнутом, а сам ест пряник, приходит быстрее, чем в других сферах (может, кто-то не согласится, но я такое замечал из опыта).
Руководитель должен знать, что происходит в проекте, до мелочей. Когда сотрудник вовремя сообщает о проблеме, над ее устранением уже начинает думать несколько человек.
Как «договорится с сотрудниками» об этих «флажках»? Прежде всего, хорошо, если руководитель до текущей должности сам «бывал в той же шкуре». Это поможет разъяснить ситуацию на личном примере (а личный пример — один из лучших методов организации, на мой взгляд). Раньше я работал в нескольких компаниях рядовым/старшим сотрудником. Что ж, могу сказать, что почти все вещи, описанные в топике — частенько пробегали у меня в голове, но со мной никто не общался по этому поводу, поэтому, описанные ситуации все повторялись и повторялись.
Тут, помимо описанных причин, пробегает еще одна. Возникает проблема и сотрудник пытается ее решить. Проходит час, два. «Ну, еще немного, щас точно смогу ее победить». Проходит еще день. И т.д. Потом выясняется, что провал по срокам получился из за того, что «я устранял появившуюся проблему». Почему не сказал, что проблема есть? Или что ты потратил на нее уже час и это стало для тебя сигналом к тому, что пора сообщить руководителю. И так далее.
Общение с сотрудниками. Поднятие этого вопроса на планерках, дейли-скрам-митингах и т.п. Замечание возникновения таких «просрочек» на ранних этапах и указание на эту ситуацию по факту сотруднику. Эти вещи помогут в борьбе с этой распространенной проблемой.
Ну а через какое-то время это станет политикой компании и все новые сотрудники будут уже «въезжать» сразу вначале работы на новом месте. Надеюсь, информация была полезна.
P.S> Если у кого-то есть желание пообщаться на эту тему/обменяться опытом — только за. Скайп svscorp — стучитесь.
Скорее всего, меня заминусуют, однако все решается довольно просто: введением небольшого количества бюрократии в виде ежедневных отчетов для новых/неопытных сотрудников. В отчете должны содержаться пункты: какие задачи были поставлены, какие выполнены и за сколько времени, какие проблемы возникли, решились ли они и сколько на них ушло времени. Если текучка кадров небольшая, то у менеджера не будет отбирать много времени чтение отчетов.
После того, как менеджер понял, что за человек с ним работает — можно отменять ежедневные отчеты и работать без них.
На составление отчета времени уходит от 5 до 20 минут максимум. На его чтение и анализ — 10 — 30 минут. Профит просто огромен, если менеджер хоть как-то разбирается в людях и проекте, который он ведет.
После того, как менеджер понял, что за человек с ним работает — можно отменять ежедневные отчеты и работать без них.
На составление отчета времени уходит от 5 до 20 минут максимум. На его чтение и анализ — 10 — 30 минут. Профит просто огромен, если менеджер хоть как-то разбирается в людях и проекте, который он ведет.
Нет, почему же? Вы все правильно говорите.
Одно время у нас был допиленный до нормального состояния dotProject, куда по окончанию дня вписывалось затраченное время по задачам. А каждое утро — рассылка с кратким отчетом. Вполне себе рабочий инструмент.
Просто на осознание необходимости использовать инструменты учета времени у руководителей уходит очень много времени. А на внедрение и более того.
Одно время у нас был допиленный до нормального состояния dotProject, куда по окончанию дня вписывалось затраченное время по задачам. А каждое утро — рассылка с кратким отчетом. Вполне себе рабочий инструмент.
Просто на осознание необходимости использовать инструменты учета времени у руководителей уходит очень много времени. А на внедрение и более того.
> Просто на осознание необходимости использовать инструменты учета времени у руководителей уходит очень много времени.
Кстати, есть один нюанс: все эти системы, методологии, и т.д. — все лишнее и все бесполезно пока руководитель смотрит на процесс разработки ПО как на автоматизированный конвеер. Уже чуть ли не на каждом столбе написано, что ПО создают люди, а не машины, и в управлении процессом разработки ПО надо отталкиваться от человеческого фактора. И даже при выборе инструментов, используемых при разработке следует это учитывать.
Кстати, есть один нюанс: все эти системы, методологии, и т.д. — все лишнее и все бесполезно пока руководитель смотрит на процесс разработки ПО как на автоматизированный конвеер. Уже чуть ли не на каждом столбе написано, что ПО создают люди, а не машины, и в управлении процессом разработки ПО надо отталкиваться от человеческого фактора. И даже при выборе инструментов, используемых при разработке следует это учитывать.
Хорошая мысль. Мне нравится такой подход, когда человек признает что несправился. Честно и вовремя.
Вы меня конечно извините, но покажите мне программистов которые укладываются в заранее оговоренные сроки, и менеджеров которые всегда согласны со сроками которые говорят программисты. Где этот Эдем?
А если серьезно, то как уже говорили выше, надо чтобы менеджер знал все значительные вещи в проекте, это его стезя. И его цель всегда договариваться о срываемых и уточняемых сроках с заказчиком и программистом. И если одна из сторон с которой он общается неадекватна, то не повезло менеджеру и надо приводить все к общему знаменателю (или начать пить).
p/s
Кстати, ежедневные отчеты исполнителей (которые можно иногда не читать), и постоянный контакт с воспитанием заказчика это то без чего сложно жить.
А если серьезно, то как уже говорили выше, надо чтобы менеджер знал все значительные вещи в проекте, это его стезя. И его цель всегда договариваться о срываемых и уточняемых сроках с заказчиком и программистом. И если одна из сторон с которой он общается неадекватна, то не повезло менеджеру и надо приводить все к общему знаменателю (или начать пить).
p/s
Кстати, ежедневные отчеты исполнителей (которые можно иногда не читать), и постоянный контакт с воспитанием заказчика это то без чего сложно жить.
Спасибо автору — статья может и не стала открытием, но определенно собрала воедино разрозненные правильные мысли.
От себя хочу добавить, что на мой взгляд, не был рассмотрен еще один важный субъективный фактор. Личные характеристики сотрудника — лень, безинициативность, etc. У нас в компании один из мотвационных драйверов звучит так: «Не могу не делать!».
Если эту характеристику добавить к профпригодности и адекватности специалиста+менеджера+руководителя- успех неизбежен)
От себя хочу добавить, что на мой взгляд, не был рассмотрен еще один важный субъективный фактор. Личные характеристики сотрудника — лень, безинициативность, etc. У нас в компании один из мотвационных драйверов звучит так: «Не могу не делать!».
Если эту характеристику добавить к профпригодности и адекватности специалиста+менеджера+руководителя- успех неизбежен)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Менеджеры проектов гибнут в одиночку и зря: подними флажок!