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

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

Думаю, что в первом приближении понял правильно (что речь идет о ПО). Непонимание в следующем. Вот есть БА. Он работает в одном из подразделений Вашей компании. Не в отчетах (с недавних пор - с Ваших слов). Когда он участвует в других работах (не по направлению подразделения Отчеты) - тему эту пока не рассматриваем. Но вот он попал в проект подразделения Отчеты. Чем именно он таким занят, что все время занят и не хочет брать хотелки? Если самим проектом в рамках работы подразделения Отчеты - это одно. А если в других проектах не подразделения Отчеты - совсем другое. Для меня это главный вопрос. У меня также есть проблема коммуникации, раз не могу донести свой вопрос.

Владимир Токарев пишет: какова ситуация сейчас? С оргструктурой - есть подразделение Отчеты? Есть БА в этом подразделении?

Сейчас, после проведенных изменений в Бизнес Процессах компании, есть подразделение "Отчеты". Бизнес Аналитиков в этом подразделении нет.

Владимир Токарев пишет: Они (в рамках матричной структуры) входят в разные подразделения, откуда "изымаются" в частности в проекты по работе подразделения Отчеты. Так?

Да. Так было на начало темы. Сейчас уже не так. Есть специальное подразделение - "Отдел Бизнес Анализа".

Владимир Токарев пишет: Матричная структура, насколько я понимаю, не всегда строится только при наличии проектов.

Нет! У нас ТОЛЬКО в рамках проекта.

Валерий Овсий пишет: Бизнес Аналитиков в этом подразделении нет.

Понятно.

Валерий Овсий пишет: Так было на начало темы. Сейчас уже не так. Есть специальное подразделение - "Отдел Бизнес Анализа".

То есть, сейчас БА "изымаются" из ОБА для выполнения разных проектов, в частности для проектов подразделения Отчеты (?) А какова была цель объединения БА в такое подразделение?

Валерий Овсий пишет на мой текст курсивом: Матричная структура, насколько я понимаю, не всегда строится только при наличии проектов. Нет! У нас ТОЛЬКО в рамках проекта.

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

Владимир Токарев пишет: Чем именно он таким занят, что все время занят и не хочет брать хотелки?

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

Владимир Токарев пишет: А какова была цель объединения БА в такое подразделение?

Повышение квалификации, стандартизация, контроль => повышение качества.

Валерий Овсий пишет: С точки зрения процессов: Основная задача процесса "Бизнес Анализ" это разработка документа "Требования".

Спасибо за информацию. На самом деле я внимательно прочитал исходную информацию в самом начале обсуждения кейса, и уточняю только то, что не смог там понять. А именно -

Валерий Овсий пишет: Работа аналитика в одном проекте не является непрерывной.

В Вашем описании (в этой начальной части) я не увидел в разноплановости для БА проблему - набор разноплановых действий, без которых не сделать работу БА это нормально.

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

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

Валерий Овсий пишет: С учетом этих пауз БА участвуют в нескольких проектах в разных ролях. ... Руководителю очень трудно отследить количество пауз.

То есть, может быть участие БА и в проектах и не подразделения Отчеты? Сам руководитель ОБА отслеживает эти паузы? Или у БА есть свой интерес участвовать в других проектах, когда появилась пауза? БА, что уже подключен к проекту (проект в рамках подразделения Отчеты) может одновременно НЕ В ПАУЗЫ участвовать в других проектах и не подразделения Отчеты?

Михаил Кузнецов рассказал историю (20.07.14 18:34):
… рядовой бизнес аналитик … не сидел без работы …ему постоянно приходилось "описывать" все новые хотелки сотрудников, благо никто из них не читал все, что до них было придумано и работа эта не останавливалась ни на миг.
… трудолюбивый БА никогда не задумывался о системном подходе в описании, …
В итоге модель системы была запутанной и абсолютно не читаемой, но главное она была гигантской - такой при взгляде на которую увольнять БА не поднималась никакая рука. Ведь никому не хотелось остаться с ней наедине.... )))

Я откликнулся (21.07.14 11:21) на «историю»:
В прежние времена, запутанность и нечитаемость компьютерных программ считались недопустимыми. В книге по технике написания компьютерных программ (выпущенной где-то в 1985 г.) содержалась рекомендация, безусловно увольнять тех, кто пишет изощрённо. Потому что, изощренность программ ухудшает их сопровождение.
А нынешние ИТ-разработчики, похоже, создают свои «одоробла» именно такими, чтобы их сопровождение было возможно только с участием авторов.
Из вышеприведенного сравнения следует «обратный» вопрос:
- какие причины стимулируют и мотивируют ИТ-разработчиков стремиться к ухудшению «читаемости» их программ?

Валерий Овсий сделал вывод (21.07.14 22:54):
Вы не правы. Требования к "читабельности" и "простоте" сейчас на порядок выше чем раньше. Этому способствует активное использование т.н. SOA - архитектуре Программного обеспечения.
... Так что "читабельность" и "ремонтопригодность" современных систем на порядок выше.

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

