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

Валерий Овсий пишет: Если завтра Вы мне дадите чудесную таблетку и мне удастся ею скормить бизнес аналитиков и они начнут работать быстрее то.... Ничего не произойдет!! Просто проблема переместится в другой процесс общего бизнес процесса компании, но на мой взгляд может быть решена проще.

Это - хороший знак. Когда хотелкин носитель не слышит вопросов, или, читая вопросы не отвечает на них прямо и просто, то значит дело гораздо хуже, чем я думал в начале. И как я понимаю, Валерий Иванович это понимает тоже. Повторять прежние вопросы мне лень. Ставить новые - не вижу смысла. Полежу, подожду, скоро припрет к гландам вся эта посиделко-говорилкина муть и будет веселее. А доля из 10-20 %% - это уже интереснее. В этом плане мне нравится Дворжецкий в фильме "Возвращение "Святого Луки". Он, как и всякий профессионал точно знал себе цену.

Сергей Норкин пишет: Что такое ожидает меня, ежели включившись "по-взрослому" и "со всей звериной серьезностью" ...?

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

Валерий Овсий пишет: К сожалению не знаком! Я имел ввиду Banking Industry Architecture Network (BIAN)

Беру назад свои слова о том, кто более уважаем - я-то имел в виду Bain & Company - top management consulting firm.

Проблемы: 1. Бизнес аналитик ВСЕГДА занят и не хочет брать новую "хотелку" банка и с ней возиться. качество его работы, документ "Требования" оставляет желать лучшего. 2. Системный аналитик ВСЕГДА занят и не хочет брать новую Задачу. Ссылается на плохой документ "Требования". 3. разработчик - почти то же самое. Сразу скажу, что объединить их "в одну команду" практически невозможно, они и так в "одном" проекте. Количество заказов в очереди очень большое. Банки требуют очень быстрые экспресс-анализы. Не все "хотелки" после анализа превращаются в "деньги".... Как стимулировать и мотивировать ТАКИХ сотрудников???

Какие проблемы испытывает бизнес, в итоге? Действительно ли низкое качество документа "требования" - есть следствие именно нежелания БА брать новую хотелку в проработку? Не возникало ли обратной мысли? что, быстро сдав (спустя рукава, да) очередное "Требование", БА сможет затянуть под себя новую хотелку? (заработав с нее денег). В большом количестве хотелок, он может ли притормаживать те, которые наименее выгодные для него, или для тех, кому он формирует фронт работы? (системным аналитикам, разработчикам). В оконном производстве рабочим у станков часто платят за квадратные метры выпущенных готовых конструкций; таким образом, они хотели бы делать окна только: "квадратные, глухие, максимальной площади". Им не интересно делать более сложные (и более маржинальные для компании) конструкции. Поэтому, существовали разные схемы стимулирования: на количество "углов" в готовой конструкции (угловых сочленений профиля). Самое простая конструкция - глухое окно - имеет 4 угла; конструкция с одной распашной створкой - 8 углов; распашная конструкция с фрамугой - 12 углов. Соответственно, сколько "углов" (а не метров!) сдал в единицу времени - за столько получи оплату. Можно ли вывести закономерность в выборе бизнес-аналитиком наивысшей квалификации хотелок? Сколько он берет хотелок, и каких? (1) он с удовольствие берет одну в месяц, со сложностью 10/10. (2) он возьмет четыре в месяц, со сложностью 5/10. (3) он с удовольствием возьмет двенадцать в месяц, со сложностью 2/10. Какая стратегия (1)-(3) позволит ему заработать больше? - по официальным каналам - по неофициальным каналам (например, получить подношения от тех сотрудников, кому он формирует фронт работы: "давай мне много простых задач", "давай мне только сложные задачи") Далее, какие проблемы испытывает компания: - получает меньше выручки (от недообработки хотелок) - несет больше издержек (высокооплачиваемые разработчики занимаются низкомаржинальными работами) - разработчики бунтуют (загружены "всякой "ерундой, вместо серьезных задач") - заказчики высказывают недовольство тем, что часть их хотелок отсекается - репутационная проблема

Валерий, так как Вы совершенно трезво не ждете готового решения, при этом выразили готовность отвечать на любые вопросы, предлагаю Вам ответить на следующие (на мой взгляд, Ваши ответы на них могут способствовать прояснению причин проблемы). Я прочитала всю дискуссию и вот вопросы, которые появились: 1. В некоторых случаях или в большинстве случаев бизнес аналитик может получать вознаграждение за «превращение «хотелок» в «Требования» очень отсрочено (например, через несколько месяцев)? Это уточняющий вопрос возник из «бизнес аналитик может закончить свою работу в январе, а установка в банке и оплата - в декабре. Он уже и забыл про этот проект». 2. Почему, на Ваш взгляд, задача бизнес аналитика непривлекательна? В чем основные причины непопулярности этой работы: а) необходимость общения с заказчиком (дополнительные «эмоциональные затраты»), b) последующие сложности при переговорах с коллегой системным аналитиком, c) отсутствие влияние бизнес аналитика на конечный результат (работу разработчика), d)уровень технической сложности данного вида работы (несложный-слишком сложный); возможно что-то еще? 3. Вы считаете, что выраженная профессиональная мотивация «на первом месте престиж, значимость, новизна и возможность повысить свою "рыночную стоимость"» свойственна подавляющему большинству ваших сотрудников? 4. В целом уровень заработной платы сотрудников, выполняющих задачу бизнес-аналитика, превышает уровень зар. платы работников, не выполняющих данную задачу? 5. Есть ли в вашей организации проблемы с текучестью персонала: увольняются ли сотрудники, проработавшие продолжительный период времени и обладающие высокой квалификацией; увольняются ли вновь прибывшие работники? Насколько эти показатели критичны, на Ваш взгляд? 6. Сколько человек – руководителей подразделений? Сколько человек руководителей проектов (понимаю, что это нестатичная цифра, но вероятно не каждый сотрудник может быть руководителем проекта, а существует некий «пул» сотрудников, которые наиболее часто становятся руководителя проектов)?

