Стимулирование и мотивация

Владимир Токарев пишет: Я решил поддержать эту шутку Валерий, остаюсь :)))))))))))

Это радует!) Далее комментировать не буду - не мне написано)), но точно поддерживаю конструктивное взаимодействие!) У меня тоже есть интерес: ни ТОС, ни АРИЗ мне не шибко нравятся - знакомилась с ними мельком, решила, что основной принцип ТРИЗ и РМВоК удобнее)), но очень интересно узнать мнение, отличное от моего. Тем более, что Вы взялись применить ТОС к вполне конкретному кейсу. Только я не поняла - результат уже был или результата теперь уже можно не ждать?

Наталья Черентаева пишет: Только я не поняла - результат уже был или результата теперь уже можно не ждать?

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

Владимир Токарев пишет: Но, если нужно не шашечки, то работу выполняет сам клиент, консультант оказывает методическую помощь

- прям заставили меня на время почувствовать себя на 8-9 лет моложе!))) Та консалтинговая компания говорила примерно так: "Инструктор в тренажерном зале не сам садится на тренажер, чтобы клиент смотрел, а учит, как надо заниматься. Мы даем вам методику, учим, а вы делаете сами". Вот только это сравнение мне не нравится. Потому что инструктор в тренажерном зале сам может сесть на тренажер и показать, как надо делать упражнения. В нашем (том, 8-9 лет назад) случае - методику дали, на каких-то общих примерах объяснили - речь шла о регламентации бизнес-процессов. Но ни один бизнес-процесс компании-клиента для реального примера сами не разобрали! А могли бы! Было бы удобнее и проще разобраться. В том случае - мне. Потому что "сам клиент" - в лице начальников отделов той "проектной группы" сказал, что они заняты, работы у них текущей много, а за эту дополнительную им не платят. И я не знаю, появились бы те 35 (или 36?) регламентов работы, если бы это не было интересно мне лично. А так - полгода копалась (не потому, что так сложно, а потому, что практически одна), разбирала шаг за шагом работу всей компании. Компания - численность небольшая, но участник ВЭД, с оборотами в ххх млн.рублей в год. Сначала описала "что есть", потом - видение директора "как надо", потом - чем конкретно одно от другого отличается, т.е. что нужно сделать, чтобы результаты получить. Потом к этому добавили еще регламенты набора и обучения новых сотрудников, планового обучения, аттестации, мотивации и т.д. Не скажу, что все сделала одна - нет, но большую часть - да. Результаты впечатлили. Как дополнительный бонус к навыкам разбора бизнес-процессов - теперь у меня стойкий иммунитет ко всяким "этто невозможно" и т.д. :) А вот вклад тех консультантов - по моим субъективным оценкам... особенно за ту цену... Воздержусь от критики)). Тем более, что основной вопрос - зачем они вообще понадобились?) Может я ошибаюсь, но если бы на некоторые должности назначали по профессиональным качествам, а не по родственным связям, то все было бы совсем иначе... :)

Владимир Токарев пишет: Валерий, предлагаю на личности не переходить

"Предлагаю" ничего мне не "предлагать". Я сам решаю, что, кому, и как говорить. И в отличии от Вас ВСЕГДА готов отвечать за свои слова.

Владимир Токарев пишет: пока Вы не понимаете суть консультационной работы, но мне понятно почему – потому что Вы никогда не работали с настоящими консультантами

Консультанты - ДОСТЛИ!! Откуда вы можете знать кем и когда я работал? Сильно вас расстрою, но деньги, которые мне платили и платят сейчас (правда реже) за консультирование сильно превысят ваше воображение. Так что кто из нас двоих "настоящий" консультант - вопрос.

Владимир Токарев пишет: 1. Валерий принял (нашел) решение своей проблемы. Это уже хорошо.

У меня в компании если до человека не доходят мои слова с ПЕРВОГО раза, второго НЕ БЫВАЕТ. Но здесь из уважение к читателям вынужден повторить мой ответ Токареву (ему не дошло с первого раза).

Валерий Овсий пишет: 1. Найденное мною "решение" на сегодня пока наилучшее (по моему мнению). 2. Я допускаю, что существуют и другие решения, возможно лучше. Но я о них не знаю... 3. Я готов поддержать поиск других/иных решений информационно, т.е готов отвечать на вопросы.

Владимир Токарев пишет: По моему мнению, хорошее решение нашел и А.А.

К сожалению это предложение НЕ ЯВЛЯЕТСЯ решением. Это скорее всего советы на фоне не совсем удачной ассоциации. Если у кого будет интерес я докажу это. То что Токарев принимает ЭТО за решение говорит о его квалификации как консультанта.

