«Могут ли девять разработчиков родить фичу за неделю?» Как мы ускорили команду без потерь в качестве

Несмотря на немного биологический заголовок, в этом посте мы обсудим старые добрые продуктовые проблемы. Меня зовут Александр Федюнин, я пришел в Спортмастер в 2019 системным аналитиком, а сейчас — PL продукта «SM 3.0», о котором вы могли читать в предыдущих постах нашего блога. Я расскажу вам, как мы пытались придумать что‑то новое, чтобы быстро решить проблему с ресурсами и не потерять в скорости и качестве разработки.
Исторический экскурс
Начнем с того, что продуктовый подход как сущность был придуман маркетологами. В 1932 году Нил Макелрой, который работал в Procter & Gamble, решил, что стандартных маркетинговых инструментов ему уже не хватает, а более плотно развивать пользовательский опыт хочется. Он в то время как раз отвечал за продвижение мыла марки Camay. Как вы понимаете, продвигалось оно неплохо.
Другой важный этап в развитии продуктового подхода — опыт Hewlett‑Packard. Эти ребята в свое время решили, что чем ближе клиент (или конечный пользователь продукта) к точке принятия решения по этому продукту, тем успешнее будет сам продукт. И стали создавать команды, такие мини‑организации, которые полностью отвечали за весь цикл выпуска продукта, от идеи до выхода на рынок. А если численность такой организации начинала подкрадываться к 500 человек, ее делили на более мелкие части.
