29 основных ошибок, которые совершают программисты, становясь руководителями @ EXECUTIVES.RU

29 основных ошибок, которые совершают программисты, становясь руководителями

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

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

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

В-третьих, те материалы, которые есть про управление людьми, они часто не ориентированы именно на программистов. А это очень, очень необычные люди. Технические и творческие одновременно.

Наконец, вы вдруг обнаруживаете, что кроме ваших сотрудников есть еще ваш начальник и коллеги менеджеры. Со своими амбициями, желаниями и пониманием, что такое хорошо и что такое плохо. Как с этим жить, тоже пока не очень понятно. А в книжках про это тоже пишут не очень…

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

Команда

Ошибка №1. Нанимают людей глупее себя. Происходит это обычно из-за простого самолюбия. Когда начальнику очень тяжело смириться с тем, что кто-то в его команде будет умнее. Кто-то в его команде, вы только подумайте, будет программировать лучше него! Этак он найдет код, написанный начальником, и – о боже! Он же его разнесет в пух и прах!

К чему это приводит – очевидно. Все сложные задачи начальнику придется решать самостоятельно. Задач будет все больше и больше, времени – все меньше и меньше.

Ошибка №2. Просят рекомендации на человека до собеседования. Есть такая статистика, что только 5-10% людей нанимают через объявления. Все остальные приходят на собеседования по знакомству. И действительно. По знакомству нанимать как-то понадежней будет.

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

В итоге, человека нанимаете, а он оказывается, не такой классный.

Ошибка №3. Полагаются на симпатию. Во время собеседований некоторые менеджеры смотрят, насколько им симпатичен собеседуемый как человек. Если симпатичен, то нанимают. Ну, потому что, если человек симпатишный, то он, скорее всего, неконфликтный. То есть в команду впишется нормально. А знания – дело наживное. И нанимают. В итоге, потом часто получают симпатичного человека, но слабого инженера. Со всеми вытекающими.

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

Ошибка №5. Не просят написать код. В жизни такое встречал очень часто. Когда человеку задают много теоретических вопросов, или даже практических, но код написать не просят. Это очень смешно. Примерно, как нанимать жонглера в цирк, но не попросить его пожонглировать.

Ошибка №6. Оценивают только текущие знания человека. Иногда на собеседовании задают очень много вопросов на текущие знания. Причем, часто спрашивают то, что можно за пять секунд найти в хелпе или Гугле. Типа: перечислите наизусть все методы класса java.util.MegaClass. Оправдание очевидное – «нам нужно, чтобы человек сел и сразу начал работать». Однако, программирование – такая область, где знания очень быстро устаревают. Текущие знания станут бесполезными через два года.

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

Люди в команде

Ошибка №7. Методологии – это все. Часто встречающееся заблуждение task-oriented менеджеров, это то, что если следовать вот именно этой методологии, то все будет хорошо.

Проблемы начинаются сразу при попытке методологию внедрить. Будет публичное неприятие, потом якобы согласие и саботаж, много чего интересного будет… Но фокус в том, что ни одна методология не застрахует вас от, скажем, семейных проблем у программистов. Или того, что другая компания начнет агрессивно нанимать людей. А времени на то, чтобы подстраховать незаменимых людей, отдокументировать весь код, справиться со всеми рисками, не будет ни-ког-да.

Решают не методологии, а люди.

Ошибка №8. Неправильное использование метрик. Люди творческие, к которым программисты относятся, вне всякого сомнения, очень не любят, когда их измеряют. Потому что считают, что их творчество и полет мысли нельзя измерить.

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

В итоге, часто менеджеры начинают поощрять тех людей, у которых в смысле метрик все хорошо, и не поощрять тех, у кого плохо. Главный момент состоит в том, что исправить метрику – очень легко. Что нужно сделать, чтобы строк кода было побольше? Почаще использовать copy-paste. Поменьше функций, побольше кода в функциях на десять экранов! В итоге по метрикам все становится хорошо, но если заглянуть внутрь, то – ужас, ужас…

Причем, заметим, что метрика не всегда однозначна. Если взять какой-нибудь продукт, например «Сапера» стандартного. Один инженер написал его в 1 тыс. строк кода. Другой в 20 тыс. строк кода. Кто молодец?

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

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

В общем, непонятно. Надо разбираться. Метрика – это сигнал, что надо разобраться. Не более того.

Ошибка №9. Бюрократия. Любят ли творческие люди бюрократию? Не надо быть семи пядей во лбу, чтобы ответить на этот вопрос. Однако, многие менеджеры любят отчеты. Поподробней, почаще. Понятно, что в отчетах иногда есть необходимость. Но еще чаще необходимости именно в том, чтобы присылать отчеты именно такой формы и раз в два часа – нет.

