"На фига в колхозе бесы, Если бес не продуктивен, Ни по шерсти, ни по мясу, Ни тем более по яйцам... " Веня Д'ркин Я так понял, что речь в статье идет о выпускнике американского колледжа. Я расскажу о подмосковных. Четвертый год пытаюсь сотрудничать. Три раза приглашали быть председателем выпускной комиссии по специальности 09.02.07 «ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ПРОГРАММИРОВАНИЕ». Наверно больше не пойду - стремно ставить свою подпись в дипломах за такие знания. 90% выпускников не знают что такое SQL (в т.ч. и те, кому выдают красные дипломы). Через экзамены прошли ~ 75 выпускников. На первом году сотрудничества взял в штат 1(одного) выпускника (в рамках дипломной работы представил реализованный на фрилансе заказ - устройство на arduino для поливки комнатных растений с управлением через Интернет). Проводил несколько собраний со студентами - звал к себе на стажировку. Завел специальный для этого проект (полагаю тематика ностальгична). Помнится на одно из таких собраний пришло человек 100. Я даже поначалу испугался. Что мне с ними со всеми делать если все придут на мою стажировку? Из 100 на призыв откликнулось 7. Из них до выдачи хоть каких то результатов "дожило" 0 (ноль) студентов. Пытался привлечь к своему учебному проекту студентов из МИИТ (у одного сотрудника сын учится на втором курсе). Этим студентам поставили учебную задачу - создать стартап. Ну я и предложил через своего знакомого свой проект для группы заинтересованных студентов. Студенты были согласны, но комиссия на кафедре проект отклонила. Стартап должен быть рентабельным. В общем на этом сотрудничество и закончилось. Про прохождение и результаты одной из стажировок студента-"программиста" я уже писал раньше. Если буду брать студентов на вакансии программистов, то только после успешного прохождения неоплачиваемой полугодовой стажировки. Было б совсем тоскливо, вместе с тем... Потенциально есть очень много людей которые хотят попасть в IT, но не знают как. Этой зимой приобщился к интенсиву школы 21 (франшиза школы 42). Универ однозначно не заменит, однако ... Первый раз одновременно видел в одном месте так много людей страстно желающих программировать (набор на 26 дневный интенсив около 600 человек). И у нах получалось. Базовая подготовка кандидатов - "с нуля". GIT и код - с первого дня. Кстати, ограничений по возрасту в этой школе в настоящее время нет. Думал встретить там в основном молодежь, но по моим наблюдениям средний возраст абитуриентов 30-35. Понял, что еще "не вмерла" IT в РФ... Надежда умирает последней...
Спасибо за перевод. Очень крутая статья. Однако, в первом предложении выводов фраза:
еще несколько секунд каждый день, чтобы сделать запись, когда вы начали работать над конкретной задачей.
на мой взгляд переведена не совсем верно. На мой взгляд, это очень важная фраза и должна быть интерпретирована так:
< ... еще несколько секунд каждый день, для учета рабочего времени (трудозатрат), которое было потрачено на выполнение конкретной задачи>.
В Вашем варианте перевода создается впечатление, что надо фиксировать время начала работы над задачей. А по факту, от сотрудника требуется ежедневная обратная связь о трудозатратах по конкретным задачам над которыми он работал. Добавлю от себя, что еще, в случае необходимости (если разработчик видит, что не укладывается в план), требуется переоценка времени необходимого для завершения конкретной задачи. На основании этой переоценки, РП может заблаговременно скорректировать сроки (без оказания давления на исполнителей).
Спасибо за развернутый ответ. Однако хотел отметить, что в моих статьях описаны типовые процессы не для Ланита (в который кстати входит более 30 компаний), а только для моей проектной команды. Несмотря на то, что я публикуюсь в блоге Ланита, мои подходы не являются общепринятыми и больше демонстрируют толерантность редколлегии к моему личному мнению, чем корпоративные стандарты. Что касается масштабов проекта для которых необходимо оформление технических решений, то со временем, не сразу, для себя я понял, что разработка и согласование технических решений необходимо абсолютно для всех заданий на разработку ПО. Раньше я думал что примерно 80% требований заказчика не требуют уточнения. После сбора статистики в течении 8 лет я точно знаю что 100% требований заказчика требует уточнения. Именно превентивное согласование технических решений на связанные группы требований (не путать с техническим заданием) дает хоть какие то гарантии успешного завершения проекта.
В приведенном процессе фактически отсутствует этап проектирования и согласования технического решения. Детализации и уточнения требований заказчика по моему опыту недостаточно. Пример регламента технического решения можно посмотреть здесь.
Я бы разделил п.4 на 2: менять регламенты и менять их к лучшему - это два разных уровня. В одной компании поменяли регламенты сопровождения, после чего продолжительность обслуживания инцидентов возросла в 6-8 раз...
Дополнительная пища: как декомпозировать задачи, у исходно туманны трудозатраты (например, исследование возможности применения новой технологии); какие именно плагины JIRA применялись для построения дашбордов; как ведется учет трудозатрат на декомпозицию и планирование, какова доля этих трудозатрат от бюджета рабочего времени проектной группы, кто именно проводит декомпозицию; каким образом связываются между собой декомпозированные задачи (как понять что это кусочки слона, а не оленя и как узнать текущую степень реализации слона); как, какие и в каких единицах измеряются потери на проекте....
IMHO, статья была бы на порядок полезнее, если бы Вы объяснили какие именно атрибуты задач JIRA использованы для построения и назначение каждого из этих красивых графиков, гистограмм, и бубликов. И что обозначают засекреченные полутона? И в особенности хотелось бы узнать, какие именно телодвижения надо делать руководителю исходя из этих картинок...
Маржу я бы, конечно, взял... Да кто ж ее даст... ФОТ и состав команды обосновываю я, исходя из бюджетов договоров (кстати, которые тоже я обосновываю) и текущей ситуации на рынке труда, но окончательное решение принимает вышестоящее начальство. И я не прошу дополнительных РП у начальства, я выращиваю их самостоятельно. Что касается управления, у меня в команде выстроен определенный порядок достижения целей. Любое входящее требование (не только от представителей заказчика, но в том числе и требования вышестоящего руководства и мои требования тоже) регистрируется, на него назначается ответственный, как правило, из числа аналитиков (на текущий момент в группе три аналитика). Ответственный выступает как РП в рамках этого требования (или группы связанных требований). Он отвечает за организацию работ и сдачу результата решения заказчику. Я сам, как правило, осуществляю утверждение и контроль исполнения сроков и выступаю в роли рецензента отдельных проектных решений и командных процессов. Иногда, при необходимости, включаюсь в прямое управление и разработку, но стараюсь этого избегать. Недавно мне задали вопрос: "А что если аналитик не хочет решать управленческие задачи?" Я в свою очередь порекомендовал своему визави познакомится с содержанием соответствующего профессионального стандарта. С определенного времени, ссылки на соответствующие профессиональные стандарты я вписываю в трудовые договора своих сотрудников... Такая ссылка легитимно устраняет массу лишних вопросов... Так сказать, на берегу.... Однако многие руководители почему-то ограничивают полномочия своих сотрудников фантазиями чужих HR-специалистов публикуемыми на hh... Или думают, что решат все проблемы фразой в трудовом договоре о том, что "сотрудник должен выполнять все распоряжения руководителя"... Результаты своих управленческих экспериментов над живыми людьми я иногда публикую на Хабре и на своем pet-проекте aimsmart.ru. Эти же статьи использую как неформальные, но вполне действующие, регламенты для своей проектной команды...
Опять, же дело в контексте. Что называть проектом? У меня основная система над которой трудится проектная команда как бы одна. Но в ней 14 подсистем которые решают разные задачи (на каждой из них раньше специализировалась своя группа разработчиков). По этой системе одновременно может быть в работе 3-4 договора разного размера и срочности: на базовое сопровождение (решение возникающих инцидентов и консультации), на расширенное сопровождение (небольшие доработки по заявкам), на развитие (серьезная модификация подсистем, переход на новые технологии, создание новых подсистем). Это один проект или программа или портфель проектов? Кроме того в проектной команде у нас есть пара внутренних проектов заточенных на создание перспективных продуктов (решение важных, но несрочных задач - по матрице Д.Эйзенхаура). Один из таких проектов описан на Хабре. На эти проекты я стараюсь ежедневно планировать не менее 30% рабочего времени штатных сотрудников. На этих внутренних проектах решаются проблемы превентивного освоения и апробации перспективных технологий, а так же выравнивания неравномерности нагрузки сотрудников (ликвидация mura). Эти же проекты служат "песочницей" для апробации стажеров. Эти же проекты служат буфером (по Э.Голдрату), в случае необходимости решения более срочных задач по заключенным контрактам. При всем при этом моя должность звучит как <РП> (в прямом подчинении 12 сотрудников, для решения отдельных задач возможно привлечение внешних экспертов). Было бы интересно узнать, как должна звучать моя должность, с точки зрения читателей этой статьи... ;)
Согласен с автором в отношении уровня зарплат РП. Единственное, конкретизирую свое виденье главного отличительного признака РП - это человек, который лично отвечает за итоговый результат работы других сотрудников. Некоторые уверены, что РП - это человек который может талантливо делегировать свою ответственность (не работу, а именно ответственность). Это не РП - это рафинированный менеджер. Иногда, такая должность звучит как <администратор проекта>. Зарплата таких "РП" действительно может стартовать с гораздо меньших уровней.
Сделайте всем исполнителям коммуникацию, что вы разрешаете списывать время постфактум так, как им это будет удобно.
Не совсем понял, что именно надо сделать всем исполнителям и как? Списывать время как удобно исполнителям? Это как? А если им удобно раз в неделю? Или раз в месяц? А как при таком подходе в случае превышения зафиксированной трудоемкости узнать сколько нужно времени на завершение задачи?
Обратная связь: Как количественно оценивать результаты работы отдельных сотрудников на программном проекте? Как и какие именно риски Вы оцениваете в ходе проекта (после инициации) и как их предупреждаете? Нужен ли тайм-трекинг на проекте? Как решаете проблемы неравномерности нагрузки на сотрудников? Вы ведёте учёт потерь на проекте? Если да, то каких именно и как?
Прочитать не смог, но осуждаю... Будь проще... По моему, я когда-то это уже слышал... И не раз... И что грустно, народу продолжают нравится такие выводы... Видимо, если так пойдет дальше, не за горами время, когда статьи будут содержать не больше двух-трех "ку"...
Это точно.Например ГОСТ Р 15.101-2021 (и его предшественники). Рекомендую. Обращаю внимание на Приложение А. Практически все значимые научные достижения в нашей стране получены благодаря этой методологии. Но мало кто ее читал и понял, о чем там написано. И еще меньше тех, кто пытался применять на программных проектах. Что касается SCRAM, не соглашусь. Просто надо понимать условия, для которых применение этого инструмента будет эффективно. На мой взгляд, болезнь кроется в головах рафинированных менеджеров, а не в инструментах.
Что касается причин "трисоляриса", то я менее всего склонен рассматривать в качестве причин политику. Как меня учили когда-то, политика - всего лишь надстройка над исторически сложившейся экономической системой... То, что я осознал для себя на текущий момент, так это то, что не стоит бороться с мельницами, надо постараться выйти за рамки, понять истинные цели систем частью которых мы являемся и использовать их энергию в своих интересах людей, за которых я несу ответственность. Словить невидимый ветер. Не это ли основное предназначение руководителя? Некоторыми результатами экспериментов над живыми людьми, направленных на повышение эффективности управления IT-проектами, я иногда делюсь в своих статьях на Хабре. Если будет время, поглумитесь над ними как следует... ;)
Куда делись руководители с горящими глазами? Дискуссия скатилась в обсуждение проектных технологий и размера зарплаты PM... На мой взгляд причина совсем в другом... Уже не первый год и не в одной компании наблюдаю систему, которую один мой товарищ назвал "три круга". Первый круг - неприкасаемые - директор, его самые близкие замы и их родственники. В этом круге самая высокая зарплата... Второй круг - руководители отвечающие за результат работы. У этих нормальная зарплата по рынку и именно они руководят непосредственными исполнителями. Эти исполнители составляют третий круг и кадровый резерв для второго. Кроме ответственности за результат, основная задача второго круга - не допускать возмущенных исполнителей к лицам первого круга... Почему возмущенных? Потому, что зарплата третьего круга минимально возможная. Только чтобы проект не сдох. Иногда правда вынуждены держать экспертов... Но в принципе, все же знакомы с законом Паррето... Когда необходимо обеспечить минимально возможное качество, экспертов много не надо... Время жизни на первом и третьем круге, как правило значительно превышает время жизни на втором круге. С горящими глазами на втором круге долго не продержишься. По опыту, долго на втором круге держатся персонажи, которые умело превозносят руководство и не менее талантливо перекладывают все проблемы на третий круг. Кроме того, талантливый глупый руководитель второго круга может додуматься до того, что он может выполнять обязанности лиц первого круга... Таких вообще убивают сразу, пока маленькие... Благо заменить такого руководителя легко, на эти должности всегда конкурс. Поэтому долго тут держатся не самые умные, а самые преданные. Нет, преданные не проекту. Ну сами знаете кому... ;) Как мне кажется, тут лучше обсудить вопрос: в чем причина того, что во многих организациях сложилась такая система? Или у вас как то по другому?
"На фига в колхозе бесы,
Если бес не продуктивен,
Ни по шерсти, ни по мясу,
Ни тем более по яйцам... "
Веня Д'ркин
Я так понял, что речь в статье идет о выпускнике американского колледжа. Я расскажу о подмосковных. Четвертый год пытаюсь сотрудничать. Три раза приглашали быть председателем выпускной комиссии по специальности 09.02.07 «ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ПРОГРАММИРОВАНИЕ». Наверно больше не пойду - стремно ставить свою подпись в дипломах за такие знания. 90% выпускников не знают что такое SQL (в т.ч. и те, кому выдают красные дипломы). Через экзамены прошли ~ 75 выпускников. На первом году сотрудничества взял в штат 1(одного) выпускника (в рамках дипломной работы представил реализованный на фрилансе заказ - устройство на arduino для поливки комнатных растений с управлением через Интернет). Проводил несколько собраний со студентами - звал к себе на стажировку. Завел специальный для этого проект (полагаю тематика ностальгична). Помнится на одно из таких собраний пришло человек 100. Я даже поначалу испугался. Что мне с ними со всеми делать если все придут на мою стажировку? Из 100 на призыв откликнулось 7. Из них до выдачи хоть каких то результатов "дожило" 0 (ноль) студентов. Пытался привлечь к своему учебному проекту студентов из МИИТ (у одного сотрудника сын учится на втором курсе). Этим студентам поставили учебную задачу - создать стартап. Ну я и предложил через своего знакомого свой проект для группы заинтересованных студентов. Студенты были согласны, но комиссия на кафедре проект отклонила. Стартап должен быть рентабельным. В общем на этом сотрудничество и закончилось.
Про прохождение и результаты одной из стажировок студента-"программиста" я уже писал раньше. Если буду брать студентов на вакансии программистов, то только после успешного прохождения неоплачиваемой полугодовой стажировки.
Было б совсем тоскливо, вместе с тем... Потенциально есть очень много людей которые хотят попасть в IT, но не знают как. Этой зимой приобщился к интенсиву школы 21 (франшиза школы 42). Универ однозначно не заменит, однако ... Первый раз одновременно видел в одном месте так много людей страстно желающих программировать (набор на 26 дневный интенсив около 600 человек). И у нах получалось. Базовая подготовка кандидатов - "с нуля". GIT и код - с первого дня. Кстати, ограничений по возрасту в этой школе в настоящее время нет. Думал встретить там в основном молодежь, но по моим наблюдениям средний возраст абитуриентов 30-35. Понял, что еще "не вмерла" IT в РФ... Надежда умирает последней...
Спасибо за перевод. Очень крутая статья. Однако, в первом предложении выводов фраза:
на мой взгляд переведена не совсем верно. На мой взгляд, это очень важная фраза и должна быть интерпретирована так:
< ... еще несколько секунд каждый день, для учета рабочего времени (трудозатрат), которое было потрачено на выполнение конкретной задачи>.
В Вашем варианте перевода создается впечатление, что надо фиксировать время начала работы над задачей. А по факту, от сотрудника требуется ежедневная обратная связь о трудозатратах по конкретным задачам над которыми он работал. Добавлю от себя, что еще, в случае необходимости (если разработчик видит, что не укладывается в план), требуется переоценка времени необходимого для завершения конкретной задачи. На основании этой переоценки, РП может заблаговременно скорректировать сроки (без оказания давления на исполнителей).
Спасибо за развернутый ответ. Однако хотел отметить, что в моих статьях описаны типовые процессы не для Ланита (в который кстати входит более 30 компаний), а только для моей проектной команды. Несмотря на то, что я публикуюсь в блоге Ланита, мои подходы не являются общепринятыми и больше демонстрируют толерантность редколлегии к моему личному мнению, чем корпоративные стандарты. Что касается масштабов проекта для которых необходимо оформление технических решений, то со временем, не сразу, для себя я понял, что разработка и согласование технических решений необходимо абсолютно для всех заданий на разработку ПО. Раньше я думал что примерно 80% требований заказчика не требуют уточнения. После сбора статистики в течении 8 лет я точно знаю что 100% требований заказчика требует уточнения. Именно превентивное согласование технических решений на связанные группы требований (не путать с техническим заданием) дает хоть какие то гарантии успешного завершения проекта.
В приведенном процессе фактически отсутствует этап проектирования и согласования технического решения. Детализации и уточнения требований заказчика по моему опыту недостаточно. Пример регламента технического решения можно посмотреть здесь.
Я бы разделил п.4 на 2: менять регламенты и менять их к лучшему - это два разных уровня. В одной компании поменяли регламенты сопровождения, после чего продолжительность обслуживания инцидентов возросла в 6-8 раз...
Дополнительная пища: как декомпозировать задачи, у исходно туманны трудозатраты (например, исследование возможности применения новой технологии); какие именно плагины JIRA применялись для построения дашбордов; как ведется учет трудозатрат на декомпозицию и планирование, какова доля этих трудозатрат от бюджета рабочего времени проектной группы, кто именно проводит декомпозицию; каким образом связываются между собой декомпозированные задачи (как понять что это кусочки слона, а не оленя и как узнать текущую степень реализации слона); как, какие и в каких единицах измеряются потери на проекте....
IMHO, статья была бы на порядок полезнее, если бы Вы объяснили какие именно атрибуты задач JIRA использованы для построения и назначение каждого из этих красивых графиков, гистограмм, и бубликов. И что обозначают засекреченные полутона? И в особенности хотелось бы узнать, какие именно телодвижения надо делать руководителю исходя из этих картинок...
Спасибо, поправлю! Что скажешь... Сеанс кодотерапии выровнял кривые руки РП, исковерканные менеджментом, не до конца... ;)
Маржу я бы, конечно, взял... Да кто ж ее даст... ФОТ и состав команды обосновываю я, исходя из бюджетов договоров (кстати, которые тоже я обосновываю) и текущей ситуации на рынке труда, но окончательное решение принимает вышестоящее начальство. И я не прошу дополнительных РП у начальства, я выращиваю их самостоятельно. Что касается управления, у меня в команде выстроен определенный порядок достижения целей. Любое входящее требование (не только от представителей заказчика, но в том числе и требования вышестоящего руководства и мои требования тоже) регистрируется, на него назначается ответственный, как правило, из числа аналитиков (на текущий момент в группе три аналитика). Ответственный выступает как РП в рамках этого требования (или группы связанных требований). Он отвечает за организацию работ и сдачу результата решения заказчику. Я сам, как правило, осуществляю утверждение и контроль исполнения сроков и выступаю в роли рецензента отдельных проектных решений и командных процессов. Иногда, при необходимости, включаюсь в прямое управление и разработку, но стараюсь этого избегать. Недавно мне задали вопрос: "А что если аналитик не хочет решать управленческие задачи?" Я в свою очередь порекомендовал своему визави познакомится с содержанием соответствующего профессионального стандарта. С определенного времени, ссылки на соответствующие профессиональные стандарты я вписываю в трудовые договора своих сотрудников... Такая ссылка легитимно устраняет массу лишних вопросов... Так сказать, на берегу.... Однако многие руководители почему-то ограничивают полномочия своих сотрудников фантазиями чужих HR-специалистов публикуемыми на hh... Или думают, что решат все проблемы фразой в трудовом договоре о том, что "сотрудник должен выполнять все распоряжения руководителя"...
Результаты своих управленческих экспериментов над живыми людьми я иногда публикую на Хабре и на своем pet-проекте aimsmart.ru. Эти же статьи использую как неформальные, но вполне действующие, регламенты для своей проектной команды...
Опять, же дело в контексте. Что называть проектом? У меня основная система над которой трудится проектная команда как бы одна. Но в ней 14 подсистем которые решают разные задачи (на каждой из них раньше специализировалась своя группа разработчиков). По этой системе одновременно может быть в работе 3-4 договора разного размера и срочности: на базовое сопровождение (решение возникающих инцидентов и консультации), на расширенное сопровождение (небольшие доработки по заявкам), на развитие (серьезная модификация подсистем, переход на новые технологии, создание новых подсистем). Это один проект или программа или портфель проектов? Кроме того в проектной команде у нас есть пара внутренних проектов заточенных на создание перспективных продуктов (решение важных, но несрочных задач - по матрице Д.Эйзенхаура). Один из таких проектов описан на Хабре. На эти проекты я стараюсь ежедневно планировать не менее 30% рабочего времени штатных сотрудников. На этих внутренних проектах решаются проблемы превентивного освоения и апробации перспективных технологий, а так же выравнивания неравномерности нагрузки сотрудников (ликвидация mura). Эти же проекты служат "песочницей" для апробации стажеров. Эти же проекты служат буфером (по Э.Голдрату), в случае необходимости решения более срочных задач по заключенным контрактам.
При всем при этом моя должность звучит как <РП> (в прямом подчинении 12 сотрудников, для решения отдельных задач возможно привлечение внешних экспертов). Было бы интересно узнать, как должна звучать моя должность, с точки зрения читателей этой статьи... ;)
Согласен с автором в отношении уровня зарплат РП. Единственное, конкретизирую свое виденье главного отличительного признака РП - это человек, который лично отвечает за итоговый результат работы других сотрудников. Некоторые уверены, что РП - это человек который может талантливо делегировать свою ответственность (не работу, а именно ответственность). Это не РП - это рафинированный менеджер. Иногда, такая должность звучит как <администратор проекта>. Зарплата таких "РП" действительно может стартовать с гораздо меньших уровней.
Было бы интересно увидеть как именно выглядит живая карта ресурсов.
Не совсем понял, что именно надо сделать всем исполнителям и как? Списывать время как удобно исполнителям? Это как? А если им удобно раз в неделю? Или раз в месяц? А как при таком подходе в случае превышения зафиксированной трудоемкости узнать сколько нужно времени на завершение задачи?
Обратная связь: Как количественно оценивать результаты работы отдельных сотрудников на программном проекте? Как и какие именно риски Вы оцениваете в ходе проекта (после инициации) и как их предупреждаете? Нужен ли тайм-трекинг на проекте? Как решаете проблемы неравномерности нагрузки на сотрудников? Вы ведёте учёт потерь на проекте? Если да, то каких именно и как?
Однажды Резерфорд зашел поздно вечером в свою лабораторию и увидел там, несмотря на неурочный час, одного из своих сотрудников.
«Что вы делаете здесь так поздно?» — удивился ученый.
«Работаю», — ответил подававший надежды.
«Что же вы, в таком случае, делали днем?»
«Разумеется, работал».
«А утром? Неужели и утром вы тоже работали?»
«И утром тоже».
«Позвольте, — неподдельно изумился Резерфорд, — а когда же вы думаете?»
Прочитать не смог, но осуждаю... Будь проще... По моему, я когда-то это уже слышал... И не раз... И что грустно, народу продолжают нравится такие выводы... Видимо, если так пойдет дальше, не за горами время, когда статьи будут содержать не больше двух-трех "ку"...
Я таки думаю, что не дешевые программисты, а некомпетентные менеджеры...
Это точно.Например ГОСТ Р 15.101-2021 (и его предшественники). Рекомендую. Обращаю внимание на Приложение А. Практически все значимые научные достижения в нашей стране получены благодаря этой методологии. Но мало кто ее читал и понял, о чем там написано. И еще меньше тех, кто пытался применять на программных проектах.
Что касается SCRAM, не соглашусь. Просто надо понимать условия, для которых применение этого инструмента будет эффективно. На мой взгляд, болезнь кроется в головах рафинированных менеджеров, а не в инструментах.
Что касается причин "трисоляриса", то я менее всего склонен рассматривать в качестве причин политику. Как меня учили когда-то, политика - всего лишь надстройка над исторически сложившейся экономической системой... То, что я осознал для себя на текущий момент, так это то, что не стоит бороться с мельницами, надо постараться выйти за рамки, понять истинные цели систем частью которых мы являемся и использовать их энергию в
своихинтересах людей, за которых я несу ответственность. Словить невидимый ветер. Не это ли основное предназначение руководителя?Некоторыми результатами экспериментов над живыми людьми, направленных на повышение эффективности управления IT-проектами, я иногда делюсь в своих статьях на Хабре. Если будет время, поглумитесь над ними как следует... ;)
Куда делись руководители с горящими глазами? Дискуссия скатилась в обсуждение проектных технологий и размера зарплаты PM... На мой взгляд причина совсем в другом... Уже не первый год и не в одной компании наблюдаю систему, которую один мой товарищ назвал "три круга". Первый круг - неприкасаемые - директор, его самые близкие замы и их родственники. В этом круге самая высокая зарплата... Второй круг - руководители отвечающие за результат работы. У этих нормальная зарплата по рынку и именно они руководят непосредственными исполнителями. Эти исполнители составляют третий круг и кадровый резерв для второго.
Кроме ответственности за результат, основная задача второго круга - не допускать возмущенных исполнителей к лицам первого круга... Почему возмущенных? Потому, что зарплата третьего круга минимально возможная. Только чтобы проект не сдох. Иногда правда вынуждены держать экспертов... Но в принципе, все же знакомы с законом Паррето... Когда необходимо обеспечить минимально возможное качество, экспертов много не надо...
Время жизни на первом и третьем круге, как правило значительно превышает время жизни на втором круге. С горящими глазами на втором круге долго не продержишься. По опыту, долго на втором круге держатся персонажи, которые умело превозносят руководство и не менее талантливо перекладывают все проблемы на третий круг. Кроме того,
талантливыйглупый руководитель второго круга может додуматься до того, что он может выполнять обязанности лиц первого круга... Таких вообще убивают сразу, пока маленькие... Благо заменить такого руководителя легко, на эти должности всегда конкурс. Поэтому долго тут держатся не самые умные, а самые преданные. Нет, преданные не проекту. Ну сами знаете кому... ;)Как мне кажется, тут лучше обсудить вопрос: в чем причина того, что во многих организациях сложилась такая система? Или у вас как то по другому?