Hygger corporate blog
Development Management
Project management
Product Management
Comments 32
0
В некоторых креативных командах стало модным проводить короткие собрания в планке

Классная идея — через 30 секунд пузатенький менеджер упал с планки, все собрание закончено, возвращаемся к работе.
0
Достаточно пузатый менеджер имеет в планке дополнительную точку опоры
0
Ежедневное собрание в Scrum-команде должно помочь собственнику и менеджеру продукта

менеджеру продукта

Нечасто вижу людей которые так умело дискредитировали свою экспертизу с первых строк.
В scrum команде нет роли менеджер. Тут либо крестик снимать либо плавки надеть нужно.

-1
Если вы судите о процессах по обертке, то это вы себя дискредитируете.
Первый принцип agile — человеческие отношения которые важнее учебника.
Есть два места, где понятие менеджер входит в scum:
1) Есть люди которые больше делают технические вещи а есть люди которые больше взаимодействуют с людьми. Первых логично назвать разработчиками, вторых менеджерами. Если назвать собственника и scrum master'а менеджерами — по сути ничего не измениться. Придираться нужно к сути, к тому как выстроены процессы, а не к названиям.
2) Вне скрама есть своя организационная структура — и у проекта есть человек который отвечает за проект/продукт. Этот человек может быть собственником, может скрам-мастером, а может быть частью команды — не суть важно. Но роль такая есть в жизни. Это задача скрама ее в себя включить, а не наоборот.
0

Извините меня за мою глупость, и поверхностность.
Спасибо что процитировали слова, которые я слышу раз за разом в 9 случаях из 10 когда мне объясняют зачем нужен менеджер в их версии scrum'на.
Мне повезло, когда компания решила оплатить мою сертификацю scrum-мастера международной тренинговой конторой. Так получилось что в scrum нет менеджеров, использования слова менеджер сильно ошибочно. Если Вы подразумаевте под менеджером переговорщика, то странного называть его менеджером. Проактивный разработчик договаривается с соседними командами и пилит функционал, от того что он договорился стал ли он менеджером ?

-1
Если Вы подразумаевте под менеджером переговорщика, то странного называть его менеджером

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

Так получилось что в scrum нет менеджеров, использования слова менеджер сильно ошибочно.

Менеджер проекта/продукта есть в реальной жизни. Всегда есть человек который принимает решение, что проект будет и несет за него ответственность. До того как команда стала делать скрам должен быть человек, который принял решение делать скрам. И этот человек может быть на разных ролях в скраме, или, например, стэйкхолдером без явной роли. И в контексте статьи явно говориться про этого человека. Как еще его назвать?
0
Но так есть. Человека который пошел в софт скилы вместо хард скилов у нас принято называть менеджерами.

У вас в компании? Софт скилл и управленец принимающий решения — это разные вещи. Развитый софт-скилл не делает меня менеджером, он делает меня человеком с сильным софт-скиллом.


Проект стартует и строит бизнесс.
Бизнесс платит зп команде разработки, ПО и scrum-мастеру.
Бизнесс принимает решение. Вы жалуетесь на сложность натянуть scrum на вертикальные директивные компании, но это конкретная проблема натягивания scrum на вертикальную компанию, в горизонтальных таких проблем нету.

0
Развитый софт-скилл не делает меня менеджером

Вы меня не услышали. Я не готов рассуждать что делает менджера менеджером. В индустрии используется такое слово — не важно используют его правильно или нет. В реализации скрама люди делают много ошибок. Посмотрите соседние ветки — там притензии к статье по делу. Использование слова менеджер, к месту или нет — это шашки. Вам шашечки или ехать?

Проект стартует и строит бизнесс.

Бизнес — это кто?
В любой, даже горизонтальной структуре всегда будет человек, принимающий конкретное решение.
Бизнесс не может принять решение — бизнесс не личность.

Вы жалуетесь на сложность натянуть scrum на вертикальные директивные компании

