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