Это большая боль у ребят кто пытается идти в эту сторону, а особенно не застрять на пол пути. Я сам прошел схожий путь, поэтому поделюсь своими мыслями после прочтения. Возможно, это будет полезно тем, кто сейчас думает о том: "а куда дальше?".
В общей картине разработка больше про людей и взаимодействие между ними, что, безусловно, входит в зону ответственности ЕМ.
Забавно, люди и их взаимодействие являются узким местом в разработке, а не технологии.
С этой точки зрения конечно все зависит от продукта, но очень часто EM, может прийти к выводу, что для выполнения своих обязанностей надо сначала команду построить из кучи людей (то бишь быть TL). Отсюда кстати как по мне и путаница.
А вот когда TL сделал свою работу, или у тебя есть команда, которая поддается изменением уже можно и начать задачи EM выполнять.
Предлагаю рассмотреть гипотетический путь от инженера к TL и потом к ЕМ
Если у тебя нет команды, сначала построй её. Это частый путь для разработчика через team lead. Кому-то повезёт: всё готово, и можно сразу переходить в ЕМ.
TL может совмещать работу PM, но для ЕМ это необычно и неправильно.
"Код" — это продукт для разработчиков, а разработчики — его пользователи. Их работа (coder story 🤣) — менять его. Значит, тут должен быть product owner. Эта метасистема — больше, чем архитектура, она про скорость изменений и про то, насколько более сложные задачи команда может решать на базе существующего кода. Вот EM и развивает этот метапродукт
Обосновывай переход выгодой для твоего руководителя и компании.
Это очень важно. Часто люди на этом спотыкаются. Когда разбираешь это с ними, они удивляются: "О, это так просто! Я вообще не так думал, всё усложнял и спорил."
Четвёртый пункт — про поиск вакансии внутри компании и продажу себя.
У C-level всегда проблема найти человека, готового взять на себя хоть маллую часть ответственности. Как только ты начнёшь это делать, система сама будет тебя продвигать. Такие кадры в дефиците, и всегда найдётся, чем их занять. Иногда достаточно просто помочь коллеге из другого отдела настроить Google Sheets, когда в фичу не делали год для него, сэкономив время и проявив неравнодушие.
Тут кстати есть спасение - PlantUML, можно диаграмму хранить тексом, а потом рисовать, мы использовали это, удобно в целом, например когда дока в git + Docsify
да и Сonfluence то же поддерживает и прочие wiki-системы
Это большая боль у ребят кто пытается идти в эту сторону, а особенно не застрять на пол пути. Я сам прошел схожий путь, поэтому поделюсь своими мыслями после прочтения. Возможно, это будет полезно тем, кто сейчас думает о том: "а куда дальше?".
Забавно, люди и их взаимодействие являются узким местом в разработке, а не технологии.
С этой точки зрения конечно все зависит от продукта, но очень часто EM, может прийти к выводу, что для выполнения своих обязанностей надо сначала команду построить из кучи людей (то бишь быть TL). Отсюда кстати как по мне и путаница.
А вот когда TL сделал свою работу, или у тебя есть команда, которая поддается изменением уже можно и начать задачи EM выполнять.
Если у тебя нет команды, сначала построй её. Это частый путь для разработчика через team lead. Кому-то повезёт: всё готово, и можно сразу переходить в ЕМ.
"Код" — это продукт для разработчиков, а разработчики — его пользователи. Их работа (coder story 🤣) — менять его. Значит, тут должен быть product owner. Эта метасистема — больше, чем архитектура, она про скорость изменений и про то, насколько более сложные задачи команда может решать на базе существующего кода. Вот EM и развивает этот метапродукт
Это очень важно. Часто люди на этом спотыкаются. Когда разбираешь это с ними, они удивляются: "О, это так просто! Я вообще не так думал, всё усложнял и спорил."
У C-level всегда проблема найти человека, готового взять на себя хоть маллую часть ответственности. Как только ты начнёшь это делать, система сама будет тебя продвигать. Такие кадры в дефиците, и всегда найдётся, чем их занять. Иногда достаточно просто помочь коллеге из другого отдела настроить Google Sheets, когда в фичу не делали год для него, сэкономив время и проявив неравнодушие.
Спасибо за статью!
Тут кстати есть спасение - PlantUML, можно диаграмму хранить тексом, а потом рисовать, мы использовали это, удобно в целом, например когда дока в git + Docsify
да и Сonfluence то же поддерживает и прочие wiki-системы