Управление командой/группой/отделом
Добрый день коллеги, хочу поделиться с вами своим опытом в области руководства группой разработчиков и проблемами, с которыми я встретился. Делаю я это чтобы каждый из вас как итог оставил в комментариях свое мнение, поделился своим опытом. Опишу проблемы и возникающие вопросы. Это очень важно как для личностного роста, так и для получения нового опыта от других команд (как от руководителей, так и от исполнителей).
Начало. Часть команды
Начал я свой путь, как и большинство из вас - разработчиком. Был частью команды из 3 человек. Мне это нравилось. Единственное, руководитель был иностранцем и были проблемы из-за отличия менталитетов и подходов. Но все же в такой небольшой команде мы быстро находили общий язык. Далее, почти всегда (до становления руководителем) я работал практически один в компании/отделе как разработчик. Без коллег разработчиков - был просто разработчиком в единственном числе, который делает все. Для меня это не было проблемой, так как опыт позволял мне в одиночку справится с любыми задачами. Параллельно я постоянно занимался развитием, проходил курсы, не пропускал ни одного митапа в Москве связанный с разработкой.
Да, я помню этот митап, где microsoft презентовал .net webforms, где зал охал, когда увидел первый postback, когда страница перезагрузилась частично. Я был на митапе, на котором показывали рождение windows phone. К сожалению, закат этой технологии тоже увидел (и других тоже) ... и т.д.
Руководство. Команда от 2 до 5 человек
Для меня ничего нового не изменилось, просто из-за большого кол-ва задач мне в команду были добавлены еще 2 человека. Так образовалась команда и я стал лидером, но все еще не ощущал этого. Мне очень нравится наставничество, поэтому никаких проблем с адаптацией новых людей в команде у нас не было. Все члены команды мыслили в одном направлении, все дружно решали одни задачи. Смена места работы никак не влияла на работу и взаимоотношения с коллегами/подчиненными. Со всем коллегами на "ты", все члены команды вовлечены в процесс и полностью в курсе любых изменений и т.д.
Руководство. Команда от 6 до 10 человек
В такой большой команде появились первые проблемы, а именно "бытовые". Банальные опоздания на ежедневные собрания приводили к проблемам, недопониманиям при анализе задач и отрицательным результатам. Так же замечал, что уже не получается сгладить все взаимоотношения между людьми, просто не успеваю. Люди все очень разные, и это отчетливо заметно в большой команде. У каждого свой характер, некоторые просто не командные игроки, но со всеми нужно работать, из них нужно "лепить" специалистов.
Тут хочу отметить, что у нас была продуктовая команда, и мы сами решали, как развиваться нашему продукту. То есть, кнопка будет слева или справа решала команда, а не заказчик (заказчик только верхнеуровнево), в следствии чего были всегда дебаты между участниками. Для решения конфликтных ситуаций приходилось собираться по нескольку раз на внеочередные митинги. Демократия.
Технические трудности - думаю описывать не стоит, их практически не было, сам процесс просто усложняется таким количеством разных ролей в команде.
Тут я на практике понял, что описанное во многих статьях про agile утверждение что рекомендуемая команда до ~6 ~8 человек является правдой. Больше - просто усложняется процесс коммуникации. Так я решил изменить сам процесс, если раньше все "жили" продуктом, были в курсе изменений, вносили свой вклад в каждую новую фичу, то теперь каждый разработчик брал на себя свой отдельный модуль и о других задачах и нововведениях узнавал уже на обзоре спринта (Sprint review) или на ретроспективном совещании (Sprint Retrospective).
Процесс устаканился, но фидбэк от разработчиков был негативный, они хотели участвовать в жизни продукта, а не программировать вслепую. Наверное, все зависит от продукта и нет золотой середины в этом вопросе. Так же важно, что в таком режиме больше ответственности на тимлиде, так как он должен быть связующим звеном между всеми ролями. Сам коллектив уже отчетливо стал делиться на более мелкие группы, и это нормальный ход событий. Каждый занимается своей частью большого проекта. Как итог рекомендую четко определить иерархию внутри таких больших командах и регламентировать процессы коммуникации между ролями и ведении задач от А до Я.
Руководство. Отдел до 50 человек
В такой команде уже проявляется "мини-социум" очень похожий на копию нашей страны в миниатюре. Уже невозможно со всеми быть в очень хороших отношениях. Хотя я очень стремлюсь к этому и мало того в первые недели после устройства на работу я провел около 40 внутренних собеседований, чтобы со всеми лично познакомиться, узнать у кого какой уровень и какими скилами обладает человек. Предыдущий опыт мне очень пригодился. Не всегда было такое количество человек в отделе, штат увеличивался постепенно, но особенно быстро за последние 1-2 года. Не буду сейчас описывать сам процесс и оптимизацию, которую я начал, так как для меня интересен момент взаимоотношения с людьми. В такой большой группе я заметил, что любое слово может кому-то не понравится. Мы все очень разные, как по менталитету (регионы РФ) так и по социальному положению, а тебе как руководителю очень важно чтобы была сплоченность. Поэтому стал вопрос: стоит ли в чате писать что-либо еще кроме официальной информации?
Так же в такой большой группе очень сложно внедрить что-либо новое, для этого нужны активные тимлиды.
Руководство. Группа от 300 человек
Так же являюсь автором небольшой группы в телеграмме для разработчиков, соответственно могу рассказать интересный случай. ИТ группы (форумы/чаты) разработчиков всегда для меня были эталоном нейтралитета, справедливости и толерантности. Я помню, как в конце нулевых почти все сидели на форумах сайта sql.ru, и даже когда по стране шли митинги, или столкновения (не будем вспомнить детали) разработчики на форумах никогда не переключались на политику. Сейчас видимо уже не так. В группе было поздравление по поводу 23 февраля. Неожиданно, но для одного члена группы это было серьезным нарушением его моральных устоев и через несколько нецензурных слов он удалился.
P.S. Буквально сегодня на митапе Let Another Level Алексей Шаграев рассказал коротко о двух книгах в которых описываются подходы и правила управления. В первой говорится: увольняй любого за кого ты не готов биться дальше, во второй - все люди имеют право работать на зарплату и не всегда нужно челенджить сотрудника (сам не читал, примерные слова Алексея). По его словам эти обе книги верны и при этом обе противоречат друг другу и возможно причина в том, что первая книга описывает компанию где работают 100 человек , а во второй 1000.
И я опять же убеждаюсь что от количества человек в коллективе (в подчинении ) очень сильно зависит сам подход.
Завершение
Если можно в комментариях укажите кто вы "руководитель" или "исполнитель", а далее опишите свой стиль работы.
Интересует у руководителя как тесно вы общаетесь с коллективом, что можете себе позволить, а что нет, какие приемы тимбилдинга используете?
Интересует у исполнителя: какими должны быть руководители по отношению к вам? Чего вы категорически не приемлите в действиях руководителя?
Да и в принципе хочется услышать чужой опыт.