Странный выход может случиться и по человеческому фактору. Там тоже не нулевая вероятность ошибки. Тебе как стажера настраивать на просмотр и его перепроверять, так и результат жпт. Но найти скурпулезного человека и отменеджерить его работу видится сложнее чем выстроить промпт
ну судя по этой логике, и ретроспектива не должна работать.. какой смысл разбирать ошибки, если всё равно будут ошибки. Лучше сразу брать тех, кто думает как глава команды и не ошибается. Но жизнь другая. Мне Устав позволял быстрее онбордить новичков уровня ниже среднего, по понятным правилам разрешать споры - просто времени меньше уходит на разбор ситуаций
а вообще принципы решений лежат в основе любого framework менеджмента. Именно такие принципы и описаны в статье. Адаптировать их, чтобы пафосом не пахло, или низводить Устав до инструкции - решать менеджеру, который это ещё команде продать должен
Вы совершенно правы - работу делать руками и головой. Но, чтобы её сделать, надо договориться. У каждого своя мотивация договариваться: чтобы впредь не тратить времени на выяснения "кто для чего работает", "какая норма качества", "как наказывать за несоблюдение коллективных норм взаимодействия" вводится Устав. Если команда небольшая, текучки нет, новых членов менее 20% за пол года, можно и не заморачиваться
Можно попросить выгрузить из корпоративной ВКС таблицу с инициатором и участниками созвона, поставить среднюю з/п. каждому и попросить инициатора самых больших трат обосновать необходимость встреч за последнюю неделю. И повторять такое каждую неделю. Или прям встроить в ВКС показать стоимости: "вы уже наговорили на ... рублей".
Метод измерения того, как премировать - это немного не то, о чем я писал. Не специалист в трех буквах от HR исходящих, безусловно вера и надежда комфорта добавляет для выживания. Но в тему вспомнилась индейская шутка: с одной стороны у лошади две ноги, с другой - тоже две...
сложно не согласиться, если говорить в отрыве от контекста применения слова roadmap. А как правильно переводить, если используется словосочетание agile roadmap?
ну мы как-бы обсуждаем некую абстрактную ситуацию, поэтому может получиться как угодно. Но обычно, заказчики избалованы сроками спринта и неизбежностью подарочков в конце - до существенного сдвига сроков не доходит. Ключевые лица, которые влюблены в хайповую "быструю доставку всевозможных фич", не хотят мириться с отговорками типа "тех. долг", "много уточнений", "вы слишком много фич хотите" и пр. И любой, кто этим начнет уговаривать их примириться с неполучением ожидаемого, окажется виноватым: либо меняться исполнители будут по разным причинам, либо для тех. долга запилится масштабная инфраструктурная переделка. А чаще наблюдал что происходит это одновременно, ибо выгодно всем. Старо как мир, причина всё та же - некорректные ценностные ориентиры:
Приходит как-то менеджер на работу устраиваться, ему передают дела. Уходящий коллега, говорит: "Вот тебе три пронумерованных конверта, вскрывай когда тяжко будет, только в строгой последовательности". Случился первый кризис на работе. Вскрывает, там написано: "Вини предшественника". Свалил всё на того, кто ушел. Случился второй "разбор полётов", полез менеджер за вторым конвертом, там написано: "Вини подчиненных". Свалил на коллег уровнем ниже - пронесло. Недолго ждал третьей ситуации, рванул за третьим конвертом, там последний совет: "Купи и пронумеруй три конверта..."
Статья хорошая, только не затрагивает коренную проблему описанных здесь кейсов: мне видится, что проблема не в отсутствии эффективного продуктового планирования (как бы не резала слух сама фраза), а в отсутствии единой ценностной модели принятия управленческих решений. Наверху: мне нужны деньги завтра. Где-то на середине: чтобы деньги были завтра пусть все работают на деньги. Внизу PO: команда наляпает много фичей, какая-то выстрелит и возможно принесет деньги. Отсюда: чем больше гипотез - тем хуже детализация; гипотеза выстрелит когда-то (в следующем квартале скорее нет - эффект накопительный), нет очевидной связи со сроком начала оценки (отсюда нет привязки к кварталам); главное больше гипотез - поэтому члены команд лишь ресурс, если людей считать лишь за ресурс - формализм в работе и необходимость dead line со стороны РО или иных стейкхолдеров.
Как должно быть - можно погуглить, kanban maturity model может натолкнуть на интересные мысли. Но agile прородители сказали лаконичнее: люди важнее процессов. Иначе "продуктовая революция" через силу и для галочки будет выглядеть как-то так:
Не каждая функция добавляет ценность: бывает, что функция намеренно убавляет ценность (эксперимент ухудшения); бывает, что мы так считаем - но отток клиентов за границами эксперимента может доказать обратное, но чаще встречается, что ценность функции не измеряется. Или лучше бы не измерялось (ошибки измерения). От того утверждение неверно.
Про снежинки, которые бесполезно сравнивать.. сразу вспомнилась книга фотографий снежинок, которые получились после заморозки воды особого воздействия. Книга в своё время стоила достаточно дорого, но позволяла над ней в магазине зависнуть бесплатно. В «сравнении снежинок» можно определить разницу между паттернами воздействия. Некоторые в «сравнении снежинок» находят удовольствие, бывает, что и владельцы бизнеса и топ менеджмент. Сложно отказать таким в удовольствии. А некоторые в консультировании о «корректном взгляде на снежинки» могут находить заработок - чаще agile обучение это способ развлечения, а не привитие навыка пользования инструментарием.
Странный выход может случиться и по человеческому фактору. Там тоже не нулевая вероятность ошибки. Тебе как стажера настраивать на просмотр и его перепроверять, так и результат жпт. Но найти скурпулезного человека и отменеджерить его работу видится сложнее чем выстроить промпт
дополнил статью, см. конец
дополнил статью, см. конец
чем они помогут, если они заточены под отрасль и проверочные данные? отрасль та же?
ну судя по этой логике, и ретроспектива не должна работать.. какой смысл разбирать ошибки, если всё равно будут ошибки. Лучше сразу брать тех, кто думает как глава команды и не ошибается. Но жизнь другая. Мне Устав позволял быстрее онбордить новичков уровня ниже среднего, по понятным правилам разрешать споры - просто времени меньше уходит на разбор ситуаций
а вообще принципы решений лежат в основе любого framework менеджмента. Именно такие принципы и описаны в статье. Адаптировать их, чтобы пафосом не пахло, или низводить Устав до инструкции - решать менеджеру, который это ещё команде продать должен
Вы совершенно правы - работу делать руками и головой. Но, чтобы её сделать, надо договориться. У каждого своя мотивация договариваться: чтобы впредь не тратить времени на выяснения "кто для чего работает", "какая норма качества", "как наказывать за несоблюдение коллективных норм взаимодействия" вводится Устав. Если команда небольшая, текучки нет, новых членов менее 20% за пол года, можно и не заморачиваться
Можно попросить выгрузить из корпоративной ВКС таблицу с инициатором и участниками созвона, поставить среднюю з/п. каждому и попросить инициатора самых больших трат обосновать необходимость встреч за последнюю неделю. И повторять такое каждую неделю. Или прям встроить в ВКС показать стоимости: "вы уже наговорили на ... рублей".
Это инновация - как не показать косяки после «улучшения» сервиса записи в бд и не испортить клиентский опыт. Не сказать - не значит соврать)
В Тинькове до сих пор история транзакций только через выписку может быть проявлена.
Это жжжж не спроста, как говорил Винни пух.
Метод измерения того, как премировать - это немного не то, о чем я писал. Не специалист в трех буквах от HR исходящих, безусловно вера и надежда комфорта добавляет для выживания. Но в тему вспомнилась индейская шутка: с одной стороны у лошади две ноги, с другой - тоже две...
согласен, но как быть с русскоязычным интернетом, у которого это уже давно "дорожная карта"? есть ли смысл поправлять?
сложно не согласиться, если говорить в отрыве от контекста применения слова roadmap. А как правильно переводить, если используется словосочетание agile roadmap?
ну мы как-бы обсуждаем некую абстрактную ситуацию, поэтому может получиться как угодно. Но обычно, заказчики избалованы сроками спринта и неизбежностью подарочков в конце - до существенного сдвига сроков не доходит. Ключевые лица, которые влюблены в хайповую "быструю доставку всевозможных фич", не хотят мириться с отговорками типа "тех. долг", "много уточнений", "вы слишком много фич хотите" и пр. И любой, кто этим начнет уговаривать их примириться с неполучением ожидаемого, окажется виноватым: либо меняться исполнители будут по разным причинам, либо для тех. долга запилится масштабная инфраструктурная переделка. А чаще наблюдал что происходит это одновременно, ибо выгодно всем. Старо как мир, причина всё та же - некорректные ценностные ориентиры:
Приходит как-то менеджер на работу устраиваться, ему передают дела. Уходящий коллега, говорит: "Вот тебе три пронумерованных конверта, вскрывай когда тяжко будет, только в строгой последовательности". Случился первый кризис на работе. Вскрывает, там написано: "Вини предшественника". Свалил всё на того, кто ушел. Случился второй "разбор полётов", полез менеджер за вторым конвертом, там написано: "Вини подчиненных". Свалил на коллег уровнем ниже - пронесло. Недолго ждал третьей ситуации, рванул за третьим конвертом, там последний совет: "Купи и пронумеруй три конверта..."
Статья хорошая, только не затрагивает коренную проблему описанных здесь кейсов: мне видится, что проблема не в отсутствии эффективного продуктового планирования (как бы не резала слух сама фраза), а в отсутствии единой ценностной модели принятия управленческих решений. Наверху: мне нужны деньги завтра. Где-то на середине: чтобы деньги были завтра пусть все работают на деньги. Внизу PO: команда наляпает много фичей, какая-то выстрелит и возможно принесет деньги. Отсюда: чем больше гипотез - тем хуже детализация; гипотеза выстрелит когда-то (в следующем квартале скорее нет - эффект накопительный), нет очевидной связи со сроком начала оценки (отсюда нет привязки к кварталам); главное больше гипотез - поэтому члены команд лишь ресурс, если людей считать лишь за ресурс - формализм в работе и необходимость dead line со стороны РО или иных стейкхолдеров.
Как должно быть - можно погуглить, kanban maturity model может натолкнуть на интересные мысли. Но agile прородители сказали лаконичнее: люди важнее процессов. Иначе "продуктовая революция" через силу и для галочки будет выглядеть как-то так:
Не каждая функция добавляет ценность: бывает, что функция намеренно убавляет ценность (эксперимент ухудшения); бывает, что мы так считаем - но отток клиентов за границами эксперимента может доказать обратное, но чаще встречается, что ценность функции не измеряется. Или лучше бы не измерялось (ошибки измерения). От того утверждение неверно.
Про снежинки, которые бесполезно сравнивать.. сразу вспомнилась книга фотографий снежинок, которые получились после заморозки воды особого воздействия. Книга в своё время стоила достаточно дорого, но позволяла над ней в магазине зависнуть бесплатно. В «сравнении снежинок» можно определить разницу между паттернами воздействия. Некоторые в «сравнении снежинок» находят удовольствие, бывает, что и владельцы бизнеса и топ менеджмент. Сложно отказать таким в удовольствии. А некоторые в консультировании о «корректном взгляде на снежинки» могут находить заработок - чаще agile обучение это способ развлечения, а не привитие навыка пользования инструментарием.
https://ru.m.wikipedia.org/wiki/Эмото,_Масару
В целом согласен с основной мыслью статьи, что метрики производительности без метрик бизнеса губительны.