Предлагаю изменить подход к вопросу управления сложными проектами (к коим можно смело отнести внедрение ERP). Движение от факторов, похоже, себя исчерпало… Пойдем от типичных ситуаций и начнем с одного примера. В этой статье мы придумаем новое имя для ситуации, которая часто встречается на многих инновационных проектах.
Цель и средства
Кто платит, тот и заказывает музыку
Не стреляйте в пианиста, он играет как умеет
Две известные поговорки
Сложные проекты, это не только вопросы технологий и квалификации специалистов, но и особенности взаимодействия заказчика и исполнителя. Казалось бы, заказчик платит, исполнитель выполняет, и это верно всегда. Если заказчик пожелал сменить исполнителя, то он взял и сменил. Не тут то было! Последнее утверждение многими в консалтинге будет воспринято в штыки: «на переправе коней не меняют» или «смена исполнителя может оказаться более затратным делом, чем оставить все как есть», «исполнитель тоже имеет право на долгосрочный контракт». Самые крутые скажут с сарказмом: «пусть только попробует найти кого то еще». Нет уж! Заказчик имеет право заменить исполнителя и точка.
Дело в том, что у заказчика есть цель и если подрядчик ее манкирует, то подрядчика надо менять – иначе цель достигнута не будет. Разговоры о том, что у каждого своя цель, являются бессмысленными. Даже если цель исполнителя не сводится к простому получению прибыли, и исполнитель желает сделать качественный проект, все равно цель заказчика должна стать его целью, а не наоборот. Исполнитель может предложить пути и даже может предложить более амбициозную или более достижимую цель, но новая цель будет только предложением, пока заказчик ее не примет ее как свою, а ведь может и не принять. Цель проекта это именно цель заказчика, за которую он платит и к которой он стремиться и ни кто кроме него не знает эту цель лучше. И это значит (повторюсь), что тот кто платит должен иметь возможность сменить того кто выполняет если есть ощущение, что все движется не в ту сторону.
Теперь… Если сменяемость исполнителя является необходимым условием получения правильного результата, то логично обратную ситуацию назвать недопустимой или даже абсурдной.
ТОЧКОЙ АБСУРДА называется ситуация абсолютной монополии Исполнителя по отношении к Заказчику.
Абстракция? Например, у проекта может быть дедлайн, т.е. время икс, после которого завершение проекта становится бессмысленным. Время потерянное на смену исполнителя может оказаться губительным. И заказчику придется продолжать работать с тем же подрядчиком, несмотря на то, что его надо сменить. Это и есть «точка абсурда» в которой тот кто должен делать дело начинает вить веревки из того, кто за это дело платит.
А ведь это реальный шанс заработать сверхприбыль. Что тут ссылаться на контракт, ведь заказчику нужны не разборки в суде, а выполненный проект и он будет вынужден идти на крупные уступки и дополнительные затраты.
И этот вариант, о котором мечтает каждый (чур не я). Поставить заказчика на колени и заставить платить много за пустяки, ни к этому ли стремятся все консультанты мира?
Вверх тормашками
- Вот мы тут 10 минут с тобой разговариваем
и ты уже третей раз назвал меня дураком.
А ты всего лишь сисадмин,а я все-таки директор, и мне обидно.
- Ну так сделай мне такую должность чтобы тебе не было обидно.
Цитата по памяти из просторов интернета (источник не известен)
|
Зачем нам новый термин? Есть слово «монополия» и все знают, что это плохо. Чем монополия на электричество отличается от монополии на проекте? Есть одно различие! В начале проекта ни какой монополии нет, но она появляется в процессе исполнения. И исполнитель со своим, более глубоким чем у заказчика, пониманием процесса имеет возможность (и очевидно, заинтересованность) двигать проект в этом направлении. Из осознания нового понятия следует несколько полезных выводов.
В ситуации близкой к «точке» перестает работать контроллинг, по тому, что всем известная схема «План-Контроль выполнения» на самом деле выглядит так «План-Контроль выполнения-Поиск виновного-Санкции-Мотивированность на достижение плановых показателей», приблизительно так. В «точке абсурда» возможность применения санкций к исполнителю, не то что бы ограничена, она исчезла. Теперь исполнитель может сам применять санкции к заказчику, а это значит, что обратная связь утрачена. Именно эта абстрактная точка является источником провала многих проектов. Представим себе упрощенную модель неудачных проектов. При достижении «абсурда» (или «близкой точки») запросы исполнителя растут и он быстро выгребает остаток бюджета проекта. Заказчик сперва идет на уступки и увеличивает бюджет проекта, но это все равно не помогает. В некоторый момент руководство приходит к шокирующему выводу, что проект нужно закрывать или начинать работу заново с другим исполнителем (если проект очень нужен). Нередко можно встретить собственников, которые через это прошли и теперь очень осторожно начинают новые высокотехнологичные проекты. |
рисунки Григорьевой Насти (tubby-toast.livejournal.com) |
Жизнь наизнанку
- Предложите свой вариант понятия «Точка абсурда».
- Точка абсурда - это когда у заказчика
заканчиваются деньги или терпение?
Обсуждение анонса ru-erp.livejournal.com/129824.html
Жажда власти над заказчиком, толкает консультантов на шаги в сторону «точки абсурда». Для крупных консалтинговых компаний на первое место выходят финансовые показатели и «абсурдная ситуация» для рядового консультанта работающего у заказчика – отличный способ улучшить показатели своей деятельности в компании. В пирамиде управления таких монстров нередко используется indulgence management и это значит, что наемный руководитель ради денежных результатов потерпит нечистоплотный способ их получения.
Что же делать заказчику? Как избежать проблем? Очевидно, что надо рулить от неприятностей как можно дальше. «Точка абсурда» это маяк с помощью которого можно оценить любое действие на проекте. Все решения по проекту можно разделить на две категории: те, которые приближают нас к «точке абсурда» и те, которые удаляют нас от нее. На этапе разработки архитектуры проекта следует продумать пути, которые позволят обойти «абсурд». Правда сложность технологий позволяет легко построить бутафорию, которая с виду нацелена на снижение рисков, на самом деле приближает к ситуации в которой консультант попадает из грязи в князи.
Нам надо использовать сетевые принтеры, тогда мы как специалисты
будем более незаменимыми, ведь обычный локальный принтер
настроит каждый дурак, а с сетевым поди разберись.
Высказывание начальника ИТ отдела
А что еще можно противопоставить «точке абсурда». Возможны ли проекты, которые принципиально не могут ее обойти. Если проект оказался в такой неудачной ситуации можно ли из нее вырулить? Абсолютному «абсурду» можно противопоставить только абсолютную честность исполнителя. Правда критериев измерения честности наука пока не придумала.
Словосочетание мы зазубрили, теперь его надо уметь найти на чертеже или на плане проекта, чтобы исправить план. Простого алгоритма нет, и все что связано с этим вопросом теперь выделено в новую методологию управления инновациями, которая называется «Эксперт-менеджмент».
Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2024 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
Все что описано — является попыткой оправдаться за некомпетентность в управлении проектом со стороны заказчика.
При грамотном планировании проекта, грамотном поиске исполнителя (а не по принципу «кто даст большую скидку/откат»), и, что самое важное, при реальном (а не на словах!) управлении рисками вышеописанные проблемы отсутствуют априори.
(1) Gureev, указанная проблема не решается даже гибкими методологиями (XP, Scrum, …), я уж не говорю про контроллинг (PMI, SureStep и иже с ними).
А вы какую компетентность и грамоту вы имеете ввиду? В каких методологиях и как этот вопрос на ваш взгляд решается? Эта статья — это постановка вопроса. Этот вопрос пока просто ни где не был поставлен. Для того, что бы начать решать проблему, надо сперва признать ее существование.
(1) Gureev, Вы слишком категоричны. Даже компетентное управление проектом не дает гарантий что проект не скатится в «точку абсурда» (мне понравился термин). Сейчас именно так происходит в нашей компании, а виной (я так считаю) амбиции исполнителя и как следствие: умалчивание исполнителем о не возможности того или иного, ошибки проектирования, и отсутствие элементарного опыта подобных проектов (но это выяснилось только в процессе, а в начале переговоров нам показывали «красивые картинки» и рассказывали как все будет «волшебно») хотя заказчик (мы) четко формулировал требования и в дальнейшем описывали это в ТЗ. Но …
Почитайте Том ДеМарко «Deadline. Роман об управлении проектами», очень рекомендую.
p.s. Волшебно получилось, все происходит как по волшебству :0, то данные появляются, то пропадают, то считаются, то нет и никакой системности, волшебство/чудеса да и только.
Согласен с (1)
Заказчик как правило не может четко сформулировать свои мысли.
Диалог примерно следующий
— Нам нужна система для учета вот этого
— У нас есть отличная система. Она может вот это, это, это и вот это…
— А это?
— И это может. Только для этого нужно внедрить сначала это…Вот смотрите…
— Ладно. Нету времени. Вроде все Ок. Внедряйте!
Идет внедрение… И тут заказчик начинает прозревать.
— Так это нужно делать так? Нет! Сделайте так! Нам так удобнее. В нашей другой системе было так. А там куча чего завязано…
И в этом момент и начинается путь к точке абсурда.
Если исполнитель принимает позицию «Кто платит, тот и заказывает музыку» и начинает по ходу внедрения кроить систему по заданиям того, кто не сильно вникал изначально в систему, то провал обеспечен. Точнее происходит следующее
— Почему с 1-го не запустились?
— Так Вы же нам сказали переделать это.. и это…
(прошел месяц)
— Почему с 1-го не запустились?
— Так Вы же нам сказали переделать то.. и то… и даже это, что повлекло за собой переделку и того и даже вон того блока! Там столько работы! А вы еще за прошлый месяц не рассчитались!
— Так а чего платить? Система то не работает!
И так пока у сторон хватит терпения и денег.
Один из вариантов развития события
Заказчик — Что-то эти <…> не могут нам внедрить. Меняем исполнителя!
Приходит новый исполнитель. Смотрит на то, что уже наделали по желаниям заказчика и понятное дело рассказывает как все плохо и сколько нужно времени (т.е. денег) что бы все переделать «правильно». Потому как прошлый исполнитель безусловный <…> . Ни строчки ТЗ, ни строчки документации, один сплошной .овнокод непонятный
Все в шоке.
А нужно было то всего заказчику тратить свое время на начальное изучение системы и понять — оно ему как есть подходит или нет. И если подходит, то внедрять как есть, а если не подходит, то сначала заказать доработку, а потом говорить о сроках внедрения.
Но, как правило, заказчику некогда… у него текущая работа… а выделит отдельного компетентного специалиста, да еще с правом принимать решения… на какое-то там 1С калькулятор… там же все просто…
Мне тоже кажется что «точка абсурда» это проблема заказчика. Зачастую у исполнителя присутствует хоть какие то понятия об управлении проектами, но не у заказчика.
И если у него нет знаний, времени контролировать исполнителя, то может помочь внешний аудитор/контролер, который притушит амбиции исполнителя, оценит его опыт, разберется в «красивых картинках», вовремя заметит ошибки проектирования, заставит писать документацию и не позволит писать «один сплошной .овнокод непонятный».
По моему опыту, достижение «точки абсурда» зачастую происходит в следствии:
1. Недостаточной квалификации Исполнителя, как следствие (лишь несколько примеров):
1.1 Не правильный подбор технологии внедрения
1.2 Низкое качество планирования
1.3 Низкое качество коммуникаций с Заказчиком (тем, кто действительно заказывает музыку, т.е. платит)
2. Отсутствия руководителя/куратора проекта со стороны Заказчика. Как следствие (лишь несколько примеров):
2.1 Не исполнение своих обязанностей
2.2 Не качественная постановка задачи Исполнителю
Есть такое понятие: риски проекта. На этапе старта проекта, необходимо эти риски предвидеть. Увидеть эти риски, зафиксировать, донести до сознания Заказчика — это задача, в первую очередь, Исполнителя.
Далее Исполнитель (равно как и Заказчик) должен честно принять решение: можно ли сделать проект с ЭТИМ Заказчиком, с ЭТИМ бюджетом, с текущими ресурсами и т.д. Если, при ответе на эти вопросы, Исполнитель лжет сам себе и начинает проект, заранее понимая что проект обречен, то в последующем проект приходит к точке абсурда.
Могу привести еще цитату: «Никогда не говорите заказчику правду — она ему не понравится…»
«Цель проекта это именно цель заказчика, за которую он платит и к которой он стремиться и ни кто кроме него не знает эту цель лучше.»
Заказчик тоже обычно не говорит исполнителю правду, поэтому истинная цель часто выясняется только уже в точке абсурда.
(2) » Эта статья — это постановка вопроса. Этот вопрос пока просто ни где не был поставлен. Для того, что бы начать решать проблему, надо сперва признать ее существование.»
Реально. В проектах чаще всего проблемы не решаются только потому что стороны отказываются признать их существование.
(6) Vladimir_Konyrev,
Далее Исполнитель (равно как и Заказчик) должен честно принять решение: можно ли сделать проект с ЭТИМ Заказчиком, с ЭТИМ бюджетом, с текущими ресурсами и т.д. Если, при ответе на эти вопросы, Исполнитель лжет сам себе и начинает проект, заранее понимая что проект обречен, то в последующем проект приходит к точке абсурда.
Идеальный исполнитель? Он не получит ЭТОТ заказ, и другой тоже ибо типичный заказчик не хочет оценивать и тем более оплачивать риски.
(3) kiros, сразу оговорюсь для всех, я ни когда не ставлю лайки за лайки, соответственно здесь лайк за поднятие вопроса «умалчивания» и за рекомендацию по литературе. Рекомендованную вами книгу читал, не дочитал, т.к. она мне не понравилась. Выводы в ней многие правильные, но делаются безосновательно (не научно).
(5) andpal, внешний аудитор может помочь. С ним только одна проблема: как проконтролировать работу аудитора? Все только на доверии…
(6) Vladimir_Konyrev, «Не правильный подбор технологии внедрения» — точнее такой подбор технологий, который ставит заказчика в зависимость от исполнителя
(11)
Еще можно привлечь аудиторов для аудитора 🙂 .
Но, хоть у меня нет аттестатов PMI, мне кажется что выполнение заказчиком рекомендаций PMBOK (или чего то подобного) позволит не приближаться к «точке абсурда».
Ну а простого и дешевого варианта, вероятно, нет.
(12) andpal, я берусь доказать, что PMBOK книга антинаучная. Не то что бы не научная, а именно антинаучная. Она сочетает в себе три составляющие: бессодержательность, наукообразие и добротную защиту от типовых методов проверки на научность. Ее единственное достоинство, это она диктует нам язык по управлению проектами. Должен признаться что я это достоинство не очень то заметил, но тут я доверюсь специалистам (то что мы говорим на языке Пушкина то же признают только пушкинисты)… На мои выпады специалисты обычно отвечают что я ни чего не знаю про PMI, т.к. существует 12 секретных практик, которые изучаются на курсе. Интересно, где их можно посмотреть 🙂
Участвовал в процессе смены исполнителя (были уже третьими и не последними :)). Так что прямо про себя читал.
А проблема то интересная! Читая коменты сразу понятно кто заказчик проекта, а кто исполнитель 🙂
Да проблема существует. В любых самых мелких задачах франч как правило предпочитает перекроить конфу и брать деньги за обновления, вместо того чтобы обоитись свойствами объектов и внешними обработками.
У заказчика и исполнителя немного разные интересы в проекте. Для кого то это новость?
Любой продавец хочет продать услугу подороже, а покупатель купить подешевле. Разве это не естественно?
Нужно договариваться и находить компромиссы.
Позиция заказчика: «Делайте мне все под ключ, я в это вникать не собираюсь», это и не позиция вовсе, это наплевательское отношение к проекту. Если всё уходит на откуп исполнителю, какие потом вопросы? Бери что получилось.
Аналогия с изготовлением мебели: либо ты берешь готовую либо несешь чертежи. Хочешь рисовать чертежи сам, не удивляйся если все развалится.
Я считаю точка абсурда это абсурд. Смена исполнителя в проекте ВСЕГДА приводит к увеличению стоимости проекта.
о причинах читать Фредерика Брукс «мифический человеко-месяц». Если есть объективная необходимость менять исполнителя нужно сразу брать несколько подрядчиков делить между ними задачу и выделить участок работ, который отойдет тому, кто покажет лучший результат.
(13) Про PMBOK спорить не буду, ибо некомпетентен. Посоветуйте научную книгу по управлению проектами.
Мое мнение что лучше следовать каким нибудь правилам, чем никаким. Некоторые следуют своим правилам, но прежде чем они выработались, вероятно пытались следовать каким либо известным и всегда полезно сверяться с чужими.
Цикл управления известен и прост: планирование — контроль — анализ — корректировка плана. Если таких циклов в проекте < 2, то выходим на «точку абсурда». Все сложности в деталях.
В конце статьи у Вас есть
, где про нее почитать?
Тему подняли, конечно же весьма злободневную, но искать истину тут все равно, что в споре: «Что первым появилось: яйцо или курица»!
Я сам программер. Работаю сам по себе. И, чего уж греха таить, не только заказчики пофигительски относятся. И чем дороже проект, тем серьезнее отношение заказчика, и тем важнее высокая квалификация исполнителя. А этого то как раз и не хватает. О нынешних франчайзи даже на просторах Инфостата уже писано не мало. Когда в конторе на каждое направление имеется по одному действительно классному спецу вокруг которого вьется с десяток девочек — мальчиков «на подхвате». И ест-но такого спеца на все не хватает. А когда его вся эта беготня по залатыванию чужих дыр достает, он вообще на все забивает. Оттого и качество работ соответствующее, и сроки выполнения и проч…
И что бы не попасть в эту «точку абсурда» (а правильнее — в жопу) должен быть выполнен целый комплекс решений, по сути уже здесь озвученных:
— изучение типового прикладного решения и в случае принятия решения о его доработке:
— создана команда по работе над проектом со стороны заказчика. Причем окончательно работу должен принимать не только тот, кто курировал исполнение, но и тот, кому предстоит с этим далее работать.
Т.е. фактически задействовано должно быть не малое количество народа. Далее:
— выбор исполнителя. Хорошо если есть рекомендация о качественном выполнении чего-то подобного. И не просто фирма. А конкретные Маня или Ваня, которые это делали или руководили. А чтобы подстраховаться, то целесообразно разбить проект на отдельные блоки. И поручить в начале выполнить что-то незначительное, работающее автономно.
— и конечно же контроль, разбор полетов, снова контроль, и потом поэтапная оплата только после принятия очередного блока, или — «До свидоза!»
Я вообще не сторонник мегапроектов. Это больше комплекс «Маленького Члена», чем реальная необходимость. Напротив: двигаясь небольшими шагами, всегда проще вносить коррективы в изначальные планы без необходимости перелопачивать все тех задание (а их, как правило бывает много: в начале трудно все просчитать и предвидеть)! И тем самым можно свести и риски к минимуму, и смену пользователя, в случае чего, произвести менее болезненно.
(18) andpal, хороших книг очень и очень мало. В моем списке их всего две:
1. Это уже упомянутый здесь «Мифический человеко-месяц или Как создаются программные системы» Фредерика Брукса. Теоретическая книга с практической базой.
2. Хенрик Книберг: «Scrum и XP: заметки с передовой». Наоборот — практическая книга с элементами теории. Несмотря на то, что она посвящена конкретным методологиям, она ценна тем что в ней упомянуты ВСЕ существенные проблемы, которые могут возникнуть при организации процесса разработки ПО.
Далее начинаются плохие книги. Да, они плохие, но нужные, ибо лучше ни чего нет…
3. Эд Салливан «Время деньги» («Under Pressure and On Time» Ed Sullivan ). Большое количество историй о том, как решали какую проблему. Интересные идеи, но вероятность встретить свой случай близка к нулю…
4. Нонака и Такеучи «Компания – создатель знания». Скучная но полезная теоретическая книга с притянутой за уши практической базой. Ее ценность только в том, что в ней введено важное понятие «Гипертекста организации» и в результате затронут вопрос «Точки абсурда», хотя он там не поднимается.
Все остальные книги на эту тему которые я читал (несколько десятков наименований), это или бред или скука с отсутствием новизны или полное шарлатанство…
(18) andpal, по поводу «Эксперт-менеджмента». Спасибо! Очень хотелось услышать такой вопрос. В основе методологии лежит новый язык. Т.к. термины новые и я активно конкурирую с маркетологами (они же обладают исключительными правами на введение нового языка в нашу жизнь), то каждый новый термин приходится защищать, т.е. писать отдельную статью. Таким образом методология — это приблизительно 15 статей. Из них опубликовано только 4. Предстоит большая работа…
Пока все что есть собрано .
(4) mashinist, «— Почему с 1-го не запустились?«. Это менее вероятный сценарий. Вот когда запущено и надо что то исправить, вот тут выясняется, что быстро может это сделать только один человек на всем белом свете.
(16) Vit aka proger, а ведь мы можем прийти к абсурду даже когда Заказчик очень заинтересованно относится к проекту. Опытный исполнитель обведет его вокруг пальца. Помните как в анекдоте «Я не опытный водитель, думал проскочу. Я опытный водитель, у меня хрен проскочишь…»
(22)
Позволю себе не согласиться.
Немного лирики. У меня случаются шабашки. Когда я начинаю работать с новым человеком, который сам вышел на меня, я всегда завышаю цену за первый заказ. Это проверка на жадность, страховка от «дурака». Я называю это управление рисками 🙂
В моей практике только один раз был случай когда заказчик аргументированно оспорил цену.
Оказалось что он, прежде чем предлагать мне работу, прочитал книжку из коробки! (я тоже раньше думал что никто этого не делает) Сам определил что он хочет изменить в типовом функционале. И естественно определил среднюю цену, обзвонив франчази.
По настоящему заинтересованный заказчик для начала должен сам изучить вопрос.
К сожалению заказчик практически всегда хочет получить под ключ что-то, чего он толком не может описать.
Когда описываешь возможности типовой заказчикам неинтересно они сидят в полудреме, когда моделируешь бизнес процессы, отсылают к каким то девочкам, которые кроме как нажать на три кнопки ничего не знают. Когда перекладываешь модель на типовую, заказчики со всем согласные лишь бы их не дергали. Тех задание не читается дальше второй страницы.
А вот когда все практически сделано идут громкие заявления, что заказчиков обманули, им сделали совсем не так как они хотели, надо менять исполнителя.
Конечно бывает много некомпетентных исполнителей. Но их достаточно легко определить. Вполне достаточно прочитать техническое задание. Ну или дать его почитать компетентному человеку.
(2) не надо проекты натягивать целиком на каркас «книжных» технологий.
Лично я из книг черпаю только ту информацию, которая бы мне позволяет избегать уже случавшихся проблем в будущем, либо вносить некоторые полезные изменения в уже запущенный проект.
Не стоит на чем-то зацикливаться.
Проект это весьма динамичный процесс, если не умеешь адаптироваться то тебя ждет провал.
Ведь еще Дарвин говорил, что выживает не самый сильный, а самый восприимчивый к переменам.
И кстати, у идеального исполнителя должен быть хороший продавец, который умеет продавать воздух.
Не стоит в одну кучу скидывать проблемы продаж и проблемы выполнения проекта.
Это имя уже есть и созвучно с одним северным зверьком, с красивой белой шерсткой.
И возникает это когда
Как по мне, описанная ситуация это ситуация уже после того, как проект провален. Поэтому выходит за рамки управление проектам, и относится больше к операционному менеджменту.
(26) Gureev, не надо проекты натягивать целиком на каркас «книжных» технологий
Результатом научной деятельности является алгоритм действий, который работает даже тогда, когда ты не веришь в то, что он работает. Вы можете не верить в теорию Ньютона, но она работает и все тут. Т.е. хорошая книжная технология, это способ получения надежного результата в типовых ситуациях, которые встречаются часто. Но книжки плохи, хороших мало. Даже умные японцы в книге «Компания – создатель знания» очень политкорректно обходят вопрос стороной…
(23) Vit aka proger, прежде чем предлагать мне работу, прочитал книжку из коробки
Почему ценятся профессионалы, по тому что они знают то, чего нет ни в одной книжке. Мы живем в очень динамичное время, все быстро меняется. Профессионал легко обведет вокруг пальца заказчика.
А вот когда все практически сделано идут громкие заявления
Все это конечно правильно, но к теме вопроса имхо отношения это не имеет. Допустим исполнителя обидел заказчик. Имеет ли при этом право исполнитель поставить заказчика в Точку абсурда. Наверно не имеет, но он и без обид часто это делает, просто из профессионального интереса…
(27) Gureev, это ситуация уже после того, как проект провален
Да, и по этому в статье сказано, что это не ситуация а маяк: рулите от рифов. А профессионал, будет стараться как можно дольше держать заказчика в состоянии надежды на результат, продолжая его доить…
(28)
не стоит смешивать фундаментальные науки, и всякие теории управления.
Первое это попытка понять алгоритм функционирования мира, второе исключительно человеческие отношения, которые слабо алгоритмизируются.
Не профессионал, а аферист.
Я никого никогда не доил, а иногда даже отказывался от денег, если считал «цели заказчика» вредными для его бизнеса и объяснял почему.
Репутация важнее.
(29) Gureev, у меня очень много статей на которые профессионалы так и реагируют: все это правда, но вот я ни когда так не делаю…. 🙂
Ха, ха! Я тоже….
Если честно, то не встречал проект, где в момент запуска какие то проблемы ставят заказчика перед исполнителем в неудобное положение. Обычно наоборот, исполнитель в авральном режиме срочно решает те проблемы, о которых заказчик умолчал. И еще непонятна позиция — бедный заказчик его обманули. Да, есть некомпетентные и нечестные исполнители, но результат проекта нужен не исполнителю, а заказчику. Заказчик будет пользоваться продуктом, а не исполнитель. Поэтому в интересах заказчика отнестись ответственно к внедрению продукта, что встречается еще реже чем компетентные исполнители. Тут уже много дали точно описания типового проекта — заказчику некогда, делайте «вы же профффессионалы». А когда получают продукт — ой нас кинули. Если я делаю ремонт в квартире у меня два варианта — дать денег незнакомому мастеру и сказать сделай классно, а потом плакать что все не так. Либо сначала продумать что я хочу и что можно сделать, нанять несколько мастеров для консультации и расчетов и только потом приступать к работе, проверяя каждый кусок работы. И самое интересно, когда заказчик делает в квартире ремонт то он так и поступает, ибо «мастера обманывают», а когда внедряет учетную систему то поступает по первому варианту и жалуется что его обманут.
Очередное нытьё представителя заказчика. Как обычно, он забывает упомянуть, что в 80% случаев заказчик делает подлянки исполнителю( пытается недоплатить; заплатить через год; запрашивает бесплатные доработки/ консультации; перекраивает ТЗ на финишной прямой проекта; запускает 1С на калечном виртуальном оборудовании, а потом жалуется на быстродействие). Хочете иметь гарантии от точки абсурда — заложите 200% запас времени, разбейте проект на 20 этапов и каждый этап пусть делает другой исполнитель. Долго? Пусть делают этапы параллельно. Дорого? Ставьте типовую и не парьтесь. При СССР бухгалтерия/производство велись на счётах и никто не парился. Сейчас есть мощнейший компьютеры, крутейшие программы, и кто-то ноет про точку абсурда. Уважаемые ПМы, отрабатывайте зарплату. Языком трепать каждый может, об глубокой научности методологии, а понимают, что происходит — единицы.
(32) PiccaHut001, вам видимо не приходилось делать очень большие проекты. Толку то делить… У меня есть отдельная статья из той же серии «Эксперт менеджмента» про неделимые операции (я тут ссылку давал выше). Читайте если не лень, а в двух словах суть такова: результаты инновационного проекта можно разделить на два вида. П Е Р В Ы Й вид — это реальный результат. Это когда уже все сделано — работает, вертится, приносит пользу и выгоду. В Т О Р О Й — это промежуточный результат. Даже П Е Р В Ы Й реальный не является показателем качества. Два с виду и изнутри одинаковых (по заметным полезным показателям) дома будут разваливаться по-разному и один превратиться в труху за 10 лет, а другой и 1000 простоит. А уж В Т О Р О Й промежуточный — это всегда бутафорская презентация, в которой контролер избавлен от скучных или не понятных ему деталей. Не существует качественного алгоритма принятия промежуточных результатов в инновационных проектах. Если у вас есть — предложите.
Хочу обратить ваше внимание еще на то, что тема управления людьми подразумевает, что управленец не вникает во все детали и это делают за него подчиненные. А на инновационном проекте это даже не возможно ни при каком микроменеджменте…
(33) вы как то странно пишите.. перечисляете факты, а потом делаете нелогичный вывод.
Что это вообще такое?
Если
то это результат проекта по попилу денег. И не стоит об этом вообще разговаривать — у нас в стране это уголовно наказуемо.
(32) PiccaHut001, «Языком трепать каждый может, об глубокой научности методологии, а понимают, что происходит — единицы.»
Я давно понял что профессионализм ПМ не измеряется в знаниях по PMBook и всяких там сертификатах. Как и любой руководитель. К этому должен быть заложен «талант» (харизма, коммуникабельность и т.п.). Но по себе могу сказать, что не всегда достаточно просто понимать что происходит. Поэтому я предпочитаю работать с вменяемым заказчиками, а не парить себе мозг с невменяемыми. Вменяемых конечно не так много, но они есть 🙂 А тех заказчиков, которые пытаются «обмануть» меня я посылаю к внедренцам, которые «обманывают» заказчика 🙂 Вот такая у меня философия отношений с заказчиком.
Задача исполнителя чтобы не потерпеть фиаско довольна проста:
просто нужно четко обговаривать ТЗ с заказчиком, все зафиксировать до мелочей (я конечно не про то где будут кнопки находится, а как будут работать в целом те или иные функции и как будут построены бизнес-процессы), а если правила игры начинают меняться просто нужно говорить заказчику что это невозможно по техническим причинам и все, гнуть свою линию все что обговорено ТЗ сделаем, на все остальное ищите других.. или нас но за сумму*2 от текущего проекта. Прогибаясь под хотелки заказчика вы сами по себе формируете ту самую точку абсурда, к которой и придете.. останетесь и без клиента, и без какой то суммы денег.
99% клиент не знает что его хотелки потянут за собой, доносите это до вашего клиента, как для ребенка, на понятном для него языке.
ПС: со стороны исполнителей за частую наблюдаю позицию «ну раз клиент хочет, будем делать, клиент же всегда прав…» — вот такая позиция провальная изначально
(36) AllexSoft, «»ну раз клиент хочет, будем делать, клиент же всегда прав…» — вот такая позиция провальная изначально»
Провальная для кого ? Для заказчика — провальная 🙁 А франчи только так и зарабатывают 🙂
(37) ZLENKO.PRO, и для заказчика и для исполнителя (ну конечно если исполнитель не только думает как срубить бабла, но и еще все таки что то внедрить)
(33) ваш ответ напоминает ответ ПМ-а на подведении итогов провального проекта. Мол проект инновационный, поэтому ничего нельзя было сделать. Вероятность 50% — или взлетит или не взлетит. Зачем же тогда менеджмент в проекте? Может лучше взять кухарку какую-нибуть, вероятность не поменяется. Эта ваша сверхзадача
решается элементарно — тендер. нанимается два, три, четыре исполнителя, которые делают одну и ту-же задачу. Потом заказать независимый аудит, можно даже не один. Кто справится лучше, тому платим премию, остальным — по себестоимости. Да дорого, но ПМ-ам не придётся включать мозг и вникать в детали. Как вариант, можно взять толкового программиста начальником внедрения, дать ему прямой выход на владельца — и окажется, что большинство проблем не стоит выеденного яйца. Говоруны/ эксперты менеджмента умеют напускать туману, проводить пафосные презентации и зашибать откаты, а в реальном деле бесполезны. На моей прошлой работе держали одного такого 2 года. 200 кг живого веса, называли за глаза трутнем, проводил бесконечные совещания, 10 раз на дню пил кофе, пилил откаты, рассуждал про «контур учёта материалов». Потом франч, внедрявший УПП за несколько лямов оказался «непорядочным» (номер 1 по размеру франч у нас в стране), инновационный ПМ отправился работать в другой кормушке.
(37) ZLENKO.PRO, это смотря какие франчи. Знаю один франч который в результате такой политики прекратил свое существование. Просто потому что клиенты тоже не с Луны свалились и требуют перед внедрением крупного проекта какие нибудь рекомендации других клиентов. а они ой какие грустные были у других заказчиков. Хоть исполнитель делал всегда то, что хотел заказчик, но не предупреждал о последствиях заказчика.
(39) PiccaHut001, узнаю этот франч (номер 1 по размеру франч у нас в стране) .. отношение к ним аналогичное, там профессианализм сотрудников заменяет откаты
(39) PiccaHut001,
видимо это единственное в чем был прав ваш ПМ ))
чем там проект Доминикана кончился?)
(42) Gureev,
мне тоже интересно
А что делать в маленьком городке, где выбор исполнителей не велик?
(34) Gureev, «Промежуточный результат», то это вообще такое? Я имел ввиду результаты на которых строиться контроллинг: предварительная архитектурная и разработческая документация, прототипы, модели и т.д.
(36) AllexSoft, Задача исполнителя чтобы не потерпеть фиаско довольна проста Завести заказчика в Точку абсурда и там доить…
или нас но за сумму*2 от текущего проекта Об этом и статья!
не знает что его хотелки потянут за собой, доносите это до вашего клиента И вы правы в том, что двигаться к абсурду можно путем умалчивания важных деталей.
(44) antares2010, единственный надежный вариант — это развивать собственные компетенции. Например вы нанимаете исполнителя и сажаете рядом двух студентов, что бы они ему помогали или мешали. Пусть это будет обязательным условием контракта. Это вам выгодно даже если это обойдется дороже…