?

Log in

No account? Create an account

psilonsk


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


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


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

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


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

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

Будете писать глупости, да еще с ошибками, - забаню. Второго предупреждения не будет.

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

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

Думаю, что пункт 1-3 вполне реально выполнить в течение месяца. И по его результатам вырабатывать решение с привлечением собственников и руководства компании. Я бы на "серебряную пулю" сильно не полагался. Уж больно распространенная ситуация, и прогностические, к сожалению, не слишком хорошая.

[Комментарий от менеджера] Вы представляете, что такое "переписать продукт", который делался 7 лет?

Чем лучше сработала команда, тем больше выделять времени на рефакторинг (украшательство кода).

Право принимать решения о приоритетах рефакторинга дать тем, кто не косячил.

Рефакторинг - это и кайф от убитого дракона, и ощущение профессионального роста.

Лолшто? Рефакторинг - украшательство и кайф? Вы определение-то этого понятия знаете?
По теме - да, переписать на мейнстрим. Итерации делать короткими - от двух до одного раза в неделю. Кроме понедельника и пятницы.

Добавлю еще несколько пунктов. очень не понятно роль руководителя этой группы. Он номинальный руководитель или у него есть полномочия? Какая его мотивация на работу? есть ли у него реальные полномочия управления людьми, в том числе увольнять? Как возникла такая ситуация с менеджерами, ведь это не ежесекундное событие?
если данная ситуация сложилась в том числе по "инициативе" прямого руководителя, то ему будет тяжело изменить ситуацию - нужно будет начинать с себя. Это как с детьми, если они чувствуют слабохарактерность родителя, то они будут ездить на нем по самое не хочу. Задача руководителя в этом случае ориентироваться на цели и держать рабочие рамки для коллектива.

[Комментарий от менеджера] Тут вы правы - полномочий не хватает. Вообразите, что они есть. Что тогда?

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

Так потому он к аудитории моего блога и обратился, что не придумывается и не воплощается. )

Начать монтаж системы видеонаблюдения за рабочими местами прям в рабочее время. Монтажники с проводом, стремянками целят новые камеры прям на рабочее место. На монитор. Купольную с тонировкой за спиной поставить. Тож хорошо.
Камера может быть и пустышкой. Монтажи должны уныло кивать и рассказывать, что у них контракт, старший приказал и вообще все пидарасы, пивка бы.
Менеджеру ходить и контролить монтажей, на суету и вопросы ласково смотреть в глаза и по доброму улыбаться, загадочно молчать и по секрету рассказывать про качество кода, бьющихся в падучей на ковре топов и требования кровищи.
На вход в помещения карточки.
Раз в неделю пустив предварительно по секрету в этот обезьянник слушок о проверке, ровно в нуль нуль работа, делигация из юриста, хр и менеджера на входе в офис. Здороваются, пишут в книжечку. Особо ретивым опоздунам выговор приказом с занесением в задний проход. Случаи отсутствия на рм более 3х (не уверен в количестве) часов сделать прогулами, как и положено по Кзот. Объяснительные, росписи в приказах — оч стимулирует.
То что их нельзя увольнять не значит, что им нельзя помочь это сделать добровольно. Тем, кто начнет работать нормально можно будет перестать выкручивать левое яичко. Правое не отпускать. Зарплату начислять пропорционально отрабытому в офисе времени, в случае косяков по результатам работы.

да, кнуты знатно расписаны, понравилось.
а пряники?

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

Про стажеров уже сказали, я разверну немного.

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

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


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

А именно:
1. Сохраняются ли бэкапы сделанного вне группы.
2. Как ведется документация. Есть ли технический писатель? Кто описывает сущности, объекты, функции. Как разработка ведется, есть ли комментарии. Часто сталкивалась, что "безопасностью" считался тот факт, что существовало несколько тысяч страниц распечатанного на белых листах кода!
Есть ли контроль версий, как он ведется, сохраняются ли результаты контроля вне группы.
3. Существуют ли договора о передаче авторских прав, о том, что сделанное в рамках трудовых обязанностей, отчуждается в пользу компании. Зарегистрирована ли программа в реестре программ для ЭВМ на компанию.
Если всего этого нет, то устраивать пляски с программистами себе дороже. Нужно выделить время на то, чтобы нормально наладить менеджмент работ, описание всего, что делается, пусть со скрипом, чтобы исключить крайние варианты, когда обиженные палками программисты просто уйдут.

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

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

