Pull to refresh

Comments 30

А вы вычитку перед публикацией делали?

Гибкий эджайл — это не масло ли масляное?

Про «продумывает KPI, по которым можно было бы постоянно отслеживать приближение к цели» — можно ли поподробнее. А то я по наивности думал, что выполнение спринтов, юзер сторей и позволяет отслеживать выполнение.
Про сберджайл слышал, а у вас какой-то промсвязьбанкэджайл — с kpi и… еще чем-то там.

И еще: у вас правда все такие ответственные, самостоятельные, самоорганизующиеся?
Можете не отвечать, это был риторический вопрос

KPI на продуктовую группу — это оптимально для достижения целей и стратегии организации. KPI в этом смысле очень помогает PO.

Приведите примеры, пожалуйста, таких kpi
Самый хороший KPI — это квартальные и годовые отчетности о прибыли. По ним хорошо смотреть как работает PO, так же как и смотреть за тем как работают разработчики.

А откуда в банке такие крутые, сознательные, узкие и в то же время все умеющие специалисты, и уже готовые к любым изменениям проекты?


Похоже на очередную фантазию.

Скорей откуда в банке столько денег, что бы без согласования юристов, безопасников и руководства внедрять разного рода решения, собранных на скорую руку, без утвержденного ТЗ, а со слов какого-то менеджера Васи, который завтра перейдет к конкурентам?

На мой взгляд все эти манифесты, новые подходы — лишь попытка добавить себе грамм конкурентоспособности, но по факту пыль.
Я не просто программист, я аджаил-программист. Я не просто ИТшник, у меня все по Итил.

Задачи же в JIRA, а не на словах (в аджаил ж главное не инструмент, а хотелки и общение) хорошо показывает как тратятся ресурсы и насколько адекватны те кто ставит задачи. Особенно если менеджер прибегает к программисту в десятый раз с правками. Хотел слона — ему сделали слона, но оказалось что слон то и не нужен, а нужна собака, Потом нужна собака которая мяукает, но это ладно, тут просто «вывод» перепишем, но потом как к собаке приделать голову жирафа? И тут приходит начальник и спрашивает, а где же десяток котят, которых ты должен был предоставить еще вчера? Разводишь руками — тычешь в заявку от менеджера с приоритетом и установленными сроками. Но уже поздно… ни собаки с головой жирафа, ни котят. А где был начальник который должен был правильно распределять ресурсы? Поэтому он втык и получит, если до такого дойдет.

В свою очередь с этим же аджайлом сидел бы он рядом и так же в пене вJOBывал непонятно над чем, и не знал бы кто чего сделать должен и когда.
Потом бы они вместе руководству доказывали что менеджер только с 10-го раза понял чего хочет, и то только когда коллективными силами догадались о его хотелках и ему всё разжевали. Ну а менеджер он же эффективный, это вы ни черта не можете понять с первого раза четко поставленную задачу. А на словах окажется что задачу он поставил еще пол года назад и да же половину кода за вас написал. Ну если не кода, то точно всю логику вплоть до мелочей.

kpi это вообще отдельная история — измерить силу мысли в попугаях, главное что бы вышло не меньше чем три обхода сторожа по территории за смену.

И самое интересное… возврат к доске с магнитиками оказалось эффективней тикет-систем?
Это как вернуться к паровым двигателям и говорить что КПД у них выше.
Трекер задач — это просто инструмент, не самоцель.
Если нет проблемы выяснения, сколько ресурсов тратится и куда, то и традиционный трекер задач не нужен. Трекеру задач остается только закрыть вопросы координации нескольких команд и взаимозависимости задач.
Аналогично про любой другой инструмент. Используем те инструменты, которые помогают достигать наши цели. Используем инструменты так, как это помогает достижению наших целей.

Юристов и безопасников мы включаем и вовлекаем в нашу работу. Если их игнорировать, то это ошибка указанная в статье.


Эффективен тот инструмент, которым хотят пользоваться, а не тот который навязан для контроля. Чем проще, тем лучше, доска это же всего лишь инструмент.

