Привет) одна из важных мыслей, которую я пытался донести - важность принципов. Меньшее значение имеет инструментарий, фреймворки.
Каган пишет, что все равно как именно работают процессы delivery/discovery, но важно, чтобы они опирались на вот такие-то принципы. Когда читал про принципы, то у меня в голове "щелкало" - даааа, это то что надо)
А если хочется разобраться с delivery, то из моего опыта курсы Вани Замесина и go practice раскрывают прекрасно. Там нет "водопада", жизненного цикла. Только выстраданный опыт и методологии.
Руслан, спасибо за комментарий и что прочитал статью)
Задачи возникают из различных источников. Что-то приходит от бизнеса, что-то от регуляторов (например, изменения Google Policy), что-то от самой команды (техдолг). Приоритетами задач управляет продакт-менеджер, а задача команды помогать приоритеты определять. От технической команды представителем является как правило тимлид, но важно, чтобы разработчик сам интуитивно понимал важность той или иной задачи и мог внести свой инпут.
Парадигма "дали задачу и сказали что делать" - это мидл, а если мы говорим про синьера, то в этом случае он начинает активно организовывать работу команды, вставать в позицию девлида, проактивно митигировать проблемы, подсвечивать риски стейкхолдерам. И для того, чтобы эффективно это делать понимание бизнеса критично.
Прежде чем перейду к теории: работа в крупной компании - это всегда трейдофф. В таких компаниях очень хорошо платят, а особенно людям, которым на уровне компании считаются синьерами+ (экспертами). Но при этом и задач приходится решать не мало, в том числе подобного рода (ревью кандидатов на синьерство). Ну и считаем, что по "пирамиде Маслоу" и прочих аналогов, базовые потребности у инженеров в крупных компаниях закрыты (или почти закрыты).
Есть замечательная книжка "Мотивация 3.0" или "Драйв: что на самом деле нас мотивирует". Базовый тезис, что мотивация деньгами работает для скучных и рутинных задач, а вот для сотрудников, которые решают сложные задачи, мотивация строится на чувстве предназначения (делаешь классные штуки, которыми сам гордишься), автономности (сам выбираешь как работать, когда работать, где работать) и возможности прокачать свое мастерство/скилл. При этом мы учитываем и знаем, что в разное время на людей действует разная мотивация, но в общем случае для экспертов эта активность не про деньги.
Согласен, что тимлиду необходимо знать информацию о хэдкаунте и планах. Еще ему важно работать с HR, своим руководителем и бизнесом, чтобы хэдкаунта на планы хватало, то есть помогать сводить планы и реальность.
Не соглашусь, что тимлид должен тянуть каждого разраба к синьер+. Тянуть нужно тех людей, у которых есть на это запрос. Синьерность подразумевает определенные навыки, умения, желания, а если человеку комфортно на текущей позиции, он справляется с работой, то и не надо трогать человек, не ломая композиция команды
Доброе утро! Спасибо за классный комментарий и мне радостно за Вас, что двигаетесь с двух сторон. На 100% согласен, что задача тимлида растить людей.
Внесу маленькое уточнение в статью: анкета - это результат работы тимлида и кандидата. На самом деле заполняет ее как правило кандидат по предоставленному шаблону + опираясь на публичные анкеты коллег, которые ранее проходили успешный промоушн. Задача тимлида убедиться, что фактуры достаточно для того, чтобы кандидат считался синьером на уровне нашей компании. При этом желание, план перехода на синьера и прочие вопросы тимлид обсуждает с кандидатом в рамках регулярной работы (как правило встречи 1-1).
Дополнительно поясню зачем нужны эксперты - мы хотим выравнивать уровень разработчиков между разными департаментами. Например, сегодня ты занимаешься проектом А и (неожиданно) возникает потребность на твой проект найти людей, которые помогут его "затащить" => ты знаешь, что люди которые стали синьерами соответствуют некоему общему стандарту компании => c большей долей вероятности помогут тебе в проекте.
Интересный подход. Опираться только на количественные данные по решенным задачам точно недостаточно, но сигнал для будущих решений сильный.
В моей картине мира любой сотрудник получает зарплату за решаемые бизнес задачи. И пониманием зачем он это делает критично. Даже если ему задачу делегирует лид, то это не повод не разобраться в чем ценность и что на самом деле хотят.
Игорь, согласен, что в терминологии мы забыли синхронизироваться. Спасибо, что подсветил. Я исходил из того, что тимлид - это роль, ответственная за профессиональный и карьерный рост сотрудников. Где-то это руководитель разработки, где-то прожект менеджер, где-то тех лид.
И конечно же подходов к топологии команд, ролям внутри жутко много. И все пытаются адаптировать их под себя.
Да, мир сложный. Реальное продвижение по карьере зависит от сотен параметров: от уровня твоего руководителя до финансовых показателей компании. Любой процесс в крупной компании нужен, чтобы была управляемость, предсказуемость и общие понятные правила.
С позицией, что все построено против разработчиков, не соглашусь. Суть работы - это взаимный обмен. Ты нам x ютилей полезности, а мы тебе y рублей. Построить справедливую систему сложно, мы пытаемся.
Согласен. Job hopping - один из самых понятных и быстрых способов в начале карьеры быстро забраться на синьера с отличной зарплатой.
Проблемы начинаются дальше. Например, у нас после синьера есть позиции ведущего разработчика, эксперта, старшего эксперта, ведущего эксперта и principal эксперта. Плюс есть возможность на этой карьерной лестнице сделать переход в менеджерскую ветку. Тут job hopping не помогает.
Мой личный опыт - 10 лет в компании. 5 лет от стажера до синьера и 5 лет на менеджерском треке. В целом очень рад, что не выбрал job hopping как карьерную стратегию
В тексте есть важное упоминание, что разработчик должен успешно решать задачи, но просто решать задачи недостаточно чтобы стать старшим разработчиком.
Если мы смотрели бы на опыт MAANG-компаний, то разработчик на проектах, которые менее важны для бизнеса, не получил бы продвижения - факт. В нашем случае мы хотим, чтобы у кандидата в синьеры было понимание какой вклад его работа для бизнеса компании. We live in society) Но и да мы активно промоутим людей с самых различных проектов.
Да, российские авторы и ученые очень здорово продвинулись в педагогике. И когда ты замечаешь, что книги для детей также важны для работы со взрослыми, то испытываешь огромное удовольствие.
По поводу времени, то все очень по-разному: - иногда выделяю слот в рабочее время; - иногда читаю в свободное время; - иногда читаю за обедом или по дороге домой.
У меня выделение времени на чтение скорее связано с другими аспектами: - мотивацией (все ли хорошо с дофамином); - удовлетворение своих базовых потребностей (понимаю ли я что мне нужно делать, чтобу удовлетворить свои базовые потребности и смог ли я выявить и каскадировать эти потребности на подцели и есть ли там необходимость читать); - дисциплина.
Я невероятно горжусь российским менеджментом и восхищаюсь его находчивостью и уверен, что в будущем мы увидим множество качественной литературы про технический менеджмент.
Отсутствие русскоязычных авторов обусловлено тем, что опыт управления коммерческими IT-компаниями у нас пока не такой богатый и пока мы ждем когда текущие звезды управления напишут свои книги.
Привет, спасибо, что поделился. Если для тебя выбранный подход работает, то это замечательно. Наличие своего бизнеса - это тот опыт, что есть у оочеень малого количества людей, но он стоит очень дорого.
В моей картине мира опора на личный опыт, опыт коллег и последующее извлечение знаний из этого опыта имеет 2 особенности: - стоимость обучения для компании и риски. Бывают ситуации, когда цена ошибки слишком велика, поэтому возникает потребность поискать иные способы получить навык/знание. Более дешевые для всех) - из-за того, что наш опыт и опыт наших коллег достаточно ограничен, то нам необходимо загрузить в нашу голову как можно больше знаний, т.е. постараться научиться смотреть с разных углов. Для этого книги - достаточно дешевый вариант это знание/опыт получить.
Итого: у нас у всех очень разные карьеры, жизненные предпосылки, навыки, поэтому в среднем моя рекомендация совмещать теорию и практику.
Опечатался: У Вани Замесина и Gopractice - Discovery, а про конкретные практики Delivery можно смотреть у Gergely Orocz и Александра Поломодова.
Привет) одна из важных мыслей, которую я пытался донести - важность принципов. Меньшее значение имеет инструментарий, фреймворки.
Каган пишет, что все равно как именно работают процессы delivery/discovery, но важно, чтобы они опирались на вот такие-то принципы. Когда читал про принципы, то у меня в голове "щелкало" - даааа, это то что надо)
А если хочется разобраться с delivery, то из моего опыта курсы Вани Замесина и go practice раскрывают прекрасно. Там нет "водопада", жизненного цикла. Только выстраданный опыт и методологии.
Руслан, спасибо за комментарий и что прочитал статью)
Задачи возникают из различных источников. Что-то приходит от бизнеса, что-то от регуляторов (например, изменения Google Policy), что-то от самой команды (техдолг).
Приоритетами задач управляет продакт-менеджер, а задача команды помогать приоритеты определять. От технической команды представителем является как правило тимлид, но важно, чтобы разработчик сам интуитивно понимал важность той или иной задачи и мог внести свой инпут.
Парадигма "дали задачу и сказали что делать" - это мидл, а если мы говорим про синьера, то в этом случае он начинает активно организовывать работу команды, вставать в позицию девлида, проактивно митигировать проблемы, подсвечивать риски стейкхолдерам. И для того, чтобы эффективно это делать понимание бизнеса критично.
Прежде чем перейду к теории: работа в крупной компании - это всегда трейдофф. В таких компаниях очень хорошо платят, а особенно людям, которым на уровне компании считаются синьерами+ (экспертами). Но при этом и задач приходится решать не мало, в том числе подобного рода (ревью кандидатов на синьерство). Ну и считаем, что по "пирамиде Маслоу" и прочих аналогов, базовые потребности у инженеров в крупных компаниях закрыты (или почти закрыты).
Есть замечательная книжка "Мотивация 3.0" или "Драйв: что на самом деле нас мотивирует".
Базовый тезис, что мотивация деньгами работает для скучных и рутинных задач, а вот для сотрудников, которые решают сложные задачи, мотивация строится на чувстве предназначения (делаешь классные штуки, которыми сам гордишься), автономности (сам выбираешь как работать, когда работать, где работать) и возможности прокачать свое мастерство/скилл.
При этом мы учитываем и знаем, что в разное время на людей действует разная мотивация, но в общем случае для экспертов эта активность не про деньги.
Согласен, что тимлиду необходимо знать информацию о хэдкаунте и планах. Еще ему важно работать с HR, своим руководителем и бизнесом, чтобы хэдкаунта на планы хватало, то есть помогать сводить планы и реальность.
Не соглашусь, что тимлид должен тянуть каждого разраба к синьер+. Тянуть нужно тех людей, у которых есть на это запрос. Синьерность подразумевает определенные навыки, умения, желания, а если человеку комфортно на текущей позиции, он справляется с работой, то и не надо трогать человек, не ломая композиция команды
Доброе утро! Спасибо за классный комментарий и мне радостно за Вас, что двигаетесь с двух сторон. На 100% согласен, что задача тимлида растить людей.
Внесу маленькое уточнение в статью: анкета - это результат работы тимлида и кандидата. На самом деле заполняет ее как правило кандидат по предоставленному шаблону + опираясь на публичные анкеты коллег, которые ранее проходили успешный промоушн. Задача тимлида убедиться, что фактуры достаточно для того, чтобы кандидат считался синьером на уровне нашей компании. При этом желание, план перехода на синьера и прочие вопросы тимлид обсуждает с кандидатом в рамках регулярной работы (как правило встречи 1-1).
Дополнительно поясню зачем нужны эксперты - мы хотим выравнивать уровень разработчиков между разными департаментами. Например, сегодня ты занимаешься проектом А и (неожиданно) возникает потребность на твой проект найти людей, которые помогут его "затащить" => ты знаешь, что люди которые стали синьерами соответствуют некоему общему стандарту компании => c большей долей вероятности помогут тебе в проекте.
Понимание смотрим на этапе ревью анкет, которая заполняется лидом и кандидатом на промоушн.
Если человек напишет, что вот мои артефакты, которыми я горжусь и в рамках их он опишет их output+outcome, то это и есть понимание.
Интересный подход. Опираться только на количественные данные по решенным задачам точно недостаточно, но сигнал для будущих решений сильный.
В моей картине мира любой сотрудник получает зарплату за решаемые бизнес задачи. И пониманием зачем он это делает критично. Даже если ему задачу делегирует лид, то это не повод не разобраться в чем ценность и что на самом деле хотят.
Игорь, согласен, что в терминологии мы забыли синхронизироваться. Спасибо, что подсветил. Я исходил из того, что тимлид - это роль, ответственная за профессиональный и карьерный рост сотрудников. Где-то это руководитель разработки, где-то прожект менеджер, где-то тех лид.
И конечно же подходов к топологии команд, ролям внутри жутко много. И все пытаются адаптировать их под себя.
Да, мир сложный. Реальное продвижение по карьере зависит от сотен параметров: от уровня твоего руководителя до финансовых показателей компании. Любой процесс в крупной компании нужен, чтобы была управляемость, предсказуемость и общие понятные правила.
С позицией, что все построено против разработчиков, не соглашусь. Суть работы - это взаимный обмен. Ты нам x ютилей полезности, а мы тебе y рублей. Построить справедливую систему сложно, мы пытаемся.
Согласен. Job hopping - один из самых понятных и быстрых способов в начале карьеры быстро забраться на синьера с отличной зарплатой.
Проблемы начинаются дальше. Например, у нас после синьера есть позиции ведущего разработчика, эксперта, старшего эксперта, ведущего эксперта и principal эксперта. Плюс есть возможность на этой карьерной лестнице сделать переход в менеджерскую ветку. Тут job hopping не помогает.
Мой личный опыт - 10 лет в компании. 5 лет от стажера до синьера и 5 лет на менеджерском треке. В целом очень рад, что не выбрал job hopping как карьерную стратегию
Привет.
В тексте есть важное упоминание, что разработчик должен успешно решать задачи, но просто решать задачи недостаточно чтобы стать старшим разработчиком.
Если мы смотрели бы на опыт MAANG-компаний, то разработчик на проектах, которые менее важны для бизнеса, не получил бы продвижения - факт. В нашем случае мы хотим, чтобы у кандидата в синьеры было понимание какой вклад его работа для бизнеса компании. We live in society) Но и да мы активно промоутим людей с самых различных проектов.
Да, российские авторы и ученые очень здорово продвинулись в педагогике. И когда ты замечаешь, что книги для детей также важны для работы со взрослыми, то испытываешь огромное удовольствие.
По поводу времени, то все очень по-разному:
- иногда выделяю слот в рабочее время;
- иногда читаю в свободное время;
- иногда читаю за обедом или по дороге домой.
У меня выделение времени на чтение скорее связано с другими аспектами:
- мотивацией (все ли хорошо с дофамином);
- удовлетворение своих базовых потребностей (понимаю ли я что мне нужно делать, чтобу удовлетворить свои базовые потребности и смог ли я выявить и каскадировать эти потребности на подцели и есть ли там необходимость читать);
- дисциплина.
Я невероятно горжусь российским менеджментом и восхищаюсь его находчивостью и уверен, что в будущем мы увидим множество качественной литературы про технический менеджмент.
Отсутствие русскоязычных авторов обусловлено тем, что опыт управления коммерческими IT-компаниями у нас пока не такой богатый и пока мы ждем когда текущие звезды управления напишут свои книги.
Привет, спасибо, что поделился. Если для тебя выбранный подход работает, то это замечательно. Наличие своего бизнеса - это тот опыт, что есть у оочеень малого количества людей, но он стоит очень дорого.
В моей картине мира опора на личный опыт, опыт коллег и последующее извлечение знаний из этого опыта имеет 2 особенности:
- стоимость обучения для компании и риски. Бывают ситуации, когда цена ошибки слишком велика, поэтому возникает потребность поискать иные способы получить навык/знание. Более дешевые для всех)
- из-за того, что наш опыт и опыт наших коллег достаточно ограничен, то нам необходимо загрузить в нашу голову как можно больше знаний, т.е. постараться научиться смотреть с разных углов. Для этого книги - достаточно дешевый вариант это знание/опыт получить.
Итого: у нас у всех очень разные карьеры, жизненные предпосылки, навыки, поэтому в среднем моя рекомендация совмещать теорию и практику.