Это всегда так. Именно поэтому мы обновляем прогноз каждую итерацию (раз в две недели, например). Мы можем построить прогноз на throughput + wip + Lead Time (в predictable.team есть epic forecasting в Monte Carlo, там можно тыкнуть на +1 эпик и наполнить его в соответствии с вашими задачами. Тогда разброс в прогнозе будет учитывать одновременное историческое количество элементов в работе + параллельную работу + Lead Time и 50 и 85 перцентилей). Тогда ваша историческая информация о времени завершения задач будет учитывать и хвосты.
Это если у вас тендеры и аутсорс, наверное? Взаимоотношения между компаниями, предоставляющими и потребляющими услуги всегда разные. Звучит как совсем другая (хоть и очень наболевшая) проблема :)
Но мы тут говорим что прогноз первоначальный всегда надо обновлять, просто есть стат данные в не-аутсорс компаниях что на основе этой метрики считать честнее и корректнее.
А так - всегда есть миллион факторов, которые влияют на прогнозы, потому и обновляем. Также как в метеорологии первоначальные прогнозы никогда не сбываются, и они дают их с уверенностью в 30%.
В АйТи параметров прогноза меньше, но без обновления все равно никуда.
Титаническая и кропотливая работа) насколько активно те же топы или другой менеджмент пользуется самими дешами? Если активно, то это в рамках каких-то каденций или самостоятельно по необходимости?
Все верно, именно поэтому стори поинты хороши когда вам надо выровняться.
Но для квартальных и далее планирований стори поинты часто неточны. В том пункте мы говорим про кросс-командную работу - чтобы запланироваться толпой команд вместе, и вовремя выйти в прод. Так как все используют SP по-разному, надежность прогнозов когда именно та или иная команда сделает свой кусок работы низкая.
Опыт написания этого поста как раз вышел из работы в стартапе, и применим к стартапам - это я знаю точно =) Стартапе в Series B, с ~$780kk valuation, в финтех рынке ЛАТАМа.
Глубины не предполагалось, потому что это только про знакомство с подходом. Оно скорее про то, чтобы задуматься и, возможно, попробовать у себя почелленджить. Для меня этот калькулятор - самый базовый инструмент, чтобы просто сделать быструю диагностику дел в компании.
Спасибо Станислав, мы с вами прекрасно знаем как в стартапе прекрасно работается с отказоустойчивой архитектурой и какие ресурсы были выделены в этом конкретном примере. В условиях ограниченного бюджета и конкретных штатных единиц более подходящим и управляемым оперировать в рамках описанной выше таксономии. Безусловно, вы как более опытный специалист и с опытом внедрения ITIL-а, как более мачурного фреймворка имеете обширный опыт в работе с инцидентами. Было бы здорово поработать с вами в будущем.
Это подмножество обычны метрикик реагирования на сбои, но если у вас есть конкретная NOC-команда - то она может отвечать и работать в рамках этих конкретных метрик. То есть именно они те самые предметные владельцы Response, Acknowledge, Assemble. А не кто-то еще. Это скорее особенность и KPI при такой таксономии отделов.
О, тож удобная вещь, все никак не доберусь.
Про приватность карточки — удобно звучит. Правда я бы сделал видимой карточку для всех по мере того как ребята добавляют их, но у всех все своё. Надо заценить.
о, супер, попробую.
У трелло самая большая загвоздка в том, что теперь тарифы не разрешают безлимитных досок для команд — и надо делать подписку в рамках atlassian suite.
Пробовал лично, в качестве рабочего инструмента нет. Мне вообще не очень понравилось как он работает (У меня — нестабильно, как и ringcentral, blue jeans).
Как я писал, нам актуально лочиться на экосистему Atlassian :)
1. Исторически сложилось, что в штатах больше FE, в РФ больше BE девелоперов. И хоть относительный фулстек был и там и там (.net), но для некоторых фич нужна была экспертиза бэкэнда тут в РФ.
2. Есть проекты с архитектурной т.з. требующие обоих сторон океана. Но, тут надо понимать, что domain область, то есть складская логистика и продакты у нас в штатах, и за прояснением вещей в нутре проекта надо их тыркать постоянно.
Конфигурация команд сейчас
— 2xFullstack RU на пожаротушение всякое;
— 2xFE, 1xBA, 1xQA US + 3xBE, 1xQA, 1xPM RU на один гигантский проект;
— ну и 1xFE, 1xBA US + 1xBE, 1xBA, 1xPM RU;
В общем, без взаимодействия никак. Но и без постоянной коммуникации можно работать продуктивно, и в распределенных командах.
3. При необходимости, можно делать географически распиленные команды, но пока найм сотрудников и его политика этого не позволяет, да и безумно много передачи знаний требуется меж континентов =)
А, я с радостью погуглю и поизучаю, спасибо. Вы первый, кто дал такой коммент :)
это про UI?
Это всегда так. Именно поэтому мы обновляем прогноз каждую итерацию (раз в две недели, например). Мы можем построить прогноз на throughput + wip + Lead Time (в predictable.team есть epic forecasting в Monte Carlo, там можно тыкнуть на +1 эпик и наполнить его в соответствии с вашими задачами. Тогда разброс в прогнозе будет учитывать одновременное историческое количество элементов в работе + параллельную работу + Lead Time и 50 и 85 перцентилей). Тогда ваша историческая информация о времени завершения задач будет учитывать и хвосты.
Это если у вас тендеры и аутсорс, наверное? Взаимоотношения между компаниями, предоставляющими и потребляющими услуги всегда разные. Звучит как совсем другая (хоть и очень наболевшая) проблема :)
Но мы тут говорим что прогноз первоначальный всегда надо обновлять, просто есть стат данные в не-аутсорс компаниях что на основе этой метрики считать честнее и корректнее.
А так - всегда есть миллион факторов, которые влияют на прогнозы, потому и обновляем. Также как в метеорологии первоначальные прогнозы никогда не сбываются, и они дают их с уверенностью в 30%.
В АйТи параметров прогноза меньше, но без обновления все равно никуда.
спасибо, незаметил :)
Спасибо за интересную статью.
Титаническая и кропотливая работа) насколько активно те же топы или другой менеджмент пользуется самими дешами? Если активно, то это в рамках каких-то каденций или самостоятельно по необходимости?
Наверное, если экстраполировать, он не работает эффективно для абсолютного большинства.
Я согласен с тем, что инструмент не самый простой, и поэтому на масштабе при отсутствии людей которые поддержат процесс он работает плохо.
Все верно, именно поэтому стори поинты хороши когда вам надо выровняться.
Но для квартальных и далее планирований стори поинты часто неточны. В том пункте мы говорим про кросс-командную работу - чтобы запланироваться толпой команд вместе, и вовремя выйти в прод. Так как все используют SP по-разному, надежность прогнозов когда именно та или иная команда сделает свой кусок работы низкая.
Я к тому чтобы не прогнозировать через SP.
Опыт написания этого поста как раз вышел из работы в стартапе, и применим к стартапам - это я знаю точно =) Стартапе в Series B, с ~$780kk valuation, в финтех рынке ЛАТАМа.
Глубины не предполагалось, потому что это только про знакомство с подходом. Оно скорее про то, чтобы задуматься и, возможно, попробовать у себя почелленджить. Для меня этот калькулятор - самый базовый инструмент, чтобы просто сделать быструю диагностику дел в компании.
Так и есть, команда целиком и полностью смотрит 24/7 на алерты, графики, и чат с саппортом. Эта команда под ключ которая этим и занимается.
Спасибо Станислав, мы с вами прекрасно знаем как в стартапе прекрасно работается с отказоустойчивой архитектурой и какие ресурсы были выделены в этом конкретном примере. В условиях ограниченного бюджета и конкретных штатных единиц более подходящим и управляемым оперировать в рамках описанной выше таксономии. Безусловно, вы как более опытный специалист и с опытом внедрения ITIL-а, как более мачурного фреймворка имеете обширный опыт в работе с инцидентами. Было бы здорово поработать с вами в будущем.
Это подмножество обычны метрикик реагирования на сбои, но если у вас есть конкретная NOC-команда - то она может отвечать и работать в рамках этих конкретных метрик. То есть именно они те самые предметные владельцы Response, Acknowledge, Assemble. А не кто-то еще. Это скорее особенность и KPI при такой таксономии отделов.
Про приватность карточки — удобно звучит. Правда я бы сделал видимой карточку для всех по мере того как ребята добавляют их, но у всех все своё. Надо заценить.
У трелло самая большая загвоздка в том, что теперь тарифы не разрешают безлимитных досок для команд — и надо делать подписку в рамках atlassian suite.
Как я писал, нам актуально лочиться на экосистему Atlassian :)
и еще политика компании сейчас именно страйд =)
2. Есть проекты с архитектурной т.з. требующие обоих сторон океана. Но, тут надо понимать, что domain область, то есть складская логистика и продакты у нас в штатах, и за прояснением вещей в нутре проекта надо их тыркать постоянно.
Конфигурация команд сейчас
— 2xFullstack RU на пожаротушение всякое;
— 2xFE, 1xBA, 1xQA US + 3xBE, 1xQA, 1xPM RU на один гигантский проект;
— ну и 1xFE, 1xBA US + 1xBE, 1xBA, 1xPM RU;
В общем, без взаимодействия никак. Но и без постоянной коммуникации можно работать продуктивно, и в распределенных командах.
3. При необходимости, можно делать географически распиленные команды, но пока найм сотрудников и его политика этого не позволяет, да и безумно много передачи знаний требуется меж континентов =)