Владимир Токарев пишет: Ну что Валерий скажите, будете засылать свои конфликтогены дальше или найдем вариант конструктивного взаимодействия?

Вынужден опять повторять: Я буду делать ЧТО ХОЧУ, что считаю нужным и когда ХОЧУ. Очень мало людей могут повлиять на это. Вы точно не в их числе...

Нежен совет или мозговой штурм для решения задачи стимулирования и/или мотивации сотрудников одного отдела!!

"К сожалению это предложение НЕ ЯВЛЯЕТСЯ решением. Это скорее всего советы на фоне не совсем удачной ассоциации. Если у кого будет интерес я докажу это. То что Токарев принимает ЭТО за решение говорит о его квалификации как консультанта.

Абсолютно верно, был запрошен совет, и мною был дан совет, не являющийся решением. То, что сформулировано без погружения в ситуацию, не может быть "решением", а только "советом". Решением (в моем случае) явилась индивидуальная договоренность с каждым руководителем ИТ-проектов (у каждого различались сильные и слабые стороны, накопившиеся огрехи и достижения, мотивация, уровень авторитета в кругу инженеров и бизнес-заказчиков). Таким образом, мною было проведено в жизнь 5 индивидуальных мотивационных решений, сработавших, в конечном счете, как на задачи проектов, так и на авторитет ИТ-подразделения в целом.

Добавлю.
Каждый заказчик в ИТ - фигура индивидуальная, каждая его хотелка - отдельный "пароход", и каждый ГИП или БА - отдельная планета со своей орбитой.
Все эти отношения сплетаются из человеческих, инфраструктурных и методических нитей, и длящийся хвост этих отношений у каждой компании уникален, он в какой-то мере "виляет компанией".

Да, существуют общие подходы к организации рабочего процесса, но, учитывая вышесказанное, отклонения от этого процесса требуют погружения в этот "хвост", анализа уникального "среза" этого хвоста, если хотите. Соответственно, принятия уникального решения.

Разубедить меня в этом не сможет ни Билл Гейтс, ни Марк Цукерберг, и никто другой, потому что сам прошел это. Более того, движения этого "хвоста" до сих пор доносятся..

Александр Абрамов пишет: Каждый заказчик в ИТ - фигура индивидуальная, каждая его хотелка - отдельный "пароход", и каждый ГИП - отдельная планета со своей орбитой.

К сожалению Вы правы - сложность на каждом шаге! И... К [COLOR=red=red]СЧАСТЬЮ Вы опять правы[/COLOR]. И умение решать проблемы заказчика приносит хороший доход!!! и моральное удовлетворение...

Какие «сложности»:
- «фигуры индивидуальные»;
- «отдельности пароходов и планет»;
- «уникальность хвостов, виляющих компаниями».
И эти «сложности» представляются как имманентно присущие ИТ-производству.

В обычных сложных проектах, между техническим заданием и рабочим проектом есть обязательная ступенька – эскизный проект. ЭП содержит описание комплекса решений по изделию. В РП это описание тонет в деталях-подробностях.

А в ИТ-индустрии, пропуск ЭП (прямой переход от «требований» сразу к кодированию) является, наверное, способом сокрытия устройства ИТ-изделий.
Но, вряд ли надо кидать камень в «жлобство» ИТ-ишников.
Потому что, есть большая разница между знанием устройства материального изделия и устройства ИТ-программы.
Знать устройство материального изделия – не значит суметь его изготовить (тиражировать). Да и «плагиат» в этом случае заметнее.
ИТ-производство (копирование) – практически беззатратное. А к копии можно сделать изменения в интерфейсе «изделие-пользователь» и двигать её как «оригинальное изделие».

И затраты на разработку-изготовление материального изделия, от ТЗ до серийного выпуска, растут в геометрической прогрессии. (Об этом я прочёл в книжке по экономике проектных разработок, лет 30 назад).
А для разработки-изготовления ИТ-изделия – наоборот. Почти все затраты – это разработка. Изготовление – практически бесплатно.

Таким образом, ИТ-ишники специально организуют незнание заказчика в части «устройства» своей продукции.

Кстати, отсутствие ЭП может быть «желательным» и для внутрифирменных отношений.

Так что, почти все рассуждения в этой теме слабо затрагивали суть проблемы.
А решение В.И.Овсия, наряду с положительной простотой (привязка премии к прибыльности проектов) содержит и отрицательные сложности (реальные потребности разработчиков обеспечиваются не прямым а косвенным образом).

Тем не менее, из этой темы я понял, что решение В.И.Овсия будет более адекватным сложившимся реалиям ИТ-производства. Потому что, «революций (с внедрением ЭП в ИТ-производство) – не надобно». Их последствия – для «революционеров» – однозначно отрицательные.

Разъясню о сложности параходов и планет, в ИТ.