Валерий Овсий пишет: . Если два руководителя не могут договориться о решении пограничной (их зон ответственности) проблемы они ОБЯЗАНЫ сформулировать КАЖДЫЙ свое мнение и ЭСКАЛИРОВАТЬ проблему вышестоящему руководителю. Это руководитель выслушивает (обычно прочитывает в офисной системе) мнение каждого и Обязан!! принять решение

Это вышестоящий руководитель - всегда Вы? (Это предположение, не исключаю, что неверное). 8. Вы предпринимали попытку обсудить данную проблему с руководителями подразделений и руководителями проектов? Если да, то к каким предварительным решениям вы коллегиально пришли? Если не обсуждали, то почему? 9. На Ваш взгляд, общее количество работников организации достаточно для ее «идеального» функционирования, т.е. качественной реализации задач всех уровней?

ПризнаЮ избыточность своих вопросов о том, какие проблемы испытывает компаниях.

Конечно, трудно кратко и вместе с тем полно изложить проблему. Поэтому, моё решение исходит из моих представлений; а значит, не совсем соответствует реальной проблеме.
Валерий Иванович говорит, что он хочет свести проблему к задаче управления персоналом, а не к организации и технологии работ. По моему пониманию, её нельзя так сводить. На этом мне и нужно замолчать. Потому что, глупо отвечать то, что не спрашивают.
Но, думаю, что проблема изложенная на примере «отчёты» – не уникальна. Поэтому, всё же, скажу.

Начну с понимания того, что будет далее считаться проектом.

Есть 2 варианта:
- Проект – это отдельное задание заказчика.
- Проект – это все задания отдельного заказчика

В фирме В.И.Овсия выполняется 200 проектов в год. А заказчиков тоже 200?
– Вряд ли. Значит, понимание проекта – по первому варианту. А это значит, что и руководителей проектов 200?
– Да, конечно меньше. Руководители проектов работают как многостаночники. У каждого – по десятку проектов.

Далее.

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

Таким образом, руководитель проекта – это единый «преобразователь» ВСЕХ «хотелок» отдельного заказчика в исходные данные. Утверждение, что-де, нет и не может быть «одного грамотея на всё и всех» – это «управленческий сбой». Есть такой «грамотей». Называется он «эскизный проект». ЭП, разрабатываемый под руководством руководителя проекта, является:
- результатом понимания «хотелок» заказчика;
- источником исходных данных для работы всех «узких» проектировщиков, в разработке РП;
- изложением основных решений по проекту.
Поэтому, все дополнительные «хотелки» заказчика должны пониматься и выполняться в контексте ЭП. Вполне возможно, что некоторые «хотелки» могут потребовать определённой переделки ЭП. Даже хуже. Переделки могут быть настолько значительными, что потребуют изменений в полном диапазоне проекта – от исходных данных до реализации РП. Но, в любом случае, «хотелки» заказчика – это изменения в ЭП (дополнения-корректировки).

