Перепост статьи с https://habrahabr.ru/company/e-Legion/blog/314170/
Один в один мой опыт (с поправкой на то что я работал на долгоиграющем проекте, придя на 3-х летнюю кодовую базу). Отвечу на вопросы.
А можно без прочтения статьи? :)
- Ты пришел с конкретной задачей в проект или просто занял эту позицию?
- Как ты завоевывал авторитет?
- Какие действия ты предпринимал чтобы улучшить процесс?
- Сколько времени в неделю занимают митинги?
- Сколько времени ты кодишь?
- Что ты кодишь? Фичер девелопмент, бага фиксинг или ты просто улучшаешь процесс разработки команды?
Ну и такой вопрос отдельно (он мне очень актуален):
Как думаешь Тех. лид должен больше времени уделять тому, чтобы продукт над которым идет работа был лучше или должен просто анблокать тимку? Я склоняюсь к первому, а потом уже если ничего критичного то делать второе.
Проработал год. Чтобы эффективно решать задачи, приходилось общаться и с большим количеством людей, и больше разбираться в одних или других вопросах. Брал инициативу по нестандартным задачам собеседования. Через год парень, который был лидом, уходил, и предложил меня на свое место. Де-факто я уже выполнял половину обязанностей техлида. Откровенно, мне не нравится то как он вел дела, но поделать я мог только то что было доступно разработчику, чем, собственно и занимался.
У меня часто был ответ что делать. Со мной было удобно работать менеджерам. Старался чтобы разработчикам тоже было удобно со мной работать (не всегда успешно).
Разбирался почему и как все работает в компании и в рамках команды, до того как стал лидом. Как стал лидом - предлагал и внедрял практики, сопоставлял краткосрочные планы (обычно продиктованные бизнесом) с долгосрочными (реализовать желание команды улучшить кодовую базу), поддерживал инициативы ребят, даже если считал их провальными (только если бы инициатива не повредила бы сильно проекту).
У нас были стандартные 15 минутные стендапы по утрам. В минус мне: далеко не всегда команда помнила для чего эти митинги нужны. Митингов было не много, по договоренности. Возможно неправильное решение, потому что далеко не всегда видение ситуации членами команды текущей и будущей совпадало с моим. В самые “жирные” недели было по 2 митинга в неделю.
1/3 времени. Остальное - переключался между зачами как координации, так и участия в делах команды и менеджмента.
Фиксил баги, делал средние фичи. Со временем стало ясно что из-за очень частого переключения контекста, на задачу у меня уходило раза в 2 больше времени чем надо. Так же дописывал тулзы и скрипты для автоматизации, реализовывал пруф оф концепт предложений, реализовывал начальную обкатку решений. В последнее время фокусировался на том чтобы дать как больше безразрывного времени на одну задачу каждому каждому члену команды (что опять не всегда удавалось).
Зависит от ситуации. Что будет более эффективным (с учетом известного будущего) то и надо делать. Твоя задача как техлида - быть полезным бизнесу, при этом защищать и оберегать команду за счет своего положения.
2 лайка
Через год парень, который был лидом, уходил, и предложил меня на свое место
У меня точь в точь такая ситуация. Только пол года прошло. И он мне нравился, очень крутой спец.
Слушай, а что на счет Скрам? Ты это вывозишь? Какие ты решения принимаешь?[quote=“dmitry, post:3, topic:1546”]
поддерживал инициативы ребят
[/quote]
А свою точку зрения отстаивал?[quote=“dmitry, post:3, topic:1546”]
В самые “жирные” недели было по 2 митинга в неделю.
[/quote]
Счастливый мир :)
Если тебя больше тянут на митинги и заставляют решать проблемы, которые очевидно уже имеют решение, но другие команды это делать не хотят, что думаешь делать?
Как вообще были самые большие проблемы, не технические, а там где надо было говорить и доказывать?
Мы пробовали настроить скрам, считаю что безуспешно, но лучше чем никакой организации или вотерфол. Если бы я продолжил работать, однозначно бы продолжил движение в сторону настройки правильного скрама. Я понимаю ценность этого подхода как для бизнеса, так и для команды.
Что ты имеешь в виду под “вывозишь”?
Однозначно. Опять таки нужен баланс, чтобы не переусердствовать, и не задавить инициативу, а с другой стороны не нанести вред продукту. Даже адекватные технические предложения приходилось отсекать из-за ситуации со временем и ресурсами.
Если решение зависит от нескольких людей или команд, мы планировали конкретные сроки для митингов и просто действий. Если это инициатива, от которой деятельность компании особо не зависит, и никто не поддерживает идею, я за счет своего времени решал и развивал тему. Если не поддержали другие отделы, то взвешивал, надо ли эскалировать мысль или идею выше чтобы на другие отделы надавили, и никогда не эскалировал.
Узнай причины почему тебе очевидные вещи не принимаются другими командами. Большинство проблем что я встречал проистекали из непонимания друг другом, недоговорок о том что именно надо делать и лени. Первые устраняются общением, последнее устраняется или политикой компании (особенно когда компания заинтересована в решении проблемы).
Непонимание, излишне эмоциональное отношение к вопросу (как с моей, так и с их стороны), просто неудача. Если система отношений между командами не настроена, то роль личности и отношение к тебе будет так же влиять на принятие решений (минимум промежуточных), так что не стоит раскидываться невыполнимыми обещаниями, или грязью в другие отделы: чаще всего у них были достаточно весомые причины сделать ту хуйню что они сделали (минимум они это смогли себе объяснить).
Ну справляешься/терпишь?
Я думаю это тоже зависит от проекта. Я думаю должна быть граница в этом. Вот у нас просто в день в среднем 4 митинга. То есть от 1 часу до 4 выпадает. Если приплюсовать сюда то не рабочее время что ты просто сидишь, то нет времени работать за день. Поэтому просто разработка “по ТЗ” в нашем случае больше подошла бы. Потому как, когда у нас проблема на проде, то собирается другой митинг обсудить почему так и что делать чтобы такого не было.
Ты считаешь что делать какие-то фичи и наращивать технический долг лучше чем переубедить бизнес сейчас дать “капасити” и пофиксить часть долга?
Тут я полностью согласен :D
Если я вижу что митинги нецелесообразны, я пытаюсь по этому поводу что-то сделать. Если не получается повлиять, я взвешиваю, хочу ли я продолжать так работать (конечно только митинги не влияют на решение перкратить сотрудничество с компанией). Общая стратегия: делай максимально хорошо, но помни что не на все можно повлиять.
Если ты видишь проблему в прерывании работы или “потока”, договорись о гарантированном времени, на которое не будут организовывать митинги. Аргументами можно раскопать статей, которые объясняют почему программиста прерывать не надо.
Вся проблема в слове “лучше”. Моя оценка того как вести бизнес с точки зрения отношения к разработчикам и кодовой базе может сильно отличаться от оценки тех людей, которые принимают решения.
Я выбрал стратегию делать максимально правильные (на мой взгляд) вещи в тех рамках, которые выстроены внутренними правилами. Это не гарантирует успех, это не гарантирует признание, это не гарантирует правильность принятия решений (но дает инструмент для саморазвития: анализ провалов). Это дает опору, от которой ты отталкиваешься когда принимаешь решения. Когда ты ошибешься, ты пересмотришь свою опору, что ты считаешь “хорошо и правильно”, и пойдешь на следующий виток. Тот же скрам, вид сбоку.
На вопрос невозможно ответить без знания контекста. Если у компании новый клиент, который принесет деньги, то не время причесывать кодовую базу или менять процессы. Если состояние критическое, и усложнение кодовой базы приведет к невозможности пошевелиться в обозримом будущем, то смотри пункт про стратегию “делай максимально хорошо в данных сложившихся условиях”.
Что ты имеешь в виду?
У меня как технаря есть представление какого результата надо достичь по тому или иному вопросу. Не всегда мое представление совпадает с представлением людей как из моей команды, так и тех, кто принимает решения. Не всегда у меня есть достаточное количество ресурсов, или полномочий.
В таких условиях я выбрал тактику затраты некоторого количества усилий на то чтобы повлиять на ситуацию, сопоставляя цену (времени, репутации) и серьезность поднимаемого вопроса.
Моментально хороших результатов можно не получить, но в долгой перспективе я не только добиваюсь больше чем средний разработчик, но и обучаюсь, пересматривая свои взляды.