.
Словить блокер на N процентов - если что, норм? Как-то договаривались с бизнесом?
Тогда скорость разработки имела бОльшее значение чем отсутствие багов
Size: a a a
2020 June 28
АБ
...
Тогда скорость разработки имела бОльшее значение чем отсутствие багов
Вот это очень хороший пункт, спасибо :)
.
Могу ещё книгу Проект Феникс порекомендовать глянуть, это как Савин для тестирования, публицистика, но у неё меньше хейтеров (ну или я реже про них слышу)
AG
О, вот это уже разговор.
1. Проблема не в том, что человек занимается не своей работой. Проблема в том, что он не занимается своей. В том числе (бас фактор, да) решаемые только им. И вот лучше сначала бы устранить бас-фактор. Тогда и свои задачи будут выполняться, и о помощи соседям можно подуматью
2. Оценивать перформанс сотрудников в условиях отсутствия оценок в соседних отделах - тяжеловато. Вероятно, мой косяк, но до импакта в продукт еще надо добраться, пока так.
3. Здесь фишка не в мотивации, а в "ну только ты ж знаешь". Когда есть прямой запрос "снимите с меня эту задачу, я хочу тестировать" - странно говорить о заявлении на стол, если именно этим ты и занимаешься.
4. см п. 2: ни ревью, ни других подобных метрик пока нет. Когда будут - да, туда будут включены в том числе и межкомандные взаимодействия. Пока же есть четкие задачи, согласованные с бизнесом, их и выполняем.
1. Проблема не в том, что человек занимается не своей работой. Проблема в том, что он не занимается своей. В том числе (бас фактор, да) решаемые только им. И вот лучше сначала бы устранить бас-фактор. Тогда и свои задачи будут выполняться, и о помощи соседям можно подуматью
2. Оценивать перформанс сотрудников в условиях отсутствия оценок в соседних отделах - тяжеловато. Вероятно, мой косяк, но до импакта в продукт еще надо добраться, пока так.
3. Здесь фишка не в мотивации, а в "ну только ты ж знаешь". Когда есть прямой запрос "снимите с меня эту задачу, я хочу тестировать" - странно говорить о заявлении на стол, если именно этим ты и занимаешься.
4. см п. 2: ни ревью, ни других подобных метрик пока нет. Когда будут - да, туда будут включены в том числе и межкомандные взаимодействия. Пока же есть четкие задачи, согласованные с бизнесом, их и выполняем.
Знаешь, я проведу, как мне кажется, отличную параллель.
Как-то давным давно, когда работал в рекламном нетворке, мы пытались отдебажить, почему же мы всё никак не закрываем спринты вовремя.
Результатом инвестигейшена стало то, что на протяжении последних двух месяцев 4 из 16 разработчиков больше половины своего времени тратили на задачи, которые прямщас в мастер, и соответственно не добирались до задач запланированных на спринт.
И там было очень много холиваров на эту тему, пушта вот спринт есть, вот дедлайны есть, чо с этим делать?
В итоге и capacity меняли, закладывая определенное количество времени на такие задачи, и всячески эксприментировали с наполнением спринта и планированием хотелок.
Кончилось, в общем-то, всё тем, что CTO установил диктатуру в формате “посоны, вот у нас спринт длится 5 рабочих дней, за это время проходит 3-7 релизов”.
Все хотелки пришедшие после начала спринта делаются не раньше первого релиза следующего спринта.
Казалось бы, стандартная практика, фиксируем скоуп, вот это всё.
Даже стали успевать закрывать спринты в дедлайны.
И в целом все четко занимаются своим делом и никто никого не дергает.
Как-то давным давно, когда работал в рекламном нетворке, мы пытались отдебажить, почему же мы всё никак не закрываем спринты вовремя.
Результатом инвестигейшена стало то, что на протяжении последних двух месяцев 4 из 16 разработчиков больше половины своего времени тратили на задачи, которые прямщас в мастер, и соответственно не добирались до задач запланированных на спринт.
И там было очень много холиваров на эту тему, пушта вот спринт есть, вот дедлайны есть, чо с этим делать?
В итоге и capacity меняли, закладывая определенное количество времени на такие задачи, и всячески эксприментировали с наполнением спринта и планированием хотелок.
Кончилось, в общем-то, всё тем, что CTO установил диктатуру в формате “посоны, вот у нас спринт длится 5 рабочих дней, за это время проходит 3-7 релизов”.
Все хотелки пришедшие после начала спринта делаются не раньше первого релиза следующего спринта.
Казалось бы, стандартная практика, фиксируем скоуп, вот это всё.
Даже стали успевать закрывать спринты в дедлайны.
И в целом все четко занимаются своим делом и никто никого не дергает.
AG
Всем стало хорошо, приятно и спокойно жить, пока не посчитали количество бабла, потерянного на лишнем time to market для фичей из категории “сделать прям щас”.
АБ
...
Могу ещё книгу Проект Феникс порекомендовать глянуть, это как Савин для тестирования, публицистика, но у неё меньше хейтеров (ну или я реже про них слышу)
которая про девопс? Спасибо, почитаю :)
АБ
Всем стало хорошо, приятно и спокойно жить, пока не посчитали количество бабла, потерянного на лишнем time to market для фичей из категории “сделать прям щас”.
И чем все кончилось?)
AG
Тем что за два месяца спокойной жизни разработчиков компания заплатила потерянной прибылью в размере годового бюджета разработки, и всё откатили назад.
.
Но это же не по флоу. Так не правильно. Где-то в угле плачет маленький скрам-мастер
AG
Вот ситуация, которую ты описал, про боттлнек на тестировании - примерно та же история.
Это очень большой вопрос, что выгоднее компании - поассистить продактов, или закончить регрессию вовремя, а не на день позже.
Это очень большой вопрос, что выгоднее компании - поассистить продактов, или закончить регрессию вовремя, а не на день позже.
AG
И без метрик и цифр ответить на него довольно сложно. :)
.
Стоит ли слезинка на лице скрам-мастера денег на годовой бюджет разработки?
ДБ
Ну, первый тезис: превращать бюджетирование в проблему членов команды (ака “не занимайся вот такими задачами, они не из нашего бюджета оплачиваются”) - признак [censored] менеджера.
Второй тезис: оценивать перформанс по команды по “профильным задачам”, а не по импакту в продукт - признак того, что менеджер или не умеет, или сознательно ленится этот импакт оценивать, что делает его [censored] менеджером.
Третий тезис: если у человека хватает мотивации и скиллов решать сторонние задачи, то говорить ему “давай ты не будешь туда лезть, это не твоя зона ответственности” - прямой путь к получению заявления на стол, и признак [censored] менеджера.
Четвертый тезис: позиция “мне так будет менее удобно проводить перформанс ревью, и бюджет сложнее рейзить”, без учета импакта в продукт, интересов юнита и команды - это попытка огородить свою жопу в ущерб всему остальному и признак [censored] менеджера.
Второй тезис: оценивать перформанс по команды по “профильным задачам”, а не по импакту в продукт - признак того, что менеджер или не умеет, или сознательно ленится этот импакт оценивать, что делает его [censored] менеджером.
Третий тезис: если у человека хватает мотивации и скиллов решать сторонние задачи, то говорить ему “давай ты не будешь туда лезть, это не твоя зона ответственности” - прямой путь к получению заявления на стол, и признак [censored] менеджера.
Четвертый тезис: позиция “мне так будет менее удобно проводить перформанс ревью, и бюджет сложнее рейзить”, без учета импакта в продукт, интересов юнита и команды - это попытка огородить свою жопу в ущерб всему остальному и признак [censored] менеджера.
Схоронил
АБ
И без метрик и цифр ответить на него довольно сложно. :)
Именно. И пока метрика "скорость тестирования" бизнесом обозначена как приоритетная, а метрики "скорость продактов" нет (с чем я борюсь, кстати) - будем делать то, что хочет бизнес. Если увидим, что нужен ассист продактам - будем ассистить.
AG
Именно. И пока метрика "скорость тестирования" бизнесом обозначена как приоритетная, а метрики "скорость продактов" нет (с чем я борюсь, кстати) - будем делать то, что хочет бизнес. Если увидим, что нужен ассист продактам - будем ассистить.
Ну, Арсений, я ж и не осуждаю.
В моих глазах “ну мне что бизнес сказал, то я и делаю” это то же самое, что “а в таске не написано было, что надо подумать”.
Но это, вероятно, сугубо мои предубеждения.
В моих глазах “ну мне что бизнес сказал, то я и делаю” это то же самое, что “а в таске не написано было, что надо подумать”.
Но это, вероятно, сугубо мои предубеждения.
МК
...
Могу ещё книгу Проект Феникс порекомендовать глянуть, это как Савин для тестирования, публицистика, но у неё меньше хейтеров (ну или я реже про них слышу)
Мне зашла эта книга, а тут нет где-то списка книг, которые стоит почитать для общего развития?
AG
Мне зашла эта книга, а тут нет где-то списка книг, которые стоит почитать для общего развития?
Общего развития в чем-то конкретном?
АБ
:)
Не "что мне бизнес сказал", а "что мы бизнесу предложили и согласовали как необходимость". Я потому здесь и набрасываю, что хочу увидеть другие возможности. Вот книжку уже намутил.
Возвращаясь к теме - а что делать в отсутствие метрик-то? Особенно - со стороны других отделов?)
Не "что мне бизнес сказал", а "что мы бизнесу предложили и согласовали как необходимость". Я потому здесь и набрасываю, что хочу увидеть другие возможности. Вот книжку уже намутил.
Возвращаясь к теме - а что делать в отсутствие метрик-то? Особенно - со стороны других отделов?)
AG
:)
Не "что мне бизнес сказал", а "что мы бизнесу предложили и согласовали как необходимость". Я потому здесь и набрасываю, что хочу увидеть другие возможности. Вот книжку уже намутил.
Возвращаясь к теме - а что делать в отсутствие метрик-то? Особенно - со стороны других отделов?)
Не "что мне бизнес сказал", а "что мы бизнесу предложили и согласовали как необходимость". Я потому здесь и набрасываю, что хочу увидеть другие возможности. Вот книжку уже намутил.
Возвращаясь к теме - а что делать в отсутствие метрик-то? Особенно - со стороны других отделов?)
Ну, я бы предложил, что без метрик как минимум не стоит размышлять о том, что как правило непрофильные активности вредят продукту и команде. :)
В целом, как и делать любые другие не подтвержденные утверждения.
В целом, как и делать любые другие не подтвержденные утверждения.
МК
Общего развития в чем-то конкретном?
Не только тестирование, но и девопс/по проектам вообще
Я говорю про такие Книги аля как работает гугл, кради как художник, феникс, inspired- такие околопроектые не совсем технические Книги, но которые помогают развивать видение и другие точки зрения, чтобы лучше понимать «а что происходит»
Я говорю про такие Книги аля как работает гугл, кради как художник, феникс, inspired- такие околопроектые не совсем технические Книги, но которые помогают развивать видение и другие точки зрения, чтобы лучше понимать «а что происходит»