Чой-то меня на нетленку потянуло

[sfy]

Как распоследний лох решил написать наставление говноконсалтерам, чтобы они были не таким уж говном. Это дип-дип драфт, так, на поржать. Если куражу хватит, будет что-то вроде Нагорной проповеди. Истинно говорю вам!

Краткое пособие консультанта

Прелюдия

Я видел столько дерьмовых консультантов, что ой. Собственно, эта краткая памятка для тех, кто хочет не быть дерьмовым консультантом. Надеюсь, это будет полезно и хорошим консультантам. А кто-то ещё что-то добавит, и дальше распространит. Я – только «за».
Для Заказчиков. Консультанты (я имею в виду нормальных) – очень полезные люди. Не надо их путать с коучами, которые реально на 99% - шарлатаны. Консультанты владеют полезными методиками и знают то, что на их консалтерском птичьем языке называется «best practices». То есть, опыт тех, кто уже прошёл по аналогичным граблям и вышел из неравного боя без особых повреждений.
Основные правила
Главное правило. Если Вы считаете, что знаете бизнес заказчика лучше него самого, Вы – негодный консультант. Вы только что пришли в кожаном пальто с горы, а заказчик этот бизнес строил. Слушайте, вникайте. Выясните, кто является реальными ключевыми фигурами, кто управляет бизнес-процессами, добейтесь встречи и внимательно слушайте их. Это значительная часть успешного проекта.
По каждому разговору СРАЗУ, не откладывая, делайте minutes of meeting – конспект интервью, с обязательной фиксацией всех контактов визави. А вот диктофон – штука вредная, не советую.
И, не удивляйтесь, Вам надо уметь говорить с заказчиком на одном языке. Очень хорошо иметь профильное высшее, но так бывает не всегда, да и маловато этого будет. Поэтому и учатся индустриальные консультанты годами. Да, вообще-то, постоянно.
Все методики, которые Вы знаете, говно и ноль по сравнению с реальной жизнью. Это костыль, который можно и нужно применять для первичного моделирования, но для окончательных рекомендаций – ЗАБУДЬТЕ. То есть совсем всё. eTOM, ITIL, MOF, KPI и BSC – это Ваш словарь, Ваши методики и просто средство для упорядочения собственных мозгов и общения с коллегами. Заказчику это всё нафиг не надо.
Всегда, я повторю, ВСЕГДА до начала проекта пишите и согласовывайте его устав. Что это такое? Да просто разграничение работ и ответственности сторон, сроки и измеримые результаты. С каждой стороны должен быть куратор, обладающий достаточными полномочиями, чтобы привлекать ресурсы, менеджер для общего руководства и рабочая группа. Со стороны консультанта обязателен главный инженер проекта (он же технический руководитель, он же – ответственный за quality assurance). В качестве аналогии ГИП проекта – режиссёр, ПМ проекта – директор фильма. Понятно разделение обязанностей?
Выходной документ в большинстве случаев содержит разделы AsIs, ToBe и ToDo. Что это такое? Очень просто.
AsIs содержит текущее состояние, с обязательным подразделом «выявленные проблемы». Если не умеете строить графы «анализ первопричин» - срочно научиться, это не сложно. Вот эти самые выявленные ключевые проблемы предстоит порешать. И не забывайте согласовывать всё это с представителями заказчика. Вы могли не так услышать или понять. Это Ваша техника безопасности, а её надо знать, как свои три пальца.
ToBe – часть мечтательная. Это те райские кущи, которые Вы считаете идеальными для заказчика. По опыту, полностью не реализуется никогда.
Но мечтать надо в меру. Один мой знакомый дерьмовый консультант написал в требованиях к работнику колл-центра оператора связи «высшее профильное образование» вместо логичного «хороший разговорный язык, психологическая устойчивость, умение пользоваться FAQ и средствами маршрутизации звонков».  Так делать не надо.
Если не владеете SWOT-анализом – вешайтесь. Но разумнее им овладеть, он прост, как дверь, но помогает замечательно формулировать цели и задачи, а также первично  оценивать риски. Это реально работающий, и при этом простой, инструмент.
ToDo. Если всё делать честно, самая сложная часть. Это пакет проектов, которые надо выполнить, чтобы из AsIs сделать ToBe. С оценкой стоимости, времени и последовательности выполнения, экономической эффективности. Требует очень серьёзной профессиональной подготовки. Не надо недооценивать этот раздел. Это самое важное для заказчика и самое сложное для консультанта.
Маленькие советы
Не все стандарты плохи. Внимательно почитайте стандарты ЕСПД и ИС. Особенно на ТЗ и техпроект. Сделайте себе темплейт на их основе (удобное оглавление) и наслаждайтесь.
Полезен также универсальный стайлшит, обязательный к использованию в команде. Любой ГИП оценит удобство такой простой стандартизации.
Никогда не выбрасывайте материалы проектов. Никаких. Ни финальных материалов неудачного проекта, ни даже промежуточных материалов. Никогда.

