Как Product Owner повлиять на перформанс
Привет, такой вопрос: как может Product Owner или продукт менеджер повлиять на скорость и качество разработки? У нас до последнего времени лютовал скрам мастер, который не давал продакт оунеру вмешиваться во что либо, кроме формулировки бизнес-требований к продукту и их приоризации. То есть как ПО ты описываешь требования, сортируешь их в бэклоге и ждёшь, когда разработчики их внедрят. А внедряют их очень медленно - постоянно нужно что-то чинить и расширять в технике, а если таск взят в рвботу, то его могут мурыжить несколько недель, пока он без ошибок начнёт работать.
Теперь вроде стратегия изменилась, и ПО имеет право вмешиваться в организацию технических тасков. И вот мне интересно, насколько реально улучшить перформанс? Не меняя работников и не принуждая их самообразовываться в свободное время? Ведь многие считают, что перформанс данной команды - величина практически постоянная, которую без глобальных переворотов не изменить.
Или рецепты все же есть? Без смены персонала, исключительно изысканием внутренних ресурсов?
Мощным рыком шефа, что
Timelines sind projektrelevant
В этом собственно и суть: клиент платит за сдачу в определенные сроки? Тогда вынь и положь. У нас проектмэнеджер за сроки ответственный, он и формулирует/согласовывает таимлайнсы - которые неотъемлимая часть задачi (торгуюсь иногда как на восточном базаре :)))) )
Быстро, качественно, дешёво. Решай чем поступиться.
Не меняя работников и не принуждая их самообразовываться в свободное время?
Значит только качеством.
Шефу запрещено рычать на команду разработчиков. По правилам скрама только команда решает, сколько времени потребует разработка какой темы. Продакт оунер должен тогда подстроить объем задачи под этот прогноз временных затрат. Например где-то урезать требования, чтобы уложиться в сроки.
В итоге если не уложились в требования клиента по скорости выполнения и по объёму функций - значит либо он перенесёт оплату на более поздний срок, либо откажется от продукта. Давить этим на разработчиков нельзя.
А как проект менеджер может устанавливать таймлансы, не зная, сколько времени и ресурсов потребуется на реализацию требований? Обычно проект менеджеры или продавцы идут консультироваться с производством (в цеху завода или в ИТ-разработке) , каков будет расход времени, людей и материалов.
На качество я повлиять не могу. Не имею права принять фичу, если она не прошла тесты. А качеством в смысле объёма функций или например комфорта пользователя я и так жертвую постоянно. Хотя вообще-то у нас девиз "довести одну фичу до идеала, прежде чем переходить к другой". Но если не переходить, то элементарных частей не создадим типа колёс, мотора и салона для автомобиля. Всё же минимальный набор требований объективно существует.
А если увеличить влияние? У нас вроде осознали, что без влияния нет ответственности. Но если я начну наезжать, чтобы оценивали затраты на реализацию пониже, то кроме психологического эффекта якоря это мало что даст?
Может ещё какие-нибудь системы раннего распознавания проблемы ввести? Чтобы реагировать мерами типа поддержки вторым разработчиком. Или Pair-Programming ввести? Тренинги в рабочее время?
Обычно проект менеджеры или продавцы идут консультироваться с производством (в цеху завода или в ИТ-разработке) , каков будет расход времени, людей и материалов.
Мы работаем тесно с разработчиками в одном из видов проектов: индустриальных. Т. е. Они разрабатывают, а мы внедряем в производство. Сложность всегда в том, что разработчики работают агиль, а мы по стандарту каскадно. Поэтому в самом начале проекта все совместно согласовывается и для разработчиков ставятся довольно жёсткие рамки по времени, в которые они должны уложиться.
Для мотивации отслеживания статуса в проекте проводятся регулярные совещания с менеджментом, где каждая сторона отчитывается о статусе.
Отслеживание статуса не проблема. Сложность в том, что мы не можем поставить разработчикам временные рамки. Сколько продлится - столько и продлится. А если были сделаны ошибки, то это просто будет стоить дополнительных затрат времени. Никакие исправления ошибок во внерабочее время невозможны. Вот хотя бы это я изменила (хотя может это неэтично, человек имеет право на ошибку). А то, что в итоге разработка продлится столько, сколько этого требуют объем работы и выбранные методы - этот факт наверно не изменишь постановкой жёстких сроков. Беременность вот тоже длится 9 месяцев. Вот выбор оптимальных методов может повлиять на сроки. Но это дело архитектора, а он точно также имеет право на ошибку. Ошибки в архитектуре тоже никем не компенсируются, а просто ведут к ещё более долгим срокам достижения цели.
Ах да, и продуктменеджер часто не начальник над разработчиками, то есть он не может на годовом разговоре с работником поставить ему на вид ошибки или снизить за них годовую оценку.
Беременность вот тоже длится 9 месяцев.
Единственное что у нас от "очень сложно до нельзя" изменить-сроки испытаний, остальное как раз таки решается в проектах по принципу:" 3 женщины родят ребёнка за три месяца" . Не знаю как у вас, у нас если угроза срыва срока у клиентов - это очень серьёзная проблема, поэтому я не зря выше написала, что для "мотивации" проводятся совещания, где всегда обсуждаются риски и если нужно, своевременно запрашиваются дополнительные ресурсы и до работающих в проекте сторон на доступном языке доносятся приоритеты.
Дополнительные ресурсы влекут за собой потери времени на коммуникацию. И часто есть бутылочные горлышки в виде ключевых членов команды. Обход которых опять же влечёт за собой потерю качества. Alles schon gesehen. Короче, техлида надо менять ☺️
Может ещё какие-нибудь системы раннего распознавания проблемы ввести? Чтобы реагировать мерами типа поддержки вторым разработчиком. Или Pair-Programming ввести? Тренинги в рабочее время?
У вас какой процесс-то? Разработчик сидит один в уголке и ковыряет проблему 9 месяцев, причём никто не знает что там творится?
Ну да, только в первом сообщении вы это не указали как возможность 😀 если возможно выделить доп. ресурсы - надо выделять
Так у нас этой возможности нет. Человек написал, как у них - я откомментировала.
У вас какой процесс-то? Разработчик сидит один в уголке и ковыряет проблему 9 месяцев, причём никто не знает что там творится?
У нас скрам, каждый день дейли-стендап. Есть архитектор. На мой взгляд, все медленно, но фиг знает, почему.
Например мне разработчик говорит, что рассчитывать средние недельные значения числового ряда - это нетривиально. Я хренею "чего, среднее значение - нетривиально???". Разработчик такой "ну да, мы этого ещё не делали нашим майкросервисом, вот месячные средние значения мы можем уже". И типа, что ты звереешь, я же только сказал, что недельная статистика менее тривиальна чам месячная. Я говорю, что ботинки со шнурками тоже менее тривиально завязывать, чем ботинки на липучках, но почему мы вообще этот детсад обсуждаем
В общем я в непонятках. Но мне пока и вмешиваться в технику было нельзя (хвала скраму). А теперь вроде можно. Но как?
Это что за бред вообще? Тут явно персонал надо менять.
PS И что значит нельзя? Ты же присутствуешь в рефайнментах? Можешь там прижать разработчика в углу, и ласково спросить "а вы прикупаете к девятке?" как он видит реализацию фичи?
назад
список