Мы в Промсвязьбанке активно переходим от каскадных команд каналов к гибким продуктовым командам.
Где-то это стоило пары ударов, где-то уже можно поменять грабли.
но в результате у нас накопился большой опыт, связанный с гибкой трансформацией.
В этом посте мы хотим поделиться своим опытом на случай, если вы откроете для себя что-то новое.
Как рождается идея перехода на agile
Обычно в компании появляется идеолог, который заражает всех вирусом Agile, рассказывая о ценностях командной работы.Все будет просто и быстро, результат поразит воображение, деньги потекут в наши карманы, а все сотрудники будут с удовольствием лежать на пуфиках с кружкой кофе в руке и бесконечной миской печенья, обещает он.
Для закрепления мыслей об agile приглашаются эксперты, которые прогнозируют пару сотен дней работы над продуктом, и, как следствие, продукт «запачкается», его кончину.
А потом, возможно, кончина компании.
Примеры включают HTC и Blackberry. Как не повторить их судьбу? Консультанты предлагают рецепт, который использовали такие гиганты, как Google, Amazon, Apple, — а именно гибкий agile.
Что обычно происходит во время трансформации
И вот вы выучили все необходимые слова и фразы, чтобы иметь право носить гордое имя PMI Agile Certified Practitioner: «стендап, груминг, демо, команда, доска, стикеры, все пошли по лесу со своими одобрениями.» Вы профессионалы своего дела, знаете, что и как работает, знаете все новые необходимые концепции, виды деятельности и процессы.
Остается только провести гибкую трансформацию.
Вот список типичных ошибок.
- Были отделы разработки, но этим занимались гибкие команды.
- Бесконечная очередь задач по запросам на изменения в Jira одним движением руки превратилась в отставание от RFC.
- Если раньше ресурсы под задачу выделялись централизованно, то теперь задачи распределяются между разработчиками.
- «Что этот застройщик с нами сделает? Давайте поместим эту задачу в резерв, он с ней справится».
- Вы поставили цель уйти от оценки задач за один месяц работы.
В ответ разработчик говорит: «Хорошо, начнём делать в этом спринте и закончим в следующем».
- Задача не согласована со службой безопасности и юристами? Давайте введем нормативные каникулы и проигнорируем этот момент.
- Начальник распределяет задачи? Тогда мы создадим гибкую, плоскую структуру, но «я все равно буду боссом».
Что мы получаем в результате?
Структура не изменилась.Начальники ставят задачи подчиненным.
Мозги у людей взрываются, менеджеров много, эти менеджеры одновременно ставят разные задачи с прописанными сроками.
Задачи стали измерять просто в спринтах, а не в месяцах.
Что делать непонятно, как делать непонятно.
Никакой документации! Вся команда постоянно сидит на собраниях, куда приходят старые, матерые технологи и программисты.
На сотрудников коллектива они смотрят так, будто те пришли в зоопарк понаблюдать за поведением гиббонов в стае.
Скрам-мастер говорит об определении готовности и определении готовности.
Все понимают, что это важно и нужно, так почему же разработчики сопротивляются? В этот момент, как назло, поступает важное задание со сроками исполнения от руководства, и молодой, все еще неуверенно стоящий на ногах, погибает под натиском врагов и зомби.
А как надо?
Нельзя слепо следовать шаблонам успешных компаний.Здесь проще объяснить через аналогию – например, через футбол.
Представьте, что вы тренер, ваша команда проигрывает, за пять минут до конца матча.
Есть пример безупречного плана известного тренера Эрнесто Вальверде.
По его словам, нападающий Луис Альберто Суарес врывается в штрафную, его сбивают, и судья назначает пенальти.
Лионель Месси приближается к мячу и пробивает точно в дальнюю от вратаря девятку.
Идеальный план.
Но ты не Вальверде, и в твоей команде нет Суареса и Месси.
Все.
Ты проиграл.
Кроме того, мы начинаем цепляться за процессы, забывая, зачем внедряем их в свою работу.
Поэтому я бы посоветовал вам сформулировать цель и повесить ее на видном месте.
Вы все умеете ставить цели.
Цель должна быть конкретной, измеримой, достижимой, значимой и ограниченной по времени.
Что все это означает на практике? На практике это означает, что самое главное во всем этом процессе – Клиент. Поэтому обязательно потратьте время и выясните, кто ваш настоящий клиент, который приносит вам деньги.
Опишите его личность.
Ответ на этот вопрос очевиден не во всех компаниях.
Вы делаете Продукт для клиента, причем такой, чтобы клиент оставался довольным после его использования.
Товар должен быть:
- полезен, то есть для решения существенной проблемы клиента;
- качество, то есть соответствие или превышение ожиданий клиента;
- сделано и предложено вовремя, а не через год.
На самом деле, Продукт и Команда тесно связаны.
Как говорил утонувший экипаж затонувшего корабля в «Пиратах Карибского моря»: «Часть экипажа, часть корабля».
Хороший продукт не может существовать без хорошей команды, и наоборот. И это основная причина, почему большинство попыток гибкой трансформации терпят неудачу.
Чтобы избежать такой ситуации, мы в Промсвязьбанке начинали запуск каждой команды с выбора продуктового направления и владельца продукта.
О том, каким должен быть Product Owner, уже много сказано и написано.
Все это так, основная трудность – найти нужного человека.
Вот что делает владелец продукта:
- ставит цель;
- описывает невыполненную работу верхнего уровня;
- продумывает KPI, по которым можно было бы постоянно отслеживать прогресс на пути к цели; в том числе не забывайте о счастливом клиенте;
- рассчитывает, как задачи из бэклога влияют на KPI.
Он хочет сделать для клиента лучший продукт, сделать его таким, каким он видит его каждый день в будущем.
Команда разработчиков — это ответственные люди, способные самостоятельно и самостоятельно развивать продукт. Команда должна обладать всеми компетенциями, необходимыми для достижения результатов.
Внешними зависимостями не следует управлять, их следует устранять путем включения в команду или обучения нужных людей.
Создавать команду с дублирующими ролями точно не нужно.
Чтобы достичь соглашения, команда должна быть как можно меньше.
Мысленно уберите роль из команды, без этого будет хуже? Лучший вопрос команде на старте: «Хватит ли вам всего для достижения целиЭ» А самая эффективная практика формирования состава участников – это самостоятельное проектирование, когда сотрудники сами определяют, с кем и с кем им работать.
Мы пытались сделать это уже на старте — когда нам предложили сделать ротацию самостоятельно, получилось хорошо.
Теперь, когда есть команда, она должна стремиться к тому, чтобы в конце спринта произошел рост «хорошего» продукта с явной бизнес-прибылью.
Хорошей аллегорией командной работы в Scrum являются соревнования лодок-драконов.
Барабанщик задает темп для синхронизации коллективной гребли, а в передней части лодки стоит рулевой, задающий направление.
Наш владелец продукта управляет видением бизнес-направления, а Скрам-мастер помогает команде поддерживать правильный темп для синхронной работы на всех фронтах.
Барабан — это Scrum-доска, обычное место встреч для командных мероприятий.
Основная ошибка здесь — попытка назначить Скрам-мастера или даже совместить несколько ролей в одном человеке.
Возможно, в зрелых командах это сработает, но это точно не ваш случай.
И даже в зрелых командах владелец продукта никогда не сможет одновременно быть Scrum-мастером.
Вы должны найти Скрам-мастера, а не назначать кого-то из людей, которые попадутся под руку.
Такой человек поможет команде стать более сплоченной и эффективной от спринта к спринту.
Для развития инженерных практик нужно создавать не отдел, который будет навязывать нужные вещи вроде юнит-тестов, а сообщество заинтересованных в этом разработчиков.
Если подобные инициативы рождаются снизу, они будут поддерживаться на всех уровнях.
Работа команды должна быть прозрачной для всех заинтересованных сторон.
Это и ответственность команды, и ее существенное преимущество.
Команда самостоятельно выстраивает свой рабочий процесс, и все вопросы, которые могут возникнуть, также будут решаться самостоятельно по мере роста.
И последний совет: используйте простые инструменты.
Любые поля и процессы в Jira легко заменяются физической доской с набором магнитов.
К чему мы пришли?
У нас регулярно появляются новые продуктовые команды.Они не обсуждают agile, а создают новый функционал.
Благодаря людям в командах создаются продукты, полезные и удобные для клиентов, выгодные для банка.
Теги: #agile #Промсвязьбанк #Управление развитием #Управление проектами #agile #Управление персоналом
-
Проблемы И Риски Криптовалют
19 Oct, 24 -
24X01 I2C На Attiny13 Без Twi
19 Oct, 24 -
Это Mvc?
19 Oct, 24 -
Создаем Свои Теги В Тестах Rspec
19 Oct, 24 -
Polymer 3.0 На Google I/O 2018
19 Oct, 24 -
Умная Нормализация Данных
19 Oct, 24 -
Утечка Памяти С Помощью Threadlocal
19 Oct, 24