(1) не всякий руководитель готов слушать "бредни" ИТ-шника о длительности аналитической фазы большей, чем самому руководителю представляется. Как же, "ведь надо сделать всего табличку 3х4, чего тут думать!" Вряд ли строителям приходилось слышать предложения от заказчика объединить в одном лице прораба и инженера по технадзору (переводя на строительную терминологию), для сокращения ФОТ, а мне приходилось.
(2) работа строительной компании зарегламентирована и хорошо известна, тогда как в ИТ существует достаточно много подходов к проектированию и разработке. Если человек долго работал пр одной методике, ему нужно приспосабливаться к другой.
(3) одну из сложностей поднял автор темы: сложно однозначно осметить работу, "я сделаю эту работу из семи дней! - а я из трех!", и кому верить? Может, надо дать десять? Или вообще не браться за нее? Тогда как в строительстве все знают, какие примерно сроки производства и нормы рентабельности в работах по кровле, дорогам или водоснабжении. Потому что там физические объемы, а в ИТ физического объема НЕТ.
(4) завязанность системы на отдельно взятого человека - ее автора. Чтобы эту завязанность минимизировать, приходится тратиться дополнительно. А то знаете, вплоть до того, что всплывают разные закрытые внешние модули, ответственные за ключевые вычисления. Логические бомбы даже всплывают, видел и составлял акт. Но я больше о том, что человек знает историю системы, предпосылки возникновения ее отдельного блока. Бывает, что блок присутствует в системе только потому, что исторически так сложилось, а сейчас он никому не нужен, но все с этим блоком вынуждены считаться. Например, адаптация данных к определенному формату внешней программы-получателя. Может "внезапнэ" выясниться, что программа-получатель уже не используется. А в строительстве не бывает, чтобы резко стал не нужен например, лестничный пролет, между вторым и третьим этажом.
(5) желание отдельных представителей на стороне заказчика протолкнуть своих исполнителей: "а вот мой племянник Петя - делает гораздо лучше!" - источник палок в колеса, в текущей работе.
(6) часто требуются уникальные компетенции, для налаживания "мостов" между разными модулями. В строительстве конечно, тоже, но в ИТ каких только реликтов из 90-х я не навидался, а в них лежат данные, к ним надо писать интерфейсы.
(7) одна и та же проблема в ИТ может быть решена бОльшим количеством разных способов, в отличие от лестничного пролета между 2 и 3 этажами.
(8) придя на проект, в его промежуточной стадии, ГИП в ИТ часто сталкивается с тем, что НЕТ проектной документации, НЕТ рядом прежнего ГИП, и значительное количество персонала закзачика саботирует проект.
(9) Следует из (8), ИТ редко когда возникают на пустом месте, системы чаще отпочковываются либо трансформируются. Саботажников этому процессу - уйма. Саботажников процессу строительства нового офисного здания - я никогда не видел.
(10) Отдельная боль - ведение проектной документации, в небольших ИТ-компаниях и тем более ИТ-подразделениях компаний. Скажу: я никогда не видел систему, где присутствует актуальная проектная документация не то что по всей системе, а даже по ключевым блокам. Скажу больше: я сам, в бытность Ит-внедренцем-"одиночкой", создавал системы без проектной документации, т к никто не платит за нее (одна из систем, к слову, используется 11-й год - производственный бизнес).

Я не говорю, что всё это неуправляемо, в ИТ, как и везде - регулярный менеджмент. Просто доля "параходов и планет" в нем довольно велика. И я всегда голову клал на то, чтобы разъяснять бизнес-заказчикам специфику (надо же как-то было обосновывать новые ставки в ШР), никогда секретов не делал из своей работы.

Владимир Токарев пишет (7.11.13 22:34): ... Но и работа не оплачивается. Потому все справедливо.

Может скинемся? Очень интересно, чем конкретным закончилось эпохальное деяние - изучение ТОС Владимиром Фёдоровичем.

"А в ИТ-индустрии, пропуск ЭП (прямой переход от «требований» сразу к кодированию) является, наверное, способом сокрытия устройства ИТ-изделий."

Строго наоборот.

Рассказать (задокументировать) о том, как устроено изделие, будет рад любой ИТ-шник. Только, денег на это ему не дадут, потому что "племянник Петя может и без документации!". И это чистая правда! Я упомянул систему, созданную 11 лет назад, без единой строчки документации. Общаясь сейчас с этим же предприятием, поставлен вопрос: "может, хотя бы сейчас задокументировать? А то программист, принявший ее 11 лет назад, уже состарился! :) ". Но, зачем это делать, если всё и так работало 11 лет?
Если строительной компании не поздоровится, буде она допустит огрехи в документации, и обе стороны это понимают, то применительно к ИТ-проектам, этот вопрос пускается на самотек прежде всего, заказчиком. И этот же заказчик - в первых же рядах рубит шашкой, когда случилась проблема, а о системе никто не знает: "почему не настояли на своем, что нужна документация? Почему не переубедили?!".
Нельзя ИТ-подрядчику быть "заказчиком" больше, чем таковым является заказчик.