Лучше расскажите нам как Вы «гибкой методологией» а не водопадом внедряли для примера новые бизнес фичи от VISA, а еще лучше требования или отчеты ЦБ РФ? Как вам удалось внедрить ЕСИА и ЕБС?
Наверное написали письмо в ЦБ что мол сроки не важны, и что регламенты не нужны?

Работа в командах сроки только сокращает, так как ликвидируются очереди и следовательно время ожидания при передаче между функциональными отделами. Поэтому если надо что то сделать срочно по приоретету от ЦБ, то просто берём и делаем. Так как всё равно в каскаде получится дольше разрабатывать.

Тут еще одна загадка.
Чем отличается отдел от команды? Как вы сократили очереди и время ожидания?
Если нужно сделать 10 задач/заявок/фич, а в одно время можно заниматься только 1, то как ты не рви пятую точку, как ты этот процесс не назови, общее время на разработку от этого не изменится.
Помню еще в школе говорили: от перемены мест слагаемых — сумма не меняется.

Чем приоритетные задачи в аджайл отличаются от не-аджайл?
Или вы имеете ввиду под каскадом выполнение задач строго по порядку поступления?

А вот еще.
Пришла вам приоритетная задача: Купить тигра.
А вы только начали клетку строить.
По аджайлу это как? Купить тигра, а потом клетку строить или построить клетку из табуреток и надеяться что не развалиться?
Так оно дороже выйдет, если тигр загрызет кого, пока вы клетку достраиваете.

Или все же надо сначала сварить нормальную клетку?
Как ни крути, а в таком аспекте аджайл выглядит как: «бежать впереди паровоза». Оно конечно можно, но не долго.
Да, тигр и клетка плохо агилизируются ;)
Что это означает? То что не все может успешно агилизироваться.
А что может быть успешно агилизировано?
Ну например, у вас есть пиццерия.
Тут вам пришла идея, что можно принимать заказы через телеграм, и повысить свои продажи.
Как это реализовать?
Можно детально продумать все технические нюансы, сразу заточиться на 24х7, highload, кучу фишек и плюшек, и потом разом создать все это. И через некоторое время запустить прием заказов через телеграм.
А можно вначале посадить девочку с телефоном и поручить девочке переносить заказы из телефона на доску заказов руками. Потом автоматизировать самую рутинную операцию. Потом, ту где больше всего возникает ошибок. И т.д. постепенно реализовывать тот функционал, в котором больше всего необходимость на момент реализации.
Какой способ лучше?
Успешен может быть любой.

Есть только один нюанс. Бизнес, часто, слабо прогнозируем. Что реально будет болеть, предсказать не всегда можно. Что реально взлетит, аналогично. Что делать в условиях неопределенности? Не планировать детально на далекую перспективу. Много пробовать. Часто оценивать полученные результаты. С учетом этого корректировать планы.
Это и есть agile.
Agile не отвечает на вопросы реализовывать ли очередные требования VISA или регуляторов, и как реализовывать. Также как не отвечает на вопросы: нужны ли тесты, и как их внедрять, нужны ли контейнеры, и как их внедрять, нужны ли поездки на конференции и какие конференции, нужен ли root в production девелоперам и для чего, и прочее, прочее, прочее.

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 (человеку, команде, проекту, продукту), то он мудак.
Хорошо, чем плох KPI?
— привлечь по продукту Х новых клиентов в размере Z.
— по продукту Х из числа существующих клиентов через год должны остаться активными не менее Y%.
У тех кто отвечает за KPI есть свой бюджет, свои ресурсы, что и как делать, решают сами.
Дело в том, что привлечь Z клиентов в продукт — не проблема. Более того, это даже не цель компании. KPI по определению (см. например, определение в википедии) не учитывает ценность и цель компании.

Допустим, вы поставили маркетологам задачу: привлечь N клиентов. Они привлекут. Каждого за $1000. Клиенты зарегаются, что-то подулают в продукте. Но главный вопрос — а что дальше? Зачем нам нужны были эти клиенты.

