Комментарии 13
Тимлид на испытательном сроке. Первый месяц. Заголовок именно про то, что я чувствую. Все описано так, как оно есть изначально. Пару ссылок утащил. Что-то из пунктов выше уже сделал/делаю, что-то пока нет.
Есть ещё одна проблема, с которой я, на удивление, столкнулся: сложность спланировать задачи команды на будущую неделю (у нас это неделя именно). Кто-то уже приходит и говорит, что ему нечего делать. И есть очевидные задачи, которые я понимаю почему надо взять в план. Да, у нас есть некоторые верхнеуровневые планы, но по ним с нашей стороны по одному продукту уже все сделано 😂можно сходить начальника спросить. Продакты к нам редко приходят. Бывшему тимлиду очень помогало знание предметной области, чтобы выдумывать задачи, когда их нет. Например, на переработку интерфейса. Я пока так не умею, так как предметную область не знаю. А сказать "сделайте красиво" не могу. Надо разбираться хотя бы поверхностно. Вот такая вот сложность имеется.
Очень понимаю ваши чувства, сама там была :) Главное помнить - что так будет не всегда, выход точно есть!
Что касается беклога, я бы предложила, например, обратиться к более опытным разработчикам в команде, вдруг у них есть идеи, что можно улучшить. Уверена, что в любом приложении всегда есть что порефачить или оптимизировать. Так вы и сервис улучшите, и разработчики будут более мотивированы, тк смогут проявить себя.
Тимлид - зачем вообще эта прослойка? Есть проект менеджер. Есть ведущий программист направления.
Мне кажется, эту роль выдумали, чтобы было с кого спросить вообще за любую фигню, происходящую на проекте. А с ведущего разраба не получится за всё подряд гонять, он быстро объяснит, что он за технику а остальное сами разгребайте. Лично я разочаровался в тимолидстве, это действительно неведомая хрень
Их может не быть. Либо ведущий программист направления может быть техлидом и он будет за тех. часть, а не за менеджерство. Плюс , если все будут только делать задачи, кто их будет приоритизировать ? Сами ? И да, с кого спрашивать за результат ? Далеко не у всех исполнителей развитые софты. У меня в команде есть прекрасный аналитик. Но софты у него так себе. В итоге тимлид еще и организует встречи по тем или иным вопросам, фильтрует задачи, в принципе, на входе. И что-то отбрасывает как не валидное. И т.п. На самом деле, пока не поработал, всегда кажется, что эти лиды и начальники ничо не делают. Мне так казалось, когда был специалистом )
И по факту да, если нет нормальной команды, то тимлид может быть сборной солянкой из проектного и продуктового менеджера. А это та еще история.
Отличная статья для начинающих тимлидов. Скажите, что думаете о системе управления по Александру Фридману, о его книгах и подходах к управлению? Если кто читал это.
Надо относится взвешенно, потому что у него есть доля "инфоцыганщины". Если нравится стиль Фридмана, то лучше читать Владимира Тарасова (искусство управленческой борьбы), Фридман многое у него позаимствовал. Такого рода книги это адаптация западного менеджмента к отечественной психологии,и к отечественным кейсам. У Тарасова базисом является традиции китайского менеджмента которые становятся нужны при взаимодействии с бизнесом.
Спасибо! я, к сожалению, не знакома. Внесу себе в список:)
Не всегда все так легко и просто. Я можно сказать сгорела работая Тимлидом.
Пришлось увеличивать штат разработки. В итоге пришло 4 новичка, а прогружать в проект могли я и еще один человек. Плюс новый фронт (с ним работала с одна). Плюс еще каждые 3 месяца приходилось обучать тестировщиков. Приходило два нулевых человека, которых можно сказать другие тестировщики не погружали в мой проект. И их я обучала работать с проектом, а это было очень тяжело, т.к. часть инфы лежала в 2х других проектах.
И самое главное - разделение проекта на фронт и бэк. И я одна занималась и аналитикой и описанием всех контрактов и работы со стороны фронта и бэка.
И еще круть - в параллель шли 2е крупных фичи.
Как здесь не перегореть вообще не понимаю.
P.S. Сроки естественно все пропустили.
P.S.S. Мораль такова - 9ть женщин не родят за один месяц. Поэтому никогда не увеличивайте команду больше чем на 2а человека на крупных проектах. Ну и ставить начальство перед выбором чего-то одного, а не как они хотят в параллель с увеличением команды.
Соглашусь с мыслью про "не увеличивайте команду больше чем на 2а человека" за раз. Онбординг в нагрузке, к сожалению, часто очень сильно недооценивают, а он действительно может занимать ОЧЕНЬ много времени. А увеличение команды помогает в долгосроке. Условно, если проект нужно завершить в течение пары недель, добавление новых людей лишь замедлит вас, а не наоборот.
Относительно параллельных проектов тоже часто есть соблазн "сделать побольше за раз", как итог часто получаем расфокус команды и увеличенные сроки по всем проектам. Обычно помогает проговаривать с бизнесом альтернативы и все плюсы и минусы того или иного подхода. Например, мы можем делать два проекта в параллель и закончить оба их через два месяца. А можно первый закончить через месяц, только потом приступить ко второму. А бонусом и команда не погорит и, вероятно, качество исполнения будет лучше.
В общем, лучи поддержки Вам в этом непростом деле :)
Как начинающему тимлиду не сойти с ума от обилия задач: практический гайд