|
ФОРУМИ: Відгуки на статті: Відгук на статтю 'Management by Objectives (управление по целям)' (читати статтю)
|
Автор: Sergiy
Дата: 2003-08-14 14:02:52
Собственно говоря, из статьи так и осталось не понятным, зачем это MBO необходимо и в чем его основные преимущества.
Все проблемы, которые поднимались в статье, решаются, скажем так "классическими" методами и без применения "умных" терминов SMART, MBO.
А некоторые проблемы так и вовсе надуманы. Вот, например, проблема, поднятая в статье(цитирую): "Незнание сотрудником тех задач, которые требуется ему решить". Так а куда смотрит начальник сотрудника? Почему он не выдал задачу или поручение? Ах, да. Он же MBO изучает.
Или же (цитата): "«Плохая мотивация персонала». Сотрудники будут ориентированы на результат, требуемый компании. И они будут стараться его достигнуть и перевыполнить". Сотрудники будут ориентированы на результат, требуемый компании, только тогда, когда, простите за простоту выражения, сотрудник будет на 120% уверен, что за это компания отлистает ему бабла в соответствии с его, сотрудника, представлениями о справедливости. А в остальных случаях чихал он на этот "результат, требуемый компании".
Более того, опять (это похоже инфекционное) не указана область применения. А без этого - статья вообще теряет всякий смысл. Вот например, цитата: "Причем чем выше соотношение «премиальная часть / заработная плата», тем большего эффекта можно получить. К примеру, для отдела продаж, от которого напрямую зависит выручка организации, данное соотношение реально может составлять 1:1."
А если в организации (реальный пример) это соотношение достигает 10:1 и больше. При этом область деятельности - информационные технологии, автоматизация, разработка ПО и т.д. Будет ли работатьт этот метод (MBO)?
Или другой пример. Производственное предприятие, на котором персонал (основная масса) можно сравнить (мягко говоря) разве что с гоблинами. Будет там MBO работать или нет?
Или случай, когда генеральный директор является владельцем контрольного пакета акций, а остальные директора - держатели остальных акций предприятия. Будет работать такой метод стимулирования высшего руководства?
Будет ли работать MBO в производстве, развернутом на базе мест принудительного лишения свободы?
ГДЕ ГРАНИЧНЫЕ УСЛОВИЯ ПРИМЕНЕНИЯ?
И таких "если" можно привести в пример вагон и маленькую тележку.
Кстати, о самом примере, который приводится в статье. Если участнику моей проектной команды (когда у меня идет проект) кто-либо, не дай бог, поставит цели, которые так сформулированы (особенно классная цель: "Ежедненаная отчетность" - да это же не цель! - это средство), то он будет тут же отправлен изучть народный фолькльор. И вызывает недоумение вот еще что. Каким образом программист узнает о том, как он влияет на выполнение целей всей организации, если его персональные цели никак явно не связаны с целями организации в целом?
Кстати, если кому-то действительно интересно прочитать про MBO, советую посмотреть здесь: http://www.1000ventures.com/business_guide/mgmt_mbo_main.html. А особенно обратить внимание на разделы/врезки: "Six MBO Stages" и "MBO: Key Advantages and Disadvantages".
|
|
|
Автор: Konstantin
Дата: 2003-08-14 17:00:16
Спасибо за ссылку, Сергей.
Жаль, что это не читали те менеджеры, которые покупают тренинги по MBO у всевозможных тренинговых компаний.
Тренеры предлагают дать MBO за 3 дня, а там какой из 6-ти этапов не возьми, он сам по себе претендует на монументальность :-)
|
|
|
Автор: Sergiy
Дата: 2003-08-15 09:01:33
Константин,
Научить читать (и _понимать_ написанное) нашего менеджера/руководителя (про "их" мненеджеров не знаю) - это одна из наиболее сложных задач современности :-)
У нас в организации сейчас при ведении проектов одна из самых сложных проблем (внимание!) - это то, что руководство заказчиков не читает проектную документацию. О каком согласовании задач по проекту может идти речь? И руководителю проекта приходится "на пальцах" (а иногда и "по понятиям" :-) объяснять заказчику о чем идет речь.
Точно также и с тренингами. "Спорт залу" деньги заплатили. В затрты поставили. Налоги уменьшили. Какое MBO?
|
|
|
Автор: Konstantin
Дата: 2003-08-15 09:21:20
По поводу немения читать проектную документацию - это да. Болезнь в глобальном масштабе.
Если следовать здравому смыслу и старым советским ГОСТам, техзадание проекта должен писать ЗАКАЗЧИК (или его уполномоченный представитель), но уж никак не исполнитель. Интересно, как часто это выполняется в нашей реальности? ;-)
|
|
|
Автор: Sergiy
Дата: 2003-08-15 10:45:15
Ну, не совсем согласен.
Если следовать ГОСТам, то может быть требования и должен писать заказчик.
А вот если следовать здравому смыслу, то требования должен писать исполнитель, поскольку в противном случае, есть риск, что они не будут написаны никогда :-)
|
|
|
Автор: Konstantin
Дата: 2003-08-15 12:10:58
Вот и имеем в результате ситуацию, когда ИСПОЛНИТЕЛЬ говорит ЗАКАЗЧИКУ, что же ему (заказчику) на самом деле нужно :-)
Конечно, такая ситуация устраивает многих Исполнителей (особенно, не самых профессиональных).
Хотя, думаю Вы согласитесь, работать с Заказчиком, который точно знает, чего хочет, намного приятнее...
|
|
|
Автор: Sergiy
Дата: 2003-08-15 13:03:23
Вах! Работать с грамотным заказчиком - это подарок Небес!
Только вот с непрофессиональными исполнителями, Константин, Вы по-моему, погорячились. Я бы, например, с удовольствием занимался _исключительно_ внедрением информационных систем по _грамотно_ написанным заказчиком требованиям. Только вот реалии жизни таковы, что приходится держать в штате бизнес-аналитиков, а половина ИТ-шников - это почти готовые бизнес-аналитики по направлениям.
На самом деле, исполнитель только фиксирует требования (например, к информационной системе) и согласовывает (обязательно!) их с заказчиком до достижения полного взаимопонимания по всем пунктам требований и искоренения возможных неоднозначностей в трактовках.
Источником же требований все равно является заказчик, который выдает их нагора под напором аналитиков исполнителя. Мне например, в этой связи очень нравится устоявшийся термин, который этот процесс описывает "customer requirements elicitation", который буквально можно перевести примерно как "извлечение/вытягивание требований заказчика" - очень хорошо описывает реальный процесс. Собственно говоря, если посмотреть на рекомендации "лучших собаководов" в этой области, то они это и рекомендуют.
А если мы посмотрим на заказчика (реального, а не идеального), то увидим, что:
- ОН всегда занят основным бизнесом и ЕМУ некогда тратить время на "всякую ерунду" - и тут ЕГО можно понять;
- ОН не обладает специальной квалификацией по подготовке требований (это целый раздел области знаний), в отличие от моих аналитиков - это абсолютно естественно, поскольку каждый должен заниматься своим делом. И, например, если прочесть IDEF0 диаграмму в состоянии практически любой толковый менеджер, то "нарисовать" ее не так просто, как может показаться на первый взгляд.
- некоторые вещи ЕМУ кажутся настолько очевидными, что ОН забывает включить их в требования - вполне понятно - "свежий взгляд" на организацию всегда ценится;
- ОН не может выделить человека, который видит всю картину целиком на проект - такие люди обычно заняты "по горло" на бизнес-задачах, а особенно критично это в услових, когда уровень технологической зрелости организации/предприятия низок - для Украины это нормальная ситуация, как впрочем и для западных стран, если судить по публикациям;
- ЕГО сотрудникик склонны замалчивать неприятные для них моменты, а сторонний аналитик является лицом независимым и, что называется, режет "по живому".
И этот список можно продолжать. Причем, такие соображения настолько убедительны для заказчкиа, что он с ними соглашается, пратически, безоговорочно.
|
|
|
Автор: Konstantin
Дата: 2003-08-15 13:52:02
Да я спорить и не собираюсь :-)
Очевидно, в проектах внедрения информационных систем должны присутствовать три стороны: "Заказчик" - "Внедренец" - "Вендор ПО"
При нормальной системе, когда внедренец не зависит от конкретного программного комплекса, наверное да...
А если внедренец и вендор - это одно и то же лицо? Заказчик может оказаться в неприятной ситуации, когда его требования чуть-чуть "привели в соответствие" с возможностями программного комплекса.
Или такого быть не может?
|
|
|
Автор: Sergiy
Дата: 2003-08-15 14:23:22
Все зависит от квалификации и честности (читай, репутации) внедренца, и желании заказчика получит работающую систему.
Что отражено в требованиях - то и получит заказчик. И если заказчик подмахнуд неглядя бумаги, а внедренец (радостно потирая руки) сваял то, что подписано... Ну, ситуация понятна.
Поэтому такое внимание сейчас и уделяется, например, ISO или (к сожалению, в основном на Западе, CMM). Там работе с требованиями (кстати, явными и неявными) заказчика отведено очень большое место.
Все зависит от качества требований - это ключевой момент в производстве любых работ. Если перефразировать известное выражение, то можно сказать: "Ищите требования" :-)
А кто в каких лицах выступает - это уже дело техники. Кстати, многие производители ПО сознательно не работают с клиентом напрямую, а только через партнеров. Смысл в том, что внутри партнерской сети создается конкуренция (за счет присутствия нескольких партнеров в некотором регионе), которая и гарантирует непрерывное повышение уровня сервиса и качества выполняемых работ.
|
|
|
Автор: Konstantin
Дата: 2003-08-15 14:33:14
Сергей,
а не могли бы Вы порекомендовать литературу по управлению требованиями?
|
|
|
Автор: Sergiy
Дата: 2003-08-15 15:16:55
В печатном виде на русском языке, к сожалению, ничего не могу назвать.
В электронном и на английском примерно следующее:
1. CMMI (www.cmm.org)
2. ISO 9001
3. Любые работы Карла Вигерса (Karl E. Wiegers)
|
|
|
 |
|
|
|
