?

Log in

No account? Create an account

psilonsk


Блог об управлении проектами


Previous Entry Share Flag Next Entry
Упражнение для менеджера: программисты и виртуальная палка
psilonsk


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

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

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

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

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

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

Ну а я предлагаю и вам поучаствовать в изобретении такой палки для программистов. ))

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


Жду ваших вариантов. Автор задачки обещал просматривать этот пост регулярно и оперативно отвечать через меня на возникающие вопросы.

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


promo psilonsk february 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

Моральное наказание

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

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

Re: Моральное наказание

Поддержу. Проблема моральная. Значит стоит попытаться её решить морально. Такой армейский вариант - если кто-то проштрафился, значит отвечает весь коллектив. Пусть априори такое негативное поведение сильно наказывается в других отделах, а в этом нет. Тогда люди из других отделов сами им намекнут - дескать нас за малейшую провинность гоняют, а вы тут... Морально должно стать некомфортно подобное поведение со стороны других отделов.

Можно попробовать обмен сотрудников между командами.

Вы невнимательно читали условие. )

(Deleted comment)
(Deleted comment)
Если это возможно конечно, я бы организовал несколько рабочих помещений по разному.
Светлый офис с кофе-машиной, кондиционером и диваном. Новые компы/мониторы, наушники, удобные кресла.
И темный офис со старой мебелью, хламом, стены покрашены зеленой подъездной краской при царе горохе.

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

[Комментарий от менеджера] Идея любопытная, но это невозможно.

1. Ограничить в свободном графике. И потом разрешать послабления только при качественном выполнении работы. Любой человек быстро привыкает к свободному графику и тяжело отказывается.
2. Стандартизация и унификация методик разработки + документирование + внешний аудит (хотя бы в плане архитектуры и методологии). Это даст небольшую конкуренцию и внешнюю критику.
3. Ввести что-нибудь типа agile с публичной доской (особенно хорошо, если она будет висеть на корпоративном портале), чтобы все видели, кто, что и чем занят + каждый на митинге будет говорить всем, что делает или сделал. Зачастую такие уникальные спецы не любят светить своими промахами на весь мир.
4. Принять нового спеца для обучения и передачи знаний, но не включать его в старую команду, а держать по-максимуму на особицу - конкуренция + новая кровь и знания + неопределенность для остальных.

[Комментарий от менеджера] Пункт 2 существует. Но все чаще игнорируется.

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

2. Подкрутить комфортные условия работы для этой команды - до тех пор пока сбои, работаем с 9-00 до 18-00 в офисе под надзором.

3. Нематериальная мотивация - хвалить, отмечать и поощрять другие - нормально функционирующие команды программистов (Мы получаем то, что продолжительное время вознаграждаем).

Ужесточить график работы. Не выполнили в срок - потеряли возможность работать из дома. Сделали не качественно - ходим с 9 до 18 и т.д.

Ок, идея понятна.

