?

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
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

к размышлению, раз:
в рисмком праве был пункт "неотвратимость наказания". мягкое воздействие, но каждый раз, дисциплинирует сильнее, чем жёсткое, но "необязательное" наказание.
если водителя останавливали бы при каждом (даже так: Каждом) нарушении и просили просто посидеть в машине 30 минут, есть мнение, что это действует сильнее, чем "штраф 5000р., но меня ещё поймать надо"


к размышлению, два.
"двигай -- выгодой, сдерживай -- вредом", сунь цзы, "искусство войны"

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

еще там же: "если приказы не исполняются, в этом вина командиров, и такие командиры должны быть обезглавлены", но это не про нас )


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

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

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


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

специфики ит не знаю, но если б завтра пришёл на ваше предприятие, для решения этой проблемы действовать стану так:
0. исследование. долго поговорить с каждым по-отдельности о личном отношении к ситуации (нравится/не нравится, выгодно/не выгодно, удобно/не удобно, кто мудаквиноват и что предлагаете делать?)
1. ввести правила. спросить согласия Всех участников процесса ввести Правила и соблюдать их. если совсем операционный бардак, то ввести войскапорядки по собственной инициативе.
2. жжём мосты. дать понять, и делать это постоянно, что это не "еще одно шутливое предупреждение", это -- правила, отступать от них не можно.
3. контроль. опоздал -- получи "люлей". сорвал сроки -- такой же ответ. "вася, уже 9:15! у тебя всё хорошо? я волнуюсь, уже отправил к тебе бригаду спасателей! как проспал? ты же ответственный мужик -- ты не мог проспать, не ври мне, у тебя точно что-то случилось! бросаем с мужиками работу, все едем к тебе! уже в дверях, одеты"

Уволить. Нельзя? Ну тада сами себе злобные буратины.

Я, кстати, сужу с противоположного края 8) Название чудо компании в русском варианте не их 4х слов состоит %?)

Всем написать заявления по собственному с открытой датой

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

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

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

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

Конечно, помогла бы смена команды на 50% (вместе с менеджером). Ибо это позволило бы пересмотреть общепринятые правила и подходы. Кстати, а починить команду надо только менеджеру? Может быть стоит поговорить с командой и выделить инициативную группу?

Загипнотизировать :) И внушить ответсвенность :)

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

если нельзя повлиять на разработку - это неконтролируемый проект, уникальные сотрудники имеют дополнительную проблему "автобуса" http://en.wikipedia.org/wiki/Bus_factor

в итоге:
1) проект не скейлится
2) проект имеет очень выскоие риски в разработке

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

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

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

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

а про недостаточность тестирования программистом вопрос - а не связана ли недостаточность тестирования с недостаточностью требований?

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

>В частности, они все чаще игнорируют процессы разработки, не следуют им, из-за чего написание кода превращается в хаос.
Что это за процессы такие конкретно?

Подозреваю, что на самом деле ситуация развивалась так

1. начинаем новый проект. у всех энтузиазм, глаза горят, срочно-срочно делаем что-то хоть как-то работающее
2. энтузиазм падает, "технический долг" растет
3. в коде появляется всё больше костылей и подпорок. код начинает разваливаться под собственной тяжестью. программисты начинают говорить что-то такое непонятное про проектирование и рефакторинг
4. программистов не слышат, ударными темпами внедряют еще новые фичи.
5. тут внезапно выясняется, что проект уже давно кривой и страшный, как гибрид ужа с ежом, летающий между пальм
6. уже всё плохо. все знают, что всё уже давно плохо и надо всё переделывать. но переделывать дорого, а завтра будет еще дороже.

на мой взгляд, тут нужно
1. задокументировать архитектуру на уровне "из каких соображений вот тогда выбрали вот ту технологию"
2. задокументировать связь и назначение крупных блоков
3. подумать, всё ли хорошо в п2. смело сделать на бумаге схему того, что должно было быть вместо п2
4. и вот после этого начать переписывать всё согласно схеме из п3, а не п2.

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

есть компания с несколькими командами. и только одна команда - причем, какое совпадение, весьма узких специалистов - явно филонит.
по моему опыту, этому есть два объяснения:
1. их не ценят. точнее даже, им не доверяют. и они, эти уникальные специалисты, исполняют роли обезъянок. так долго работать сможет далеко не каждый ценный специалист. ясен пень, их прикармливают изо всех сил, иначе текучка бы этот проект убила. только вот деньгами можно удержать скиллзы, но не интерес.
2. они не понимают, что делают. нет, конечно, они знают свою работу. но не понимают, какого они тут сидят семь лет? уникальная технология - не равно продукт. можно херачить код, отмечать таски и выполнять прочую низкоуровневую рутину, но при этом не понимать, что мы на самом деле делаем, как, зачем, почему и для кого. Не обязательно для этого ежедневно мучить менеджеров этими вопросами и вскидывать руки горе. Не обязательно даже осознавать это, в принципе. Приносить пользу - подсознательное стремление индивидов, и если они не видят, как могут принести пользу, то мотивация падает. зачем делать бессмысленные вещи? а ну да, зп ж получать, ща вот код запилю, таски закрою, отчет напишу, дело сделано, блин скорей бы уже 7 часов, в кинотеатр иду.
наймите хорошего продуктового менеджера. он всем расскажет, что, зачем и для чего делается в этом проекте (в т.ч. и менеджеру проекта). он же сможет вовлечь этих людей в командную работу. Если будут после этого люди, которым будет интереснее _систематически_ филонить - можете их смело заменять. Специалист такого уровня и уникальности не имеет права быть бестолковым.
не, ну можно и запреты попробовать - очевидно же, что сразу все станут хорошо работать)))