Comments 24
Очень знакомая история, автору желаю найти свое состояние баланса :)
Менеджмент не отличается так сильно от программирования, как поначалу кажется. Те же KISS, SOLID и DRY, только абстракции и операнды другие.
Разработка: накидал код a = b, протестировал что a = b на нескольких кейсах, проверил через год — a = b до сих пор.
Менеджмент: настроил процесс a = b, завтра оказалось что процесс не работает если b = 5, через неделю что точное сравнение вообще не уместно, а через две — что a — это число, b — строка, а сравнивать по понедельникам и средам вообще нельзя.
Ну да, практически одно и то же...
Вы сами только что это подтвердили своими примерами)
Ваш кейс в менеджменте = развивающаяся кодовая база (продукт), меняются и добавляются сущности, бизнес-логика и т.д. Это не прокси сервис который годами можно не трогать.
Так же этот кейс показывает некомпетентность менеджера или его босса. Либо требования (вектор) не тот, либо тот кто настраивал процесс — заложил хреновую "архитектуру") Хардкод — зло)
Есть такие практики, вести список м&%^в-заказчиков или заметки, что Вася плохо дружит с WCF-сервисами, а Настя обычно болеет весной и у неё меньше получается рабочих часов?
АХААХАХАХ, нет. Не можешь. (Сарказм если что)
Расскажу немного про свой опыт. Но прежде, следует уточнить, что в каждой компании роли тим-лида/тех-лида определяют по своему. И часто бывает — что это человек, который должен заткнуть все оставшиеся дыры.
В целом, на мой взгляд, тим-лид — это больше в сторону развития команды. И сейчас, наконец-то, по прошествии многих лет, стало появляется понимание этого. В последнее время я стал замечать, что в вакансиях тим-лидов все чаще встречаются требования, связанные именно с командной работой, решением межличностных конфликтов, развитием компетенций команды, планирование обучения и так далее и все меньше технических знаний.
А тех-лид — это больше в сторону технического развития. Мне в свое время предложили стать тех-лидом. Но как впрочем и всегда, это была мешанина обязанностей. Хотя именно развитием и обучением команды я не занимался. Конфликты не решал (хотя вроде их и не было).
То, что делал я — я бы назвал "ведущий программист". Я вел проект с технической точки зрения. С одной стороны у меня был Product Manager/Owner и BA, которые олицетворяли стейкхолдеров. Так как это был интегратор в банковской сфере — там было довольно много бумаг, в том числе и технические задания. Я же олицетворял весь технический проект целиком. Мне на входе "что надо сделать", а я думал "как это сделать" и делал вместе с командой. Выбирал технологии, продумывал архитектуру, оформлял и распределял задачи в жире, сам назначал созвоны для обсуждения рабочих вопросов с участниками команды (да это все еще было удаленно), проводил код-ревью и сам писал код и довольно много.
По распределению времени — процентов 60% на архитектуру и написание кода, 10-20% на ревью кода, остальное на остальное.
Собственно чего от меня ожидали:
- Мне опишут, что надо сделать, а я найду решение и сделаю.
- Оценка и корректировка времени.
- В жире был виден прогресс по проекту, но ко мне могли прийти и спросить технических подробностей и текущих проблем, так как PM бывший технарь. Размер проекта позволял мне держать весь его в голове. Я сам погружался немного в каждую задачу, которую выдавал участникам команды, продумывая, что и как там надо сделать и как это состыковать с остальным проектом. Поэтому я мог рассказать обо всем.
- Участие в принятии решений — в каком объеме надо сделать очередной этап проекта, чтобы и успеть в обещанный клиенту срок и показать действительно ценный функционал. Так однажды, мы не укладываясь в календарный срок, приняли решение о переработке, чтобы клиенту выдать полностью готовый один из воркфлоу. В противном случае, этот этап не принес бы никакого бизнес-валью конечному клиенту. Был бы бесполезен.
- Распределения задач в команде, с учетом опыта (джунам попроще, мидлам посложнее, сеньорам с большей долей неопределенности и исследовательской работы).
- Мне никто этого не говорил, но я сам наделил себя обязанностью отвечать за качество проекта. Отсюда следовало еще два пункта:
6.1. Ревью кода. Я успевал просмотреть код за каждым участником
6.2. Ближе к концу я с BA прошлись по коду и тех заданию. Сопоставили и каждый себе пометил то, что надо еще доработать. В итоге синхронизировали документацию и код. И я стал уверен в том, что проект делает именно то, что требовалось
Чего я не делал:
- Не общался напрямую с клиентом
- Не обучал команду (но как-то старался давать задачи по силам)
- Не решал конфликты (вроде их не было, но сейчас уже понимаю — мне повезло с командой, все работали плотно и слаженно).
Я столкнулся с аналогичной проблемой во фронтенде, так как сам был (и остаюсь больше) бэкендером. Но, из-за того, что я мог сам выбирать технологии и UI был довольно простым — остановился на том, что я довольно хорошо знал (в те времена это был ASP.NET, даже еще не MVC) + взял подходящую демку из набора готовых компонентов. Сейчас, на крупных проектах, я бы ставил перед руководством вопрос разделения фронт-енда и бэк-енда и у каждого свой "ведущий программист". Фронт-енд довольно обширная и крайне зыбкая тема.
Сейчас уже, я замечаю, что замкнул на себе довольно много всего. Это было ручное управление. Но тогда мне нравилось так работать. Команда была продолжением моих рук. Я успевал делать проект (на это конечно влияет размер команды и проекта). Но мои те подходы нельзя было масштабировать. И сейчас бы я думал в сторону настройки процессов и показателей. Например чтобы ревью-кода проводилось между участниками команды, а не лично мной. И так далее.
Это целевая история, к которой надо ещё прийти и выстроить всё так, чтобы доверие действительно себя оправдывало. Тут ключевой момент, чтобы у руководителя, который расставляет приоритеты и доверяет задачи другим людям, были адекватные ожидания от их поведения и результатов работы. Как следствие — за сценой много пипл-менеджмента и кропотливой работы с процессами. Либо везение — когда коллектив счастливым образом сложился из ответственных и увлечённых людей, которые друг друга дополняют. Но и тут за везением обычно стоит кропотливая работа того, кто команду собирал.
Непонятно, почему «проревьювить то, помочь с этим...» — стали функцией менеджера? Тут налицо либо жесточайшая нехватка ресурсов (когда в команде все заняты, и менеджер вынужден тушить пожары), либо команда внаглую пользует ресурсы менеджера, чтобы поменьше работать. Бо команда обязана сама и ревьювить, и помогать, и сроки планировать. Менеджер нужен больше для того, чтобы представлять команду вовне (в других командах, у заказчиков, и и.д.). Ну и заниматься развитием команды, естественно.
Добавил бы также, что на моем опыте хорошие тим-лиды получаются из тех людей, у которых помимо технического прошлого был и опыт торговли. Потому что опыт торговли хорошо тренирует «чуйку» хитрожопых людей, которые за 3 копейки хотят получить результат на 100 рублей. И умение вежливо, но жестко ставить таких людей на место.
Автор просто перешёл не на своё место, отсюда и дискомфорт. Если автору комфортно сидеть в своей ракушке и размеренно писать код от рассвета до дидтайма — то надо так и продолжать, не переходя на руководящую должность тимлида, который скорее маркетолог, чем программист. А на должность тимлида лучше назначить экстраверта, которому общение с людьми не в тягость и который будет подзаряжать своей неуёмной энергией всю команду.
Не без душевных терзаний я сменила работу на более перспективную в плане карьерного роста, и через 9 месяцев стала тимлидом команды разработки, размер которой достигал в пике 12-ти человек, по большей части разработчики — фронт и бэк, а также аналитики, проджекты и QA.
Завидую вам) Я вот был раньше манагером, а потом переехал в другую страну разработчиком. И никак не найду себе "перспективную в плане карьерного роста", чтобы вернуться к тому, к чему у меня больше душа лежит.
Черити Майорс периодически пишет на тему перехода из разработчиков в менеджеры:
https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/
https://charity.wtf/2019/01/04/engineering-management-the-pendulum-or-the-ladder/
https://charity.wtf/2020/09/01/the-official-authorized-list-of-legitimate-reasons-for-deciding-to-become-a-manager/
https://charity.wtf/2020/09/06/if-management-isnt-a-promotion-then-engineering-isnt-a-demotion/
Всем бы так поступать, осознавая своё истинное предназначение, а не превращать жизнь в бесконечную погоню за барышами.
Интересный контраст: еще совсем недавно — в середине нулевых — вертикальный карьерный рост считался чуть ли не must have.
Если в ответе на вопрос собеседования «Кем Вы видите себя через 5 лет» не упоминалось повышение в должности, на тебя начинали косо смотреть…
Я рад, что пришло массовое понимание простого факта — все люди разные, и их возможности, а также желания тоже разнятся. Наконец-то появился термин горизонтальный рост…
Еще раньше — в начале нулевых — существовала другая проблема: IT-шников заставляли работать в те же часы, что и остальных сотрудников.
Никогда не забуду, как был вынужден написать обоснование на 3 (трёх!) страницах для смещения начала рабочего дня на 2-3 часа (должность сисадмина).
Вскоре к большинству руководителей пришло понимание, что пользы от такого смещения гораздо больше, чем вреда. К этому добавились результаты исследований, наглядно показавшие бесполезность борьбы с биологическими часами конкретного индивида.
Теперь примерно каждая вторая-третья вакансия предполагает гибкий график.
В середине 10-х годов та же ситуация наблюдалась в нашей стране с удаленной работой.
Как же я устал в ту пору доказывать работодателям её преимущества! Даже выписал отдельно выгоды для компании, работников, а также тех и других вместе взятых. Но никто не хотел слушать…
«Не было бы счастья, да
Теперь немало тех, кто вообще отказывается от офисов в пользу 100%-ной удаленки.
Это я всё к тому, как важно не закостеневать, идти в ногу со временем, быть гибким, прислушиваться к мнению других, не бояться перемен, обладать качествами визионера.
И, подобно автору статьи, не следовать стереотипам «если долго кодишь, пора переходить в тимлиды». Познать собственное призвание гораздо важнее, как для окружающих, так и для самого себя.
Статья обязательна к прочтению теми, кто хочет написать про "эффективных менеджеров" и бедных непонятых программистах. Рулить людьми это ВСЕГДА сложно. Это самое сложное чем вообще можно рулить.
Вы о конкретной программе конкретной школы сейчас? А то я не сторонник фантазий "в воздух".
Пара-тройка пунктов из сотни.
Как хороший разработчик становится плохим менеджером