Комментарии 17
Вся проблема в том, что бизнес обычно довольно агрессивный в корпоративном сегменте. И диктует порой идиотские решения и задачи, которые нужны прямо сейчас. Это такая плата за рост, зряплату и бонусы. Все работают ради бонусов. Особенно менеджмент. Которому начальство говорит, что нужно деливерить по 500 задач в год с отдела. А какие... сами придумайте. Имитация деливери и велью ради отчетности перед акционерами. 60% задач и 80% начальства можно былоб вообще не нанимать и не делать. Но важен оборот, отчетность и количество закрытых тасок.
Согласен, есть и такие компании. Я надеюсь, что у нас все-таки не так, а те изменения, которые происходят в нашей компании, принесут пользу. Последние из них - ориентация и ответственность продуктовых команд за бизнес-показатели, теперь они напрямую влияют на бизнес и могут оценить свой вклад.
Вся проблема в том, что бизнес обычно довольно агрессивный в корпоративном сегменте.
А может он потому и дорос до корпоративного размера и остается в нём, что был "агрессивным" и не позволял себя водить за нос новомодными типа методологиями? )
Расскажете как проводить анализ для построения Эффект-Диаграммы? Откуда берутся формулировки этих эффектов? Это обобщенные "жалобы"? Как их выясняют? Через личное интервью с участниками цепочки? Через рассмотрение записей из ретроспектив команд? Или каким-то другим способом?
Потому что инструмент как мне кажется очень мощный, если им правильно пользоваться. Вплоть до предсказания фатального исхода на этапе планирования, если в процессе присутствуют индикаторы негативных цепочек эффектов. Ну и конечно выработка альтернативных методик с меньшим количеством недостатков.
Узнал о инструменте после прочтения книги Элияху Голдратт. Цель-2. Дело не в везении.
Для построения Дерева текущей реальности я использовал материалы статьи: https://vc.ru/hr/81710-instrukciya-kak-stroit-derevo-tekushchey-realnosti-dlya-resheniya-biznes-problem
У меня, как у agile coach, есть доступ ко многим командам и ретроспективам, мы проводили исследования и интервью. Когда в компании работаешь 4 года, знания накапливаются в голове, остается их только оформить с помощью какого-либо инструмента.
Что может помочь собрать нежелательные явления:
Ретроспективы. От чего сильно бомбит команду или проблемы, которые не решаются на постоянной основе;
1t1 с сотрудниками из компании. Доверительные отношения в командах дает больше информации о проблемах;
Инетрвью/исследования. С другими Agile коучами проводили исследования на уровне всей компании мидл менеджмента.
Я советую прочитать Цель-2, тогда можно быстро погрузиться и узнать из бизнес-романа о данном и других инструментах.
P.S. Книги Голдратта одни из самых любимых и многие из них читаются на одном дыхании.
На показанной диаграмме, самый интересный момент — первый квадратик: "В работу поступают проекты с фиксированным сроком". Можно было бы ожидать, что к моменту получения заказа, имеется набор вариантов реализации с указанием важнейших свойств и спроков выполнения. У заказчика будет возможность самому выбрать один из возможных вариантов. А у разработчиков для каждого варианта будет готовый план реализации проекта.
К сожалению, задачи с фиксированным сроком обычно появляются как снег на голову.
Команду разработки подключают уже в самы последний момент, когда все решения уже приняты и требования собраны, и проект уже утвержден. Команду ставят перед фактом, что есть срочная задачаа, которую нужно решить к такому-то числу.
Решение: подключать команду на этапе discovery для проработки проектов. Мы только начинаем это делать.
Ваш бизнес уже выкинул белый флаг перед Продуктовым подходом и более не контролирует ситуацию. Дальше только позиционная борьба за минимизацию ущерба.
@DikSoft А какой подход лучше использовать? И в чем его преимущества?
По поводу внутренней разработки я солидарен с позицией описанной в этой статье. Если ИТ не Ваш основной бизнес, то "Продукт" и все пляски вокруг скорее всего будут худшим выбором. Оптимальнее, как мне кажется, брать конкретные задачи и закрывать их Проектным подходом.
Статья хорошая, только не затрагивает коренную проблему описанных здесь кейсов: мне видится, что проблема не в отсутствии эффективного продуктового планирования (как бы не резала слух сама фраза), а в отсутствии единой ценностной модели принятия управленческих решений. Наверху: мне нужны деньги завтра. Где-то на середине: чтобы деньги были завтра пусть все работают на деньги. Внизу PO: команда наляпает много фичей, какая-то выстрелит и возможно принесет деньги. Отсюда: чем больше гипотез - тем хуже детализация; гипотеза выстрелит когда-то (в следующем квартале скорее нет - эффект накопительный), нет очевидной связи со сроком начала оценки (отсюда нет привязки к кварталам); главное больше гипотез - поэтому члены команд лишь ресурс, если людей считать лишь за ресурс - формализм в работе и необходимость dead line со стороны РО или иных стейкхолдеров.
Как должно быть - можно погуглить, kanban maturity model может натолкнуть на интересные мысли. Но agile прородители сказали лаконичнее: люди важнее процессов. Иначе "продуктовая революция" через силу и для галочки будет выглядеть как-то так:
"...команда наляпает много фичей..." Не факт, что при этом фич будет "наляпано" много:
Если задача поставлена абы как, то сроки неизбежно будут уезжать вправо в результате многократных переделок.
если "ляпать" фичи на то, что "наляпано" ранее, то можно подойти к неизбежному финалу, когда новое наляпаное начнёт отваливаться с кусками старого наляпаного.
ну мы как-бы обсуждаем некую абстрактную ситуацию, поэтому может получиться как угодно. Но обычно, заказчики избалованы сроками спринта и неизбежностью подарочков в конце - до существенного сдвига сроков не доходит. Ключевые лица, которые влюблены в хайповую "быструю доставку всевозможных фич", не хотят мириться с отговорками типа "тех. долг", "много уточнений", "вы слишком много фич хотите" и пр. И любой, кто этим начнет уговаривать их примириться с неполучением ожидаемого, окажется виноватым: либо меняться исполнители будут по разным причинам, либо для тех. долга запилится масштабная инфраструктурная переделка. А чаще наблюдал что происходит это одновременно, ибо выгодно всем. Старо как мир, причина всё та же - некорректные ценностные ориентиры:
Приходит как-то менеджер на работу устраиваться, ему передают дела. Уходящий коллега, говорит: "Вот тебе три пронумерованных конверта, вскрывай когда тяжко будет, только в строгой последовательности". Случился первый кризис на работе. Вскрывает, там написано: "Вини предшественника". Свалил всё на того, кто ушел. Случился второй "разбор полётов", полез менеджер за вторым конвертом, там написано: "Вини подчиненных". Свалил на коллег уровнем ниже - пронесло. Недолго ждал третьей ситуации, рванул за третьим конвертом, там последний совет: "Купи и пронумеруй три конверта..."
Как тебе известно, для управления решениями у нас внедряется метод OKR.
Я надеюсь, он как раз свяжет все уровни управления и сделает модель поставноки задач прозрачной.
Как продуктовые планы могут внести хаос в IT команду