Ещё важно отметить, что при отсутствии ЭП, знания о проектируемом и создаваемом объекте распылены по большому количеству участников проекта. Что приводит к невозможности автономной работы отдельных специалистов. Потому что, для решения вопросов, затрагивающих смежные части проекта, приходится собирать совещания. Но, таких вопросов бывает очень много. Значит, заседать придётся всем и постоянно. А работать когда? Единственный выход – знания должны быть изложены в письменном виде; и изложение должно быть упорядоченным. Этим требованиям и отвечает ЭП.
ЭП и есть ответ на странную апелляцию, что-де, нет одного человека, который знал бы весь диапазон работ банка. А при создании материального объекта иначе? Например, ЭП создания сложного материального объекта может представляться многотомником, с двузначным количеством томов. И там никто не страдает от отсутствия «одноликого грамотея». Никто не представляет неизбежно возникающие [COLOR=gray=gray](в процессе создания или эксплуатации материального объекта)[/COLOR] изменения-дополнения, как отдельные проекты, не связанные с ЭП.

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

[COLOR=gray=gray]Совокупность ИТ-средств банка - это, по сути, информационная модель банка. и лучше, если её проектируют и сопровождают свои сотрудники, а не подрядчики со стороны. Какими бы ни были сложными, инструменты поставляемые сторонними разработчиками, они всё рано - только часть единой ИТ-модели банка.
[/COLOR]
Повторяюсь. Любые изменения-дополнения, сначала должны учитываться в ЭП (а, если потребуется, и в ИД), и только затем идти в стадию РП.
При таком подходе, заказчика не будут осаждать толпы «руководителей проектов», … .
И разработчики дополнений будут обеспечены контекстом ожидаемых от них разработок. Что значительно уменьшит, для них, трудность разработок. А часто сделает их очевидными. Например, в некоторых программах, необходимость бесконечных автоматизаций создания отчётов исключается наличием языка запросов (SQL)

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

[COLOR=gray=gray]Думаю, что я недостаточно ясно представляю проблему, чтобы кратко, за один раз, изложить своё решение[/COLOR].

Александр Абрамов пишет: Какие проблемы испытывает бизнес, в итоге?

Недополучение прибыли.

Александр Абрамов пишет: быстро сдав (спустя рукава, да) очередное "Требование", БА сможет затянуть под себя новую хотелку? (заработав с нее денег).

Да. Именно так.

Александр Абрамов пишет: В большом количестве хотелок, он может ли притормаживать те, которые наименее выгодные для него, или для тех, кому он формирует фронт работы? (системным аналитикам, разработчикам).

Да, может. Но ему не всегда прозрачна "выгода". Как я писал раньше бюджеты проекта определяет внутренний инвестор (это в основном я) и не связанно с ценой проекта для Баенка-заказчика. Такой подход уравнивает выгоду исполнителям.

Владимир Крючков пишет: Можно ли вывести закономерность в выборе бизнес-аналитиком наивысшей квалификации хотелок?

Очередность обработки заявки не всегда определяется БА. Есть "высшие силы" - бизнес компании.

Александр Абрамов пишет: Сколько он берет хотелок, и каких?

Заявки попадают в "стек" аналитика и очередь формируется автоматически. Конечно он может "начать" несколько проектов одновременно. Тогда заявки убираются из очереди-стека "ожидания" и попадают в категорию "на исполнении".

Александр Абрамов пишет: Далее, какие проблемы испытывает компания: - получает меньше выручки (от недообработки хотелок) - несет больше издержек (высокооплачиваемые разработчики занимаются низкомаржинальными работами)

Да!

Елена Казарина пишет: В некоторых случаях или в большинстве случаев бизнес аналитик может получать вознаграждение за «превращение «хотелок» в «Требования» очень отсрочено (например, через несколько месяцев)?

В НЕКОТОРЫХ - да. НО чаще через 1-2 месяца.

Елена Казарина пишет: Почему, на Ваш взгляд, задача бизнес аналитика непривлекательна?

Я это не говорил. Если такой вывод Вы сделали на основе моих текстов, то я исправлюсь ))