Я не жалуюсь. Я работаю на аутстафе и часто меняю компании, поэтому вижу разные ситуации.
Я предложил конкретный пример, когда понятие проект менджера применимо к scrum — что ПМ создает scrum команду и становится собственником или стейкхолдером. Мне кажется, что это вполне рабочий вариант. Вы в ответ предлагаете менять всю вертикальную структуру компании?
У горизинтальный компаний есть свои проблемы — горизонтальность нельзя назвать универсальным решением.
0

CEO решил начать проект
собрали dev — команду, позвали ПО и скрам-мастера, где в этой истории менеджер ?

0
CEO — менеджер вот прям по определению. Если CEO не менеджер, то не понятно кто вообще менеджер.

Затем. Обычная ситуация, у ПО обычно в этой истории есть визитка, в которой написано: «продакт менеджер». И зарплату в бухгалтерии когда он получает — в ведомости написано «продакт менеджер». И когда члены команды уходят в отпуск — ПМ подписывает бумажку, где написано что он «продакт менеджер» и отпускает члена команды в отпуск. И самое главное, если проект провалится, то ПО не получит премию и нагоняй получит именно ПО в первую очередь.
Я не говорю, что ПО в этой истории ПМ или что так и должно быть всегда. Я говорю, что если вы приходите на аудит в эту историю, и первая ваша претензия: «у вас есть ПМ и скрам у вас неправильный потому что у вас есть ПМ», то вы явно упустили смысл скрама.
0

что делать тем людям у которх на визитки ПО нет слова менеджер, в рассчетной ведомости ПО тоже нет слова менеджер, а еще он не подписывает мне отпускные ?


Пускай каждый окажеться при своем, вам кажеться что в скрам нормально иметь менеджера, мне нет. Взрослые люди должны остаться при своем мнение.

0
что делать тем людям у которх на визитки ПО нет слова менеджер

Так я говорю, что это вообще не важно. Скрам это про взаимодействия и итеративное улучшение. А не про роли, отпускные и слова в визитке.
0

Снова с вами не соглашусь. Про взаимодействие это agile.
Agile это идеология или mindset которая говорит о важности взаимодействия и итерактивности.
Scrum очень конкретный фреймворк, с определенным списком ролей и мероприятий, артефактов и правил.


Не поучатильства ради а достоверности информации в интернете для.

0
Так ведь Scrum это фреймворк для применения Agile.
Если делать Scrum без Agile mindset'a то скрама не получиться по определению. Пиратский кодекс-это всего лишь свод указаний, а не правил.
Тут же вопрос в том, что люди берут внешние части скрама теряя суть.
0
Хорошо, когда у нас есть пул задач и мы под них выбираем методологию разработки… Но в текущей компании (название умолчу) происходит всё наоборот — под методологию загоняется спринт и происходит чёрти что.
Ну и не хватает в этом тексте то, что Scrum master обязан контролировать эти миттинги, потому что всяко без лидера — все в команде начинают разглагольствовать и эти встречи затягиваются от 40 минут до 1 часу.
0
15 человек. Мастер у нас мёртвый, просто потому что опыта не было. Иной раз рявкать приходится, потому что невозможно это. Как по мне, ежедневные Stand Up'ы, Ретро — это пустая трата времени, если команда не умеет взаимодействовать друг с другом. За рабочую неделю — мы рабочий день, извините за выражение, пустословим (п**дим) ни о чём. Я бы лучше это время потратил на разработку или ещё какое-либо полезное занятие, но нет, ты обязан слушать о том, как дизайнер или контентмейкер мусолит свою задачу, посещать собрания на которых мы очередной раз профукали спринт, потому что кто-то чё-то тормозит и вообще команда ужасная и плохая.

Не спорю, Scrum идеально вписывается под сплоченную команду, которая готова включатся и бросаться на любую проблему. Но когда у тебя коллектив забитых интровертов, которые хотят реализовывать только тот объем задач, который на них висит, да ещё сверху добитых бюрократией — по такой схеме невозможно работать. Да, и как описал выше, нужно выбирать методологию под задачи, а не подгонять задачи под методологию. Со стороны это жесть как весело смотрится, а работать в этом безобразие — вообще одно удовольствие.
0

Все что Вы описали — это проблемы конкретной конторы.
Неясно только зачем вы продолжаете там работать.

