L>>Какие в задачи в целом, должен решать тим-лид? R>В целом — ровно одну: эффективность комманды с лидом должна быть намного выше чем без него. R>Вообще тебе стоило спросить у твоего начальства какие задачи оно хочет чтобы ты решал, и сделать это _до_ трудоустройства
Я спрашивал, уточнял и не раз. Но все проясниться на месте, поэтому спрашиваю про чужой опыт. Видите слово "в целом?".
Здравствуйте, licedey, Вы писали:
L>Прошу консультации у тим лидов, которые работают/работали на реальных проектах на этой позиции в офисе, что важно. Дело в том, что весь мой многолетний опыт сводится к фрилансу и удаленке. Лидерством тоже там занимался, но не так чтобы системно, а скорее человек-оркестр, который и там и здесь. L>Как работает тим лид в офисе на больших проектах я в своей жизни не видел. Соответственно идя на эту позицию, незнаю чего ожидать. По разным постам и комментариям друзей, выделил для себя несколько категорий вопросов, которые хотел бы прояснить у уважаемых коллег. Если что, размер команды 6-8 человек включая джунов и стажеров. Аутсорс. Проект новый.
L>Какие в задачи в целом, должен решать тим-лид?
Задач дофига, но главные это то что лид проекта должен уметь делегировать задачи на своих синьоров, и знать трудоемкость их решаемых задач.
L>В чем отличие тим лида от архитектора или PM'a?.
Две совершенно разные роли на проекте, по должностной матрице нередко выполняет один и тот же человек.
L>1. Что делать с джуниорами? Какие задачи им назначать?
На проекты, длительностью до одного года не брать. На длительные проекты — обучать.
L>2. Что делать со стажерами? Тот же вопрос.
Не брать ни при каких вариантах. "Заворачивать" на уровне формирования вакансии. Пусть "стажируются" в ВУЗе или у мамки своей.
L>3. Как по науке распределять задачи между мидлами и сеньорами?
Никакие задачи между синьйорами и мидлами не распределаются. Это абсурд. Синьер выполняет важнейшие задачи проекта и следит за мидлом чтоб он выполнял свои задачи. А вот синьора контролирует лид.
L>- Code Review, CI и билды, заполнять SCRUM-боард тасками и спринтами — это взять на себя или переложить на PM'a.
Все эти задачи не ПМ, а лидовские.
L>* Какие инструменты и какие подходы вы используете у себя?
Excel для расчета стоимости, для планирования и всего остального лично я использую OmniPlan — затем переношу все в JIRA
L>* Что посоветуете почитать, посмотреть или лучше пройти курс?
PMBOK
L>* Что лучше При реализации — писать свои велосиепеды или искать и изучать 3rd party решения.
3rd party
L>Мне сказали, что за open-source 3rd party никто ответственности не несет, поэтому спросить не с кого будет.
Кто сказал? Мамкины борщехлебы? Они готовы из своего кармана бабло заплатить за велосипеды или только теоретики?
L>Но скажем, я хочу использовать MVVM Light, чем писать все вручную, разве плохо?
Лучше сэкономить на времени разработки чем на зарплатах личного состава. Или нанять еще людей.
L>Библиотека отлажена и используется тысячами если не миллионами разрабов по всему миру.
Забей на мнение мамкиных борщехлебов. Исходя из личного опыта в больших проектах (там где членами команды было написано от 1млн строк кода и выше) 75%-80% остального кода это результат работы не членов команды.
L>* Это будет ежедневный процесс, и как говорят мои знакомые, часто возникает конфликт, между хотелками заказчиков и ресурами команды, а также качестом. Как решать?
Вообще-то общение с заказчиками делает исключительно ПМ, или бизнес-аналитик, или аккаунт менеджер или BDO, но точно не лид. Если лид начинает общатся с заказчиком, то это значит что ПМ положил на проект либо на заказчик сует свой сопливый нос в проект (у меня обычно происходило когда заказчики евреи были, те были "экпертами во всем", но то к теме не относится).
Так вот, вариант — выгонять на выходные всю команду — пусть херячат на благо великого ПМа (как ниже я замечу заказчик здесь никаким боком). Тебе за успех проекта, как начинающему лиду, скажут "спасибо и хорошего настроения", а вот у 99% ПМ есть премия за не срыв сроков.
L>* Что в целом посоветуете на митингах? Ранее на удаленке, я мог рассказывать басни, что все прекрасно и процесс идет, вот вот доделаю. Что было не всегда было правдой.
Продолжай рассказывать басни о том, что ты офигенный лид и знаешь что делаешь, что не просто так занимаешь должность и ты лучшая кандидатура, кого можно было представить за эти деньги.
L>Хотелось понять как не завернуть проект в сторону, что хочет заказчик — так и пляшем.
Да ты и так его завернешь. У вас с заказчиком цели разные. У заказчика — сделать больше за меньшие деньги. А у тебя сделать больше за большие деньги. Чувствуешь разницу? Вы — две стороны одного контракта, говоря простым языком — в твоем лице — исполнительная власть, а заказчик — заканодательная.
L>Неважно будет уже, и архитектура и покрытие тестами и в целом качество, главное успеть его удовлетворить.
1. Во-первых, построил рабочий процесс таким, каким он должен быть. Распределил сферы влияния, назначил смежных спецов на случае болезни/отпуска и т.д.
2. Во-вторых, периодически обучаю свою команду. Раньше они бегали к сеньорам и те решали за них задачи, теперь бегают ко мне, но я их задачи не решаю, а помогаю это делать им самим. Сейчас буду стараться их развивать дальше в техническом плане. Результатом пункта 1 и 2 стало то, что я могу плевать в потолок, а работа всё равно будет делаться. Раньше приходилось давать по рукам, т.к. продакшн падал, а им хоть бы хны. Когда эскалация доходила до VP, пояснял, что так быть не должно и проблема должна решаться в соответствии с SLA/OLA ими самими, либо эскалироваться ими самими, а уж не как не доходить до VP от бизнеса.
3. Поддерживаю приятельские отношения с членами команды, стараюсь сплотить команду, чтобы она работала как единое целое (мы все в разных офисах сидим).
4. Стараюсь раз в год организовать командный сабантуй (т.к. все в разных офисах, это обходится в копеечку)
5. Пятым пунктом должен был стать распределеие ресурсов по проектам, но проектами ведает мой босс и пока не спешит ими делиться.
6. Всякие там утверждения отпусков, командировок и т.д. Каждые 6 месяцев ревью и другая бумажная волокита.
7. Организовал отчётность, которая автоматически высылает каждому сотруднику задачи, которые висят на нём, их статус и так далее (у нас 3 трекинговых системы )
Сейчас стараюсь расширять сферу своего влияния и туда внедрять уже построенные процессы.
L>Какие в задачи в целом, должен решать тим-лид? Я понимаю, есть универсальный ответ — все зависит от проекта. В конторе X, он пиццу носил для сплочения коллектива, а в конторе Y, решает финансовые вопросы с заказчиком. Но все же, как у вас?
Основная задача тимлида делать так чтобы гребцы не посрались и гребли более-менее в одну сторону. Кроме того, на тимлиде лежит ответственность превращать планов громадье менеджера в конкретные задачи для исполнителей и контроллить разрешение этих задач.
L>В чем отличие тим лида от архитектора или PM'a?. Разве лид не должен решать архитектурные вопросы? Разве не должен создавать распределять таски?
Архитектить должен но на низком уровне. Архитект решает на высоком уровне, будет в проекте трехзвенка, толстый клиент или вообще P2P, в тимлид решает как побить фичу на классы. ПМ решает в каком месяце что должно быть готово, а тимлид раздает задачи по неграм.
L>1. Что делать с джуниорами? Какие задачи им назначать?
Багфиксинг, наращивание мяса на скелет. Типа синьор делает прототип, а джун прикручивает обработку ошибок, валидацию входных параметров, тесты и т.п. рутину.
L>2. Что делать со стажерами? Тот же вопрос.
То же самое что и с джуниорами, только задачи брать менее ответственные.
L>3. Как по науке распределять задачи между мидлами и сеньорами? На интервью я сказал, что нужно выделить часть проекта, за которую человек отвечает, максимально независимую от остальных, и пусть совершенствует свою песочницу общаясь с другими через интерфейсы. Это решение похоже на идеального коня в вакууме, и PM неодобрительно покачал головой. Но а как правильно?
Задачи которые могут сделать только синьоры отдавать синьорам. "Могут сделать" означает "могут сделать с должным качеством в нужном объеме за разумный срок". С остальными аналогично вплоть до стажеров.
L>Проект будет по Скраму двигаться вперед, что это такое — я знаю, но не эксперт. А неясные вопросы по организации процессов есть такие. L>- Code Review, CI и билды, заполнять SCRUM-боард тасками и спринтами — это взять на себя или переложить на PM'a. Есть вероятность, что соглашаясь на все можно перегореть, от количества обязанностей. В оффере мне сказали, что кодинг/организация будет 50/50%. Если будет куча разноплановых задач — то спать в офисе станет привычкой.
CR делегируй синьорам, CI и билды это типичная задача для джунов. Короче делегируй что можно делегировать, а оставшееся делай сам. Если ты знаешь что кто-то сделает задачу хуже тебя, все равно отдавай ее ему потому что если ты сам закопаешься в деталях, упустишь контроль над ситуацией.
L>* Какие инструменты и какие подходы вы используете у себя?
Из платформонезависимого глубоко тюненый Redmine, GIT + merge-free gitflow, Jenkins + Docker + Salt.
L>* Что посоветуете почитать, посмотреть или лучше пройти курс?
PmBOK, Жизнь внутри пузыря (для адекватного понимания ожиданий верхнего менеджмента), Office Space (для адекватного понимания настроений подчиненных)
L>* Что лучше При реализации — писать свои велосиепеды или искать и изучать 3rd party решения. Мне сказали, что за open-source 3rd party никто ответственности не несет, поэтому спросить не с кого будет. Но скажем, я хочу использовать MVVM Light, чем писать все вручную, разве плохо? Библиотека отлажена и используется тысячами если не миллионами разрабов по всему миру.
В аутсорсинге плевать. Платит заказчик за велосипед, можно делать велосипед, денег больше будет. Платит за допиливание 3rd party, можно допилпивать 3rd party. По нормальному оно как делается, берешь опен сорс, используешь, если чего не хватает, нанимаешь оригинального разработчика и он быстро и дешево допиливает что тебе нужно. Но в аутсорсинге из заказчика черта с два на такое выбьешь деньги. Приходится своими силами разбираться и допиливать.
L>* Это будет ежедневный процесс, и как говорят мои знакомые, часто возникает конфликт, между хотелками заказчиков и ресурами команды, а также качестом. Как решать?
Торгуйся. Заказчик хочет А? Ок, говоришь ему, но тогда на B и С не хватит денег/времени, давайте решать что важнее.
L>* Что в целом посоветуете на митингах? Ранее на удаленке, я мог рассказывать басни, что все прекрасно и процесс идет, вот вот доделаю. Что было не всегда было правдой.
Планируй показы заказчику промежуточных результатов. Так чтобы было видно что работа идет но еще осталась. Поскольку заказчик оценивает в первую очередь интерфейс тебе придется научиться кое-каким трюкам.
L>Хотелось понять как не завернуть проект в сторону, что хочет заказчик — так и пляшем. Неважно будет уже, и архитектура и покрытие тестами и в целом качество, главное успеть его удовлетворить. В корне не хотелось бы такого, иначе работа будет ад и я уйду опять в свою берлогу фрилансить.
Почему? Заказчик лучше знает какой продукт нужен его бизнесу. Твоя задача и задача команды сделать такую архитектуру, которая позволит как можно дешевле вносить изменения требуемые заказчиками.
Здравствуйте, Джеффри, Вы писали:
Д>Если говорить коротко — то если джуниор, зафакапит задачу, то я даже не удивлюсь. Если мидл зафакапит задачу, то это мой провтык, т.к. не отследил вовремя. Если синьор зафакапит задачу, то это тоже мой провтык (т.к. я тим лид), но я серьезно поговорю с этим человеком.
О чем?
Твой вопрос дает информацию о культуре конторы, людях и о тебе. Есть несколько сигналов, которые я распознал:
Внутреннее качество технических решений занимает последнее место после финансовых показателей и отношений в коллективе. Показателен отказ использовать open-source решения и отказ от разделения труда. Ты же, наоборот, инженер и технический специалист.
Буду отвечать ниже исходя из этого:
Здравствуйте, licedey, Вы писали: L>
Общие вопросы
L>Какие в задачи в целом, должен решать тим-лид? Я понимаю, есть универсальный ответ — все зависит от проекта. В конторе X, он пиццу носил для сплочения коллектива, а в конторе Y, решает финансовые вопросы с заказчиком. Но все же, как у вас?
1. Отслеживать прогресс
2. Знать и быстро отвечать, кто и чем занимается в данный момент
3. Знать о дедлайнах, что нужно завершить для их выполнения и напоминать об этом членам команды.
4. Распознать сильные стороны членов команды и кому, что лучше поручить.
5. Так же, иметь представление об амбициях и обидах ("а почему мне не дали?!") и распределять задачи вызывая минимум истерик.
6. Знать на высоком уровне детали проблем, которые решает команда и участвовать в разговоре.
7. Арбитраж и суд, чье решение или предложение выберем.
8. Хвалить команду и отдельных ее членов, чтобы всем было приятно и никто не завидовал.
9. Напоминать о timesheets, КПА и прочей бюроктатии и уметь писать простыни самому. "Что хорошего можете написать о работе Махмуда за 2016 год?"
10. Быть позитивным, стричься, бриться, аккуратно одеваться и излучать успех. L>В чем отличие тим лида от архитектора или PM'a?. Разве лид не должен решать архитектурные вопросы? Разве не должен создавать распределять таски?
ПМ не знает тех. деталей, а Тим Лид должен разбираться и в технических вещах и в пользовательском домене. ПМ отслеживает и напоминает, Тим Лид делает тоже самое, но еще и принимает решения. L>
Распределение задач
L>1. Что делать с джуниорами? Какие задачи им назначать?
В заграницах Старший Разраб это самая низкая должность. Джуниоров, обычно, быстро повышают или они сами уходят на повышение в другую контору. L>3. Как по науке распределять задачи между мидлами и сеньорами? На интервью я сказал, что нужно выделить часть проекта, за которую человек отвечает, максимально независимую от остальных, и пусть совершенствует свою песочницу общаясь с другими через интерфейсы. Это решение похоже на идеального коня в вакууме, и PM неодобрительно покачал головой. Но а как правильно?
Ты сказал правильно с точки зрения технаря. Для них же, распределение труда это смертный грех. Они хотят заменяемость и ротации. Никто не будет смотреть на качество кода, а если баги, то заказчики позвонят в суппорт и потепят. Убытков, скорее всего от этого не будет. Подыграй им, и в следующий раз следуй аджайлу и скраму. Только фул стек, учимся на ходу, дольше месяца на одном модуле не сидим, книжки не читаем, стек оверфлоу и вперед. Ротации, ротации. Так победим! L>
Организация процессов (SCRUM)
L>Проект будет по Скраму двигаться вперед, что это такое — я знаю, но не эксперт. А неясные вопросы по организации процессов есть такие.
Скрам — это когда не ты ходишь к каждому и спрашиваешь, а они сами приходят каждый день и отчитываются. Кроме того, они друг друга мотивируют, так как отчитываются публично. Peer pressure. Посмотри список вверху. Большое число твоих задач выполняются стендапами с минимальными затратами с твоей стороны. L>- Code Review, CI и билды, заполнять SCRUM-боард тасками и спринтами — это взять на себя или переложить на PM'a. Есть вероятность, что соглашаясь на все можно перегореть, от количества обязанностей. В оффере мне сказали, что кодинг/организация будет 50/50%. Если будет куча разноплановых задач — то спать в офисе станет привычкой.
Забудь про коддинг. Если успеешь, хорошо, но кодинг это теперь, как волонтерство. Тебе платят деньги не за него. Никто не говорит, что ты будешь перерабатывать. Ты будешь мало программировать. L>
Разработка архитектуры
L>* Какие инструменты и какие подходы вы используете у себя?
Нужно задавить свой перфекционизм. Говнокод это норма. L>* Что посоветуете почитать, посмотреть или лучше пройти курс?
Почитай книжку про разные культуры и их отношения на работе. Азиаты, англосаксы и европейцы. Тебе нужно это знать. L>* Что лучше При реализации — писать свои велосиепеды или искать и изучать 3rd party решения. Мне сказали, что за open-source 3rd party никто ответственности не несет, поэтому спросить не с кого будет. Но скажем, я хочу использовать MVVM Light, чем писать все вручную, разве плохо? Библиотека отлажена и используется тысячами если не миллионами разрабов по всему миру.
Понятно, что open source используют все и это лучше. Даже очень важные финансовые компании, где цена ошибки миллионы долларов используют опен сорс. Как можно меньше писать самому. Постарайся убедить начальство. Думаю, что это будет легко. L>
Митинги и общение с заказчиком
L>* Это будет ежедневный процесс, и как говорят мои знакомые, часто возникает конфликт, между хотелками заказчиков и ресурами команды, а также качестом. Как решать?
Не нужно быть слишком честным, как хороший технарь, но и врать уж совсем тоже нельзя. Здесь принято наобещать, а потом рассказывать о непредвиденных проблемах и объяснять почему сроки отодвигаются. Если есть хорошая причина, то конфликтов не будет. L>* Что в целом посоветуете на митингах? Ранее на удаленке, я мог рассказывать басни, что все прекрасно и процесс идет, вот вот доделаю. Что было не всегда было правдой.
Продолжай в том же духе. L>Хотелось понять как не завернуть проект в сторону, что хочет заказчик — так и пляшем. Неважно будет уже, и архитектура и покрытие тестами и в целом качество, главное успеть его удовлетворить. В корне не хотелось бы такого, иначе работа будет ад и я уйду опять в свою берлогу фрилансить.
Именно так и будет. Не будь перфекционистом.
Listen up, maggots. You are not special. You are not a beautiful or unique snowflake. You're the same decaying organic matter as everything else in the world.
Здравствуйте, greenpci, Вы писали:
G>Твой вопрос дает информацию о культуре конторы, людях и о тебе. Есть несколько сигналов, которые я распознал:
Спасибо за ответ, вроде как развернутый. Но форум и для того чтобы спрашивать, неправда ли? Я себя не на помойке нашел, и лидом взяли не просто так. А "контора" — одна из крупнейших в мире в сфере ИТ сервисов.
Здравствуйте, TechL, Вы писали:
TL>Спасибо за ответ, вроде как развернутый. Но форум и для того чтобы спрашивать, неправда ли? Я себя не на помойке нашел, и лидом взяли не просто так. А "контора" — одна из крупнейших в мире в сфере ИТ сервисов.
Всегда рад помочь. Все это выстрадано и получено горьким опытом. Советую прислушаться. Я, как раз, в таких "крупнейших" и работал и информация оттуда.
Как я и писал выше, я распознал, что ты хороший технический специалист, а значит, чем-то похож на меня и цели у тебя похожие. Например, ты ценишь разделение труда, архитектуру, готов отстаивать свои взгляды и т.д.
Не хотелось бы, чтобы ты разочаровался в "крупнейших" конторах, так же тяжело, как это было у меня. Если ты сразу поймешь, что это все театр и будешь знать их настоящие цели, а не то, что они говорят на митингах, то, возможно, всего этого удастся избежать. Может быть, даже сделаешь карьеру и приобретешь эмоциональное равновесие.
Про snowflake это шутка была. Это скорее показывает, что я увидел сам в "крупнейших" конторах. Слова подходят к теме, так как, "личинки мух" копающиеся в говнокоде — это типичная ситуация. Начальство и коллеги намекают словами и действиями, что ты должен присоединиться. Как писал Стауструп — хороший код это статистическая аномалия.
Здравствуйте, TechL, Вы писали:
TL>Я себя не на помойке нашел, и лидом взяли не просто так.
Напрасно ты так реагируешь, человек дело сказал.
Излишне романтическое представление о себе и своей работе — недостаток многих пожизненных удаленщиков.
Первое чему ты должен научиться это здоровый офисный цинизм.
Здравствуйте, Sealcon190, Вы писали:
S>Здравствуйте, TechL, Вы писали:
S>Напрасно ты так реагируешь, человек дело сказал. S>Излишне романтическое представление о себе и своей работе — недостаток многих пожизненных удаленщиков. S>Первое чему ты должен научиться это здоровый офисный цинизм.
Так я с ним вроде и не спорю. Показалось, что меня и компанию немного недооценивают в контексте вопроса. Уточнил.
Что касается романтизма — то он будет наверное всегда. То что мне сейчас приходится пилить — это сложно называть креативом, но что-то там присутствует. Разного рода командные взаимодействия.
Конечно может на Спринте N, это вывестрется...Кстати — что такое здоровый офисный цинизм?)
Здравствуйте, greenpci, Вы писали:
L>>* Что посоветуете почитать, посмотреть или лучше пройти курс? G>Почитай книжку про разные культуры и их отношения на работе. Азиаты, англосаксы и европейцы. Тебе нужно это знать.
Какую-то конкретную посоветуешь?
Здравствуйте, _ABC_, Вы писали:
Д>>Вы идеале я бы предпочел работать с full-stack разработчиками. Но в любом случае в скрам-команде должны быть люди, которые могут работать с любой частью системы. Конечно, бывают исключения — например, высоконагруженная база данных, где нужны выделенные БД разработчики.
_AB>Практика показывает, что при команде, состоящей только из full-stack разработчиков, практически любая БД через год-два превращается в "высоконагруженную", т.е., испытывающую проблемы с выдерживанием текущей (обычно, весьма умеренной) нагрузки. Поэтому полезно запланировать найм такого специалиста в означенный срок, а заодно и ресурсы для рефакторинга системы. Раньше этого срока убедить в необходимости специалиста по БД бывает затруднительно.
Имхо, хороших full-stack разработчиков мало. Может получиться что UI будет кривоватым и неудобным, а код и база будут тормозить (если проект высоконагруженный, а не перебросить 50 записей в день из одного места в другое). У нас на текущем проекте четкое разделение, по-моему нормально работаем.
Здравствуйте, licedey, Вы писали:
L>В чем отличие [b]тим лида от архитектора или PM'a?[/b]. Разве лид не должен решать архитектурные вопросы? Разве не должен создавать распределять таски?
Вообще, это всё -- лишь слова, смысл которых бесконечно размыт...
Здравствуйте, MasterZiv, Вы писали:
L>>В чем отличие [b]тим лида от архитектора или PM'a?[/b]. Разве лид не должен решать архитектурные вопросы? Разве не должен создавать распределять таски?
MZ>Вообще, это всё -- лишь слова, смысл которых бесконечно размыт...
Понимание, основанное на моём опыте (правильность не гарантирую, чистое имхо):
Team-lead: старший разработчик с менеджерскими способностями и обязанностями. Может до половины времени заниматься менеджерством вместо программирования. Распределяет задачи, проверяет прогресс разработчиков и т.д.
Архитектор: нечасто видел отдельную должность архитектора. зачастую архитектурят просто тим-лиды и старшие разработчики, не обязательно в одиночку, иногда вместе продумывая архитектуру.
PM: Насчет работы PM'а у меня, честно говоря, недостаточное представление. Он не кодирует вообще (я не видел по-крайней мере), зачастую является связующим звеном между бизнесом и командной разработки, хотя команда разработки может напрямую общаться с бизнесом если так проще или удобнее. PM общается с бизнесом и тим-лидами, решает что in scope и что out of scope, т.е. например какие задачи нужно сделать в следующем релизе. его задача и ответственность — контролировать успешный прогресс и выполнение проекта. Если тут есть PMы — поправляйте, дополняйте.
)
