Think from idea to production — сфера интересов EM должна включать не только написание кода. Они должны интересоваться тем, как проблемы превращаются в идеи, как эти идеи формируются и реализуются. Это означает понимание процесса разработки продукта в вашей компании и влияние на него при необходимости.
Lower lead time means higher value — влияя на процессы вашей компании, сосредоточьтесь на сокращении времени выполнения от идеи до производства. Успех команды определяется не качеством работы инженеров, а тем, насколько быстро они могут предоставить своим клиентам высококачественную и эффективную работу. Это означает принятие решений, стимулирующих короткие циклы обратной связи, короткие итерации и тесное взаимодействие между подразделениями по всем направлениям.
Focus on early alignment — главное преимущество кросс-функциональных команд инженеров продукта заключается в том, что они имеют разные точки зрения на формирование продукта на всех этапах его разработки. Поэтому крайне важно стимулировать согласованность на раннем этапе между продуктом, дизайном и разработкой, гарантируя, что все понимают и согласны с тем, что они разрабатывают, почему они это разрабатывают и как они это будут делать. Практический метод, который я использовал для достижения этой цели, — это вводные встречи для планирования, гарантирующие всей команде возможность высказаться с самого начала.
Scope development in iterations of quality — самый простой способ избежать аврала - гарантировать, что всегда будет версия продукта, которая запущена или готова к запуску. Это превращает любой неудобный разговор о объеме работ «Почему эта функция ещё не запущена?» в более приемлемое бизнес-решение «Стоит ли выпускать версию 0.2, которая уже готова?». Лучший метод для этого — User Story Mapping, которое позволяет командам мыслить в рамках объема работ, а не переключателями «вкл/выкл».
Create space for challenging conversations — EMs должны убедиться, что другие специалисты понимают работу и компромиссы, которые необходимо принять, что позволит им участвовать в инженерном обсуждении. На практике это означает, что все объемы работ должны быть прописаны с точки зрения клиента, стимулировать конструктивные обсуждения объема работ и трудозатрат, а также позволять всем сторонам оценивать ценность любой работы, выполняемой в команде.
В конечном счете, инженерам и EMs необходимо сосредоточиться на влиянии, а влияние в команде разработчиков продукта определяется не только написанием кода — чем шире обсуждение этого вопроса EMs смогут организовать, тем лучших результатов они достигнут.
Красиво и даже может работать (есть у кого сейчас что-то подобное?).
Но сильно зависит от процессов в компании и взаимоотношениях между разработкой и продуктологами.
Иногда трения таковы, что велик соблазн уйти в "напишите нам, что надо сделать - мы закодим". И это печально.
#процессы