+1
В пассивном поиске, мой друг, в поиске)

Поэтому, в последнее время больше склоняюсь к методологии waterfall. Так спокойно работается и каждый понимает свою зону ответственности. Лиды на своих местах, разрабы и другие на своих.
0
А еще классно, когда Master не может надовить на product owner'a))) Пример. Я, как разработчик вижу, что эту задачу могу сделать за 8 часов, но product owner считает, что тут можно и за 2 часа всё сделать, поэтому ставит своё время. Я смело могу с наглой рожей сказать, чтобы он сам задачу делал за 2 часа. А master стоит и хлопает глазами, потому что не понимает как работают процессы. Это его команда и он должен ей рулить, он должен диктовать правила, а не owner. Конечно, не стоит идти в штыки с owner'ом, а уметь взаимодействовать с ним. Поэтому, такой вот у нас бардак.
0
Хоть и некро комментарий, но всё же.

Только что перечитал гайд по скраму (тот, что на ~17 страниц). И там четко написано, что время должна определять только команда. Владелец продукта этого делать не может — вообще никак. Он может только искать компромиссы, изменяя задачу или приоритет задач.

Скрам мастер тут должен был скорее напомнить владельцу, что это не в его компетенции.
0
Если стендап превращается в никому не нужную рутину, вероятно, командная работа отсутствует. Обычно члены команды заинтересованы знать, кто что делает и какие сложности. Возможно, команда не была запущена.
+2
Отзыв будет несколько резковатым, но это реакция больше на всю индустрию, статья — только отражение ситуации.

> Во время спринта определяется набор фич и требований из бэклога для новой итерации.

Простите, а в чем разница между спринтом и итерацией?
Почему два понятия?
Это вы так груминг и планирование изволили смешать вместе?!

> На практике — Scrum meeting может быстро превратиться из эффективной короткой встречи в никому не понятную рутину

Это потому непонятную, что большинство менеджеров занимаются «наукой самолетопоклонников», т.е. делают ритуалы, суть которых они не понимают и не в состоянии обьяснить. Например, а зачем вообще нужны ежедневные стендапы? Какой от них толк? Люди, в отличие от менеджеров (sic!), не любят делать бессмысленные действия. Поэтому, если они не понимают зачем это нужно, они делают это формально.

У меня никогда не было подобной проблемы, т.к. суть стендапа обьяснялась сразу и для всех. Что мы делаем, что мы с этого имеем.

> Отвечая на эти простые вопросы, команда быстро может выявить проблемы, которые требуют особого внимания и оптимизации.

Общие слова, которые никоим образом не раскрывают суть и даже близко к сути не стояли.

Менеджер это понимает (хотя часть, как собака, все знают, но выразить не могут), люди это понимают. Но книжка требует говорить вот так, следуем ритуалу. «Потому что здесь так заведено»

> В некоторых креативных командах стало модным проводить короткие собрания в планке или выполняя другие полезные физические упражнения.

Т.е. креативный менеджер не только не понимает сути, но и не выполняет свою работу модератора? Прелестно.
Тупо режем по физическим способностям? Дабл-килл!
Вместо обсуждения занимаемся приседаниями! Трипл-килл!

Но вообще логично, да, одну бессмысленную активность заменяем другой.

> Лучшее решение для Scrum-собрания — это 8-10 человек, заинтересованных в обсуждении.

Нет, вот Вы серьезно? Если у меня команда на 12 человек, то нужно пригласить 8, кому интересно? Вы точно понимаете суть стендапа?

<---------------------------------------------------------------------------------------->

Окей, начнем сначала, стендап, это процесс короткого обсуждения командой прогресса, работы и блокеров.

Стендап позволяет:
1. члену команды рассказать другим о том, над чем он работает и дать статус;
2. команде понять, кто чем занимается и какие знания и опыт у кого; это поможет понять, кто в нужной тебе теме, если нужна помощь;
3. члену команды поднять технический блокер и либо сразу получить ответ либо быстро найти того, кто сможет помочь и уже работать с ним после стендапа (сильно помогает №1 и №2);
4. озвучить блокер, который требует внимания scrum master или product owner
5. всей команде понять, на треке ли они или нужно менять приоритеты и т.д. (у менеджера есть burndown, но он дает понимание наличия, а не сути проблемы)
6. менеджеру понять статус и иметь возможность разруливать проблемы по конкретным блокерам, а не пялиться в burndown и ныть, типа вы не успеваете.
7. членам команды понять, где они пересекаются в активностях и скоординировать действия (что планируешь)