Байки
ту би риттен


 

Comments

Дополню маленько

[dmarck.livejournal.com]

... хотя для не-разработчиков это и будет выглядеть диковато

Внедрите сами, или организуйте средствами доверенных подрядчиков внедрение какого бы то ни было SCM и ведите проекты в нём, автокоммиты можно делать, можно не, главное, что будет хоть какая история проекта, которую потом можно будет проанализаровать и прокоррелировать с прочими

Re: Дополню маленько

[sfy-y.livejournal.com]

Да, это специфично. Я пока ещё не сформулировал, как правильно написать, что для заказчика "объект" и "атрибут" млгут означать совсем не то, что для разработчика ИС, а ты про SCM. :)

Re: Дополню маленько

[dmarck.livejournal.com]

А это ортогонально. Хоть, прости Г-ди, если фалов мало, RSC с еженощными коммитами (прозрачными для всех, никто ничего не знает) -- феерически помогает, в особенности при разборках.

Re: Дополню маленько

[sfy-y.livejournal.com]

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

[kukmor.livejournal.com]

все верно
как консалтер говорю =))))

[sfy-y.livejournal.com]

Привет, коллега. :) Я ещё буду дотачивать, как настроение соответствующее появится.

А добавления/замечания е? (ясное дело, подвал участников - будет)

Можно поучаствовать?

[airmak.livejournal.com]

Юрий. Привет Вам. Решил отписать по этой теме, если можно.

Мне кажется, нужно в начале опуса написать про цели, поскольку правильно все делать при неправильных целях означает решать не ту задачу. Посему в начале нужно четко сформулировать и согласовать с заказчиком цели проекта.

Re: Можно поучаствовать?

[sfy-y.livejournal.com]

Нужно. Профессии консультанта нигде не учат. Попробуем опыт обобщить?

Да. Надо будет это явно добавить в пункт об уставе проекта. Хотя обычно цели и задачи есть в контракте и, конечно же, в отчёте.

[airmak.livejournal.com]

В отчете уже поздно. В уставе еще можно. Чем раньше, тем лучше. Без правильных целей проекту смерть.
Опытом поделюсь, тем более его очень много... :)

Re: Можно поучаствовать?

[sfy-y.livejournal.com]

Согласен. Там я упомянул про измеримые результаты, расшифрую. И усугублю необходимость согласования устава.

Дык. ;)

[airmak.livejournal.com]

Тогда поехали дальше -
1. Цели определяются только при общении с непосредственным заказчиком проекта, т.е. тем руководителем, который все это и затеял (ну если конечно он это затеял не для известных делишек). Послушайте его, послушайте тех, кто ниже по иерархии управления, сформулируйте и согласуйте с топом.
2. Цели могут быть неизмеримыми и довольно высокоуровневыми. Измеримыми должны быть результаты. В этом разница. А для детализации целей на прикладной уровень существуют задачи. Поэтому - Цели и Задачи.
3. Ну и на сладкое. Не найдете ни в одной методологии: Не забывайте для себя о СКРЫТЫХ ЦЕЛЯХ, и тут я говорю не об откатах, будь они не ладны. :) Скрытые цели - это всего лишь те цели, которые нельзя озвучить официально. Они всегда есть. Например, заказчик хочет сократить пол штата (ох и не люблю я такие скрытые цели), или еще проще - получить больше влияния в компании. Их (скрытые цели) в договор и в устав писать не надо. Но их надо понимать.

Пример - в политике люди всегда анализируют скрытые цели, а не публичные. А в консалтинге про это забывают.

Ну пока хватит...

[sfy-y.livejournal.com]

1,2. Согласен. Это и написал уже в текущей версии. Пожалуй, сформулирую ещё отличие целей от задач, их часто путают.

3. Я пишу, только в завуалированной форме. Типа "сокращение эксплуатационных затрат", "повышение эффективности управления". :)

[airmak.livejournal.com]

Продолжу.

