15 ‌советов‌ ‌по‌ ‌управлению‌ ‌командой‌ ‌разработчиков

0
275

От редакции. Этот материал подготовлен для нас Вадимом Ивановым, руководителем компании Главкон.

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

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

1. Знайте свою команду

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

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

Во-вторых, это позволит “держать руку на пульсе” — видеть настрой команды, назревающие в ней конфликты и вовремя предпринимать какие-то действия, если в них есть необходимость.

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

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

2. Доверяйте команде и не занимайтесь микроменеджментом

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

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

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

Команда должна уметь работать без вас. Это не делает вас ненужным — это означает, что вы хорошо наладили процесс. И что вы сможете приболеть или пойти в отпуск, не отвлекаясь каждую минуту на проверку почты, сообщений в мессенджере, звонки и тому подобный контроль.

3. Учитесь управлять

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

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

4. Не пытайтесь быть руководителем всё время и во всех ситуациях

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

Одна из проблем, с которой сталкиваются руководители, особенно новички — неумение делегировать полномочия. Зачастую люди думают, что делегировать — значит сказать другим, что нужно делать. Но это не совсем так. Хуже того, такой подход может обернуться микроменеджментом.

Делегирование — это сознательное разделение ответственности. Берясь за новые задачи и обязанности, люди получают новый опыт, оттачивают свои способности, так что передавая определённые бразды правления членам команды, вы даёте им возможность расти.

Несколько советов, как эффективно делегировать полномочия:

  • Найдите желающих. Если вы делегируете какую-то задачу, позвольте людям вызваться добровольцами. Возможно, кому-то из команды нравится заниматься именно этим или они хотели бы научиться это делать.
  • При этом убедитесь, что одним и тем же делом не занимаются постоянно одни и те же люди. Иначе может оказаться, что на время больничного/отпуска и т.д. с задачей справиться некому.
  • Если поручаемое дело не нравится никому, делегируйте его попеременно, так, чтобы все в команде поровну делили нагрузку. Причём ротация должна быть очевидной и прозрачной — так люди будут видеть, что никакой предвзятости со стороны руководителя не существует.

5. Знайте то, чем управляете — но не занимайтесь только программированием

Часто тимлидами/руководителями команды разработчиков становятся программисты, которые получили повышение благодаря своему умению создавать качественный код. И потому, особенно на первых порах, им сложно найти баланс между программированием и руководством. Если это ваш случай, то остерегайтесь двух самых распространённых ошибок. Первая — продолжать программировать, как и раньше. Вторая — перестать программировать вообще.

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

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

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

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

Сколько времени уделять программированию, зависит от многих разных факторов. Найдите свою золотую середину.

6. Будьте последовательны

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

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

7. Будьте примером для команды

Руководитель, на любом уровне — пример для подчинённых, на который если не равняются, то точно обращают внимание все сотрудники. Скажем, если вы чётко соблюдаете правила, то и команда будет серьёзнее относиться к нормам, требованиям и регламентам. Если вы сказали, что сделаете что-то к конкретному времени и делаете это, сотрудники будут знать, что на вас можно положиться, и сами будут стремиться быть надёжнее.

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

8. Обеспечивайте синхронизацию в команде

Разработчики чаще всего работают под давлением дедлайнов и требований заказчиков. Дополнительный хаос не нужен никому, и задача руководителя — обеспечить структуру и распорядок. Это значит, что люди должны чётко понимать, что требуется от них, что ожидается от продукта, что и когда предстоит сделать и кто за что отвечает. Эти пункты должны быть прописаны и оговорены с сотрудниками.

Если у вас большая команда, если часть людей работает удалённо и в особенности если у вас есть программисты из разных стран (то есть с разными культурными традициями), ваша задача как руководителя — добиться того, чтобы все сотрудники знали, каковы ожидания, сроки и требования. Иными словами — обеспечить синхронизацию внутри команды.

9. Предполагайте лучшее

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

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

Конечно, если проблема повторяется, и не раз — это другое дело. В таком случае стоит провести более официальную встречу — поговорить о том, что происходит, объяснить, как это сказывается на всей остальной команде. Спросите человека, что он собирается делать, чтобы такого не повторилось. Пусть сотрудник сам сформулирует решение. Задокументируйте его и через пару недель оцените, выполнил ли он свои намерения.

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

10. Хвалите за успех

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

11. Избегайте многозадачности

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

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

Ещё вариант — дать разработчикам самостоятельно планировать свою работу, заранее обозначив задачи и расставив приоритеты, чтобы люди могли сами решать, как им удобнее распределять своё время.

12. Культивируйте командный дух

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

Что поможет сплотить команду? Ощущение общего дела, принадлежности к команде, дают:

  • Наличие общей цели, когда программисты понимают, что делают что-то крутое и делают это совместно. Когда люди видят, как из-под их рук выходит готовый продукт, работающий, востребованный, и что это они, вместе, создали его с нуля — это очень сплачивает группу и мотивирует на дальнейшие свершения.
  • Участие команды в планировании и ведении дел, когда сотрудники могут обсуждать планы работы и цели проекта, предлагать какие-то практики и влиять на принятые стандарты. Если люди видят, что к их решениям прислушиваются, что их предложения реализовываются, они ощущают гораздо большую ответственность за свой проект и проект, чувствуют свою связь с ним.
  • Личное общение в команде. Это важно, если ваша команда работает на удалёнке или у вас распределённая команда. Взаимодействие лицом к лицу, а не в почте или мессенджере помогает сплотить людей. Поэтому, если есть такая возможность, нужно периодически собирать людей, чтобы они могли поработать вместе и перестали быть друг для друга только именем в чате или адресом в переписке.
  • Совместное празднование дней рождений или каких-то значимых событий — рождение ребёнка, юбилей работы в компании. Не надо ничего грандиозного. Поздравить, вместе попить чай с плюшками, разделить пиццу — этого достаточно: человек будет чувствовать, что он часть команды, а не безликий винтик, что о нём помнят, его знают.

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

13. Признавайте свои ошибки и позвольте ошибаться другим

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

Вы — тоже человек и тоже можете (и будете) ошибаться. Обнаружив свою ошибку, не пытайтесь обманывать команду или перекладывать вину на другого. Честно признавайте свои ляпы и старайтесь их исправить. Ваши люди будут делать то же самое.

14. Если увольняете, пусть всё будет прозрачно

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

Если же вам приходится идти на крайние меры и увольнять кого-то, сделайте так, чтобы и увольняемый, и остающиеся члены команды знали, почему так вышло. Пообщайтесь и самим человеком, и с коллективом, объясните причины, поговорите о последствиях, ответьте на вопросы. Сделайте всё достаточно прозрачным, чтобы люди понимали, что привело к такому исходу. Иначе они будут додумывать поводы и ощущать неуверенность: “раз уволили одного, могут уволить и меня”. Всё это негативно скажется и на работоспособности, и на продуктивности команды.

15. Всегда оставайтесь человеком

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

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

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

Не давайте обещаний, которые точно не можете — или не планируете — выполнить.

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

Помните: ключ к созданию команды и удержанию топовых разработчиков — это хорошее, человеческое отношение и справедливое руководство. Удачи в управлении!

Автор: Вадим Иванов. Руководитель компании Главкон.