имею честь представить вам свой скромный труд «Руководство командой разработчиков программного обеспечения. Прикладные мысли». Читать здесь.
ДЛЯ КОГО?
Книга адресована в первую очередь менеджерам проектов и лидерам команд разработчиков программного обеспечения (ПО). Книга будет полезна руководителям отделов и служб ИТ, поскольку позволит им глубже понять особенности разработки программных систем и учесть эту специфику при построении эффективных производственных процессов в подразделении. Думаю, что изложенные мысли могут оказаться полезными в практике HR-служб, для грамотного руководства улучшениями в области подбора, оценки, развития и закрепления наиболее эффективных сотрудников. И, наконец, все остальные участники проектов разработки ПО смогут применить изложенные здесь принципы для повышения личной эффективности: адекватной постановки индивидуальных целей, стратегического планирования личного профессионального и карьерного развития, успешного решения своих задач на основе эффективного взаимодействия с другими участниками команды.
ЧТО ВНУТРИ?
[…] Первая и главная мысль, которою мне хотелось бы донести до читателя, состоит в том, что творческими командами разработчиков ПО невозможно управлять, их можно только направлять и вести. А для этого не достаточно быть эффективным управленцем, необходимо еще получить признание от команды в качестве лидера. Ответ на вопрос, почему прежние методы управления людьми не работают, дан во Введении.
Следующая моя мысль о том, что все люди разные, требуются терпимость и умение принимать людей такими, какие они есть. Недостатки людей – это, как правило, оборотная сторона их достоинств. Следует эти достоинства разглядеть и постараться использовать их с максимальной отдачей для общего дела. В главе 1, на основе последних наработок в типологии Майерс-Бриггс и соционики, обсуждаются профессиональные психологические особенности разработчиков ПО, которые необходимо учитывать при формировании команд, организации их деятельности и их мотивации на достижение общего успеха.
Лидер – это главным образом состоявшаяся личность, поэтому глава 2 посвящена личностному росту и развитию эмоционального интеллекта. В главе 3 рассмотрены вопросы эффективного межличностного взаимодействия и конструктивного разрешения производственных конфликтов на основе доверия и взаимовыгоды, без которых не бывает эффективных команд.
Для российского менталитета командная работа достаточно органичный вид коллективной деятельности. Сельская община, профессиональные артели, рабочие бригады, временные научные творческие коллективы – все это страницы нашей истории. Что такое команда, ее отличие от рабочей группы, динамика ее становления, командные роли участников и стратегии руководителя на разных этапах развития команды – все это обсуждается в главе 4.
Главная проблема успешного командообразования – это создание и сохранение высокой степени мотивации ее участников на общий успех. Но не может быть эффективной мотивации, если руководитель не исключил из своего управленческого арсенала демотивирующие практики. В глава 5 приведен обзор наиболее часто используемых антипаттернов руководства командами, которые приводят к фатальной демотивации исполнителей и делают невозможным создание самоорганизуемой и самоуправляемой команды. Работники приходят в компанию, как правило, не потому, что привержены ее миссии. И не для того, чтобы заработать еще больше денег для владельцев бизнеса. Работая в конкретной компании, участвуя в конкретном проекте, каждый работник стремится к достижению своих индивидуальных целей. «Лучшей заботой о компании будет вовремя сданный проект» (с) анонимный пост на rsdn.ru. Поэтому, в главе 6 рассмотрены вопросы мотивации участников команды на достижение общего успеха в совместной работе, на основе достижения личных целей каждого.
Создание и закрепление эффективной команды — это стратегическое приобретение компании, поэтому последняя глава 7 посвящена вопросам подбора, развития и сохранения эффективных команд.
Мои мысли, надеюсь, принесут вам пользу. Но это произойдет только в том случае, если у вас самих уже возникли аналогичные вопросы «почему». Так как, если вопрос поставлен правильно, то это половина решения проблемы. А если таких вопросов у вас нет, то мои ответы вам, вряд ли, удастся куда-либо приложить.[…]
БЛАГОДАРНОСТИ
[…] Особая благодарность членам сообщества RSDN.ru, в первую очередь, господам под никами bkat, Gaperton, Spidola, Курилка. Мысли и статьи участников я регулярно и с большим интересом изучаю, творчески переосмысливаю и стараюсь использовать в своей работе.
Здравствуйте, craft-brother, Вы писали:
CB>Уважаемые коллеги,
CB>имею честь представить вам свой скромный труд «Руководство командой разработчиков программного обеспечения. Прикладные мысли». Читать здесь.
Большое спасибо. С интересом прочел, нашел немало интересных мыслей.
Однако по ходу чтения осознал вещь, которую не понимал раньше. Принципиального значения она не имеет, конечно, но все-таки...
Всем, в общем-то, понятно, что программисты — зверьки психологически нежные. Ими нельзя руководить — это их угнетает. К ним нельзя применять меры дисциплинарного воздействия — их это демотивирует. Им нельзя навязывать свое мнение — это плохо влияет на их самооценку. Им нельзя говорить, что они хреново работают — критика воспринимается ими, как акт агрессии. С ними нельзя быть неискренним — они умные люди и сразу это чувствуют.
Человек (начальник), который этого не понимает — априори дурак. Если он этого не понимает на форуме rsdn-а — он автоматически огребет мегатонны минусов. Если он этого не понимает просто на форуме — ему в крайне нелицеприятных выражениях объяснят, кто он таков и где его место (место это дурно пахнет и вдобавок, как правило, плохо освещено). Если он этого не понимает в реальной жизни — он получит низкую производительность труда, саботаж и высокую текучку кадров.
Но вот то, что я буквально сейчас с удивлением осознал. Программистов, при всей их сверхъестественной ранимости, почему-то совершенно не обижают методологии управления разработкой, созданные исходя из предположения, что любой программист по определению является капризной примадонной, неспособной владеть собой, да и вообще конструктивно работать в команде без тщательнейшей психологической работы своего менеджера.
Т.е. утверждение, что программисты нуждаются в управлении, действует на многих, как пресловутая красная тряпка на быка. А лишь поверхностно завуалированная оценка программистов в целом, как плохо владеющих собой истеричек (или скорее маленьких детей), почему-то воспринимается сообществом вполне одобрительно. Что лично мне представляется достаточно удивительным, учитывая, что профессия наша почти исключительно мужская.
Как результат — есть множество книг и статей, в которых менеджерам рассказывают о том, как они должны приспосабливаться к психологическим особенностям (а часто — просто капризам) своих разработчиков, но я не знаю ни одной серьезной работы на тему — как программист должен работать над собой, чтобы не создавать проблем своим собственным неконструктивным поведением. Очевидно, что именно менеджерам в силу положения (и как правило возраста и опыта) и полагается нести основную ответственность за психологический климат, но ведь многие вообще отрицают какую-либо ответственность исполнителей.
Это не было бы большой проблемой, если бы мы жили в условиях избытка хороших менеджеров в IT, но ведь на практике-то ситуация прямо обратна — при всей серьезности проблемы нехватки хороших программистов, хороших менеджеров все равно еще меньше. Так разве не является очевидным, что умение жить в команде, правильно понимать своего (пусть и далеко не идеального) PM-а, самому решать свои психологические проблемы является неотъемлимыми качествами профессионального разработчика, причем — более важными, чем многие технические навыки? Как ни странно — нет, не является, массового интереса к этой теме вообще нет. Почему так?
Здравствуйте, mrozov, Вы писали:
... M>...Так разве не является очевидным, что умение жить в команде, правильно понимать своего (пусть и далеко не идеального) PM-а, самому решать свои психологические проблемы является неотъемлимыми качествами профессионального разработчика, причем — более важными, чем многие технические навыки? Как ни странно — нет, не является, массового интереса к этой теме вообще нет. Почему так?
Здравствуйте, sc, Вы писали:
M>>...Так разве не является очевидным, что умение жить в команде, правильно понимать своего (пусть и далеко не идеального) PM-а, самому решать свои психологические проблемы является неотъемлимыми качествами профессионального разработчика, причем — более важными, чем многие технические навыки? Как ни странно — нет, не является, массового интереса к этой теме вообще нет. Почему так?
sc>Нет никакой проблемы — нет интереса.
Проблема есть. А интереса к ней нет, поскольку личности незрелой и инфантильной страшно признаться себе в том, что проблема есть.
Это ведь не только программистов касается. Интроспекция и развитие собственной личности -- дело трудное и часто неприятное. Поэтому легче делать вид, что проблемы нет.
Здравствуйте, TheBeard, Вы писали:
TB>Проблема есть. А интереса к ней нет, поскольку личности незрелой и инфантильной страшно признаться себе в том, что проблема есть.
TB>Это ведь не только программистов касается. Интроспекция и развитие собственной личности -- дело трудное и часто неприятное. Поэтому легче делать вид, что проблемы нет.
Здравствуйте, TheBeard, Вы писали:
TB>Здравствуйте, sc, Вы писали:
M>>>...Так разве не является очевидным, что умение жить в команде, правильно понимать своего (пусть и далеко не идеального) PM-а, самому решать свои психологические проблемы является неотъемлимыми качествами профессионального разработчика, причем — более важными, чем многие технические навыки? Как ни странно — нет, не является, массового интереса к этой теме вообще нет. Почему так?
sc>>Нет никакой проблемы — нет интереса.
TB>Проблема есть. А интереса к ней нет, поскольку личности незрелой и инфантильной страшно признаться себе в том, что проблема есть.
TB>Это ведь не только программистов касается. Интроспекция и развитие собственной личности -- дело трудное и часто неприятное. Поэтому легче делать вид, что проблемы нет.
Я имел ввиду, что все это является очевидным, поэтому неинтересным для обсуждения. Думаю, что в среднем, кол-во "проблем" одинаково для программистских и непрограммистских коллективов.
M>Так разве не является очевидным, что умение жить в команде, правильно понимать своего (пусть и далеко не идеального) PM-а, самому решать свои психологические проблемы является неотъемлимыми качествами профессионального разработчика, причем — более важными, чем многие технические навыки?
Согласен на 100%. Именно эту мысль я хотел донести в главе «Личная эффективность». Видимо, получилось недостаточно убедительно.
Здравствуйте, sc, Вы писали:
sc>Я имел ввиду, что все это является очевидным, поэтому неинтересным для обсуждения. Думаю, что в среднем, кол-во "проблем" одинаково для программистских и непрограммистских коллективов.
Боюсь, что это не так. В непрограммистских коллективах обычно не принято ожидать от непосредственного руководства подтирания попки. Люди чаще всего возлагают ответственность за решение психологических проблем не на начальство, а на себя. Как следствие — проблем становится меньше.
П: Я не понимаю, почему я должен следовать этой архитектуре? Кому она нужна! (У меня
проблемы и мне от этого плохо!)
М: Ты недооцениваешь важность концептуальной целостности системы. (Мне еще раз указали
на то, что я плохой программист!)
П: Без всякой архитектуры я бы мог сделать это гораздо быстрее. (Иначе я не смогу
справиться с заданием в срок!)
М: Ты ошибаешься. Если ты не будешь следовать архитектуре, то пожалеешь об этом, когда
придется ее сопровождать. Следует больше доверять опыту нашего архитектора. (Со мной не
считаются и не хотят понять!)
Ну неужели я один вижу, что этот диалог является точным воспроизведением диалога между мужчиной и его блондинистой истеричной подружкой из руководства по пониманию женской логики?
В силу своей интроверсии, граничащей с аутизмом, программист просто не в состоянии...
Прелестно...
Как получилось, что весьма самолюбивые и обидчивые представители почти чисто мужской профессии стали воспринимать такое отошение к себе, как должное?
Мне кажется, что идеология управления в IT, соглашаясь с тезисом о том, что всю ответственность за процесс несет PM, который при этом однако не должен использовать аминистративные рычаги давления, заводит ситуацию в тупик. Мне кажется, что индустрии необходимо работать над тем, чтобы имидж эмоционально-неустойчивого и слабо мотивированного программиста воспринимался негативно в самой программистской среде.
Мой тезис. Если менеджер в своей работе не умеет применять навыки психолога — он непрофессионален. Если менеджеру в его работе приходится применять на практике навыки психолога — значит его персонал непрофессионален. Для многих это самоочевидно. Но для многих — нет.
M>Мой тезис. Если менеджер в своей работе не умеет применять навыки психолога — он непрофессионален. Если менеджеру в его работе приходится применять на практике навыки психолога — значит его персонал непрофессионален. Для многих это самоочевидно. Но для многих — нет.
Все люди разные. Встречаются программисты, которые волком смотрят, когда пытаешься детализировать им требования с точки зрения архитектуры ("- Я сам знаю как я лучше сделаю!"), а встречаются те, которые хотят чётких детальных формальных требований ("- Сами не знают чего хотят!"). Это вопрос ответственности. Кто-то готов брать на себя ответственность за решения и хочет это делать, чтобы иметь свободу действий, а кто-то боится. Причём обе позиции часто наблюдаются не как чёрное и белое, а просто в разной степени.
В конце концов, если бы программист всегда брал на себя всю ответственность, он бы не работал "на дядю", как впрочем и ПМ
И к каждому нужен свой подход.
VGn>В конце концов, если бы программист всегда брал на себя всю ответственность, он бы не работал "на дядю", как впрочем и ПМ
Хм... Однако в программисткой среде зачастую бытует мнение, что ПМ просто не нужен — он мешает, он непрофессионал, без него будет лучше! Однако, случись что (проблема, нестыковка, или еще что) идет тут-же перевод стрелок на ПМа. Т.е. ПМ воспринимается, как некий мальчик для битья, что в общем-то нехорошо как-то.
N_C>Хм... Однако в программисткой среде зачастую бытует мнение, что ПМ просто не нужен — он мешает, он непрофессионал, без него будет лучше! Однако, случись что (проблема, нестыковка, или еще что) идет тут-же перевод стрелок на ПМа. Т.е. ПМ воспринимается, как некий мальчик для битья, что в общем-то нехорошо как-то.
Не мальчик для битья, а ответственное лицо. Ответственное лицо — это лицо, которое несёт ответственность. А "для битья", "перевод стрелок" — это как кто себя поставит.
Советую ознакомиться с основами менеджмента прежде чем разглагольствовать о "подтирании попок". В часности, с историей развития менеджмента от рабовладельчества до современного времени. И понять, что ИТ это не феодальное хозяйство и даже не капиталистический завод. Отрасль передовая, постиндустриальная, следовательно и управление обязанно быть продвинутым.
M>... не капиталистический завод. Отрасль передовая, постиндустриальная, следовательно и управление обязанно быть продвинутым.
Что, если не капиталистический завод, управляющие ответственности не несут? Чушь! Управление — всегда и везде управление. Недаром все хорошие управленцы поголовно читают Макиавелли.
Здравствуйте, VGn, Вы писали:
M>>... не капиталистический завод. Отрасль передовая, постиндустриальная, следовательно и управление обязанно быть продвинутым.
VGn>Что, если не капиталистический завод, управляющие ответственности не несут? Чушь! Управление — всегда и везде управление. Недаром все хорошие управленцы поголовно читают Макиавелли.
Имелось ввиду, что если раньше для управления применялись принуждение и грубая физическая сила, то сегодня самые эффективные инструменты — интеллект и харизма лидера. К сожалению, стремление понять человека зачастую воспринимается окружающими как слабость. А ответственность никто не отменял.
Здравствуйте, Nikolay_Ch, Вы писали:
VGn>>В конце концов, если бы программист всегда брал на себя всю ответственность, он бы не работал "на дядю", как впрочем и ПМ N_C>Хм... Однако в программисткой среде зачастую бытует мнение, что ПМ просто не нужен — он мешает, он непрофессионал, без него будет лучше! Однако, случись что (проблема, нестыковка, или еще что) идет тут-же перевод стрелок на ПМа. Т.е. ПМ воспринимается, как некий мальчик для битья, что в общем-то нехорошо как-то.
Да ну. Может Вам просто не повезло со средой? У нас, например, никто не считает что ПМ не нужен, впрочем как и на соседних проектах тоже.
Здравствуйте, VGn, Вы писали:
M>>Мой тезис. Если менеджер в своей работе не умеет применять навыки психолога — он непрофессионален. Если менеджеру в его работе приходится применять на практике навыки психолога — значит его персонал непрофессионален. Для многих это самоочевидно. Но для многих — нет.
VGn>Все люди разные. Встречаются программисты, которые волком смотрят, когда пытаешься детализировать им требования с точки зрения архитектуры ("- Я сам знаю как я лучше сделаю!"), а встречаются те, которые хотят чётких детальных формальных требований ("- Сами не знают чего хотят!"). Это вопрос ответственности. Кто-то готов брать на себя ответственность за решения и хочет это делать, чтобы иметь свободу действий, а кто-то боится. Причём обе позиции часто наблюдаются не как чёрное и белое, а просто в разной степени. VGn>В конце концов, если бы программист всегда брал на себя всю ответственность, он бы не работал "на дядю", как впрочем и ПМ VGn>И к каждому нужен свой подход.
Вообще для всего сектора интеллектуального труда свойственно более "чуткое", "психологическое" управление. Разница лишь в том, что с нынешним состоянием дел на рынке труда, программисты могут себе позволить давить на менеджеров. И средства давления — капризы и увольнение. Если бы работу было найти тяжело — каприз было бы меньше. (Ыы, сам программист, и получается говорю против себя же ( )
Кстати говоря, многие "умные" менеджеры понимают что капризничают программисты не просто так. Конфликт возникает когда программист чем то не доволен: Повысили коллегу а не его, низкая з/п (субъективно), решил супер задачу — а менеджер не оценил и т.д. К капризам лучше прислушаться, найти причину и избавиться от нее. Мы ведь все знаем, как дорого обходится замена человека. И опять таки, это относится ко всему интеллектуальному труду, а не только к IT.
Есть еще одна крайность, которую должны учитывать именно хорошие менеджеры. Сам сталкнулся с такой ситуацией: Хорошего программиста, не супер гения, а просто хорошего программиста перевели к нам в команду (с С++ desktop на .NET web). За 3 месяца он не сделал ничего. Абсолютно. Все что делал приходилось переделывать. Уже стоял вопрос о его увольнении, но волею судеб освободилось место на С++ desktop продукте и его перевели туда. Что вы думаете? Человек просто расцвел! Очень быстро разобрался с проектом, уже закончил несколько серьезных задач, постоянно проявляет инициативу и не остается в стороне от общекомандных дел. Начальник очень доволен... К людям относится нужно очень внимательно, и это забота исключительно менеджмента.
Мне, например, нужны свобода и ответственностью. Нужны как воздух. Мне просто необходимо создавать огромные системы, решать задачи клиента, находящегося на другом побережье, чуствовать и нести ответственность за свой код. За свою делову переписку и за принятые мной решения. Именно ради этого я занимаюсь программированием. Но в команде у меня есть человек, который при любой ответственности начинает паниковать, теряться. Только не думайте что он плохой программист, наоборот. Если точно рассказать что от него требуется, предупредить о всех известных ньюансах и расставить приоритеты — он сделает свою работу просто великолепно. Раскопает любой код и соберет обратно. И так соберет что ненарадуешься. А мне вот кровь с носа необходимо самому расставить приоритеты, самому знать все грабли и предупредить о них коллег при первой же возможности. Вы хотите сказать что это не задача менеджера удержать нас, таких разных в одной команде? Раздать задачи так, что бы всем было интересно и все были довольны? А если менеджер этого не сделает, то я буду капризничать и мои коллеги тоже будут капризничать и все мы уволимся подальше от такой компании. (А если бы рынок был перегретым, и работу было бы найти тяжело, то мы бы не капризничали, но КПД было бы очень низким. Прямо как в рабовладельческие времена)
TT>Да ну. Может Вам просто не повезло со средой? У нас, например, никто не считает что ПМ не нужен, впрочем как и на соседних проектах тоже.
Да мне вообще... Не везет...
Хотел быть ТЛ — не вышло — проскочил ступеньку... Хотел быть в софтверной компании не случилось...
Блин, а в мечтах так хочется поработать в нормальной софтверной компании на нормально поставленном процессе разработке ПП...
M>Имелось ввиду, что если раньше для управления применялись принуждение и грубая физическая сила, то сегодня самые эффективные инструменты — интеллект и харизма лидера. К сожалению, стремление понять человека зачастую воспринимается окружающими как слабость. А ответственность никто не отменял.
Хе-хе... Это пока есть куда идти — т.е. есть голод рынка по профессионалам. Как только голода не будет — опять начнется тоже самое — принуждение и грубая физическая сила (ну будет она в виде ора, например)...
TT>Кстати говоря, многие "умные" менеджеры понимают что капризничают программисты не просто так.
Конечно же нет! Однако сама манера сталкиваясь с проблемой — "капризничать" — это реакция истерички, а не нормального, взрослого мужика. Нормальный мужик, сталкиваясь с проблемой, должен ее решать, а не капризничать в ожидании, когда кто-нибудь догадается сменить ему памперс.
TT>Есть еще одна крайность, которую должны учитывать именно хорошие менеджеры. Сам сталкнулся с такой ситуацией: Хорошего программиста, не супер гения, а просто хорошего программиста перевели к нам в команду (с С++ desktop на .NET web). За 3 месяца он не сделал ничего. Абсолютно. Все что делал приходилось переделывать. Уже стоял вопрос о его увольнении, но волею судеб освободилось место на С++ desktop продукте и его перевели туда. Что вы думаете? Человек просто расцвел! Очень быстро разобрался с проектом, уже закончил несколько серьезных задач, постоянно проявляет инициативу и не остается в стороне от общекомандных дел. Начальник очень доволен...
Отличный пример! Сам от такого как-то пострадал. Однако из этого примера можно сделать и прямо противоположный вывод.
Хороший программист добровольно согласился на перевод на другую технологию. Никто ему пистолет к виску не приставлял. Он мог отказаться. Он мог уволиться. Но он дал свое согласие.
После этого вместо того, чтобы освоить новую технологию и начать с ней работать (как это делают нормальные люди) "За 3 месяца он не сделал ничего. Абсолютно.". Это называется — непрофессионализм. В таких случаях нужно либо отказываться от работы, либо сжать зубы и делать через "немогу". Понятно, что эффективной работы не получится — это очевидно. Понятно, что это яркий пример неэффективного использования ресурсов. Это все — очевидно. Но и ваш "хороший программист" в этой истории себя показал с далеко не лучшей стороны.
То, что менеджер в своей работе обязан учитывать психологические моменты — это очевидно. Но вот предположение, что любые проблемы в проекте — это по-определению проблемы менеджера и других они не касаются — явный перебор.
Ну что там далеко за примером ходить — рядом лежит топик про мотивацию. Тимлидер спрашивает — "вот у меня люди потеряли мотивацию, не работают — что делать?". Ему отвечают — "это потому, что ты — хреновый менеджер". Нет, ребята. Это потому, что они — хреновые программисты. А хороший менеджер отличается от просто менеджера как раз тем, что непрофессиональные исполнители не в состоянии сорвать его проект, потому что он знает, как нивелировать их недостатки.
Здравствуйте, mrozov, Вы писали:
M>я не знаю ни одной серьезной работы на тему — как программист должен работать над собой, чтобы не создавать проблем своим собственным неконструктивным поведением.
Не в тему и не для программистов (рассчитано на менеджерско-тимлидскую аудиторию, как мне показалось), но прочтение Steve McConnell, Rapid Development очень и очень помогает в плане "работать над собой".
А вообще подумалось, а с какой стати программисты будут стремиться "не создавать проблем", если за это денег не платят? Это же на собеседовании не очень заметно Это потом, когда-нибудь, когда будешь увольняться , может-быть, скажут, мол, приятно было поработать. Не способствует современная рыночная ситуация и отношение "типичного" менеджмента росту программистов "над собой" — думается, вполне обычным будут размышления из серии "некогда читать всякую психологию и прочую муть, для этого надо мной есть ПМ да девочка-айчарка, им за это деньги платят, а у меня тут фреймворк v.3.1415.926 вышел, надо учить новые фичи, пора коллегу за пояс заткнуть"
Еще, кстати, интересно — какой процент народу из ПМно-ТЛного менеджмента действительно "работает над собой" ?
