Comments 30
без опыта управления командой попытались решить собственные проблемыЕсли у скрам мастера болит от какого-нибудь процесса — это может служить индикатором того, что какой-то процесс можно оптимизировать. Процессы же ради результата, а не для того что бы сделать больно скрам мастеру.
Вы не описали, зачем это было нужно команде.Соглашусь с вами и отвечу в комментарии. Были проблемы с тем, что некоторые задачи занимали больше времени по факту, чем было оговорено на планнинге.
Вы осознаёте, что подобный подход может разрушить команду и не способствует здоровому климату в коллективе?Советоваться с командой нужно и важно, так как процессы в первую очередь для команды, не для скрам мастера. Но выносить на обсуждение каждую мелочь — это может быть утомительно и неэффективно. Иногда стоит придумать и продумать какое-либо улучшение, и только потом предлагать его команде.
Были проблемы с тем, что некоторые задачи занимали больше времени по факту, чем было оговорено на планнинге.
Задачу невозможно точно оценить заранее в количестве часов, можно лишь примерно. В процессе работы могут возникнуть подводные камни и непредвиденные сложности, которые трудно или невозможно предусмотреть заранее, вследствие чего время на решение задачи увеличивается. И это совершенно нормально. Печально, когда руководство не понимает таких вещей и подгоняет сотрудников, поощряя быстрый говнокодинг. Зато скрам, аджайл, все дела.
Вообще чтобы коллектив работал более эффективно, на мой взгляд нужно:
1. поднять зарплату до конкурентной рыночной участником команды
2. создать доброжелательную не кислотную атмосферу. Исключить публичное обсуждение участников команды
3. контролировать результат, а не процесс работы. Дать человеку возможность заниматься работой, как творчеством
Все остальное — это просто пляски с бубном или вера в волшебную красную кнопку «scrum», что по сути одно и тоже
Эффективного результата без коммуникации и доброжелательной атмосферы добиться не просто. Но на одной доброжелательности результата не достичь. Если посадить группу заинтересованных в достижении цели людей и дать им задачу, рано или поздно они начнут договариваться о процессе её выполнения. А это уже построение процессов.
Прочитал статью и вздрогнул. Мне интересно, кому вообще в голову приходит поставить человека с явным синдромом вахтера на позицию, которая подразумевает улучшение коммуникации? Кто предполагает, что работа команды станет лучше, если дать иллюзию полномочий (в статье акцент именно на них, хотя реально их нет) сотруднику, который совмещает новые обязанности с работой инженера? Кто допускает превратить гибкие методологии в цирк, потому что скрам — это стильно, модно, молодежно? Здесь тот случай, когда рыба гниёт с головы, привет руководству Вашей компании и добрый совет — поменяйте подход.
Автору epifan001 — удачи и успехов на новом выбранном пути. Публиковать подобную статью на habr смело, но может быть травмирующе — очень уж здесь сильна культура ненависти к менеджерам и к Agile. Сам факт того, что вы перешли в скрам мастера, делает вас по-умолчанию врагом для большинства аксакалов здесь.
Возвращаясь к статье, становиться скрам мастером из команды действительно тяжело, и да, проблема даже приоритезации новой информации стоит остро. Для того, чтобы понять скрам гайд, что скрывается за его формулировками, требуется опыт, которого начинающим скрам мастерам часто не хватает. Почувствуешь, что не твоё, не идёт — путь назад в тестирование не закрыт навсегда) Советов давать не буду, их и так достаточно со всех сторон.
Предыдущий скрам-мастер довольно остро воспринимал отзывы о своей работе, а мне было важно получать обратную связь. В итоге, первый полезный фидбек удалось собрать только через пару месяцев
Вот эта работа, которая выполнялась первое время. Для меня (может я не прав, но предположу) очевидно, что прошлый скрам мастер тоже был/была не особым экспертом, но используя накопленное доверие команды не давал/давала себя ругать. Т.е. он/она за время скрам мастерства уничтожил/уничтожила механизм обратной связи, критически важный для процесса в целом. Официально всё было нормально, работается-работаем (но о проблемах молчать!)… А теперь попробуй-ка улучшить что-то в этой ситуации. А потом начинаешь восстанавливать обратную связь и всё это скрытое и дурно пахнущее выливается на тебя, как будто это ты виноват во всех проблемах команды сейчас (и 1 год назад, и 5, и 10 лет назад проблемы тебе припомнят).
Что касается комментаторов выше, то этого и следовало здесь ожидать).
Осуждение, неуважение, сексизм (оба зачем-то ссылаетесь на пол автора — какая разница, что она девушка, в статье совсем другая тема!). Оба осудили за то, что автор взялась «рубить с плеча, не вникая», а при этом сами что, вникли? Вылили на автора ведёрко своего контекста, ну бывает.
Почему вы считаете что она всё делала исходя из своих амбиций? Она согласилась, когда ей предложили. Вполне вероятно, людям, которые в команде дольше неё, предложили тоже самое, но желающих не нашлось. И вот она начала работу, без особых возражений команды, но без кредита доверия, но в тени прошлого скрам мастера.
И вы ещё спрашиваете
Не успели получить власть, как начали строить кулуарную политику?… вы организуете «круг приближённых» и административными методами заставляете мнение меньшинства доминировать над мнением большинства коллег. .
Вот поэтому она и начала с поиска союзников, потому что в её команде наверняка есть такие, как вы, с нежеланием слушать, авторитетом в команде, но не готовые взять роль скрам мастера на себя, зато готовые осудить. А потом эти юные скрам мастера послушают вас на паре ретроспектив или планирований спринта и идут плакать в тихую переговорку, собирать себя по кусочкам, чтобы потом вернуться и попытаться помочь команде. За что им это? Не потому, что они не правы, а потому что токсичный красный авторитет уже подмял команду под себя и не готов слушать советы какой-то мелочи зелёной/бирюзовой.
А как же аджайл и все эти бирюзовые ценности?Она же не гуру, и сама об этом заявляет с самого начала, поэтому вполне может и не знать, что такое спиральная динамика, не знать про цвета и т.д. Хотя я почему-то уверен, что staticlab, оставивший 2500 коментариев и при этом написавший 0 статей, уверенно развязал бы холивар с любым гуру.
puyol_dev2, коротко по вашим советам. №1 — а с чего вы взяли, что у автора в команде не конкурентная зарплата? Что указывает на то, что это проблема в её команде или компании? Это может быть ваш контекст, не её. Насчёт атмосферы она уже сказала
Команда, в которую я пришла как QA-инженер, была уже сформирована: стандартные процессы построены, атмосфера в коллективе — дружелюбная и спокойная.
так что ваш совет №2 тоже мимо кассы. Насчёт совета №3 — ок, хорошо, может у них так и есть.
Давайте все же не будем кривить душой относительно ненависти к менеджерам на хабре, как Вы об этом пишете. Интерес к тем или иным практикам стабильно высок, для многих из аудитории ресурса наоборот интересно посмотреть взгляд с той стороны баррикад, а некоторые, как, например, я, когда-то пришли в управление из разработки. Статьи, описывающие "на пальцах" основы управления или элементы методологии всегда пользовались большим успехом и имели и высокие рейтинги, и массу каверзных вопросов в комментариях, а их авторы пользуются уважением со стороны сообщества. Но когда под соусом подачи очередных "n ошибок" человек начинает писать откровенный, простите, бред, то реакция со стороны сообщества логична и ожидаема.
Она согласилась, когда ей предложили. Вполне вероятно, людям, которые в команде дольше неё, предложили тоже самое, но желающих не нашлось.
Мне захотелось попробовать.
В том то и дело, что ей не предложили, а она сама вызвалась «порулить». И «нарулила». А команде реально не было нужно, команда, судя опять же по тому, что говорит автор, устала от предыдущего скрам-мастера и вообще перестала ей давать обратную связь, просто слив
Думаю, что статья поставила всех в диссонанс, потому что читая ее, постоянно возникает вопрос "нафига вся эта чушь вообще нужна, какие-то лишние совершенно запары и суета".
Классическая ошибка — недостаток контекста у читателя. Его надо было создать, а не писать все в виде лапши.
Надо более системно подходить:
Предисловие
описание команды, кто что зачем, что делаете
когда, как давно и по каким соображениям в команде сделали скрам, что изменилось с его введением, команде хорошо или плохо или может нафиг он никому не нужен?
вести основные идеи скрама, ещё раз для понимания и контекста
обязанности скрам мастера, какие ещё роли есть в процессе кроме него, кто что делает, какую проблему решает
Что такое agile
Как выглядел процесс разработки, каким он стал после скрама, каким он стал "после вас".
Например, изначально были двухнедельные спринты, но стало понятно, что фичи пилить сложно ввиду разных зависимостей и недостатка знаний и временно спринты стали размером в месяц. Да что угодно.
В конце статьи непонятно, добились ли вы своих целей или все как было непонятным сбродом, так и осталось.
Вы закончили статью опять какими-то абстрактными навыками опять же оторванными от контекста.
Статьи о любой методологии и процессе должны быть цельными на мой взгляд, идти бок о бок с этой методологией.
Они должны описывать в целом экосистему, ее эволюцию при внедрении методологии и эволюцию вашего личного опыта.
Кто эти люди? Зачем я им нужна? и другие проблемы скрам-мастера