то есть вы перпендикалярно теме вопрос поставили

посчитать-то можно, но зачем?

А если, например, заказчик хочет output, а не outcome?

То что?

То нафиг так работать 😁

А если, например, заказчик хочет output, а не outcome?

зачем так жить?

Я несколько раз сталкивался с темой - а давайте посчитаем стоимость фичи

Обычно это значило что кто-то получает зря зарплату

;/

а потом надо пересчитать прибыль с фичи и занести заказчика в расстрельный список

в Agile как правило считают outcome (ценность), а не output (фича)

Слава, можешь рассказать немного подробнее

погуглите wsjf

нагуглится вот это скорее всего http://www.scaledagileframework.com/wsjf/

не фанат этой темы, но она про ауткам

Сам по себе SAFe сложно назвать гибким, но зато много интересного описано :)

Бюджетирование только там

и в Kanban ESP, больше нигде нет (не беру в расчет Prince agile, не знаком)

недавно услышал о нем от вот этого дядьки: http://ailev.livejournal.com/ все посты очень интересные, но половины не понимаю :-)

доступным языком здесь можно послушать http://2016.secon.ru/speakers/26 А у дядьки книжка хорошая, посмотри в медиафайлах группы. Цепков тоже рассказывал в контексте истории практики управления проектами http://mtsepkov.org/Развитие_управления_проектами_и_критериев_качества_в_ИТ_(Максим_Цепков_на_AgileDays-2015)

в Agile как правило считают outcome (ценность), а не output (фича)

Такой подход так же интересен. Я так понимаю это ценнсть от внедрения?

Такой подход так же интересен. Я так понимаю это ценнсть от внедрения?

Это мера решения проблем пользователей, связанная с использованием продукта. Задайте вопрос: за что на самом деле платят эти люди? Какие цели помогает этот продукт решить?

Практика показала лучше задавать вопрос - а вот если мы эту штуку выключим, расстроитесь? )))

Согласен. Что произойдет, если этого не случится?

т.е. с таким подходом мы пытаемся влиять на какие-то компоненты деревьев KPI? глубокий подход, а он работает?

KPI :) я пасс

Но вопрос задам ВОт у меня есть отдел разработки, есть менеджер отдела. Я ему ставлю KPI на скорость выпуска фич, что он будет делать?

доход = средний доход с пользователя * количество пользователей количество пользователей = текущее количество + прирост прирост = скорость приобретения - скорость оттока ну и т.д.

а в чем именно для тебя выражается скорость выпуска фич и для чего она тебе нужна?

в зафейленых сроках

IT называет дату, и не соблюдает, ввожу KPI

на соблюдение, например дельта от времени :)

а откуда ты берешь желаемое значение?

я не беру мне IT называет

"я верю"

а они _умеют_ правильную дату назвать? :-)

плохой KPI взял? Давайте поговорим а каком-нибудь другом :)

Что значит умеют, они же IT отдел

да не, нормальный. я подозреваю, что я вообще термин неправильный использую

а они _умеют_ правильную дату назвать? :-)

Все равно фича не сделается быстрее, чем она сделается

Что значит умеют, они же IT отдел

ну они тебе называли правильный срок и при этом желательно неоднократно?

так давайте сразу к сути, IT фейлит сроки, я делаю KPI на сроки - как IT отделу поможет соблюдать сроки введеные KPI?

Все равно фича не сделается быстрее, чем она сделается

ну не скажи, тут явно нужно понимать какого уровня профессионализма и осознаности у тебя люди - сроки могут постоянно срываться из за ненужного рефакторинга из за излишней сложности решения

:))

так давайте сразу к сути, IT фейлит сроки, я делаю KPI на сроки - как IT отделу поможет соблюдать сроки введеные KPI?

Слава, ну тут смотря с какой стороны пытаться решить проблему: 1) По Agile - ни каких kpi, ты садишься с командой и вы разбираете эту проблему, планируете драфт улучшения. Лучше всего сделать через общее ретро 2) По поводу kpi - да все равно не сработает, аукнется потом тех. долгом

Ну то есть никак

так давайте сразу к сути, IT фейлит сроки, я делаю KPI на сроки - как IT отделу поможет соблюдать сроки введеные KPI?

а начинался интересный бой) так нет же, надо сразу к сути и всё сломалось

Ну то есть никак

По сути да

не будет золотой пули

Хотите теперь поговорим о том как профессионализм программиста связан с его способностью сроки называть?

т.е. с таким подходом мы пытаемся влиять на какие-то компоненты деревьев KPI? глубокий подход, а он работает?

собственно, вопрос про KPI уже неактуален

только разбором и решением текущих проблем

Хотите теперь поговорим о том как профессионализм программиста связан с его способностью сроки называть?

никак?)

практически

Слава, а диапозон сроков?

на сколько декомпозирована задача ?

с теорией тяжелого хвоста знаком?

так давайте сразу к сути, IT фейлит сроки, я делаю KPI на сроки - как IT отделу поможет соблюдать сроки введеные KPI?

если сроки зафейлились, значит что-то пошло не так, надо разбираться

хвост это не про называние сроков, а про прогноз

покажите мне программиста который сроки называет из статистических данных ))

если сроки зафейлились, значит что-то пошло не так, надо разбираться

"недооценили сложность задачи, потому что не Ванги"

я понял, где у нас расхождение -- я говоря KPI, говорю SLO (индикатор), а все понимают SLA (штрафы/премии и т.д.)

он их называет по своей субъективной статистике

что примерно такие задачи он делал за X дней

ну не скажи, тут явно нужно понимать какого уровня профессионализма и осознаности у тебя люди - сроки могут постоянно срываться из за ненужного рефакторинга из за излишней сложности решения

Мей би. Но так это команда же уровня такого получается. Нужен либо человек с лучшей экспертизой в команду. Который будет ставить противовес. Либо ты обучаешь команду :)

покажите мне программиста который сроки называет из статистических данных ))

Ну исходя из опыта и знания продукта/технологий эстимейтишь, да.

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

там все проще на самом деле > что примерно такие задачи он делал за X дней оценка она в трудозатратах как правило, а не в количетве дней

то есть вопрос же задается не "когда будет на продакшене", а "а сколько времени тебе надо делать на эту задачу?"

второй вопрос - это выстрел себе в ногу

+1, про календарь никто не думает, это, в общем-то, не в зоне влияния прогера зачастую

чтобы отвечать на первый вопрос - разработчик вообще не нужен

@neemah не понятен в какую стороны идет беседа, по большей части сейчас игра слов. Есть конкретный вопрос?

:) выбираю игру слов

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

(нет)

на сколько ты погружался в их проблемы, на сколько ты знаешь их процессы и "узкие горлышки"

и не понятно как у нас связано outcome vs output с этим обсуждением скорости программистов. мы разрабатываем продукт, который поможет уменьшить непопадание программистов в сроки -- это outcome. продаем время этих программистов, чтобы лучше попадать в сроки -- это [возможно] output.

топик другой, они не связаны

на сколько ты погружался в их проблемы, на сколько ты знаешь их процессы и "узкие горлышки"

и как погружение менеджера в проблему и знание им узких мест влияет на точность оценки сроков программистом?

никак

+1