Привет, Хабр! Я Кир Дергачёв, руководитель разработки в Нетологии. Приглашаю вас обсудить умозрительные модели команд разработки, которые нам предлагает каждая вторая конференция, и посмотреть на свою реальную команду трезвым взглядом. Также я расскажу про все этапы тимлидства и что сам понял, пройдя их и наступив на все возможные грабли суровой рабочей действительности.
Мой путь к тимлидству
Сам я родом из науки: четыре года пытался писать диссертацию, дописал и бросил в самом конце. Занимался темой прогнозирования, другими словами — построением модели, которая предсказывает будущее по каким-то параметрам, что есть уже сейчас. С таким бэкграундом я и попал в разработку. Это отлично помогало мне в деятельности разработчика, потому что это, по сути, то же самое.
Мне всегда хотелось иметь большую зону ответственности. Поэтому логично, что наступило время, когда я становлюсь тимлидом. Начинаешь делегировать, отпускать из своих цепких рук интересные задачи и отдавать их другим людям, чуть-чуть проявляешь технический авторитет.
Никакого поворотного момента, когда становишься тимлидом, не происходит. Происходит он ровно в тогда, когда становишься руководителем тимлидов. И тут я узнал, что, оказывается, надо ещё больше делегировать и по-хорошему на 100% отпустить всю эту историю с кодом. На самом деле, это оказалось легко. Когда у тебя есть такая мотивация и возможности, ты легко отдаёшь свои полномочия людям. Находятся разработчики, которые тебя в этом поддерживают. Ты подаёшь сигнал, и сразу же люди понимают, что они готовы взять на себя твои обязанности.
Когда становишься руководителем, ты уходишь в полный отрыв от команды: всё, у тебя уже нет людей, тех самых разработчиков и того самого уюта, о котором я говорил в самом начале — когда ты можешь зайти на ежедневный синк, посидеть вместе, увидеть, как делается продукт.
Что на самом деле происходит, когда становишься руководителем
Возникает тот самый синдром самозванца. Ты считаешь, что тебе нужно овладеть каким-то инструментом для того, чтобы быть крутым в своей сфере, контролировать ситуацию, которая происходит, обмениваться с коллегами этими знаниями о том, какой фреймворк ты применил.
Если разработчиком ты применял это интуитивно: вот он результат, готовый разработанный продукт на проде. Когда ты руководитель, понимаешь, что твои результаты придут через полгода, может, даже через год — трансформации, которые ты запланировал, не будешь видеть до тех пор, пока они не завершатся и не будут измерены.
Можно, конечно, продумывать чекпойнты, чтобы поэтапно преподносить свою деятельность. Потом ты понимаешь, что это и есть часть твоей работы. Теперь нужно презентовать свою деятельность. Тимлидом тебя могли вытащить и попросить рассказать о своих достижениях. Окей, встаёшь на демо и говоришь: задеплоили столько-то изменений, пофиксили столько-то багов. Тут же эти знания о том, что ты сделал, становятся более абстрактными. Они понятны менеджерам выше, они понятны директорам, но совершенно непонятны команде тимлидов и разработчиков.
Это постоянный стресс. Ты не понимаешь вообще, что от тебя требуется. И тебе дают фидбэк уже гораздо реже, потому что подразумевается то, что ты сам понимаешь, что от тебя требуется.
Потом возникает новый кризис, когда ты уже устаёшь изображать из себя знающего человека. Пересматриваешь убеждения, обращаешься к специалистам и понимаешь, что твоя роль не особо велика. У тебя много тимлидов, они выполняют всю работу. Ты помогаешь им достигать глобальных целей, которые есть на уровне компании. И это не обязательно какая-то яркая роль.
Можно ли стать тимлидом, прочитав книжку
У нас есть инструменты для оценки команды: харды и софты. Предлагаю называть это измеримыми и неизмеримыми навыками.
Вот проектирование сложного приложения. Что оно есть само по себе? Это какие-то базовые навыки вроде знания UML, прости господи, если кто-то использует это, и неизмеримые навыки вроде коммуникации. Одно мы можем измерить, провести тесты. Вторую — коммуникацию — можно оценить фидбэком. Но всё это такая петля с обратной связью, очень-очень длинная и, честно скажем, неизмеримая. Это субъективные впечатления.
У разработчиков есть особая привычка, которая создаёт ложные аналогии и приводит к ошибочным выводам. Например, программист хочет выучить Java: берёт книжку с картинками на обложке от издательства O’Reilly, выбирает определённое животное и изучает, потом приступает к практике, некоторое время практикуется, проходит сертификацию, и всё — он специалист.
Когда человек становится руководителем, даже тимлидом, он по привычке спрашивает: «Слушай расскажи, а что почитать по тимлидству?». Почему почитать? Почему нужно именно брать и читать книгу? Так мы создаём ложные аналогии. Вроде как, есть знание, а значит, оно в книжке хранится или в курсе. А это могут быть практические навыки. Это может быть сначала практика, столкновение с неудачами, столкновение с реальностью, потом — рефлексия и обучение. Ложные аналогии приводят к тому, что человек разочаровывается.
Все стадии тимлидства
Тимлиды не бывают джунами. Легко быть разработчиком: ты джун, к тебе низкие требования. Но если ты тимлид, скорее всего, ты очень опытный человек в разработке и нулевой, как руководитель. Но ты уже исполняешь свои обязанности. Так возникает первый персонаж — наш оперившийся тимлид.
Что чувствует наш персонаж? Он улыбается, довольный, смотрит вперёд. Будущее прекрасно. Возможно, зарплата уже новая приходит. Перспективы отдалённые вырисовываются, пока он цели какие-то выполняет в свой испытательный срок. У него эйфория от всего нового. Ну, и опасность он воспринимает адекватно.
Здесь у тимлида хорошая, но опциональная мотивация — проявить себя. Потому что в первую очередь ему хочется выжить. Скорее всего, он может сделать много неправильных действий. Но и проявить себя он хочет. Хочет стать человеком, который понимает шире, как устроена команда. Ему хочется развивать других разработчиков.
Начинающий тимлид осторожен. На кривой Даннинга — Крюгера он находится где-то в начале, ещё не пошёл по кривой вверх. Он адекватно воспринимает реальность, понимает, что ничего не знает. Эффект Даннинга — Крюгера прекрасно работает на простых и некомплексных задачах для своего уровня знаний. Например, как джун, ты можешь hello world написать, а как синьор — создать приложение с нуля, и это будет привычная для тебя работа.
На комплексных же историях эффект Даннинга — Крюгера не подтверждается. Когда задача многосоставная, эксперты оценивают ситуацию хуже.
На простых задачах, где есть позитивная динамика, лучшие исполнители также являются наиболее точными в определении своего положения, но в то же время на сложных задачах, где есть отрицательная динамика, худшие исполнители являются более точными.
Опровержение категоричности «эффекта», выдвинутое Бурсоном, Ларриком и Клейманом
К сожалению, этот момент так и не изучили подробно. Но мы попробуем предположить, почему происходит именно так. Ты эксперт, ты считаешь, что тебе подвластны сложные и комплексные проекты. За жизнь ты уже несколько раз прошёл эти проекты и думаешь: следующее-то я точно сделаю. Ты берёшь крупный проект и говоришь: «Слушайте, вот эту систему создали, это интегрировали, это звучит похоже. Ну, окей, давайте год обозначим». А потом уходите в полное пике и не можете из него вырулить.
Человек неопытный приходит, и, знаете, не хочется сравнивать молодого тимлида с младенцем, но устами младенца глаголет истина, он смотрит свежим взглядом и говорит: «Слушайте, очень сложно». Это оценка пальцем в небо в соответствии со своим страхом и чувством самосохранения, но он оказывается правее, чем опытный человек.
Деятельность управления командой является комплексной. Тяжело оценить и смоделировать работу нескольких систем, если группу людей считать системой. На каком-то размере это становится настолько запутанно, что иногда модели дают сбой.
Все знают стадии развития группы по Такману. Вначале команда формируется, затем её штормит, что-то падает вниз. Большинство из этой модели, честно скажем, запоминает красивую кривую прогресса и перформинга. Но если у нас всё падает, мы уже не смотрим на последние стадии. Нас интересует то, что у команды бывает шторминг.
У этой модели есть свои ограничения. Американский психолог Брюс Такман исследовал тысячи экипажей подводных лодок в автономном плавании по заказу Министерства обороны США. Малознакомые люди собираются и на полгода уезжают в плавание. У нас же в командах люди редко малознакомые.
Я решил проверить свои ощущения и поспрашивал у знакомых, когда, по их мнению, возникает шторм. В среднем, ответ — от недели до месяца. У некоторых этого и вовсе не происходит или случается через год. Всё потому, что мы живём в одной среде: есть индустриальные договорённости, линтеры, agile-манифест, а тимлиды ходят на конференции, слушают всё, уравнивают знания. Шторм может не возникать долго, но он существует. Возможно, один продукт вы сделаете успешно на этих договорённостях, а потом вскроется что-то прорывное, что вызовет спор.
Модель Такмана оценивает эффективность команды. Но как её померить? Если эффективность измерять в задачах, то на графике будет много прямых: команда берёт по привычке одну большую задачу, она не декомпозирует её. На всех этапах её штормит, окей, там ноль задач. Дальше опять единичка, и пошли прямо. Непонятно, что это за эффективность.
Парадоксально, но нашему начинающему тимлиду удаётся не отрываться от реальности. Чувство самосохранения не даёт ему брать эти модели, применять их в реальности, мучить своих людей, с которыми он вчера общался как с коллегами, обсуждал действия тимлида, руководства. Он даже жалуется, зачем какие-то эксперименты проводить, какие-то воздействия применять. Ведь мы все взрослые люди, зарплату получаем, продукт делаем.
По прошествии всех этих этапов появляется тимлид. Он уже с инструментом. Не агрессивный, но уже уверенный, смотрит реалистично. Он успешен, как он думает. Ему хочется воспроизвести этот успех для того, чтобы сэкономить энергию. Эйфорию преодолел, получил результат, команда твоя, а что ты делаешь? Где-то ты присоединился к результату, по инерции всё это происходило, и ты себе приписал успешно завершённый проект. Супер! Менторинг — окей, я развил человека. А он сам развивался, ты просто рядом стоял.
Тебе хочется на всех этих действиях сэкономить силы, и главное — понять, что делать дальше. Разработчиком ты ещё понимаешь, что делать дальше: например, стать тимлидом, архитектором, какую-то нишу занять отдельную. А тут ты в возвышенном состоянии, но что дальше через год, два, три — непонятно.
Осторожность у тебя на нуле, потому что ты уже умеешь всё. Есть набор «для выживания»: один на один проводишь, интуитивный тимбилдинг строишь, копируешь модели авторитетных для тебя людей, немного делегирования здесь, проектного менеджмента там. Вот он, пик самоуверенности.
И тут руки тянутся к чему-то хардкорному. Психотипирование, соционика, какие-то психологические теории, манипулятивные техники. Ты понимаешь, что это знание, оно структурировано, можно его брать и использовать. По такому же принципу, как и компилятор работает. Можно что-то рефакторить, по-другому реализовать, но система, компилирующая код, нас прикроет и всё проверит. Тут надо сказать, что я не специалист по психологии и рассматриваю эти инструменты исключительно в прикладном смысле и по данным из открытых источников.
Например, такая вещь, как треугольник Карпмана очень хорошо заходит в мозг молодому тимлиду.
Сам Карпман признаётся, что его концепция представляет собой идеи, родившиеся в мозговом штурме, и что никакие идеи при этом им не были отвергнуты. Но модель простая, поэтому и стала популярной.
Инструмент, на самом деле, хороший: помогает выйти из тупика, и его можно крутить. Главное — не делать по нему долгосрочные выводы. Но молодые тимлиды делают такие выводы. Они берут треугольник, распределяют по нему роли в команде, и всё это у них статически. Даже теория гласит: чтобы треугольник работал, по нему нужно перемещаться. К сожалению, обычно все выбирают позицию жертвы.
Ок, может, модель Карпмана действительно не подходит для оценки разработки? Давайте возьмём другой инструмент. Вот есть MMPI. Это наиболее изученная и одна из самых популярных методик для исследования индивидуальных особенностей и психических состояний личности. Исследователи взяли студентов, составили точные оценки их личностей и посадили проходить тест. Но опросник содержал как точную оценку, так и оценку, использующую поддельные обобщённые описания. Студентов попросили выбрать, какую оценку они считают своей. 59% студентов выбрали поддельную оценку MMPI, как характеризующую их.
Вот почему к выводам по различным шкалам нужно как минимум с опаской относиться. Особенно когда мы оцениваем коллектив или группу людей.
Люди ценны. В каждом человеке сосредоточены множество разных сторон. Есть ещё один интересный эффект Барнума, по которому: если вас загрузить кучей вопросов, а потом кучу данных выдать, вы согласитесь, что это похоже на вас.
Эффект Барнума, эффект субъективного подтверждения — общее наблюдение, согласно которому люди крайне высоко оценивают точность таких описаний их личности, которые, как они предполагают, созданы индивидуально для них, но которые на самом деле неопределённы и достаточно обобщены, чтобы их можно было с таким же успехом применить и ко многим другим людям.
Например, человеку показывают результаты его опроса и говорят: «Слушай, ты экстраверт на 99%». Он: «Ну, да, вообще-то, у меня это есть. Просто не проявилось ещё».
Эффект Барнума работает так же, как треугольник Карпмана, и позволяет немного покрутить своё колесо размышления. Это хорошо работает в индивидуальном порядке. Но делать массовые выводы на весь коллектив — странно. Последнее приводит к последствиям, когда человек сопротивляется.
*Для развития ширины мышления очень рекомендую книгу «Оргуправленческое мышление» Георгия Щедровицкого.
Наш тимлид прошёл все этапы, бороду вырастил, пересмотрел свои взгляды. Столкнулся с тем, что ему команда дала фидбэк. Сначала думал, что команда капризничает. Походил на конференции, посмотрел видео. Думает, как донести свои идеи, чтобы все поняли, что его инструменты суперэффект дают. Команда выкатывает ему фидбэк. Может быть, через год-два его увольняют, может быть, отстраняют от команды. Он пересматривает взгляды и инструментарий, понимает, что нужно действовать по ситуации. Вот такой простой вывод. Он понимает, что ничего не знает.
Даже объективная истина, если она существует, трансформируется в виде взглядов на неё. Твой собственный взгляд — это супер, но нужно понимать, куда смотрят глаза окружающих тебя людей. А у тебя теперь в подчинении ещё и другие руководители, мини-руководители, которые тоже занимаются командой или уже подрастают.
Что делает опытный тимлид, чтобы не попадать в неприятные ситуации?
Уточняет границы применимости инструментов.
Действительно ли модель, описывающая жизнь подводников, ложится на команду разработчиков?Не ведётся на простоту применимости теорий.
Действительно ли, чтобы эффективно коммуницировать, нужно только знать, что человек категории D по DISC?Готов к пересмотру убеждений.
Не был ли успех применения практики связан с чем-то ещё?Не готов ввязываться в случайные эксперименты над командой.
Готов ли я решать последствия простой и быстрой теории, полученной на тренинге?Понимает цель применения методик.
Есть ли у меня вообще цель? Отдаю ли я себе отчёт в том, что применяю только для практики?Понимает измеримость и готов критически оценить её.
Измеряют сейчас все и всё, но действительно ли эта метрика согласована, например, с другими?
Что я сам понял после всех этапов тимлидства
Переоцени свой опыт как инженера
Опыт намывается со временем. Ты получаешь много-много подкрепления о том, что делаешь, а весь мир — это чёрные ящики, обратные связи и так далее. Да, действительно, на одном человеке, на куче людей это работает. Но справишься ли ты сам с этим? Будешь ли ты, как инженер, инженером человеческих душ? Можешь ли ты себе такое позволить? Я не думаю, что вы можете себе такое позволить. Это отдельная деятельность. Вы руководитель.
Цени людей больше процессов и инструментов
Думаю, вы точно знаете эту строчку, она из Agile Manifesto. Нужно ценить людей больше процессов, инструментов.
Я узнал эту строчку, когда был ещё разработчиком. Когда ты разработчик, тебе залетает эта строчка отлично. Ты думаешь: «Ну, да, я человек, какие там процессы, я важнее. Я разработчик и суперценен. Вокруг меня такие же суперценные профессионалы. А наш руководитель делает какие-то там манипуляции непонятные, внедряет процессы и говорит, что нам нужно сейчас задачки все перекапывать в „Джире“». Но это супер важная история, чтобы весь Agile работал и даже другие методологии.
Отбрасывай ложные представления
Новые модели прилипают. Вы открываете какой-то плейлист с видео, ходите по конференциям — всё налипает, как ракушки на камень, куча-куча-куча всяких знаний. Старые представления никуда не деваются. Они у вас как-то конфликтуют, иногда отнимают много сил, где-то между собой спорят, где-то вы это выносите наружу и спорите с другими.
Но освободите место, попробуйте. Это просто маленький лайфхак. Сначала освободить место, отказаться от чего-то и побыть без знания того, что делать. Просто признать: я не знаю некоторое время, что делать. Была такая ситуация, всё работало супер, у меня была абсолютная стабильность, случился кризис. Я не бросаюсь заполнить эту пустоту. Я просто сижу, жду, смотрю.
Можно смотреть по-разному. Можно смотреть с напряжением: напрягаться, ожидать какой-то обратной связи или воздействия, что что-то не так, ждать ухода разработчиков, каких-то обсуждений, отзыва от вышестоящего руководителя. А можно ожидать обратную связь спокойно наблюдая. Необязательно всё требует действий. Можно побездействовать.
В статье я приводил разные модели команд для примера, но в своей повседневной работе я использую просто трезвый взгляд на мир. То есть мне помогает модель, где отбрасываются любые модели. Но сами модели нужно знать, а также важно понимать общую картину индустрии и общие инструменты. Как и нужно уметь отказаться от их автоматического применения. Вот этот отказ, переход в просто режим наблюдения — это то, что помогает понять конкретную ситуацию, прежде чем приступить к действиям.
Получите повышение или освойте новую специальность с курсами Нетологии:
Скидка 10% по промокоду codehabr10.
odilovoybek
Интересная статья, хотелось бы почитать еще и про взаимодействие тимлида с менеджерами проекта (именно с теми, которые руководят разработкой в целом).