Комментарии 37
Почему-то у этого Озона всё манерное, напыщенное, пафосное и при этом самый бестолковый из маркетплейсов.
Честно говоря читается как "за все хорошее против всего плохого" плюс чуток вспоминается анекдот про "... вы мне фару на лоб прихреначьте"
Такое ощущение, что лид это минимум тех. и комерм. директор небольшой организации + HR
Если бы на меня все это вешалось, я бы наверное работал только за большую ЗП + доля в прибыли от проекта, не иначе
Если не делать описанного + дизайнить систему + писать код + участвовать в SRE дежурствах, то стоит быть готовым к плохим оценкам на перф ревью и последующем увольнением. (но скорее всего и раньше)
Что тогда оставили бы в качестве важных пойнтов для лида ?
Первая задача лида: управление "производственным" процессом в команде. Соответственно вот этим он и занимается. Условно, на примере лида команды бэкенда.
Определить тулы
Принимать решения по стеку (совместно с архитектором и другими лидами)
Код ревью
Орг. вопросы на уровне команды
Коучинг (если надо)
Механизм распределения задач
Его основная метрика: сикоко команда делает и с каким качетством. Все остальное как по мне - опции, которые добавляются в силу совмещения ролей
Тогда берём две предложенные вами метрики: количество сделанного командой и качество этого сделанного. Значит, исходя из этих метрик, лид должен как-то сделать так, чтобы команда делала много задач и как можно более качественно.
Теперь по пойнтам из статьи:
Как делать много, если лид не управляет ожиданиями заказчиков фичей? Тимлид соседней команды не захочет больше просить у него новых доработок, бизнес-заказчик тоже лучше придет в другую команду, там где ему скажут сроки и попадут в них с минимальным люфтом
Как делать много, если команда хочет перед стартом работ над целевым продуктов написать свою собственную IDE, удобную и быструю, а лид с этим ОК?
Как делать качественно, если лид не участвует в переговорах, а соседний сервис, от которого зависит стабильность релизов команды постоянно сбоит ?
Как делать качественно, если лид соседней команды А очень просит одного, а лид команды Б второго и обе фичи друг другу противоречат? Команда будет рада тому, что она последовательно реализует две конфликтующие фичи?
Как делать много, если лид ничего не планирует в рамках своего сервиса/части системы и не корректирует планы?
Как делать качественно, когда при каждом релизе команда почему-то кладет прод, а лид не оценивает риски и ему неважно, что где-то в его системе некорректно прогревается кэш?
Как делать качественно, если команда не знает, что такое качественно? Ведь лид не даёт ей системно обратную связь по сделанному
Как делать много, если лид не управляет ожиданиями заказчиков фичей? Тимлид соседней команды не захочет больше просить у него новых доработок, бизнес-заказчик тоже лучше придет в другую команду, там где ему скажут сроки и попадут в них с минимальным люфтом
Для этого есть продакт / BA. Зона ответственности лида - реализация фич с статусе DoR. Продажа команды - вообще не его забота. Для этого есть сейлы, аккаунты и т.д. Либо платите лиду ЗП всех перечисленных товарищей, ну и фары на лоб не забудьте
Как делать много, если команда хочет перед стартом работ над целевым продуктов написать свою собственную IDE, удобную и быструю, а лид с этим ОК?
Значит это плохой лид и он быстро вылетит на мороз, если делает не то, что взято в спринт. Но если заказчик готов платить - тогда почему бы и нет?
Как делать качественно, если лид не участвует в переговорах, а соседний сервис, от которого зависит стабильность релизов команды постоянно сбоит
В переговорах о чем? Если о технических вопросах на тему интеграционного API либо архитектурных решений на общем уровне - почему бы и нет. А о чем ее лиду говорить с другим лидом?
Что касательно "сбоит". Мы пилим свои сервисы, они пилят сервисы для нас. Они сбоят, мы это показываем и смотрим как другую команду "любят" разными предметами в разные "отверстия".
Вам рассказать про спецификацию, "моки" и все такое?
Как делать качественно, если лид соседней команды А очень просит одного, а лид команды Б второго и обе фичи друг другу противоречат? Команда будет рада тому, что она последовательно реализует две конфликтующие фичи?
Просто и понятною Мы "пилим" сервис. У него. как и любого сервиса есть API и его реализация. Если требования к API противоречивы и не складываются в общую картину на уровне контракта сервиса - вежливо на это указываем и даем сторонам договориться. До этого задача не в статусе DoR и как бы не существует. Можем даже помочь, но это чисто добровольно и не обязательно. В конце концов, если кто-то нанял двух "дебилов" на роль лидов команд "А" и "Б", которые не видят противоречий - то пусть сам с ними и разбирается
Как делать много, если лид ничего не планирует в рамках своего сервиса/части системы и не корректирует планы?
Лид планирует:
технические "ипрувы", которые можно включить в спринт по согласованию с продактом
закрытие тех. долга
Бизнес таски планируются не им. Если условно продакту нравиться "гонять вагон между солью и сахаром" - нивопрос. Главное это все фиксировать и вовремя докладывать :)
Как делать качественно, когда при каждом релизе команда почему-то кладет прод, а лид не оценивает риски и ему неважно, что где-то в его системе некорректно прогревается кэш?
Может нанять лида, которые имеет соответствующие тех. компетенции?
Как делать качественно, если команда не знает, что такое качественно? Ведь лид не даёт ей системно обратную связь по сделанному
У меня дает. Если у вас нет - выгоните его
Каждый из моих вопросов по порядку соотносится с пойнтами из статьи, вы же предлагаете о них не говорить, сказать "делай качественно и много", а дальше за все косяки наказывать вплоть до увольнения (это вывод исходя из ваших ответов)
Откуда ему знать изначально, что это косяк? Лид ведь тоже человек, а ещё у него есть сотрудники, которые будут ощущать все эти ошибки, отсюда и статья по онбордингу
Утверждения, что лид должен делать работу PM, продажника и тд, не приводились в статье. Более того есть утверждение о наличии специалистов разного профиля, но о тонких тех. нюансах они не могут знать.
Тут лишь история о том, что есть такие стримы, в которых со стороны ответственности лида могут быть косяки. На мой взгляд, сильно человечнее о них сказать сразу, а не идти предложенным вами путем с увольнениями "чуть что"
Я не совсем понимаю, зачем вы пытаетесь натянуть сову на глобус, если честно
Часть ваших вопросов относится к компетенциям других ролей, что действительно соответствует "поинтам в статье", но никак не относится к роли тим лида.
Остальные вряд ли имеют отношение к ситуации. которая могла бы иметь место быть в "нормальной" компании, вроде "если команда хочет перед стартом работ над целевым продуктов написать свою собственную IDE, удобную и быструю, а лид с этим ОК".
--------
На остальные же - такие вопросы возникают только если либо лид не соответствует своей роли, либо организация в целом представляет собой скорее предмет для изучения исследователей "а как оно еще шевелится, ведь по всем признакам уже должно умереть", чем рабочий механизм
У меня вообще возникло ощущение, что вы работает в чем-то большом, где много политики, мало скиллов и много людей на руководящих постав, которые ежедневно руководствуются принципом "я начальник - ты дурак", так как поставленные вами проблемы выглядят либо как детские болезни, либо уже симптомы большой-большой организации, которая живет своей жизнью
Тут лишь история о том, что есть такие стримы, в которых со стороны ответственности лида могут быть косяки. На мой взгляд, сильно человечнее о них сказать сразу, а не идти предложенным вами путем с увольнениями "чуть что"
Я сделаю еще одну попытку, предположив следующее. Смотрите. Есть "лиды", а есть линейные руководители, у которых есть программисты в линейном подчинении, и которые работают в "больших" конторах, где каждый друг другу либо "волк", либо "еще хуже". Так вот, такие руководители - это не лиды от слова совсем. У них куча доп. обязанностей линейного руководителя и часто сутствуют вменяемые компетенции лида. Точнее что-то есть, но не так часто.
Тим лид - это функция, а не должность. Причем сегодня он лид на одном проекте, а завтра на другом, а часто - у него в подчинении совсем другие люди. Поэтому лид - это всегда человек, который выстраивает команду из тех, кого собрали и дает результат в ограниченное время
Если ваша статья про руководителей - стоит об этом так и писать, так как по хорошему общего между этими людьми довольно мало. Но там да. И бюджеты, и соседние конкуренты-отделы, и вообще много политики
Гляньте хотя бы утиные истории, как пример хуманизации утки.
Как мне теперь развидеть волосы во рту в клюве у утки?
Мне как техлиду было крайне полезно и приятно почитать статью: текст краткий, но простой и понятный, тезисы крайне актуальные. Большое спасибо
Озон молодцы, пишут много статей, разных и больших.
Лучше бы направили энергию на переработку поиска. Поиск как был отстойным, не поддающийся никаким логическим соображениям, так и остался. Иногда даже хочется заплакать от результатов поиска товара в Озон((
Напомнило шедевр "Путь камикадзе...", только в очень кратком изложении.
Спасибо, что напомнил, что нужно хвалить , а не только тыкать палочкой.
Интересно почитать про это направление. Впечатление такое, что ошибаться нельзя и шаг влево и шаг вправо - расстрел. Какая-то чёткая шаблонизация действий. Мне кажется работать в таком потоке очень тяжело и не полезно для здоровья.
Наряду с объективно верными мыслями красной нитью сквозь статью проходит корпоративизм. "Твои интересы, интересы команды и интересы компании едины".
Давайте будем честны: основная задача компании - прибыль; ФОТ, безопасность труда, соблюдение норм санпина - расходы. Расходы нужно сокращать для максимизации прибыли.
В частных случаях, особенно в небольших фирмах (которые больше похожи на артели), интересы у всех сторон могут совпадать, все вместе делают классный продукт, растут, развиваются, и у всех растут доходы.
Но в общем случае этот весь спич о том, чтобы создать в компании обстановку, ведущую к систематическим неоплачиваемым по ТК переработкам, таинству зарплатой вилки и условий роста ЗП. И гноблению команд, которые отстаивают свои интересы (приведенный пример вызывает вопросики, уж очень он абсурдный).
Как пойнты для онбординга лида из статьи ведут к переработкам, таинству зарплат и условий роста зарплаты?
Совместим "...интересы вашей команды и интересы компании должны быть сонаправлены. Ни в коем случае их нельзя противопоставлять." с примером ужасной команды, в которой "новые сотрудники слились в едином порыве отстаивания исключительно своих интересов" (что было в исходной ситуации - черт его знает, но именно работодатель в большинстве случаев диктует жёсткую работу в кратчайшие сроки, не так ли?), плюс тезис "несправедливость - это норма".
Беря руководителей, которые согласны работать по таким лекалам, какую корпоративную культуру мы получаем, уважаемый руководитель отдела?
Корп. культура будет совершенно любой. Факторов и людей, влияющих на корп. культуру значительно больше, тимлид больше про результаты в конкретном тех. скоупе, а не про корп. культуру.
Эти два примера + остальные пойнты (планирование/риски/переговоры/обратная связь и ТД) из онбординга помогают эти результаты получать планово и комфортно (а не аврально) для лида и команды, адекватно воспринимая реальность (в ней нет справедливости и куча сюрпризов, а также приходится уважать не только свои интересы)
Вы себя или читателя пытаетесь убедить?
Набирая техлидов по принципу "защищай интересы компании, убеждай, что всегда интересы сотрудника = интересы компании", вы не вносите вклад в корпоративную культуру и она может быть любая? В теории - может, на практике - невозможно пожать то, что не сеял.
Приходится уважать не только свои интересы? Разумеется. Вот только как так получается, что это именно работник должен входить в обстоятельства фирмы и подождать зарплату, поработать сверхурочно. Какой паритет, когда работодатель идёт на встречу работнику? Мы все знаем ответ.
Условия труда справедливы ровно в той мере, в которой у сотрудников получается объединяться и грамотно, законно их защищать от поползновений работодателя с тезисами в духе "поймите наконец, мир просто несправедлив, поэтому живо прекращайте что-то требовать и давайте за работу".
Вы описываете крайне странного работодателя, особенно в реалиях сегодняшнего рынка ИТ специалистов. Безусловно, такие есть, но от них нужно бежать, на мой взгляд.
Онбординг в статье рассчитан на компании, в которых все права сотрудников соблюдаются by design.
А что вы вкладываете в слова "особенно в реалиях сегодняшнего рынка ИТ специалистов"? Я слышал крайне разные мнения, как видите рынок лично вы?
И если не секрет, насколько норма переработки в Озон?
Вы уходите от прямых вопросов.
И противоречите сами себе: "все права сотрудников соблюдаются by design" не бьётся с "мир несправедлив, интересы компании - это ваши интересы". Интересы владельца Озона совпадают с интересами кладовщика на озоновском складе?
Впрочем, если перечень "всех прав сотрудников" сократить... то тогда "by design".
P.S. Озон с ходу: пожары на складах, забастовки сотрудников, невыполнение норм санпина в пунктах выдачи (которые, что удобно, де-юро с Озон не связаны) - банальное наличие окон или приточной вентиляции можно проверить собственными глазами во время визита. Это тот самый "by design"?
Точно, спасибо, что открыли глаза на горькую правду, я ошибался
Совсем забыл, что тимлиды групп разработки из Ozon Tech базируются в помещениях без окон и вентиляции. В этих душных офисах класса А на 30+, а иногда и того хуже на 50+ этажах Москва-Сити.
Ещё этот жесточайший банановый латте, завтраки, игровые комнаты, массажные кресла - бесстыдно со стороны работодателя так эксплуатировать нас. Завтра же пишу заявление. Вы абсолютно правы.
В статье все совершенно правильно, видно что писалась на опыте, но... к сожалению, я все это давно знаю за 20 лет в разработке, использую каждую из этих best practices, а все все равно идет через одно место ) Потому что в современном айти люди не хотят работать, люди хотят сидеть дома, уделяя работе 2-3 часа в день, проблемы компании и продукта им до одного места, приоритет "бухал все выходные, прокрепиться планнинг в понедельник с каменным лицом и поспать, потом как-нибудь сделаю" куда выше всех важных KPI.
Единственная причина, по которой я, видимо, в последний раз в жизни согласился на пост CTO - любой другой из существующих сотрудников будет выполнять эту работу еще хуже
Настольная инструкция лида: читать её, конечно, никто не собирался