КаБа

Смотрите, есть такая задача - оценить удовлетворенность Заказчика результатами работы проектной команды. В моем понимании о работы проектной команды Заказчик судит по трем основным моментам: Процесс (организация работ) проектной команды - прозрачность процесса, его управляемость и ориентация на ожидаемый результат позволяют априори, до завершения проекта или получения значимого результата, прогнозировать соответствие продукта ожиданиям Заказчика через понимание того, что выстроенный процесс может привести к ожидаемому результату. Команда - компетенция специалистов, организация работы команды и ее взаимодействия с Заказчиком позволяют судить о способности команды достичь необходимый Заказчику результат. Результаты работы команды - качество результатов и понимание их необходимости определяют общее понимание того, будет ли конечный продукт соответствовать ожиданиям. Ну и соответственно получение Заказчиком конечного результата окончательно расставляет все точки над i, но мне этот с...

Я думаю, многим из нас знакома ситуация - сидишь, ни кого не трогаешь, спокойно работаешь. И тут бац - приходит письмо от Заказчика, что подготовленные документы - полное фуфло, модели не верные, написано не понятно и вообще ваши аналитики понимают задачу совсем не так, как она выглядит на самом деле. Жесть, в общем. Помните свою реакцию на такой поворот событий? Страх, враждебность, расстроенное состояние, раздражение, вина, стыд, отчаяние, гнев - вот те эмоциоальные реакции, которые могут возникать у человека в ответ на внешнее воздействие, связанное с негативом. По своей сути это реактивные реакции, выражающиеся в форме эмоций, возникающих в ответ на внешнее раздражение автоматически. Поэтому при возникновении они воспринимаются как естественные. А поскольку реакции эти реактивные, т.е. возникающие неожиданно, то управлять ими либо нельзя, либо крайне затруднительно. С другой стороны человек, находящийся во власти эмоций, ограничен в способности контролировать себя, поскольку...

Процессный подход позволяет делать проекты более слабой командой В теории да, на практике приходится сталкиваться с серьезным психологическим ограничением. Суть его в том, что можно заставить человека работать по процедуре, но если он не понимает ее смысла, то к ее выполнению будет относиться формально (еще хуже – тупо забивать), а менеджера будет считать самодуром. Бороться с этим бессмысленно, поскольку в таком понимании ситуации этот человек абсолютно искренен. Поэтому его отношение к процедуре – это уже вопрос веры. Разъяснить важность и необходимость тоже особо не получится, поскольку тут дело в уровне профессиональной зрелости (в той ее части, которая отвечает за осознанность использования навыков).

Одной из больных тем  #swp12 для меня лично стала тема принятия решений. В общем-то люди говорят правильные вещи. Причем не могу сказать, что для меня свершилось открытие. Но точно могу сказать, что в ряде очень важных моментах я не решился на те решения, которые могли бы кардинально изменить ситуацию, но либо доставили бы кому-нибудь боль, либо шли бы в разрез с какой-нибудь внутренней политикой. Под половинчатыми решениями я понимаю решения, на момент принятия которых есть совершенно четкое понимание, что их реализация не приведет к достижению тех целей, которые необходимо достичь. Не знаю, есть ли в природе какая-нибудь классификация половинчатых решений, но для себя я их разделяю на следующие категории: решения, которые на самом деле не решения - т.е. достижение цели отпускается на самотек, а там уж куда кривая Гаусса вынесет; решения, при принятии которых в первую очередь приходится ориентироваться на какие-то внутренние политические моменты, а уж во вторую - на те це...

Когда-то очень давно была такая игра - Dungeon Keeper. Смысл ее заключался в том, что игрок, играя за главного демона, должен был выстроить свое подземелье. И все бы ничего, да только вот черти и демоны, которыми ты управляешь, постоянно становились несчастными и начинали депрессировать, поскольку для того, чтобы они двигали дело вперед, тебе надо их постоянно долбашить и шевелить. А депрессивный демон - это уже не то: он не страшный, руки у него опущены и он уже ничего не хочет, кроме кусочка счастья в своей мрачной жизни. А если его не долбашить и не шевелить, он перестает работать, у него кончаются деньги и он опять депрессирует, но уже от того, что ему хочется кушать, а денежков нету.

Тема всплыла на форуме UML2.ru . Я за форумом на этом сайте не слежу, тем более в нем не участвую (не потому, что он плохой, а потому, что времени нету), но по этой теме попытаюсь высказаться, поскольку близка она, эта тема.   Я б русский бы выучил только за то... Когда человек говорит, что хочет оценить коэффициент возврата инвестиций, то я могу предположить, что он просто хочет узнать, будет ли привлечение аналитика экономически оправданным. Но задаться таким вопросом человека мотивируют (на мой взгляд) две вещи: непонимание пользы от привлечения аналитика и желание численно (а потому наглядно) выразить эффект от участия аналитика в проекте. Зачем нужен аналитик на проекте, кто такой аналитик - это вопросы, объем обсуждения вокруг которых сопоставим разве что с темой про жизнь на Марсе. Ответов на эти вопросы ровно столько, сколько народу ими задавалось, поэтому выскажу свое личное мнение. Итого, если мы говорим об аналитике, как специалисте, знающем предметную область...

Давайте поговорим о том, как придти к тому, чтобы выделенный центр был эффективным инструментом Заказика и источником бесперебойной прибыли Исполнителя. Выгоды от создания идеального выделенного центра получают обе стороны. Это очевидно: Исполнителю выгодно полностью продать рабочее время проектной команды, чтобы забыть про неприятные темы, связанные с простоями, недозагрузками и прочими “радостями” ресурсной жизни. Заказчику выгодно, когда выполненная для него работа стоит ровно столько, сколько стоит время, потраченное на ее выполнение. В таком варианте он не переплачивает за продукт, как это бывает в случае fixed cost. При этом знание своей выделенной команды и ее возможностей минимизирует для Заказчика риски, характерные для time&material, а именно: превышение ожидаемой стоимости продукта, срыв сроков производства и т.п.

Не знаю как у вас, а у меня уже реально наболело. Уже больше полугода занимаюсь менеджментом команды порядка 50 человек, которая пилит целый легион мелких проектов. И все бы оно ничего, но эти проекты ведут себя реально как прутики из веника - по одному вроде как и фигня с легким гемором, но когда собираются в кучу (а это происходит как минимум раз в неделю, на еженедельном статус-отчете), получается одна такая огромная, ломовая хрень, с которой приходится бороться изо дня в день. А поскольку искоренить из себя хрень крайне проблематично, то хотя бы погундосить о ней очень хочется. Итак, вот они, встречайте!