Да, за последние 20 лет программы и средства их создания сильно изменились. Но, идеи изменений так быстро не меняются. Особенно, если учесть, что эти идеи не были новыми. Они были известны из развития «железа». А именно: - Общая внутренняя среда существования для подпрограмм-модулей – это «головной модуль». Примером аналога головного модуля можно считать материнскую плату персонального IBM-компьютера. - Общие «инфраструктурные элементы внутренней среды» для модулей (базы данных; форматы общения с ними; …). Примеры аналогов – процессор; память на материнской плате; общая шина; … . - Стандарты на форматы обмена между модулями и «инфраструктурными элементами», стандарты на форматы обмена между модулями и «внешней средой». Примеры аналогов – контроллеры устройств и программы-драйверы. - Децентрализация управления исполнением локальных функций. Пример аналога – применение специализированных процессоров в составе контроллеров. [COLOR=gray=gray]Есть, наверняка и другие аналоги. Но, не стану же я сейчас изучать то, что уже заведомо применять не буду; изучать только для того, чтобы поспорить[/COLOR]. А идеи организации управления разработками (в том числе, и ИТ-разработками) меняются ещё медленнее. Насколько я понял сообщения В.И.Овсия, в его фирме, конечно, применяется матричная структура управления проектами. Но, похоже, она сильно отличается от той, которая применялась в отраслевых проектных предприятиях советских времён (например, в нашем ОКБ, которое относилось к Главкосмосу Минобщемаша). Кратко напомню ту матричную систему управления разработками. Предприятие имело две параллельные структуры управления: - Проектную структуру: директор (он же - главный конструктор предприятия); руководители проектов (РП); и так далее. - Административную структуру: директор; руководители специализированных отделов (РО); и так далее. Каждый РП имел: - понимание проекта; - деньги для разработки проекта; - единоличную ответственность за достижение результатов проекта. - необходимость «покупать» у РО людские и материальные ресурсы для разработки своего проекта. При такой системе управления, директор был избавлен от рутины управления оперативной работой и защищен от «неправильного поведения» РП и РО. Поясню последнее: - Если РП «вел себя неправильно», то директор, руками РО, ограничивал его по ресурсам. [COLOR=gray=gray]Из-за нехватки ресурсов, проект выбивался из графика и единоличная ответственность «падала» на РП. Тогда директор «принимал меры» к РП[/COLOR]. - Если РО «вел себя неправильно», то директор, руками РП, ограничивал его по деньгам (разрешал РП обращаться к внешним подрядчикам). [COLOR=gray=gray]«Малоденежье» создавало проблемы существованию специализированного отдела. Тогда директор «принимал меры» к РО[/COLOR]. =========================================. Описывать свои догадки, о матричной структуре управления в фирме В.И.Овсия, не вижу смысла. Скажу только главное - как мне кажется по сообщениям В.И.Овсия, в структуре управления, построенной им, нет руководителей проектов. Поэтому, я скептически отношусь к дискуссиям по обеим темам, инициированным В.И.Овсием. Обсуждать лучше не субъективные проблемы В.И.Овсия, а соответствующие им формализованные проблемы. [COLOR=gray=gray]Кстати, я, конечно, далёк от утверждений, что В.И.Овсий неправ в своём подходе к организации управления ИТ-разработками. Результатов можно добиваться разными способами, в том числе и «неправильными». Поэтому, думаю, каждый успешный спец и управленец – прав (с учетом его субъективных целей и условий работы)[/COLOR].

Владимир Зонзов пишет: Не думаю, что к этим элементам отклика применим вывод типа «Вы не правы».

Да. Я согласен на все написанное так сказать нельзя. Я среагировал на Вашу фразу:

Владимир Зонзов пишет: А нынешние ИТ-разработчики, похоже, создают свои «одоробла» именно такими, чтобы их сопровождение было возможно только с участием авторов.

Именно к этой фразе относится мое "не правы". Нынешние разработчики к этому не стремятся.

Владимир Зонзов пишет: В прежние времена, запутанность и нечитаемость компьютерных программ считались недопустимыми.

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

Владимир Зонзов пишет: Скажу только главное - как мне кажется по сообщениям В.И.Овсия, в структуре управления, построенной им, нет руководителей проектов.

То что я не опишу и не обсуждаю руководителя проекта НЕ ОЗНАЧАЕТ что его нет. Как Вы могли подумать такое? Но права и обязанности руководителя проекта определяю Я!! И до тех пор пока именно я не пойму и не укажу эти права и обязанности говорить о нем нет смысла. Сначала общая система управления в которую вписываются руководители проекта, а не наоборот.

Михаил Кузнецов пишет: Так уж повелось у нас (судя по всему у Овсия В.И. тоже), что БА это некоторый придаток к ПО.

Если уж очень примитивно то ДА! Искусство управления (нормативы, стандарты, идеология, культура...) и заключается в том как согласовать работу БА с основным производства Программного продукта.

Валерий Овсий пишет: Сначала общая система управления в которую вписываются руководители проекта, а не наоборот

Я знаю, по опыту, что наоборот. Подумаю, напишу подробнее.