У нас когда ввели правила - надо блокировать консоль при отходе от компьютера - все по началу забивали. Но потом 2-3 раза шеф подходил к чужой консоли и отправлял сообщение "to all": "бесплатно угощаю чаем и сахаром у меня на рабочем месте. Если меня не будет, берите прямо из коробки". Человек приходит а у него коробка сахара пустая и куча сообщений в почте "сука, гдеж кофе и сахар!!!" (:

Но это всё, конечно, шутка. По-моему, если люди зажрались и обленились работать, не принимают ответственность за изготовленный продукт - всё это в результате монополизма, то никакие уговоры и шуточные, не чувствительные наказания не помогут. Люди просто перестанут вообще ходить в офис, или будут там появляться раз в неделю.
"Придумать вариант наказания" - не решит проблему. Заставить человека работать может только одно - соревнование. Надо взять дополнительно 1-2 человека и начать по возможности дублировать ключевых специалистов. То, что они охамели сейчас - ещё пол-дела. А если завтра ключевой человек попадёт под трамвай? Или под машину? Кароч, надо новых людей.

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

Хочется пошутить.

Надо их вывести в лес подышать свежим воздухом.

И серьёзно. Согласен с предыдущим оратором. Нанять ещё людей или бизнесу капец (на букву пи).

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

Я бы попробовала так:
1. Ввести план поставок. Например, в течении месяца функциональный заказчик высказывает пожелания, выставляет ошибки, в конце месяца информация анализируется и формируется план поставки с пониманием, что именно будет реализовано из заявок и в какие сроки. План согласуется с заказчиком.
2. По завершению работ софт тестируется. В данном случае, появляется неуникальный тестировщик, которой замотивирован в нормальном продукте.
3. Последним этапом софт сдается заказчику, который проверяет все ли соответствует плану.
4. Если приемка прошла успешно, программисты получают часть премии. Если в течении 2 недель (например) не было выявлено критичных ошибок (или было не больше N ошибок вообще, в общем, как-то так) - еще какую-то часть.
5. Размер бонусного фонда я бы делала в 20% от дохода, 10% отняла от текущего дохода и 10% накинула сверху. Но я не уверена что так можно по кзот.
В течении 2-3 месяцев посмотрела бы как идет процесс, как реагируют программисты.

[Комментарий от менеджера] Да, это все есть, процесс релиза так и сделан. Просто заказчики не такие жесткие - если они чего-то не получают, относятся к этому спокойно.
Премии вне компетенции нашей к сожалению.

Сама из it.
Зря вы так про вариант "не увольнять". Надо-надо. А еще постараться посмотреть в сторону закупки стороннего ПО на сопровожлении. Завязываться на собственные разработки - слишком высокие операционные риски.

[Комментарий от менеджера] Технология действительно уникальна. Если программистов уволить, они небыстро, но найдут работу (за границей). Мы не найдем новых людей быстро. Обучение - полгода и после уговоров учиться.

Компанию создают собственники под свои задачи. как было замечено собственники имеют большие "выгоды" от использования уникального продукта, создаваемого этими специалистами. Те они они условно зарабатывают себе условно монопольное положение ны рынке благодаря этому продукту. Что же делают программисты - они также создают себе такое же уникальное теплое местечко, как сама компания. ...и создают похоже как могут.. отказ исполнять обязательства похоже связан с каким-то протестом сотрудников.. Было сказано, что "премию - это не очень реальное событие", то получается, что получить свою долю булочек от уникального труда им никак нельзя? Если хороший труд не оценивают, а за плохой не увольняют, то зачем работать?
1. Вопрос к собственникам - хотят ли они создавать свой уникальный продукт на уникальных специалистах? Может стоит посмотреть и пока не поздно выбрать более распространенные технологии, где большой выбор специалистов? Если нельзя, то нужно принять факт, что частью своего "бонуса" придется делиться.
2. Донести до сотрудников, что от такой деятельности реальные потери могут коснуться всех, и тогда им будет тоже не легко, так как найти работу узкому специалисту в кризис - это не всегда легко.
3. Еще раз продумать систему мотивации, но не наказаниями... а поощрениями. Бонусы должны быть достижимыми и мотивирующими на хорошее исполнение обязанностей (сдали в срок без увеличения бюджета и тд - бонусы). Прибылью нужно делиться.
4. Вместе с этим ввести монаторий на работу. Те, кто в течении 3 мес-6 мес будут катастрафически невыполнять обязательства и наносить ущерб компании - должны быть уволены. Уволить не всех, а только тех, кто приносит значительный ущерб. смысла держать - нет. При этом остальных сотрудников можно дополнительно премировать за перевыполнение работы уволеннных (из ФОТа уволенных).
5. Взять в отдел стажеров. Путь будут на подмоге, но через какое-то время из них должны вырасти новые кадры. Программа подготовки новых кадров должна быть обязательна, чтобы всех держать в тонусе.

[Комментарий от менеджера] Есть компании, где вы даже не узнаете, кто такие эти собственники. Это как раз тот вариант.

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

(Deleted comment)
чтобы спокойно обсудить проблему нужно минимальное уважение между сторонами, тут его очевидно нет