Edited at 2014-11-07 03:01 am (UTC)

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

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

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

Для того, чтобы понять, в чем проблема нужно, как минимум, провести интервью с работниками и менеджерами на 2 уровня вверх. Это неплохо работает в случае внутреннего аудитора-хорошего коммуникатора. Мы такие вещи иногда делали.

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

[Комментарий от менеджера] Автор блога по моей просьбе разместил этот кейс. На самом деле очень помогает, с диагнозом все ОК. )))

Поупражняюсь что ли...

Перечитал книгу Карен Прайор. С ее точки зрения использование наказаний не самая эффективная мера для изменения поведения (хотя и наиболее применимая). Попробую предложить варианты изменния поведения в разных стилях по ее классификации :-)

1. "Убить зверя". Поскольку убивать программистов запрещено законом, да и проблемы с кадрами значит надо создать систему, не позволяющую вносить ошибочные решения на сервер. Как вариант, перед тем как код кладется с компьютера программиста в репозиторий проводится проверка по Юнит-тестам и автопроверка на стиль кодирования. Код, не прошедший проверок в общий репозиторий не попадает. Тем самым на базовом уровне они просто не смогут халатно отнестись к документированию и качеству кода. При этом, правда, есть некоторый риск демотивации команды и появления комментариев - заглушек.

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

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

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

Можно и время на рабочем месте фиксировать, только для многих программистов это не показатель - они могут и из дома работать.

4. Угашение: поведению предоставляется возможность исчезнуть самому по себе. - это вряд ли тут получится. Случай уж больно запущенный.

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

В одной из компаний с 9:30 до 10:00 на входе стояла коробка с плюшками. Опаздавшие лишались плюшек.

6. Добиться, чтобы данное поведение совершалось по сигналу. (В последующем вы перестанете давать этот сигнал).
Сделать светофор опазданий. Например в красные дни можно опаздывать на 2 часа, в желтые - на час. В зеленые - приходить надо вовремя. За опаздания к сфетофору - публичное порицание (ребята вы как дети в 2 часа опаздания не уложились). По мере привыкания постепенно увеличивать количество желтых и зеленых дней.

7. "Формирование отсутствия": подкрепляется все что угодно, кроме нежелательного поведения. Выделить "10 смертных грехов разработчика" и потом поощрять людей, которые не проявляли такого поведения за день. Благодарить, уделять им внимание, давать моментальный бонус. 1000 рублей немедленно за правильное действие будет значить гораздо больше чем 20 000 в конце месяца. Поэтому менеджеру имеет смысл договориться, что часть премий идет лично через него и выплачивается тут же.

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

Re: Поупражняюсь что ли...

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

годный вариант. когда я был молодым перспективным инженером, мне поручили целый 1 объект и 8 мужиков. приёмка работы главным инженером была краткой:
-- ну, и кто эту всю *йню придумал? это надо переделать. согласны? все согласны. ты согласен?
а я согласен. я очень согласен.
-- осталось решить за чей счёт будем переделывать. ты не против, если мы переделку из твоей премии вычтем?
а я не против. я даже за, потому что если что-то не понятно -- надо "спрашивать", а не "додумывать самому"

А что это за технология такая? Чисто профессиональный интерес.

К сожалению, попросили не говорить. Иначе сразу становится очевидным, что за компания и что за команда.

С запозданием, но тоже выскажусь.
1. Взять пару молодых и перспективных сотрудников, с опытом хоть отдаленно сходного языка программирования с языком вышеупомянутой программы.
1. Одного подсадить стажером к наиболее адекватному человеку, на освоение системы и перенятые принципов работы.
3. Другого посадить писать паспорт системы, определенной степени глубины(системы не знаю, сказать трудно). Документировать, документировать и документировать. Его надо полноценно посадить на эту задачу.

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

Задача на 4-6 месяцев, примерно.
На второю роль "писателя" взял бы женщину, они лучше справляются с такими задачами. Плюс будет меньше сопротивления коллектива, ей придется много общаться с каждым сотрудником.
Обоих подготовить психологически к сопротивлению в коллективе "вербуя" в свою команду, дабы не произошло обратного процесса.:-)

Чтобы избежать "объединения коллектива на почве общей правоты" все это время надо с коллективом общаться и не терять контроль.

Через полгода будете готовы либо к расставанию с кем-то из особо распустившимися либо к установлению уже своих правил.

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

Программистам? Я потихоньку пост про программеров дописываю, как допишу - почитаете. )