Конечно, мои рассуждения касаются ИТ-подразделений компаний, и мелких и средних ИТ-компаний, а не отраслевых лидеров, как у автора темы.

Александр Абрамов пишет:...(1) не всякий руководитель готов слушать "бредни" ИТ-шника о длительности аналитической фазы большей, чем самому руководителю представляется. Как же, "ведь надо сделать всего табличку 3х4, чего тут думать!"...

Более того (сюжет для спектакля), уже встречаются "руководители" подразделений ИТ, которым это не интересно. Разве в МВА есть отраслевая специфика (говорят, что степень МВА - пропуск в высшее управление). С другой стороны. Искусство управления заключается в управлении исполнителями. Стоит ли разбираться в тонкостях исполнительских технологий? Думаю, что ВСЕ ответят - не стоит. Тогда, простите, какого черта от меня требуют подробных объяснений, из чего складывается стоимость моей работы, если в этом объяснении ничего не понимают? А как же, ведь нужно ДЕМОНСТРИРОВАТЬ, что процесс под контролем. Поэтому тему обсуждения я воспринимаю как управленческую, НО!!! Сегодня невозможно быть хорошим "безотраслевым" руководителем. Слишком усложнились технологии и слишком велика цена риска. Возможно, именно это обстоятельство играет свою роль в негативной оценке консультантов, которые учились "на консультантов".

Продолжу анализ замечаний В.И.Зонзова

А в ИТ-индустрии, пропуск ЭП (прямой переход от «требований» сразу к кодированию) является, наверное, способом сокрытия устройства ИТ-изделий.

...так, на это уже ответил :)

ИТ-производство (копирование) – практически беззатратное. А к копии можно сделать изменения в интерфейсе «изделие-пользователь» и двигать её как «оригинальное изделие». [...] А для разработки-изготовления ИТ-изделия – наоборот. Почти все затраты – это разработка. Изготовление – практически бесплатно.

Абсолютно не так. Основные затраты в ИТ - по крайней мере, в управленческом ИТ - это ВНЕДРЕНИЕ, это 90% бюджета проекта и сожженных нервов. Это адаптация уже готового продукта к реалиям отдельно взятого бизнеса, что важно, с соблюдением преемственности накопленных данных! Адаптация - всеобъемлюща, достаточно сказать, что нет двух компаний, где справочник "Номенклатура" ведется одинаково. Самая жесткая компания, в плане вариативности бизнес-процессов, из моего опыта - это санаторий. Пространство решений в организации БП, там существенно уже, чем в торгово-производственных компаниях, то есть казалось бы, ставь и включай. Поставщиков такого ПО в РФ - единицы, и эти пакеты - всеобъемлющи, внедрение заключается во включении-отключении отдельных опций в консоли настроек. Поставщики прямо заявляли: "мы продаем ПРОДУКТ", вместо традиционного: "мы ВНЕДРЯЕМ СИСТЕМУ". Но и с ними, возникали планеты и пароходы, вплоть до судебного разбирательства. Ключевое отличие ИТ-системы от объекта строительства в том, что это "человеко-машинный комплекс", и из него проистекают все норкинские "трассы слалома, хвосты и орбиты". Затраты на разработку у В.И.Овсия уже давно окупились (основного ядра), а в тиражных решениях например от 1С, эти затраты составляют мизерную часть от всего проекта (и то, идет не разработка, а оплата готового разработанного тиражного ПО). В случае внедрения готового ПО, документированию подлежат: (1) алгоритмы переноса данных (2) отклонения от типовых функций и регистров учета. Заказчику это НЕ НУЖНО (тем более, за деньги).

Кстати, отсутствие ЭП может быть «желательным» и для внутрифирменных отношений.

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

Так что, почти все рассуждения в этой теме слабо затрагивали суть проблемы.

Тем не менее, из этой темы я понял, что решение В.И.Овсия будет более адекватным сложившимся реалиям ИТ-производства.

Признаться, не уловил его, пойду перечитаю тему...

Наталья Черентаева пишет: заставили меня на время почувствовать себя на 8-9 лет моложе

Это здорово. А по сути: 1. Не вижу необходимости доказывать, что процессное консультирование эффективно, так как это классика. Могу только рассказать про конкретный наш опыт на конкретном примере.

Валерий Овсий пишет: Если у кого будет интерес я докажу это.

У меня есть интерес, расскажите.