В одном из проектов мы, помнится, заполняли отчеты строк на 70 со списком заданий и по часам – кто что сколько делал. Потом наводилась статистика, сколько у нас уходило на то, на се. Были ли люди счастливы от таких отчетов? Нет. Тратили ли они на заполнение отчета много времени. Да, тратили. Нужна ли была кому-то эта статистика? Практически, нет.. Достаточно было собрать данные за месяц. А не писать эти отчеты полгода.

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

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

Люди – они очень адаптивные. Поощряется процесс, а не результаты? Будет процесс, не будет результатов.

А заказчик, заметим, платит в итоге за результат, а не за процесс.

Ошибка №11. Одновременно несколько задач. Мы все с детства знаем верный способ не поймать ни одного зайца. И почему-то очень часто пытаемся повторить эксперимент на работе. Со своими сотрудниками.

Человеку дается два задания, которые он должен делать одновременно. Или четыре задания, так еще надежней.

Чтобы эффективно начать делать задание человеку нужно время на «включение». Если делать их одновременно, то на переключениях будет теряться куча времени.

В итоге, задания будут делать медленней, чем если их делать друг за другом. Люди будут расстраиваться, что ничего не успевают. От этого делать еще медленней. Еще расстраиваться. И так до печального конца.

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

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

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

Ошибка №13. Мало разговаривают с людьми. Когда я стал менеджером, я, естественно, совершил не 29ошибок, а гораздо больше. Одно из первых была именно эта – я мало разговаривал с подчиненными. С некоторыми встречался вообще раз в месяц на уровне «привет-пока». Ну, группа была достаточно большая, но это, конечно, не должно служить оправданием. В итоге, при разделе нашей компании со мной в новую компанию перешло два человека. Из 17. Причин было много, но одна из них – необщение.

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

Ошибка №14. Интриги в команде. Тут есть две фазы. Первая – менеджер не препятствует интригам. Вторая – он их поощряет и создает.

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

Первая фаза – гораздо более распространенная. Когда какой-то из сотрудников начинает жаловаться на другого, что тот пишет кривой и неправильный код, делает идиотскую архитектуру, «явно видно, что он некомпетентен» и пр., и пр. (Заметим, что обычно это говорится в оправдании собственного неуспеха, т.е. не успел что-то закончить вовремя, потому что чужой код весь в ошибках и т.д.) А менеджер все это слушает, но ничего не делает. Тем самым, поощряя подобные некомандные проявления.

Ошибка №15. Публичная ругань. Речь идет не о «матом на людях». Речь идет о том, что если сотрудник совершает какую-то ошибку, то многие менеджеры выговаривают ему об этом прилюдно. Либо устно, либо письмом на всю команду. «Я уже много раз писал о важности прогона тестов перед заливкой изменений в пространство. Однако Вася, как обычно, моих писем не читал…»

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

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

Ошибка №16. Не хвалят и не говорят спасибо. Есть такая распространенная установка, что если сотрудник работает хорошо, то это само собой разумеется. А вот если плохо, то это требует внимания начальства.

Это, разумеется, неправильно. Тут как с детьми – нужно обязательно поощрять правильное поведение. Причем публично. Чтобы остальные дети видели, что такое правильно, и как оно нравится родителям.

А спасибо… доброе слово оно и кошке приятно.

Ошибка №17. Не говорят плохих слов. Плохое поведение тоже нельзя оставлять безнаказанным. Однако, многие менеджеры, которые хотят быть очень people-oriented, стесняются говорить «плохие» слова своим сотрудникам. Считая, что поощрения хорошего поведения должно хватить.

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

Начальство

Ошибку №18. Не управляют своим начальником. Очень многие менеджеры занимают исключительно пассивную позицию по отношению к начальству. В чем это выражается?

«Нам говорят – мы делаем». Почему-то мало кто хочет сам придумывать себе, что делать. Большинство уверены, что это задача начальства говорить, что делать.

Второй симптом – уверенность, что мнение начальство изменить нельзя. Причем, настолько нельзя, что некоторые даже не пытаются. (Заметим, что изменять мнение – это не обязательно вступать в открытую конфронтацию.)

Все остальные ошибки относительно начальства, по большому счету являются следствием этой.

Ошибка №19. Не говорят начальству «Нет». То есть воспринимают слова своего менеджера как приказ к исполнению. Тем более, что, сказать «нет» означает поставить под сомнение авторитет самого! Что интересно, что чем больше начальник, тем обычно более адекватно он воспринимает мысли и возражения подчиненных. По крайней мере, мой опыт общения с большими менеджерами подтверждает это на все сто.

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

