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