После размещения первого своего поста, я получил то, что и ожидал.
Сообщество разработчиков высказало именно то, с чем я столкнулся когда только запускал свою вторую компанию.
В этом посте, я бы хотел поговорить о «воле» руководителя компании. Когда вы создаете компанию, вокруг вас соберется достаточно большое количество людей, которые будут считать себя «особенными», приближенными к вам и стараться защищать свои собственные интересы.
Мы уже говорили о том, что в компании разработчиков, всегда возникают неформальные лидеры, которые поддерживают свои позиции толкованием различных стандартов и рассуждениями о «чистоте» разработки, стандартизированности процессов и тд и тп. Я упоминал, что количество подобных людей должно быть строго контролируемо вами, и база знаний должна быть равномерно распределена между всеми участниками вашей команды.
Давайте рассмотрим что необходимо вам, как менеджеру, если вы хотите построить здоровый, живой и развивающийся коллектив. Особенность команды разработчиков в том, что это действительно команда. Скажем, в других компаниях может иметь место коллектив, офис, сотрудники, но команда обычно собирается там, где есть люди которые приносят большую пользу своими навыками и умениями и где легко можно определить тех, кто пытается плыть по течению, не внося свой вклад в коллективный продукт. Поэтому компании разработчиков обычно состоят из команд.
Я уже упоминал, что в компании необходимо убирать слишком большое количество «теорестов», искусственных авторитетов, которых вы не можете контролировать и на кого очень сложно полагаться. Очевидно, что как только вы разрушите теократию теоретиков сразу возникнет пустота, которую необходимо заполнить, в противном случае получится только хуже. Пустоту должны заполнить или вы сам, или ваш менеджер.
В любой команде, люди идут за лидером, не достаточно быть начальником, говорить что вы старше или что вы уволите человека. Это все контр-продуктивно. Для того чтобы люди пошли за вами, вы должны стать лидером. Несколько практичных советов по тому, как стать лидером для вашей команды:
1) Никогда не пугайте людей штрафами, снижениями зарплаты, какими-то репрессивными мерами. Как бы это не напыщенно звучало, это контр-продуктивно. Вы получите обиженного сотрудника, который обязательно постарается вам отомстить доступными ему способами. Вы должны действовать очень жестко и в то же время вдумчиво. Если вам нужно чтобы сотрудник выполнял ваши указания, самый простой способ это распределять ответственность между всей командой. Наказывать сотрудника должен не главный начальник, а вся команда. Рассмотрим несколько примеров, когда необходимо заставить сотрудника отказаться в дальнейшем от повторению его ошибок.
1.1 Нарушение сроков и другие операционные ошибки. Поймите, сроки всегда будут срываться. Всегда. Везде. В любом проекте. Поэтому у вас с тимлидом должна быть договоренность о приемлемом срыве срока. Сроков должно быть несколько: «срок разработчика», «срок тестера», «внутренний срок», «срок внутренней приемки», «срок клиента». При этом любой срок далее «срок тестера» должен быть известен только вам и тимлиду. В таком случае, при 10%-30% нарушении срока, вы все еще успеваете выполнить свои обязательства. Но в любом случае, когда нарушает срок разработчик он должен быть наказан.
Самый простой способ это ввод эталонных сроков. Любой тикет, задача, должны оцениваться самим разработчиком и либо старшим разработчиком, либо архитектором. Эталонная оценка, это оценка за сколько конкретную задачу выполнит ваш лучший разработчик. Затем вы определяете что от эталонной оценки может быть отклонение в рамках +-20(30)%. Если разработчик попадает в эти пределы, то все нормально, так как квалификация у разных людей, разная. Если разработчик выпадает за рамки оговоренных пределов, необходимо чтобы команда провела публичное обсуждение проблем, и на очередной ретроспективе публично разобрала случай данного разработчика, и если он виноват, нагрузила его общественными работами, скажем в виде предоставления доклада на тему где он «плавает». При этом доклад готовится строго во вне рабочее время.
Ключевой момент здесь это то, что наказание сотрудника должно проходить в виде процесса, который выгоден всем. Сотрудник теряет свое свободное время, команда получает отличный опыт и доклад, сотрудник растет профессионально и вкладывает в свой интеллектуальный капитал. Слово наказание не совсем подходит к данному контексту, но, для собственного душевного равновесия лучше использовать именно его. Чтобы все понимали что наказания в компании есть и решения об их применении принимаете всегда вы. Вы должны утверждать любое наказание, которые понесет сотрудник.
1.2 Лень. Если человек избегает работы, не желает расти, а вы находитесь в сложной ситуации и надеетесь что он все таки начнет работать и поможет вам вытащить проект, снимите розовые очки. Вы не семья, и не родственники, вы не исправите человека. Если он любит больше времени тратить на разговоры, перекуры, концептуальные обсуждения, при этом его код всегда идет медленно и не очень эффективно. Увольняйте. При этом все люди должны понимать, кто и почему увольняет сотрудников. Даже если это лучший товарищ вашего ведущего разработчика, и вы боитесь что ведущий тоже уйдет, увольняйте. Первая ваша слабина, и вы уже не лидер в команде. Мне приходилось увольнять до целой команды с проекта, когда команда защищала одного абсолютно не адекватного сотрудника, бывшего их другом. Не бойтесь потерять людей, бойтесь потерять ключи к управлению командой. Кстати, из тех людей что я уволил, 70% попросились назад, покаялись и были взяты на работу.
2) Работайте. Когда в команде возникают проблемы по проектам, не «сливайтесь». Даже если вы не самый умный разработчик, вы опытный управленец, и часто, ваши решения могут помочь команде в решение тупиковых ситуаций. Не бойтесь предлагать организационные решения технических проблем. Всегда, в любых обстоятельствах, перед заказчиком берите всю ответственность на себя. Не важно кто у вас в команде «накосячил», перед заказчиком есть вы и только вы. Терпите, выслушивайте упреки и скандалы, потом уже общайтесь с командой. Не кидайте ваших сотрудников на решение проблем с разочарованными заказчиками. Все проблемы с проектами — ваши проблемы. Затем внутри команды, устройте разбор полетов, после решения проблемы. Пример, в одной сложной системе у нас начались проблемы с IIS он начал виснуть так как пошел пик нагрузок, вся команда сидела сутки и не могла ничего сделать, изменения в базу могли народиться только в течении недели, нужно было разделять базы, чтобы иметь возможность разделить правильно сервисы. Тогда я принял решение, что позвонил клиенту, силами наших администраторов развернул дополнительные аппаратные мощности, на них мы распределили нагрузки на сервисы, «купили» себе около месяца, и смогли решить проблему.
Берите на себя ответственность, не бойтесь участвовать в обсуждениях, предлагайте даже глупые идеи. Работайте. Вы должны пахать больше всех и люди должны это видеть.
3) Общайтесь со всеми сотрудниками. Не закрывайтесь в кабинете. Запомните, вы должны стать лидером команды, не позволяйте неформальным лидерам, забирать ваш авторитет. И не потому, что вы злобный и хотите власти. А потому, что когда все неформальные лидеры отойдут от проблемы, один на один с ней останетесь вы. Когда руководитель всей моей группы разработчиков, вместе с двумя ведущими разработчиками, «слинял» из компании оставив долги по зарплате в размере 70 тысяч долларов США, я был вынужден решать проблему сам. Проблема возникла из-за того, что они решили отказаться от ведущего клиента, так как он был «козел», не шарил в стандартах, просил делать «говно»-вещи и тд и тп. Когда же они «просрали» все что можно, то просто сказали у нас проблемы, мы не знаем что делать, мы уходим. Неформальные лидеры, чаще всего «трусы». Они не будут думать о последствиях своих решений для других людей. Они «артисты» и вам, тупым управленцам их не понять. Поэтому будьте лидером, фокусируйте внимание сотрудников на себе.
4) Будьте готовы. Всегда будьте готовы ко всему. Что уйдут люди, что уйдет клиент, что проект выявит странные «черные ящики», которые вы не можете решить. Решения принимать будете вы. Только вы и никто кроме вас. Если вы уже решили стать руководителем, владельцем, компании разработчиков, будьте готовы к ассенизаторской работе. Да, это не справедливо, да это не фильмы с большими белыми офисами, красивыми секретаршами и улыбающимися людьми. Это жизнь. Жесткая правда жизни. Что в компании разработчиков, вы должны быть стержнем и никогда, ни при каких обстоятельствах не паниковать. Вы должны излучать уверенность и убеждать всю вашу команду что вы прорветесь через любые проблемы. Когда в очередной компании у меня было 2 разработчика, и к нам никто не хотел идти так как все было шатко-валко, я всегда говорил, что все будет хорошо, что к нам пойдут люди. Я был психологом, воспитателем, хотя сам не был ни в чем уверен. Иногда, хотелось сказать, блин да я тоже не знаю, что я должен что ли нянькой вам быть? Но уверенность, и целеустремленность всегда дают результат. В той компании мы создали такие условия, что сейчас у нас полный комплект и люди в очереди. А проекты, проекты какие в нашем регионе еще никто не делал.
Четыре простых вещи: Не стращайте, работайте, общайтесь с сотрудниками и всегда будьте готовы, это вам поможет стать лидером в команде, и не бояться смены поколений, лишних людей и шантажа, о чем мы поговорим после.
Автор: undry