Можно начать жонглировать понятиями — ну мы же помнимаем, что нам нужны клиенты, чтобы принести в компанию прибыль, давайте это вошьём в KPI: «привести N клиентов, за $1 за каждого, каждый принесёт по $20 в первые полгода использования продукта». И что дальше? Зачем нам эти клиенты? Какая у нас цель и ценность? Как исполнение этого KPI связано с целью компании? Никак.

Поэтому, тот кто полагается на KPI — поступает крайне неразумно.
Есть бюджет. Нет печатного станка для банкнот. Привлекать по 1000$ долго не получится. И цель не у маркетологов, а у всех кто причастен к продукту Х.

И да, хороший KPI связан с общими целями конторы, вы правы.
И допустим в данной конторе, цель увеличить клиентскую базу и не сильно растерять существующую.
Не могу согласиться, что цель может быть такой: «увеличить клиентскую базу и не сильно растерять существующую». Это скорее возможное решение некой задачи.
Почему?

Продукт создан, бизнес-модель протестирована. Начинаем масштабироваться.
ну раз уж начали ))
Зачем масштабироваться?
Причин может быть много.
Пусть будет — хотим больше заработать в среднесрочной перспективе.
Человек цитирующий сам себя тоже не светоч virtue. Что впрочем не отменяет того факта, что много лет назад подход к мотивации через KPI действительно был признан провалом в управлении. Что в свою очередь не отменяет того факта, что burndown — это самый настоящий KPI.

Согласен. Погоня за метриками и показателями как самоцелью полностью убивает этот инструмент. KPI может работать только, если это простой индикатор для достижения настоящих целей. Приведу пример аллегорию. KPI подобен термометру в комнате, который можно использовать для достижения комфортной температуры. Если целью станут показания термометра, то его можно локально нагреть, но самому при этом в комнате замёрзнуть. Получается что всё дело не в термометре, а в том что считаем целью.

А слона-то мы и не заметили. Planning poker и управление burndown — основные инструменты scrum, коий является единственной применимой в IT реализацией agile (ибо lsd, toc и прочий xp нигде и никем не используются ввиду своей излишней инновационности и/или ортодоксальности). Если ваши команды не используют ни то, ни другое, то я не очень понимаю, о каком реальном применении методологии вы рассказываете. Вы хоть scrum-колоду видели вживую?
burndown — очень плохой kpi.
хороший kpi — то что показывает насколько мы близки к нашей цели.
burndown — это тактика, типа а сколько мы пробежали. kpi — а в правильном ли направлении бежим.
Глубинные причины проблем, которые традиционно пытаются решать насаждением «эджайл» вовсе не в «богомерзком водопаде». (В конце концов и в rup никто не запрещает двигаться более короткими итерациями и корректировать план.) А причины, как правило, в «незрелости» людей в управлении (либо, что в управлении «времянщики»: любой ценой получить рост показателя, получить бонус и свалить -дальше хоть потоп).
И соответственно — какой «эджайл» ни внедряй — пока не заменить людей — результата (при аккуратном измерении) не будет. И обратно: если есть участки с осознным линейно-среднем менеджменте — там и без «коучей» — дело спорится и «ценность доставляется».

Вот был psb-батл — itшники пришли в одинаковых костюмах синего оттенка, белых рубашках, галстуках бордовых оттенков — вот он реальный показатель глубины «трансформации» ценностей.
Уже пол года экспериментируют с вендорными решениями в стремлении перейти к децентрализованным решениям. Пол года экспериментов в стол.
Зато наверно радар ценностей красивый

RUP хорош, но это методология, которая всегда приходит сверху и поэтому её внедрение встречает сопротивление. Это одна из причин, почему RUP часто работает далеко от задуманного в реальной организации.
В Agile скорее говорят про правила и практики, которые рождаются в команде разработчиками.

Поскольку вы ориентированы на удовольствие клиента, то если не сложно — реализуйте 2 вещи:
— если ваш оператор позвонил один раз с предложением и ему сказали, что данное предложение не интересует — не повторять звонки с увеличением размера кредита
— если приставы по ошибке блокируют счет, не посылать клиента в экспедицию, в которой на стене написано, что претензии она принимать не будет
Спасибо
Sign up to leave a comment.