Comments 30
Гибкий эджайл — это не масло ли масляное?
Про «продумывает KPI, по которым можно было бы постоянно отслеживать приближение к цели» — можно ли поподробнее. А то я по наивности думал, что выполнение спринтов, юзер сторей и позволяет отслеживать выполнение.
Про сберджайл слышал, а у вас какой-то промсвязьбанкэджайл — с kpi и… еще чем-то там.
И еще: у вас правда все такие ответственные, самостоятельные, самоорганизующиеся?
Можете не отвечать, это был риторический вопрос
А откуда в банке такие крутые, сознательные, узкие и в то же время все умеющие специалисты, и уже готовые к любым изменениям проекты?
Похоже на очередную фантазию.
На мой взгляд все эти манифесты, новые подходы — лишь попытка добавить себе грамм конкурентоспособности, но по факту пыль.
Я не просто программист, я аджаил-программист. Я не просто ИТшник, у меня все по Итил.
Задачи же в JIRA, а не на словах (в аджаил ж главное не инструмент, а хотелки и общение) хорошо показывает как тратятся ресурсы и насколько адекватны те кто ставит задачи. Особенно если менеджер прибегает к программисту в десятый раз с правками. Хотел слона — ему сделали слона, но оказалось что слон то и не нужен, а нужна собака, Потом нужна собака которая мяукает, но это ладно, тут просто «вывод» перепишем, но потом как к собаке приделать голову жирафа? И тут приходит начальник и спрашивает, а где же десяток котят, которых ты должен был предоставить еще вчера? Разводишь руками — тычешь в заявку от менеджера с приоритетом и установленными сроками. Но уже поздно… ни собаки с головой жирафа, ни котят. А где был начальник который должен был правильно распределять ресурсы? Поэтому он втык и получит, если до такого дойдет.
В свою очередь с этим же аджайлом сидел бы он рядом и так же в пене вJOBывал непонятно над чем, и не знал бы кто чего сделать должен и когда.
Потом бы они вместе руководству доказывали что менеджер только с 10-го раза понял чего хочет, и то только когда коллективными силами догадались о его хотелках и ему всё разжевали. Ну а менеджер он же эффективный, это вы ни черта не можете понять с первого раза четко поставленную задачу. А на словах окажется что задачу он поставил еще пол года назад и да же половину кода за вас написал. Ну если не кода, то точно всю логику вплоть до мелочей.
kpi это вообще отдельная история — измерить силу мысли в попугаях, главное что бы вышло не меньше чем три обхода сторожа по территории за смену.
И самое интересное… возврат к доске с магнитиками оказалось эффективней тикет-систем?
Это как вернуться к паровым двигателям и говорить что КПД у них выше.
Если нет проблемы выяснения, сколько ресурсов тратится и куда, то и традиционный трекер задач не нужен. Трекеру задач остается только закрыть вопросы координации нескольких команд и взаимозависимости задач.
Аналогично про любой другой инструмент. Используем те инструменты, которые помогают достигать наши цели. Используем инструменты так, как это помогает достижению наших целей.
Юристов и безопасников мы включаем и вовлекаем в нашу работу. Если их игнорировать, то это ошибка указанная в статье.
Эффективен тот инструмент, которым хотят пользоваться, а не тот который навязан для контроля. Чем проще, тем лучше, доска это же всего лишь инструмент.
Наверное написали письмо в ЦБ что мол сроки не важны, и что регламенты не нужны?
Работа в командах сроки только сокращает, так как ликвидируются очереди и следовательно время ожидания при передаче между функциональными отделами. Поэтому если надо что то сделать срочно по приоретету от ЦБ, то просто берём и делаем. Так как всё равно в каскаде получится дольше разрабатывать.
Чем отличается отдел от команды? Как вы сократили очереди и время ожидания?
Если нужно сделать 10 задач/заявок/фич, а в одно время можно заниматься только 1, то как ты не рви пятую точку, как ты этот процесс не назови, общее время на разработку от этого не изменится.
Помню еще в школе говорили: от перемены мест слагаемых — сумма не меняется.
Чем приоритетные задачи в аджайл отличаются от не-аджайл?
Или вы имеете ввиду под каскадом выполнение задач строго по порядку поступления?
А вот еще.
Пришла вам приоритетная задача: Купить тигра.
А вы только начали клетку строить.
По аджайлу это как? Купить тигра, а потом клетку строить или построить клетку из табуреток и надеяться что не развалиться?
Так оно дороже выйдет, если тигр загрызет кого, пока вы клетку достраиваете.
Или все же надо сначала сварить нормальную клетку?
Как ни крути, а в таком аспекте аджайл выглядит как: «бежать впереди паровоза». Оно конечно можно, но не долго.
Что это означает? То что не все может успешно агилизироваться.
А что может быть успешно агилизировано?
Ну например, у вас есть пиццерия.
Тут вам пришла идея, что можно принимать заказы через телеграм, и повысить свои продажи.
Как это реализовать?
Можно детально продумать все технические нюансы, сразу заточиться на 24х7, highload, кучу фишек и плюшек, и потом разом создать все это. И через некоторое время запустить прием заказов через телеграм.
А можно вначале посадить девочку с телефоном и поручить девочке переносить заказы из телефона на доску заказов руками. Потом автоматизировать самую рутинную операцию. Потом, ту где больше всего возникает ошибок. И т.д. постепенно реализовывать тот функционал, в котором больше всего необходимость на момент реализации.
Какой способ лучше?
Успешен может быть любой.
Есть только один нюанс. Бизнес, часто, слабо прогнозируем. Что реально будет болеть, предсказать не всегда можно. Что реально взлетит, аналогично. Что делать в условиях неопределенности? Не планировать детально на далекую перспективу. Много пробовать. Часто оценивать полученные результаты. С учетом этого корректировать планы.
Это и есть agile.
Agile в общем случае это способ организации бизнеса. И этот способ не единственный.
Владелец продукта, как лицо отвечающее за продукт, в том числе за риски, связанные с работой продукта, принимает решение, а нужно ли реализовывать нововведение от VISA. А что эта фича даст для его продукта? Если ничего, то что будет если не реализовывать эту фичу? Допустим штраф. А каков размер этого штрафа? Допустим 5000 евро в год. А сколько усилий нужно на реализацию фичи? Допустим 20 человеко-недель, плюс потери от задержки фич, которые реально улучшили бы его продукт. И Владелец продукта принимает здравое решение нововведение от VISA забросить в беклог до следующего года.
Аналогично по другим пунктам.
Новые требования от ЦБ, риски — отзыв лицензии, срок — через 2 квартала, какой профит для продукта — никакого, возможное решение — реализовываем требования ровно так чтобы пройти соответствие новым требованиям. (пройти соответствие != соответствовать)
В обоих случаях — принятие решения никак не связано с тем agile у нас или waterfall.
Просто здравый подход, и правильные приоритеты.
Отличие agile в том, что во главу угла ставятся приоритеты продукта, и его развития. И вся команда буквально пропитывается идеей развития продукта. Никаких целей типа — строим классную ИТ-архитектуру, пишем супер код, и т.д. (это не отменяет того, что архитектура должная быть хорошей, код хорошим — тем не менее, все это инструменты, не цель)
продумывает KPI, по которым можно было бы постоянно отслеживать приближение к цели; в том числе не забываем про счастливого клиента;
KPI
Отвечу цитатой из своего канала (https://t.me/leonid_lapidus/60):
Железобетонное правило: если ваш руководитель ставит вам KPI, значит он мудак.
Замечательный «Фитиль» про нормы выпуска продукции: youtu.be/gNWyKf--jVE?t=143
Поделитесь этим постом с теми, у кого есть KPI.
Вы прочитали, то что я не писал. KPI ставится на продуктовую группу для достижения целей и стратегии бизнеса. Подумывает KPI сам владелец продукта. Я ничего не писал про неоптимальный индивидуальный KPI, навязанный сверху.
Если кто-то ставит KPI (человеку, команде, проекту, продукту), то он мудак.
— привлечь по продукту Х новых клиентов в размере Z.
— по продукту Х из числа существующих клиентов через год должны остаться активными не менее Y%.
У тех кто отвечает за KPI есть свой бюджет, свои ресурсы, что и как делать, решают сами.
Допустим, вы поставили маркетологам задачу: привлечь N клиентов. Они привлекут. Каждого за $1000. Клиенты зарегаются, что-то подулают в продукте. Но главный вопрос — а что дальше? Зачем нам нужны были эти клиенты.
Можно начать жонглировать понятиями — ну мы же помнимаем, что нам нужны клиенты, чтобы принести в компанию прибыль, давайте это вошьём в KPI: «привести N клиентов, за $1 за каждого, каждый принесёт по $20 в первые полгода использования продукта». И что дальше? Зачем нам эти клиенты? Какая у нас цель и ценность? Как исполнение этого KPI связано с целью компании? Никак.
Поэтому, тот кто полагается на KPI — поступает крайне неразумно.
И да, хороший KPI связан с общими целями конторы, вы правы.
И допустим в данной конторе, цель увеличить клиентскую базу и не сильно растерять существующую.
Согласен. Погоня за метриками и показателями как самоцелью полностью убивает этот инструмент. KPI может работать только, если это простой индикатор для достижения настоящих целей. Приведу пример аллегорию. KPI подобен термометру в комнате, который можно использовать для достижения комфортной температуры. Если целью станут показания термометра, то его можно локально нагреть, но самому при этом в комнате замёрзнуть. Получается что всё дело не в термометре, а в том что считаем целью.
И соответственно — какой «эджайл» ни внедряй — пока не заменить людей — результата (при аккуратном измерении) не будет. И обратно: если есть участки с осознным линейно-среднем менеджменте — там и без «коучей» — дело спорится и «ценность доставляется».
Вот был psb-батл — itшники пришли в одинаковых костюмах синего оттенка, белых рубашках, галстуках бордовых оттенков — вот он реальный показатель глубины «трансформации» ценностей.
Уже пол года экспериментируют с вендорными решениями в стремлении перейти к децентрализованным решениям. Пол года экспериментов в стол.
Зато наверно радар ценностей красивый
— если ваш оператор позвонил один раз с предложением и ему сказали, что данное предложение не интересует — не повторять звонки с увеличением размера кредита
— если приставы по ошибке блокируют счет, не посылать клиента в экспедицию, в которой на стене написано, что претензии она принимать не будет
Спасибо
Agile — это не процесс разработки, а подход к созданию продукта