Точно, спасибо, что открыли глаза на горькую правду, я ошибался
Совсем забыл, что тимлиды групп разработки из Ozon Tech базируются в помещениях без окон и вентиляции. В этих душных офисах класса А на 30+, а иногда и того хуже на 50+ этажах Москва-Сити.
Ещё этот жесточайший банановый латте, завтраки, игровые комнаты, массажные кресла - бесстыдно со стороны работодателя так эксплуатировать нас. Завтра же пишу заявление. Вы абсолютно правы.
Вы описываете крайне странного работодателя, особенно в реалиях сегодняшнего рынка ИТ специалистов. Безусловно, такие есть, но от них нужно бежать, на мой взгляд.
Онбординг в статье рассчитан на компании, в которых все права сотрудников соблюдаются by design.
Корп. культура будет совершенно любой. Факторов и людей, влияющих на корп. культуру значительно больше, тимлид больше про результаты в конкретном тех. скоупе, а не про корп. культуру.
Эти два примера + остальные пойнты (планирование/риски/переговоры/обратная связь и ТД) из онбординга помогают эти результаты получать планово и комфортно (а не аврально) для лида и команды, адекватно воспринимая реальность (в ней нет справедливости и куча сюрпризов, а также приходится уважать не только свои интересы)
Каждый из моих вопросов по порядку соотносится с пойнтами из статьи, вы же предлагаете о них не говорить, сказать "делай качественно и много", а дальше за все косяки наказывать вплоть до увольнения (это вывод исходя из ваших ответов)
Откуда ему знать изначально, что это косяк? Лид ведь тоже человек, а ещё у него есть сотрудники, которые будут ощущать все эти ошибки, отсюда и статья по онбордингу
Утверждения, что лид должен делать работу PM, продажника и тд, не приводились в статье. Более того есть утверждение о наличии специалистов разного профиля, но о тонких тех. нюансах они не могут знать.
Тут лишь история о том, что есть такие стримы, в которых со стороны ответственности лида могут быть косяки. На мой взгляд, сильно человечнее о них сказать сразу, а не идти предложенным вами путем с увольнениями "чуть что"
Тогда берём две предложенные вами метрики: количество сделанного командой и качество этого сделанного. Значит, исходя из этих метрик, лид должен как-то сделать так, чтобы команда делала много задач и как можно более качественно.
Теперь по пойнтам из статьи:
Как делать много, если лид не управляет ожиданиями заказчиков фичей? Тимлид соседней команды не захочет больше просить у него новых доработок, бизнес-заказчик тоже лучше придет в другую команду, там где ему скажут сроки и попадут в них с минимальным люфтом
Как делать много, если команда хочет перед стартом работ над целевым продуктов написать свою собственную IDE, удобную и быструю, а лид с этим ОК?
Как делать качественно, если лид не участвует в переговорах, а соседний сервис, от которого зависит стабильность релизов команды постоянно сбоит ?
Как делать качественно, если лид соседней команды А очень просит одного, а лид команды Б второго и обе фичи друг другу противоречат? Команда будет рада тому, что она последовательно реализует две конфликтующие фичи?
Как делать много, если лид ничего не планирует в рамках своего сервиса/части системы и не корректирует планы?
Как делать качественно, когда при каждом релизе команда почему-то кладет прод, а лид не оценивает риски и ему неважно, что где-то в его системе некорректно прогревается кэш?
Как делать качественно, если команда не знает, что такое качественно? Ведь лид не даёт ей системно обратную связь по сделанному
Напротив, ошибаться можно и это нормально. Инструкция скорее для минимизации управленческих ошибок, полностью исключить их невозможно. Единственный способ не ошибаться вовсе - это ничего не делать :)
Спасибо, на мой взгляд прелесть техлидства в том, что можно сильно делать упор именно в техничку. Постепенно практически полностью закрывая своему тимлиду пойнт про технические риски, ему будет одной проблемой меньше, вам одним довольным руководителем больше)
Все так, но в реалиях сегодняшнего рынка такого все меньше. Знаю лично несколько прецедентов, когда команда разработки всем составом куда-то уходила или наоборот приходила в компанию и так из раза в раз. А там где компания понимает, что такое настоящая долгосрочная мотивация (в том числе и денежная) такие команды задерживаются надолго
Достаточно узнать кто поддерживает какие-то наиболее важные участки крупных и важных систем. Очень часто это будет либо старая команда, либо команда, где основной костяк "старички". Невидимая рука рынка диктует условия, все больше компаний вкладываются в свои ИТ команды на долгосрок
Статья лишний раз подтверждает, что "играть" в разработку надо только в долгую и компании, и команды разработки должны совместно совершенствовать продукт
Компания получает надёжный продукт и сильную команду. Команда получает сильную компанию, в которой реально расти и развиваться годами
Точно, спасибо, что открыли глаза на горькую правду, я ошибался
Совсем забыл, что тимлиды групп разработки из Ozon Tech базируются в помещениях без окон и вентиляции. В этих душных офисах класса А на 30+, а иногда и того хуже на 50+ этажах Москва-Сити.
Ещё этот жесточайший банановый латте, завтраки, игровые комнаты, массажные кресла - бесстыдно со стороны работодателя так эксплуатировать нас. Завтра же пишу заявление. Вы абсолютно правы.
Вы описываете крайне странного работодателя, особенно в реалиях сегодняшнего рынка ИТ специалистов. Безусловно, такие есть, но от них нужно бежать, на мой взгляд.
Онбординг в статье рассчитан на компании, в которых все права сотрудников соблюдаются by design.
Корп. культура будет совершенно любой. Факторов и людей, влияющих на корп. культуру значительно больше, тимлид больше про результаты в конкретном тех. скоупе, а не про корп. культуру.
Эти два примера + остальные пойнты (планирование/риски/переговоры/обратная связь и ТД) из онбординга помогают эти результаты получать планово и комфортно (а не аврально) для лида и команды, адекватно воспринимая реальность (в ней нет справедливости и куча сюрпризов, а также приходится уважать не только свои интересы)
Каждый из моих вопросов по порядку соотносится с пойнтами из статьи, вы же предлагаете о них не говорить, сказать "делай качественно и много", а дальше за все косяки наказывать вплоть до увольнения (это вывод исходя из ваших ответов)
Откуда ему знать изначально, что это косяк? Лид ведь тоже человек, а ещё у него есть сотрудники, которые будут ощущать все эти ошибки, отсюда и статья по онбордингу
Утверждения, что лид должен делать работу PM, продажника и тд, не приводились в статье. Более того есть утверждение о наличии специалистов разного профиля, но о тонких тех. нюансах они не могут знать.
Тут лишь история о том, что есть такие стримы, в которых со стороны ответственности лида могут быть косяки. На мой взгляд, сильно человечнее о них сказать сразу, а не идти предложенным вами путем с увольнениями "чуть что"
Как пойнты для онбординга лида из статьи ведут к переработкам, таинству зарплат и условий роста зарплаты?
Тогда берём две предложенные вами метрики: количество сделанного командой и качество этого сделанного. Значит, исходя из этих метрик, лид должен как-то сделать так, чтобы команда делала много задач и как можно более качественно.
Теперь по пойнтам из статьи:
Как делать много, если лид не управляет ожиданиями заказчиков фичей? Тимлид соседней команды не захочет больше просить у него новых доработок, бизнес-заказчик тоже лучше придет в другую команду, там где ему скажут сроки и попадут в них с минимальным люфтом
Как делать много, если команда хочет перед стартом работ над целевым продуктов написать свою собственную IDE, удобную и быструю, а лид с этим ОК?
Как делать качественно, если лид не участвует в переговорах, а соседний сервис, от которого зависит стабильность релизов команды постоянно сбоит ?
Как делать качественно, если лид соседней команды А очень просит одного, а лид команды Б второго и обе фичи друг другу противоречат? Команда будет рада тому, что она последовательно реализует две конфликтующие фичи?
Как делать много, если лид ничего не планирует в рамках своего сервиса/части системы и не корректирует планы?
Как делать качественно, когда при каждом релизе команда почему-то кладет прод, а лид не оценивает риски и ему неважно, что где-то в его системе некорректно прогревается кэш?
Как делать качественно, если команда не знает, что такое качественно? Ведь лид не даёт ей системно обратную связь по сделанному
Напротив, ошибаться можно и это нормально. Инструкция скорее для минимизации управленческих ошибок, полностью исключить их невозможно. Единственный способ не ошибаться вовсе - это ничего не делать :)
Безусловно, похвала (конструктивная) очень важна, к сожалению, про это часто забывают
Если не затруднит, могли бы поделиться ссылкой на персонажа с усами из утиных историй ?
Помню там только одного с бородой, но без усов
тезисы в статье помогают выжить или наоборот?
А какие именно поисковые запросы вызывают желание заплакать ? Если подскажите регион, устройство и конкретные запросы, обязательно передам коллегам
Спасибо, на мой взгляд прелесть техлидства в том, что можно сильно делать упор именно в техничку. Постепенно практически полностью закрывая своему тимлиду пойнт про технические риски, ему будет одной проблемой меньше, вам одним довольным руководителем больше)
Что тогда оставили бы в качестве важных пойнтов для лида ?
Тогда почему у этого маркетплейса >45 миллионов активных покупателей? Без иронии, интересно послушать ваше мнение
Все так, но в реалиях сегодняшнего рынка такого все меньше. Знаю лично несколько прецедентов, когда команда разработки всем составом куда-то уходила или наоборот приходила в компанию и так из раза в раз. А там где компания понимает, что такое настоящая долгосрочная мотивация (в том числе и денежная) такие команды задерживаются надолго
Достаточно узнать кто поддерживает какие-то наиболее важные участки крупных и важных систем. Очень часто это будет либо старая команда, либо команда, где основной костяк "старички". Невидимая рука рынка диктует условия, все больше компаний вкладываются в свои ИТ команды на долгосрок
Статья лишний раз подтверждает, что "играть" в разработку надо только в долгую и компании, и команды разработки должны совместно совершенствовать продукт
Компания получает надёжный продукт и сильную команду. Команда получает сильную компанию, в которой реально расти и развиваться годами