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

Привет

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

Ищи проблему в себе, а не в людях. Если человек делает что-то не так как ты хочешь, может ты что делаешь что-то неверно?

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

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

Люди и программисты в частности, делятся на 2 вида: инициативные и неинициативные. Как правило, первых всегда меньше, если в вашем коллективе, хотя бы 5 человек, то у вас, как правило, будет человек не проявляющий огромный интерес к проекту. Как определить таких людей? Основные особенности человека таковы:

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

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

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

Неинициативный программист не равно плохой программист

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

Может ли солдат стать инициатором и что для этого нужно?

Скажу сразу — да. Почему так уверенно? Да потому что я был солдатом, но сменив работу стал инициатором. Почему это произошло? Для понимания опишу обе работы:

1. Мое мнение по большинству вопросов было не очень интересно. Есть Вася, он мидл или сеньер, он знает лучше, а что там говорю я мало кому интересно. Что может сказать человек, который имеет малый опыт? Задачи обсуждало руководство, я просто находился рядом и слушал их мысли. В конце концов, по результату обсуждений в голове у меня была каша. К чему они там пришли не известно. Руководство в связи с этим приходит к выводу, что я летаю в облаках, но на деле слышу за 30 минут сто тысяч вариантов, а к какому варианту они пришли так и не понимаю. Проектом я не горел, для меня это была просто работа на которой я выполняю поставленные мне требования. Вот именно там я и был программистом, который постоянно ждет задачи. Если мне что-то говорили сделать, я делал, сделав я сообщал об этом, а задавая вопрос «Что дальше?» получал дозу негатива со словами «У тебя задач больше нет? Мы вчера пол дня обсуждали, ты вообще слушал нас?» Со временем я не начал глубже уходит в процесс совещаний, я просто перестал задавать вопрос «Что делать дальше?» и ждал прямых указаний из вне. Обстановка накалялась и после фразочки от директора «Ну давай его к батарее привяжем и пусть сидит пока не поймет что делать» я ушел (это и правда так было, вот такое у нас начальство было).

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

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

• Программист должен любить свой проект. Для этого он должен чувствовать, что делает что-то полезное, что его работа приносит людям радость. Понятно, не все компании могут похвастаться такими работами, в таком случае нужно в начале работы объяснить человеку почему и кому ваше дело полезно. Никто не хочет в свои 30 задаться вопросом «А что я сделал за свою жизнь полезного» и не найти ответа.
• Программист должен ощущать свою важность. Он должен видеть, что вы ждете от него инициатив и прислушиваетесь к нему. Если человек сам не предлагает решений, возможно,
  он просто скромный и боится высказывать свои мысли, в таком случае спросите его об этом и ни в коем случае не пренебрегайте его мнением, а уж тем более не высмеивайте его. Если вы не согласны с тем что он говорит, объясните это. Попытайтесь убедить его в вашей точке зрения и никогда не используйте фразу «Я тут босс и я принимаю решения».
• Давайте программисту свободу воли. Понятно, что есть случаи когда нужно сделать что-то прямо сейчас и его «Я не хочу» не очень интересно, но если он твердо уверен, что что-то сделать нужно первым, позвольте ему это. Оставьте свою гордость, если то что он сделает приведет к положительному результату, это будет плюс для вас обоих, если к отрицательному, программист поймет свою ошибку и будет прислушиваться к вам с большей внимательностью.
• Уважайте человека.

Как работать с солдатами?

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

• Ставьте конкретные задачи с подробным ТЗ. После обсуждения приведите все к конкретному выводу. Описание задачи, способов реализации, распределите одно большое задание на более мелкие и опишите их. Да, это затратно по времени, но на продолжительном отрезке вы выиграете гораздо больше часов, чем потратили на составление задания.
• Начните, наконец, использовать канбан, многие о нем знают, но не многие используют. Если в США это стало стандартом и любая, даже самая мелкая задача записывается на доске, то в России есть огромное число компаний не использующих этот инструмент
• Распределите задачи сразу на длинный промежуток времени. Запишите то что должен сделать человек в течении недели. Каждый раз когда солдат закончит работу, следующая задача будет сразу у него под рукой. Мало того, вы сможете с легкостью контролировать процесс разработки. Если просить человека подходить за получением новой задачи к начальству, будут происходить ситуации, когда начальство занято или не на месте. В таком случае программист сидит без дела, а его часы капают.
• Уважайте человека.

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

Как понять кто вам нужен?

Тут все довольно просто. В команде должен быть хотя бы один инициатор, он, как правило, со временем становится тим лидом, на одного инициатора должно приходится 3-5 солдат. На одних инициаторах далеко не уедешь и в конце некоторые из них станут солдатами.

Спасибо за ваше внимание, жду вашего мнения в комментариях.