Елена Казарина пишет: Вы считаете, что выраженная профессиональная мотивация «на первом месте престиж, значимость, новизна и возможность повысить свою "рыночную стоимость"» свойственна подавляющему большинству ваших сотрудников?

Это мое экспертное заключение :-)). Исследования не проводились.

Елена Казарина пишет: В целом уровень заработной платы сотрудников, выполняющих задачу бизнес-аналитика, превышает уровень зар. платы работников

Руководители проектов могут (не всегда) заработать больше. Вообще Бизнес-Анлитики это ЭЛИТА компании, вместе с системными-аналитиками образуют "мозги" компании.

Елена Казарина пишет: Есть ли в вашей организации проблемы с текучестью персонала:

Есть, но ниже чем у других...

Елена Казарина пишет: а существует некий «пул» сотрудников, которые наиболее часто становятся руководителя проектов)

Да!

Елена Казарина пишет: Это вышестоящий руководитель - всегда Вы?

Я НЕЙвысший :-)) есть еще один слой ниже.

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

Проблемы управления обсуждаются всегда с топами. Решение принимаю я. Сейчас есть то что есть.

Елена Казарина пишет: На Ваш взгляд, общее количество работников организации достаточно для ее «идеального» функционирования, т.е. качественной реализации задач всех уровней?

Здесь следует разделять "оптимальное" функционирование компании от "качественной реализации". Для "качественной" - требуется значительно больше, но это дороже.

Валерий Овсий пишет: Компания около (есть фриланс) 200 человек

Это, конечно, не мое собачье дело, но заинтересовала такая высокая диспропорция: на 65-82 сотрудников основного производственного персонала:

1. У меня Бизнес аналитиков 15-20 (есть совмещение) 2. Системных аналитиков 10-12 (совмещения) 3. Разработчиков 40-50 (совмещения)

приходится (делаем арифметическое вычисление) от 118 до 135 человек АУП и всяких служб? Для проектной организации вроде многовато? Или в общую численность входит еще другой бизнес? Если нет, то половину можно сократить. :-))

Владимир Зонзов пишет: Есть 2 варианта: - Проект – это отдельное задание заказчика. - Проект – это все задания отдельного заказчика

Проект - чаще (в основном) отдельное задание Заказчика. У одного банка может быть несколько проектов, несколько руководителей проектов. Их объединяет аккаунт-менеджер банка. Объединять проектых чаще всего не удается т.к. заявки из разных отделов банка. Например заявка от "операционного отдела" по "фронт офису" и от "бек офиса" ценных бумаг по "дилингу". Эти сотрудники даже разговаривают на "разных языках", они сами друг друга не понимают.

Владимир Зонзов пишет: Руководители проектов работают как многостаночники. У каждого – по десятку проектов.

К сожалению, да.

Владимир Зонзов пишет: Поэтому, сотрудники подразделения «Отчёты» должны начинать работу не с «хотелок» заказчика, а с исходных данных (с требований), сформулированных руководителем проекта. И выполнять работу согласно ТЗ, утверждённого руководителем проекта.

Без "заявок" не проектов, нет проекта - нет руководителя проекта.

Владимир Зонзов пишет: Таким образом, руководитель проекта – это единый «преобразователь» ВСЕХ «хотелок» отдельного заказчика в исходные данные.

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

Сергей Чурюмов пишет: приходится (делаем арифметическое вычисление) от 118 до 135 человек АУП и всяких служб?

Вы сделали вывод только на основе обсуждения вопроса "подготовки отчетов". Но есть еще: Сотрудники внедрения, документирования, тестирования, внутреннего контроля и аудита, поддержка офисной системы (она у нас собственная), проектный офис, горячая линия, финансовый и клиентский отдел...

Валерий Овсий пишет: Но есть еще: Сотрудники внедрения, документирования, тестирования, внутреннего контроля и аудита, поддержка офисной системы (она у нас собственная), проектный офис, горячая линия, финансовый и клиентский отдел...

Удовлетворен Вашим ответом, Валерий Иванович.

Валерий Овсий пишет: Цитата Владимир Зонзов пишет: Руководители проектов работают как многостаночники. У каждого – по десятку проектов. К сожалению, да.

Так это же нормально. Почему к сожалению?

Сергей Чурюмов пишет: Так это же нормально. Почему к сожалению?

Как в любом коллективе есть очень, не очень и совсем "хорошие" менеджеры. Из-за количества одни ПЕРЕгружены, другие НЕДОгружены.