Ошибку №20. Боятся донести до начальства плохие новости. Потому что, один раз не сказав «Нет», подписываются под нереальными сроками. После чего дела становятся все хуже и хуже. А доносить эту новость до начальства все страшнее и страшнее. И так по замкнутому кругу. Пока не происходит большой упс.

Слабые менеджеры пытаются выйти из ситуации, совершив:

Ошибку №21. Пытаются свалить вину на команду. Это может прокатить, только если вашим начальником является полный идиот или абсолютно беспринципный человек.

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

Плюс, один раз свалив вину на команду, можно смело из нее уходить. Отношения с людьми уже не наладятся.

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

Ошибка №22. Критика начальства. Это когда вы сваливаете вину на начальство. И вместе с командой переживаете, какое же оно, начальство, тупое.

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

Вы сами

Ошибка №23. Переработки. Некоторые люди почему-то думают, что много работать это очень хорошо. Если менеджер не перерабатывает, то он плохой менеджер. Это очень странная точка зрения. Потому что карьера не идет вверх от количества работы. Она идет вверх от ее качества.

Переработки плохи очень многим.

В первую очередь страдает семья и личная жизнь. Просто потому что на них остается меньше времени.

Есть такое мнение, что у каждого человека обязательно в жизни должно быть три вещи: работа, семья и хобби. Если у человека все это есть, то все у него хорошо и гармонично развивается. Как только что-то одно начинает пожирать время за счет другого – счастья не жди.

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

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

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

Следующие несколько ошибок как раз являются причинами переработок.

Ошибка №24. Замыкание информационных потоков. Что это значит? Это значит, что менеджеры не делятся какой-то информацией, предпочитая быть ее единоличным обладателем. Опять же, по себе знаю, что это очень приятно обладать каким-то знанием, которым мало кто обладает. Потом можно при случае его выгодно выложить. Это приятно, как-то собственная важность повышается, но это отнимает очень много времени. Потому что без вас ничего решиться не может.

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

Ошибка №25. Микроменеджмент. Микроменеджмент – это, на самом деле, такая форма недоверия человеку. Вы дали ему какое-то задание. Но не доверяете ему его выполнение. Поэтому вмешиваетесь как можно чаще и говорите ему, какие именно кнопки нажимать. Тут несколько негативных факторов:

Во-первых, это отнимает массу времени.

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

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

Еще одной ошибкой, связанной с недоверием, является:

Ошибка №26. Отсутствие делегирования. Вы были хорошим программистом. Потом стали менеджером. И вот прилетает техническая задача, которую вы можете сделать за два дня. А можете делегировать ее сотруднику и он ее сделает за неделю, при этом три дня будет вас спрашивать, как и что делать.

Конечно, делаете сами. В итоге, сотрудники не учатся, и потом вы делаете сами все время (см. «Переработки»).

Частным случаем этой ошибки является желание самому сделать работу интересной.

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

Сотрудникам это нравится. Но что плохо – что они начинают считать, что это задача менеджера – делать работу интересной. А, на самом деле, это задача каждого сотрудника делать ее интересной. “There is no boring job, there are boring people” ((c) Jim McCarthy).

Ошибка №28. Переделегирование. Но вот вы уже продвинутый менеджер и знаете, что задачи надо делегировать. И раздаете их направо и налево.

Может случиться вот какая проблема. Если человек не готов выполнить задачу, то ему нужен плотный контроль и поддержка с вашей стороны. Если же вы доверяете ему слишком много и не контролируете совсем, то он может и не прийти к вам, даже если видит, что сам не справляется. Он может все пытаться сделать сам, а потомрасстроиться и все ран воне прийти. В итоге получится несделанная задача и демотивированный сотрудник.

Ошибка №29. Считают, что результаты – это все. Эта ошибка особенно часто встречается у российских менеджеров. Они почему-то уверены, что главное, чтобы команда производила результаты. А дальше их (менеджеров, не результаты) заметят и произведут в следующий чин.

А почему-то не замечают. А в табели о рангах растут люди, у которых в командах вроде и с результатами как-то похуже… Почему так? Несправедливость? Нет, отсутствие работы над визибилити.

—————–
Ну, пока хватит. Можно было бы легко довести количество ошибок до 50, но пока не будем. Для выживания как менеджера программистов вполне достаточно избегать этих базовых ошибок. А если вы их уже совершаете, то срочно исправить.

Если вы исправите хотя бы три ошибки, которые вы у себя обнаружили, то эффект уже превзойдет все ваши ожидания. Главное – делать!