Как стать автором
Обновить

Продуктовый подход к инхаус-разработке: отвечаем бизнесу, когда наконец-то будет готово через метрики и 85й перцентиль

Уровень сложностиСредний
Время на прочтение9 мин
Количество просмотров4.1K
Всего голосов 11: ↑10 и ↓1+9
Комментарии8

Комментарии 8

Статья огонь!

Но не совсем понял, а какие методы использовали для сокращения сроков? Изменение от 100 к 54 дням - это следствие чего? Будет интересно почитать об этом

День добрый, спасибо за огонь)

К уменьшению сроков реализации привели вот прям все-все меры из статьи: что мы научились ограничивать одновременную работу, что мы перестали пихать любые задачи всем подряд и появилась структурность разработки, что мы приросли аналитиками, которые разгружают тим-лидов в плане постановки требований.
Так же повлияло то, что сам продуктовый подход, спринты и демонстрация показателей очень мотивирует команду двигаться вперёд.

Возможно, есть что-то ещё, что я упустил из виду, будем считать это магией)

Статья очень интересная. Тоже интересует за счет чего сократили сроки - из-за новых процессов или все таки "за год компания увеличила штат сотрудников" ?

п.с. опять приравнивание SP к абсолютным значениям. Ну как так...

п.с.с. Петрджайл - огонь название!

День добрый.

 Про SP, которые лежат на днях соглашусь, что не очень правильно, особенно с академической точки зрения, с другой стороны так делать никто не запрещал, будем считать, что это не совсем честный лайфхак)

Про ускорение ответил выше, повторюсь:

К уменьшению сроков реализации привели вот прям все-все меры из статьи: что мы научились ограничивать одновременную работу, что мы перестали пихать любые задачи всем подряд и появилась структурность разработки, что мы приросли аналитиками, которые разгружают тим-лидов в плане постановки требований.

Так же повлияло то, что сам продуктовый подход, спринты и демонстрация показателей очень мотивирует команду двигаться вперёд.

Спасибо за интерес к Петрджайлу и этой статье)

Вы не думали отказаться вовсе от оценок и например подойти к процессу иначе, через улучшение декомпозиции задач и их сегментации в рамках сервиса?

В дальнейшем уже прогнозы давать по типу задач и его принадленжности к сегменту.

Звучит интересно, я бы почитал об этом, видел видео где о подобном рассказывает Павел Ахметчанов, но на практике звучит страшновато, учитывая что мы только что выстроили иную прогнозную модель

Спасибо за статью.

Вопрос про "“Давай пока что примерно, на глаз сделаем так: три задачи L, три задачи М и четыре задачи S/XS. Устраивает?” " И бизнес сразу так согласился и не стал прибегать с "Как угодно сделайте, но чтобы завтра было готово!".

Опять же что с 85% вероятностью. Как вы и бизнес разбираете задачи которые затягиваются с 2 дней до 2 месяцев?

День добрый и спасибо за интерес к статье!

Про ограничения – всё верно, бизнес сам предложил и прям сразу согласился на этих условиях работать и даже спрашивал на комитетах «Ну что там, сколько у нас ещё слотов осталось»? Думаю, в этом есть и некоторая доля везения, и доля мастерства переговоров.

Про задачи, которые до 2-х месяцев затягиваются: во-первых, это редкость у нас, а во-вторых, мы выносим такие задачи на обсуждением с командой направления (с бизнесом или без него, в зависимости от типа задержек) и решаем, как мы можем такого избежать в будущем.

Например, была затяжная задача, которая не могла была быть протестирована из-за проблем с разворачиванием стенда. В итоге у нас появилось правило: не берем в работу Story, которые мы не знаем, как протестировать или не сможем этого сделать.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий