Третьего дня смотрел доклад с teamleadconf о применении Канбан, WIP лимитов и теории ограничений, а также об использовании статистических методов для оценки сроков выполнения задач. Хороший доклад.
В частности. в докладе звучала фраза:
Бизнесу мы скажем примерно это:
Забавно, но именно эта оценка не будет ложью, а те, что обычно звучат — будут.
К чему я?
Не знаю. Наверное к тому, что есть ещё над чем работать в плане культуры разработки и статистических методов оценки сроков. И к тому, что у менеджеров разработки сложная работа. И к тому, что я очень мало разбираюсь во всём этом, но жутко интересно.
А ещё к тому, что перед тем, как применять классные формулы из статистики и получать от них пользу, нужно прроделать огромную работу по адекватной декомпозиции задач, выстраивании воспроизводимого и управляемого процесса разработки и настройке логирования времени. Что само по себе вполне может решить исходную проблему оценки сроков. Мой опыт - в продуктовой разработке заказчик на самом деле не спрашивает "когда?", он спрашвает "а что так долго? Нельзя быстрее?".
А пока продолжим по старинке: переносить дедлайны, резать фичи, слегка обманывать заказчиков и тянуть сроки. Ага?
В частности. в докладе звучала фраза:
Мы не знаем, когда мы сделаем эту конкретную фичу, но знаем, что за три недели мы сделаем 8 из 9 фич. Это и говорим бизнесу. Так мы сможем не врать и не плодить неоправданных ожиданий.Попробуем применить к моей реальности и культуре разработки. Сегодня я взял на тестирование задачу, аналитику по которой сделали в феврале. Это не уникальная задача, таких много.
Если кто-то собирается кинуть камень, то я абсолютно точно знаю, что моя команда не единственная, среди продуктовых, у которой подобные сроки разработки фич. У вас либо такие же сроки, либо заказная разработка. Либо вы попадаете в очень небольшой процент продуктовых команд, где реально небольшой time-to-market.Итак, пытаемся применить метод из доклада для оценки наших SLA.
Бизнесу мы скажем примерно это:
Мы не знаем, когда мы сделаем эту конкретную фичу, но знаем, что за два с половиной года мы сделаем 27 из 30 фич. Не знаем, каких именно. Не знаем, когда именно. Точнее не выходит =)Интересно, что скажет в ответ бизнес?
Забавно, но именно эта оценка не будет ложью, а те, что обычно звучат — будут.
К чему я?
Не знаю. Наверное к тому, что есть ещё над чем работать в плане культуры разработки и статистических методов оценки сроков. И к тому, что у менеджеров разработки сложная работа. И к тому, что я очень мало разбираюсь во всём этом, но жутко интересно.
А ещё к тому, что перед тем, как применять классные формулы из статистики и получать от них пользу, нужно прроделать огромную работу по адекватной декомпозиции задач, выстраивании воспроизводимого и управляемого процесса разработки и настройке логирования времени. Что само по себе вполне может решить исходную проблему оценки сроков. Мой опыт - в продуктовой разработке заказчик на самом деле не спрашивает "когда?", он спрашвает "а что так долго? Нельзя быстрее?".
А пока продолжим по старинке: переносить дедлайны, резать фичи, слегка обманывать заказчиков и тянуть сроки. Ага?
Первый шаг это конечно наладить логирование в команде, дальше уже можно хоть что-то анализировать....
ОтветитьУдалить