Если Вы менеджер (или рук. проекта - ПМ), то ищите ГИПа (в консалтинге это иногда называется технический лидер проекта, в проекте с инженерной составляющей - ГИП), то есть сильного специалиста, который ответит за все решение в целом. Ключевое слово - СПЕЦИАЛИСТ. То есть - либо ГИП - Вы сами (но совмещать роли ГИПа и ПМа реально сложно и не очень правильно), либо ГИП - другой человек, но он должен быть. Не бывает, что куча молодых и не очень опытных консультантов сделает проект чудесным образом, прочитав кучу говнометодик от большой 4-ки. Они все завалят еще на уровне обследования. Ну либо позже...
Знаете, что такое менеджмент по шведски (не уверен, что это так называется, но слышал так)? Это когда куча ничего не понимающих в предмете людей пытаются решить вопрос путем собирания последовательности совещаний с расширяющимся с каждым разом составом. Это делается для единственной цели - обнаружить СПЕЦИАЛИСТА. Как только в составе совещающихся появится СПЕЦИАЛИСТ (ну тут чистая вероятность, или удача) - это тут же станет ясно, поскольку он сразу пошлет всех нахер и начнет делать то, что нужно, а не бесплодно базарить. Это и есть ваш ГИП.

[sfy-y.livejournal.com]

Тэк-с. Либо надо формат менять, либо это - из другого документа, более подробного и серьёзного.

Наверное, так и надо сделать. Короткий стёбный и отдельно - пошаговая инструкция. У меня руки зачесались написать пошаговую инструкцию по кик-оффу проекта.

Re: Можно поучаствовать?

[evt-av.livejournal.com]

Цели и задачи обычно есть в контракте, и обычно они там совершенно неправильные :-)

Самое важное:
- цели и задачи должны быть правильно сформулированы. Целеполагание - самое слабое место у российских топ-менеджеров. "Целью внедрения информационной системы является автоматизация процесса" - это не цель ни разу;
- цели и задачи должны одинаково пониматься обеими сторонами.

Re: Можно поучаствовать?

[sfy-y.livejournal.com]

Совершенно верно. И распространённое заблуждение, что при внедрении ИС ничего не придётся менять в бизнес-процессах.

Re: Можно поучаствовать?

[evt-av.livejournal.com]

Изменение бизнес-процессов -- одна из целей внедрения ИС :-)

Re: Можно поучаствовать?

[sfy-y.livejournal.com]

Нет. Это одна из задач, решаемых в процессе оптимизации деятельности.

[supereye.livejournal.com]

Юр, в копилку.
Совмещение ГИПа и ПМ на крупном проекте - крайне нежелательно, ибо перегружает этого ГИПпоПотаМа и отрицательно влияет на качество проекта.
В устав проекта обязательно:
- регламент обмена материалами
- регламент согласования документов

P.S. И давайте быть честными, консалтер крайне редко работает с создателем бизнеса, обычно с наемным персоналом у которого, свои интересы и которому важно, чтобы ему комфортно работалось, иногда в ущерб бизнесу компании в целом.

P.P.S. Для мелких проектов устав можно и не писать, но тогда нужно аккуратно прописывать обязанности сторон в договоре.

[sfy-y.livejournal.com]

Ага, это уже обсудили. :)

PS - это для крупняка, с которыми ты дело имеешь. У меня уйма друзей, (особенно ITSMщиков), для которых это не так. ;) Впрочем, про _скрытые_ цели тоже уже перетёрли.

PPS. Можно, но тогда надо использовать простой темплейт с типовой функционально-ролевой моделью. В контракте же всё на уровне заказчик-исполнитель, этого мало.

[airmak.livejournal.com]

Наверное, Макинзи общается и с владельцами. Ну или стратегические консультанты.
А технари конечно с наемным. Хотя мне приходилось и с владельцами (из первой соточки :) ). Но редко...
С гендирами чаще. И я не ITSM щик. Свят - свят.

По уставу - абсолютно согласен. Оба пункта крайне важны.

[sfy-y.livejournal.com]

У меня дочка в PWC три года отпахала (потом ушла в ритейл и теперь блаженствует), ну и много знакомых, которые четвёрку прошли.

Прошли времена, когда там были реально хорошие команды. Вот в ISG была _реально_ крутая команда, пока адмресурс не потерялся. Правда, спылесосили весь рынок труда, но как же легко было работать... Собрать команду - как два пальца об асфальт, причём реально спецов, которые в иной фирме только ГИПовали б, лучшая команда ПМ (трое - ClassC).

Дима (supereye)помнит, какие там ресурсы были в лучшие времена...

[airmak.livejournal.com]

Ну PWC консультанты и PWC аудиторы - разные вещи. Вы сейчас о ком? Да и не в PWC дело...

[supereye.livejournal.com]

Юр, у нас и ClassB, и ClassA (правда насколько я понимаю, в одном экземпляре) был.

[airmak.livejournal.com]

ClassA,B,C. Что это? :)
Какие-то дьявольские символы.

О господи. PMI