В вашем посте мне видится подмена задачи. В статью речь идёт о выполнении проекта с точки зрения команды проекта. А работа с заказчиком (в том числе и с ценой заказа) и организация выполнения проекта — это всё же разные вещи. Можно, конечно, показывать заказчику тот план, по которому вы фактически работаете, но так бывает не очень часто. Заказчику обычно нужна не столь подробная разбивка на задачи, другая терминология описания задач и т.д. и т.п. Ну и торговлю за цену заказа никто не отменял.
Впрочем, возможно, что мы обсуждаем разный масштаб заказов. Мне чаще приходилось иметь дело с проектами, объем которых измеряется в человекогодах. Если речь идёт о работах за пару штук баксов, то описанную мною мутотень никто, конечно, разводить не будет. :)
Тема хорошая. Только, как и большинство материалов по этой теме, статья получилась какая-то наукообразная. Нет ощущения, что советы испробованы на практике. Я ни разу не видел, чтобы кто-то управлял рисками в IT-компаниях на регулярной основе. Хотя готов поверить, что где-то это происходит.
Хотелось бы узнать, что у Вас получилось. Если, конечно, после аудита что-то последовало :). Ведёте реестр из 10 (3, 5, 20) наиболее неприятных рисков, мониторите его регулярно (раз в неделю, в день)? Или каким-то другим способом осуществляете управление рисками? Это удалось делать с начала и до конца проекта? Интересно было бы видеть примеры реальных (а не книжных) рисков. Реальных планов их преодоления.
>> А инженеры, которые расхлебывают то, что наобещал заказчику сейл,…
Ну обратное тоже не редкость, когда программист напрограммировал такое, с чем заказчик по разным причинам работать не может. И сейлу приходится это расхлёбывать
Абсолютно согласен. Человек оцениват команду, а не Команду из моего определения. Для абстракных людей я бы так же оценивал. Тут лучше перебдеть, чем недобдеть. :)
И потом, я ж не говорю, что Команды часто встречаются. Может в IT-сфере и существуют такие из 20-ти человек, но мне не попадались. Обычно людей в них немного.
P.S. Спасибо за цитату. Я эту книжку когда-то на английском читал, русский вариант не видел.
Что-то не припомню, чтобы ДеМарко или Брукс спорили с тем, что команда эффективнее группы одиночек. Они, насколько я помню, говорили, что в команде есть потери на коммуникацию. И чем больше команда, тем больше эти потери. Но синергический эффект покрывает эти потери в команде.
Не, я айтишник. :) Просто приходилось интересоваться этим вопросом.
А топикстартер говорил о малом и среднем бизнесе не уточнаяя отрасль. Думаю, что тут не существует универсального программного обеспечения. Надо по задачем подбирать.
Выравнивание (левелинг на сленге) — «Устранение конфликтов ресурсов или превышения доступности ресурсов, осуществляемое в результате задержки или разделения определенных задач. Когда Project выполняет выравнивание загрузки ресурсов, выбранные назначения ресурса распределяются и перепланируются.» (Из хелпа MS Project)
Например, в Проджекте я насоздавал задач, назначил ресурсы, объем, связи между задачами. А потом жму кнопку и автоматически получаю план работ.
А в Джире ну наставлю я связей. А что с ними делать? Они ж не несут никакой функциональной нагрузки. Может и существует какой-то подходящий плагин, но кто поручится, что он нормально работает? А то я насоздаю тысячи задач (в строительстве это нормально), а потом у меня фигак и всё сломалось. И делай работу заново.
Про Проджект и Прамиверу по-крайней мере известно, что они приспособлены для этого и много людей этим пользуются. А вот про использование Джиры в строительстве я что-то не слышал. :)
Ну для строительства всё ж таки вряд ли Джира годится. Там куча взаимосвязанных работ. Из-за технологических особенностей связи эти достаточно сложные. На Джире, которая является тикетовой системой, всё это будет достаточно сложно делать. К тому же левелинга в ней нет.
Может :)
Не хочется углубляться в химию команды разработчиков программ, поэтому попробую привести аналогию.
Один, даже самый здоровый грузчик не дотащит пианино на 10-ый этаж. И двое по схеме: один с 1-го до 5-го, а второй с 5-го по 10-ый, тоже не смогут. А вот двое одновременно на ремнях тащат замечательно. Сам наблюдал. :)
Так программистов у вас наверное много? И что делает программист, когда закончил задачу? Ждёт, когда у Вас будет время разобраться с новой задачей для него? Пусть даже он знает, какая его следующая задача. Но если он сам возьмётся за следующую задачу, он может начать её делать так, что потратит 23 часа, а не 5, как Вам бы хотелось.
Этот метод известен как метод прототипирования. И, в подавляющем большинстве случаев требует того, чтобы после сбора требований прототип был выброшен и программа писалась заново (описывалось у Макконнелла в Rapid Development и, наверняка, ещё в куче мест). Как показала практика, если кода тяп-ляп достаточно много, то его дорого рефакторить. Дешевле переписать. И это надо закладывать в план.
Кстати, есть и ещё одна проблема. Руководство/заказчик, увидев прототип, радосно потирая ручки говорит: «Ну вот почти всё готово». И им замумукаешься доказывать, что это всего четверть работы и до конца ещё далеко.
Меня в микроменеджменте смущают 2 проблемы:
1. руководитель влезает со своими задачами во время решения программистом другой задачи и часто приходиться браться за новую, не завершив старую. Что, понятно, не ускоряет общую работу. И тут не скажешь, что руководитель плохой. Просто в силу специфики микроменеджмента и задачи, которые ставятся, часто бывают микро. И они не могут ждать день-два-три.
2. Если руководитель постоянно участвуют в уточнении поставленных перед программистом задач (а, как мы помним, они микро и их объём измеряется в часах), то часто возникает ситуация, когда программист вынужден ждать, пока руководитель освободиться от других своих дел (например, шеф вызвал, к заказчику поехал и т.п.). И тогда описанная Вами экономия времени может растаять без остатка.
Как Вы разруливаете эти проблемы?
P.S. По-моему Макконнелл говорил не про мотивированных программистов. Он говорил, что скорость работы среднего и лучшего программиста может различаться в скорости в 10 раз.
Мне кажется, что в этой статье несколько академично излагается простая мысль о том, что команда (будем понимать под командой группу людей, эффективность которой больше, чем сумма эффективностей её членов) не образуется сама по себе. Она требует кропотливого ухода за собой. Её надо мотивировать, перед ней надо ставить цели, убирать препятствия с её пути, заботиться о её членах и т.п. И без хорошего руководителя не будет команды.
У великих спортивных команд великие тренеры. А вот о самоорганизующейся футбольной команде вряд ли кто слышал.
Впрочем, возможно, что мы обсуждаем разный масштаб заказов. Мне чаще приходилось иметь дело с проектами, объем которых измеряется в человекогодах. Если речь идёт о работах за пару штук баксов, то описанную мною мутотень никто, конечно, разводить не будет. :)
Хотелось бы узнать, что у Вас получилось. Если, конечно, после аудита что-то последовало :). Ведёте реестр из 10 (3, 5, 20) наиболее неприятных рисков, мониторите его регулярно (раз в неделю, в день)? Или каким-то другим способом осуществляете управление рисками? Это удалось делать с начала и до конца проекта? Интересно было бы видеть примеры реальных (а не книжных) рисков. Реальных планов их преодоления.
Заранее благодарен.
Ну обратное тоже не редкость, когда программист напрограммировал такое, с чем заказчик по разным причинам работать не может. И сейлу приходится это расхлёбывать
И потом, я ж не говорю, что Команды часто встречаются. Может в IT-сфере и существуют такие из 20-ти человек, но мне не попадались. Обычно людей в них немного.
P.S. Спасибо за цитату. Я эту книжку когда-то на английском читал, русский вариант не видел.
А топикстартер говорил о малом и среднем бизнесе не уточнаяя отрасль. Думаю, что тут не существует универсального программного обеспечения. Надо по задачем подбирать.
Ну мы ж и говорим о строительстве. ;)
Например, в Проджекте я насоздавал задач, назначил ресурсы, объем, связи между задачами. А потом жму кнопку и автоматически получаю план работ.
А в Джире ну наставлю я связей. А что с ними делать? Они ж не несут никакой функциональной нагрузки. Может и существует какой-то подходящий плагин, но кто поручится, что он нормально работает? А то я насоздаю тысячи задач (в строительстве это нормально), а потом у меня фигак и всё сломалось. И делай работу заново.
Про Проджект и Прамиверу по-крайней мере известно, что они приспособлены для этого и много людей этим пользуются. А вот про использование Джиры в строительстве я что-то не слышал. :)
Не хочется углубляться в химию команды разработчиков программ, поэтому попробую привести аналогию.
Один, даже самый здоровый грузчик не дотащит пианино на 10-ый этаж. И двое по схеме: один с 1-го до 5-го, а второй с 5-го по 10-ый, тоже не смогут. А вот двое одновременно на ремнях тащат замечательно. Сам наблюдал. :)
Кстати, есть и ещё одна проблема. Руководство/заказчик, увидев прототип, радосно потирая ручки говорит: «Ну вот почти всё готово». И им замумукаешься доказывать, что это всего четверть работы и до конца ещё далеко.
1. руководитель влезает со своими задачами во время решения программистом другой задачи и часто приходиться браться за новую, не завершив старую. Что, понятно, не ускоряет общую работу. И тут не скажешь, что руководитель плохой. Просто в силу специфики микроменеджмента и задачи, которые ставятся, часто бывают микро. И они не могут ждать день-два-три.
2. Если руководитель постоянно участвуют в уточнении поставленных перед программистом задач (а, как мы помним, они микро и их объём измеряется в часах), то часто возникает ситуация, когда программист вынужден ждать, пока руководитель освободиться от других своих дел (например, шеф вызвал, к заказчику поехал и т.п.). И тогда описанная Вами экономия времени может растаять без остатка.
Как Вы разруливаете эти проблемы?
P.S. По-моему Макконнелл говорил не про мотивированных программистов. Он говорил, что скорость работы среднего и лучшего программиста может различаться в скорости в 10 раз.
Дико извиняюсь, но всё ж таки PMBOK (Project Management Body of Knowledge) ;-)
У великих спортивных команд великие тренеры. А вот о самоорганизующейся футбольной команде вряд ли кто слышал.