Comments 28
Пообедать с выключенной камерой во время митинга и отлаживать код посреди обсуждения очередной поставки задач становится нормой.
Я и без тимлидства так делаю всегда ))
3 встречи по часу подряд без перерыва — типичная среда.
Люблю, умею, практикую.
"Плюньте в тех, кто проповедует идею, что тимлид — это следующая ступень для роста разработчика, это не так. Это совершенно другая роль, она не лучше и не хуже — просто она другая." - два чая этому господину.
Если вырезать слово "разработка", то эта статья отлично подходит к менеджменту во многих других направлениях. Боль и осознание собственной незначительности - основные эмоции с момента начала моего управленческого опыта.
вот забивать себе слоты для работы- самый лучший совет, хотя и не всегда работает
очень хорошая статья. стану тим лидом.
Понравился этот доклад на эту же тему https://youtu.be/sq9rvSjQRKM
Как раз завершаю период победного тимлидства, пойду в мидлы. Для статистики по пунктам:
1. Очень много времени будет уходить на обучение. - Не было.
2. Твоё время больше тебе не принадлежит. - Митингов не было, но правда потому что все время кто-то что-то от тебя хочет.
3. Теперь ты отвечаешь за всё. Совпадает. Теперь дед мороз это всегда ты.
4. Теперь ты ещё и должен знать всё. Совпадает. Без этого никак. Только если быть фиговым тимлидом.
5. А что есть ещё что-то, кроме материальной мотивации? Не думал.
6. Роль менеджера портит отношения с коллегами. Это если они были. При сегодняшней сплошной удаленке ничего не меняется.
7. Ты практически перестанешь кодить. Совпадает. Но некоторым удается продолжать кодить.
Очень много времени будет уходить на обучение. - Не было.
ИМХО хоть для девелопера, хоть для тестировщика надо учиться и развиваться и у всех уходит время на обучение. Говорить, что у менеджеров много времени уходит - ну такое себе, не больше и не меньше.
Твоё время больше тебе не принадлежит.
Хотят больше - это верно. Но нужно уметь устанавливать рамки и не бежать отвечать как только тимз\скайп\телега заморгали из-за нового сообщения.
Теперь ты ещё и должен знать всё.
Это работает на небольшой скейле, на большом уже к сожалению нет. Нужно искать людей, которые будут разбираться в той или иной области и опираться на них.
А что есть ещё что-то, кроме материальной мотивации?
Карьерный рост, развитие, более сложные задачи, но по итогу это всё сводится к деньгам. Скажем так финансовая компенсация - самая действенная.
Роль менеджера портит отношения с коллегами.
Ага, а клиент платит деньги за просранные сроки и проваленные проекты. /Sarcasm_off
Хотят больше - это верно. Но нужно уметь устанавливать рамки и не бежать отвечать как только тимз\скайп\телега заморгали из-за нового сообщения.
По моему опыту оптимальный вариант - именно отвечать как только заморгали. Если вы начинаете устанавливать рамки своей доступности, тогда каждый участник проекта будет вынужден подстраивать свои планы под тимлида и это сильно затормозит работу или ухудшит качество. Например, сел весь из себя креативный программист реализовывать требования и тут раз и дошел до непредвиденного момента, который очень плохо решать без тимлида. Если он вынужден будет откладывать до момента, когда будет совещание с тимлидом, тогда ему придется заняться другой работой. А он уже настроился на эту задачу. Или делать пока как попало а потом лень будет переделывать.
Можно конечно предусматривать в требовании вообще все и так чтобы поняли вообще все. Но это в множестве задачи или слишком сложно или нереально.
Я смирился с тем, что я могу сесть декомпозировать user story, где работы на пару чаосв и делать это до вечера, потому что каждый час меня кто-то отвлекает на разного рода обсуждения и уточнения. Если тимлид не принимает на себя эту рилтаймовую роль, все для всех становится намного сложнее.
Команды где до тимлида не достучаться по моему опыту продвигаются медленнее и каждый раз изготавливают что-то не то что было нужно.
По моему опыту оптимальный вариант - именно отвечать как только заморгали.
Посмотрите на ситуацию когда у вас не одна команда в 4-5 человек, а несколько команд, скажем 3-4 и в каждой по 9 человек. Если не будете устанавливать рамки, то вас просто разберут на запчасти.
Например, сел весь из себя креативный программист реализовывать требования и тут раз и дошел до непредвиденного момента, который очень плохо решать без тимлида.
Для этого нужна нормальная проработка сторей, NFR, AFR, FR, архитектурные синкапы, плюс выручают backlog refinement( ex-grooming) сессии, где как раз таки и надо все подобные вопросы задавать и уточнять, а не "как на охоту идти, так собак кормить"(с - русская народная пословица).
Можно конечно предусматривать в требовании вообще все и так чтобы поняли вообще все.
Вот этого делать не надо. Вы в бюрократии закопаетесь. Должен быть разумный уровень детализации сторей и заблаговременная коммуникация, где можно "покрутить" задачу с разных сторон и заранее обсудить.
Команды где до тимлида не достучаться по моему опыту продвигаются медленнее и каждый раз изготавливают что-то не то что было нужно.
Так работают все команды в которых нет настроенных процессов: архитектурного ревью, ревью кода\пул реквестов, а тестировщики не проверяют качество, а менеджер вместо того чтобы обсудить с заказчиком смещение сроков плёточкой подгоняет команду.
Нормальная разработка сторей не спасет вас от непредвиденных моментов. Если вы конечно не имеете в виду разработку в том смысле, от которого слово "разработчик".
Разработка стори всмысле разработки постановки задачи для разработчика, который будет ее разрабатывать людьми, которые не имеют к этому отношения обычно выглядит примерно так: https://www.youtube.com/watch?v=pRgIuB6tTVw
И ящитаю, что попытка заменить тупых менеджеров на умных или уделить разработке сторей ещё больше ресурсов не помогают, потому что увидеть корни, которые мешают копать можно только начав копать
1. Очень много времени будет уходить на обучение
Тоже не было. Все таки это не менеджмент в общем случае, а менеджмент разработчиков. Кажется что основные навыки нативно есть после постепенного роста.
2. Твоё время больше тебе не принадлежит.
ХЗ как без них. Даже с очень хорошими ТЗ и документацией появляются "политические" вопросы при работе с соисполнителями. Тут без лида, который в курсе политики никак.
3. Теперь ты отвечаешь за всё.
Не понимаю, почему это недостаток.
4. Теперь ты ещё и должен знать всё.
Мне кажется, что так не получится и так не должно быть. Команда разработчиков это же не стая приматов, где лид - самый большой и сильный. Как и у любого руководителя, должен быть хороший кругозор, но при этом бесполезно пытаться разбираться в работе сотрудников лучше чем они. Они тратят на это больше человекочасов, чем ты и если при этом они в своей части проекта слабее тебя - зачем такие сотрудники. Ну и есть документация же.
5. А что есть ещё что-то, кроме материальной мотивации?
Мне лично нравится что теперь можно программировать через треккер и DrawIO. Главное смириться, что ничего и никогда не будет сделано в точности так, как ты считаешь правильным это сделать.
6. Роль менеджера портит отношения с коллегами.
Кажется это все равно неизбежное бремя. Даже во время удаленки, ругать за факапы приходится. Но с другой стороны приятно официально хвалить коллег которые сделали что-то хорошо.
7. Ты практически перестанешь кодить.
Да, причем не получается брать на себя интересные задачи. Нет времени и много кто подвязан на твои задержки. Спасает хоббийная опенсорс разработка по вечерам.
Короче кажется важно для разработчика, ставшего лидом понимать что он все равно разрабатывает, просто руками сотрудников. Дизайн все равно содержит его интеллектуальный труд, даже в большем объёме чем раньше, просто содержит не так много лично ему принадлежащих строк кода.
Видно автор недавно стал тимлидом и у него подгорает.
Вообще ни разу не програмист, зашел чисто из-за картинки
Суждения спорны.
Самое страшное, как мне кажется, это неизбежное падение хард скиллов разработчика в пользу хард скиллов менеджера. Не очень понятно, что лучше, интересней или перспективней.
@skitial,Спасибо за статью!
Посоветуйте плиз статью про мотивацию?
Ой это вообще минное поле. Куча книжек и статей по мотивации писали после эксперимента на каком нибудь заводе с конвейером где работники собирают танки строго по инструкции. Там вся проблема что бы конвейер работал быстрее. Качество, или то что команда по большей части решает нестандартные и творческие задачи - про такое особо не пишут. Как вариант откуда пробовать(но лучше конечно поискать что то более фундаментальное) https://vc.ru/hr/368847-nematerialnaya-motivaciya-top-7-sposobov
Обязанности тимлида везде разные, требования к нему и зарплата тоже везде разные.
Если количество гемороя на квадратный рубль в данной конкретной конторе устраивает, то почему бы и да?
Не беспокоитесь, я и не собирался. Тем более меня название напугало.
7 причин не становиться тимлидом