Scrum master должен сводить разговор к простым вещам:
— что сделал
— что будешь делать
— блокеры
Самое важное, вдалбливать и каждый раз говорить одну фразу, «ты не мне рассказывай, ты команде рассказывай, это им нужно. А вы слушайте, т.к. может завтра это уже ВАМ будет нужно или ВЫ можете помочь сейчас».

Задача scrum master-а модерировать обсуждения и самое главное его оружие это две фразы:
1. это обсуждение за стендап
2. так, кто может помочь? окей, ты, ты и топикстартер, плз, пообщайтесь после стендапа.

Стендап заканчивается двумя фразами:
1. Мы закончили стендап, кому не интересно обсуждение поднятых вопросов, спасибо, можете переключаться на свою работу.
2. Господа, мы начинаем краткое обсуждение поднятый вопросов. <И дальше по списку>

При таком простом подходе, стендапы становятся короткими, эффективными и люди на них ОЧЕНЬ внимательны, т.к. теперь это живой синк, на котором мы быстро рассказываем где мы и подымаем\решаем проблемы.

И они очень хорошо понимают, нафига говорить о том, что ты делал и сделал. Что-бы остальные понимали, что и где ты меняешь, что ты знаешь, с чем работал. Что-бы быстро найти помощь. Что бы менеджер, который DM, по определению, в отличие от DoE, рулит не по чартам, а изнутри, мог бы помогать решать поднятые проблемы немедленно.

P.S. Поначалу приходится людей возвращать к формату, но не глупым «ты должен говорить так», а «Смотри, всем нужно понять, что ты знаешь, что ты менял, где ты можешь помочь или тебе и может скоординироваться по будущим действиям. Поэтому расскажи, что делал, что планируешь и блокеры.»

P.P.S. Куда все ушло? Десятки лет развития менеджерских практик, оттачивания методологий. Куда все эти люди ушли? Пришли какие-то креативные…, которые предлагают держать гирю, иначе типа стендап не такой, как в книжке.
0

не хочу выглядеть бестактным, но почему Вы используете словов менеджер говоря про scrum ?

0
Вы АБСОЛЮТНО правы.

Я пытаюсь говорить на языке команд и менеджмента, которые, блин, не только не понимают, что такое self-organizing team, но и, как правило, scrum manifest не видела в глаза.

Поэтому у них все еще есть понятие development manager, там, где вроде как чистый scrum.

Да, нет менеджера, есть scrum master, задача которого больше процедурная. Но в реальности возникают жуткие гибриды, в которых сова натягивается на глобус и есть DM, который заодно и играет роль scrum master.

В особо прекрасных случаях он еще и микроменеджит
0
Упс, простите.

Это ветка engineering management.

DM — development manager
DoE — director of engineering

VPoE — VP of Engineering
0
когда 15 человек в команде не знают, что делает каждый из них, это не команда, а соплежуи-индивидуалы. Тут Scrum не поможет.
0
Вообще-то стендап, в нормальной команде, именно эту проблему и решает, в том числе.

Решал. Пока не пришли креативные менеджеры, без понимания, зачем эти процессы, зато с гирей
0
Это не Scrum, а отсебятина по мотивам Agile.
Scrum — вполне конкретная авторская методика, описанная в Scrum Guide.
Ежедневные «Stand-Up» — это встречи команды Разработки. Product Owner в них не участвует:
The Daily Scrum is a 15-minute time-boxed event for the Development Team.
The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.
-1

Ох как же айтишники любят изобретать велосипеды. Учите историю индустриализации. Это называется оперативка. Почитайте и поспрашивайте как это было. Более того процесс производства на порядки сложнее чем процесс написания софта.

Only those users with full accounts are able to leave comments. , please.