Ресурсное планирование и отслеживание трудозатрат

Нужно больше арахисаНачиная эту заметку, я должен сделать два предварительных замечания. Во-первых, тема ресурсного планирования не имеет какого-либо отношения к архитектуре информационных систем. Разве что, кроме того случая, когда архитекторам начинают задавать вопрос а почему это вас так много, а архитектуру вы рисуете так долго. К сожалению, у меня в очередной раз произошел этот самый случай и мне хочется поделиться удачными и не очень удачными вариантами ответа на этот вопрос. Во-вторых, мой многолетний опыт показывает, что ресурсное планирование и отслеживание трудозатрат knowledge workers обычно никак не влияет на размер материальной мотивации, но практически всегда разрушает мотивацию нематериальную, причем делает это очень быстро. 

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

Но вернемся к планированию и измерениям. Если такое упражнение все же случилось на вашу голову, то есть несколько вещей, которых делать не следует. Прежде всего, не следует вспоминать книжку легендарного Фредерика Брукса «Мифический человеко-месяц». Вряд ли её кто-то читал, а потому ваши доводы вызовут лишь досаду и раздражение: «Опять эти айтишники считают себя умнее нас!». Не надо говорить людям правду в лицо. Измерение количества строк кода или функциональных поинтов выглядит, конечно, довольно наукообразно, но тоже не очень подходит. Скорость печати современного принтера существенно превосходит возможности человека. В крайнем случае, придется соревноваться в скорости печати с профессиональной машинисткой, а две сотни знаков в минуту это все же довольно много.

Разумный совет в духе социализма  я на днях получил от своего руководителя. Он предложил мне посчитать выполненный объем работ за последние 2-3 года и с серьезным выражением лица сказать, что один архитектор способен разработать 5 (или 10) архитектур в год. Затем вытащить кипу бумаг с таблицами и графиками и уверенно рассказывать о том, что это результаты многолетних измерений. Отвечая на вопрос, а почему так мало, посыпать голову пеплом и рассказать, что такие уж нам попались сотрудники, экология плохая, демографическая ситуация сложная, да и зима в эту году слишком затянулась. У этого метода есть два недостатка. Первый состоит в том, что во время рассказа категорически нельзя улыбаться, а вторая в том, что на следующий год вам обязательно увеличат план (или сократят штат) минимум на 10%. У социализма, как и у капитализма, есть свои жестокие правила.

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

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

Еще раз повторю, что все эти методы мало подходят для архитекторов информационных систем и других уважаемых экспертов и в короткие сроки убивают их мотивацию. И потому всем желаю по возможности не слышать знаменитую реплику из фильма «Добро пожаловать, или Посторонним вход воспрещен»: А чё это вы здесь делаете… а?

Реклама

5 Comments

  1. Аналогичная ситуация с дизайнерами, программистами и т д

    Вот есть у меня 5 проектов, а у моего коллеги руководителя их 4, а еще у одного — 7.
    И вот мы такие руководители проектов, планируем их закрыть к определенным срокам.

    Но наступают суровые трудовыебудни. И оказывается что вот тот дизайнер кроме как на мои два проекта, еще требуется на проекты коллег. Тоже самое с программистами. Архитекторов у нас нет, но если были бы, то тоже понадобились бы, и сразу всем. Ей богу.

    И вот какой из проектов получит ресурс времени ценных специалистов, а какой нет? Решает жребий, случай, уровень политической прокачки или степень родства с генеральным директором.

    Все это так и в большинстве организаций.

    У этого термина даже есть название «критическая цепь». У критической цепи есть слабое звено. И по отношению к этому слабому звену нужно провести ряд маневров.
    Это все описано в одноименной книге Ильяху Голдрата, как раз по управлению проектами.

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

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

    Это можно легко увидеть, если вся организация работает в единой системе.

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

    А по мотивации — в яблочко. Уже год наблюдаю именно такую картинку, когда
    1. одна группа, умотивированная по уши (в премиях, в игрушках, в новом оборудовании и т д) — одну половину проектов валит, а вторую затягивает по срокам, да не на 10-20%, а в 2 и более раз )
    2. вторая группа, без премий, без игрушек — закрывает проекты десятками, причем добрую половину в сроки.
    Волей не волей поверишь в гипотезу Пинка )

    Ответить

    1. У меня интересная ситуация сложилась. CIO, вероятно читал Голдрата и все это отлично понимает. Проектный офис про критическую цепь и теорию ограничений вряд ли что-нибудь слышал. Вроде бы они понимают друг друга, но на самом деле это не так 🙂 Посмотрим, как ситуация будет развиваться дальше

      Ответить

  2. Автономность и профессионализм это хорошо, но ведь вы и сами наверняка сталкивались с ситуациями, когда вдруг в последний момент выясняется, что какой-нибудь автономный и профессиональный товарищ не сделал того, что от него ожидали и стоит перед вами с ясным взором плечами пожимает, дескать, задачка очень творческая получилась, не успел пока сделать и когда сделаю не знаю…
    А с другой стороны у вас стоят заказчики с договором, и штрафными санкциями. как ва понять, то ли действительно задачка творчесская и объективно сложная, то ли товарищ он-лайн играми увлёкся…

    Ответить

    1. … лишний повод кому-нибудь из многочисленных ИТ-менеджеров проявить одну из своих ключевых компетенций — отмазаться от справедливых требований заказчика 😉

      Ответить

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s