Кросс-функциональные команды – это классно!

Давайте поговорим о способах составления команд: кросс-функциональных и компонентных. Мне посчастливилось поработать и с теми, и с другими. В итоге я пришел к выводу, что полезно некое их сочетание, когда есть и кросс-функциональные, и компонентные команды.

Сейчас я работаю с большой командой, которая строит продукт под несколько клиентских платформ (мобилки и веб), а также через бекенд интегрирована с другими системами компании. Долгое время команда делилась на компонентные подкоманды: iOS, Android, Web, Back. Казалось бы, это самый оптимальный вариант – объединить сотрудников одной компетенции вместе, добавить им тестировщиков, и пусть они выпустят нам готовый продукт. На деле же между подкомандами существует множество зависимостей по API, по способу реализации фич, по продуктовой работе и так далее.

Очень часто у нас возникали такие проблемы:

• Бекенд всегда реализовывал API новых фич первым. И даже если были договоренности на старте, они могли быть неполными или ошибочными. В результате клиентские платформы вынуждены были подстраиваться, либо ждать, пока бекенд доделает требуемое в следующем спринте.
• Команды стеснялись обращаться друг к другу, часто возникала проблема противопоставления «мы-они», хотя ребята работали над общим продуктом.
• Команды клиентских платформ реализовывали различные решения, т.к. делали это в разное время. То есть частенько изобретали велосипед, не получая знаний от тех, кто уже делал эту задачу.
• Time to market в целом по фиче на всех платформах растягивался на многие месяцы.
• Скорость работы по новым фичам снижалась, так как постоянно оставались определенные хвосты по старым задачам.

После очередного обсуждения на тему «вы опять там с API накосячили», мы решили сделать кросс-функциональные команды или фича-тимы.
Команда кросс-функциональна, если в команде есть все компетенции, чтобы реализовать фичу на всех клиентских платформах разом. При этом крайне важно, чтобы члены такой команды физически сидели вместе, в одном кабинете. Желательно, чтобы в такой команде было побольше T-shaped людей, которые прокачаны в чем-то одном, но могут и готовы помогать своим товарищам на других направлениях.

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

На небольшой ретроспективе после пары месяцев работы кросс-функциональной команды ребята сами отметили следующие плюсы:

• Коммуникации стали существенно короче. Достаточно повернуть голову в сторону коллеги и договориться сразу. Раньше такого обсуждения могло и не возникать, были недосказанности.
• Ребята стали развиваться в смежных областях. Кто-то в тестировании, кто-то в бэкенде, кто-то в авто-тестах.
• API по новым фичам согласовывалось одновременно всеми платформами и на старте фич.
• Существенно упростилась и ускорилась отладка проблем. Мобильному разработчику и бэкендеру достаточно совместно воспроизвести проблему и изучить логи.
• Тестирование начинается раньше: когда есть пусть и не до конца готовая задача, ее можно тестировать одновременно как со стороны API, так и со стороны клиентского приложения.
• Команда фокусируется на задаче, улучшается погружение в контекст, так как все занимаются одной задачей.
• Оказалось, что нужно меньше митингов, и остается больше времени на работу.
• Ребята стали предлагать кроссплатформенные решения, что стало экономить время. Например, кроссплатформенный эмулятор API.
• У членов команды уравниваются знания о продукте и знание различных нюансов работы.
• Унифицируются решения. Если раньше даже iOS и Android команды могли делать фичу по-разному, то теперь перестали изобретать велосипеды.
• Сократился time to market фичи: на все 3 клиентские платформы функционал выходит одновременно (почти).
• Возрос командный дух и мотивация команды.
• Ребята поняли, что оказывается нужно учиться договариваться об общих решениях (например, об API), а не перепихивать проблему на другую команду.

Не обошлось и без минусов:

• Периодически возникают перекосы по загрузке членов фича-тимы. Например, фронтенд может делать фичу в разы быстрее бэкенда. В условиях, когда фронтендер не готов (или пока не готов) переквалифицироваться в тестировщика или бекендера, он вынужден брать другие задачи из бэклога.
• Меньше связь с компонентными командами в рамках своей компетенции. Раньше архитектурные решения на какой-то одной платформе обсуждались сразу. Теперь необходимы отдельные воркшопы для таких задач.
• Необходимость быть T-shaped замедляет сотрудников на первых порах. Требуется время, чтобы разобраться в смежных компетенциях.

Что мы также отметили, поработав в концепции фича-тимов?

• Прежде всего это, что не все сотрудники готовы к такого рода работе: много договариваться, быть T-shaped. Надеюсь это временная проблема.
• Также осталась необходимость в компонентных командах (пусть и в меньших составах), которые отвечают за «корневые» архитектурные решения на платформе, финальную интеграцию, а также решают задачи, не требующие зависимости от других платформ.
• Необходим так называемый «налог на бэклог». Это когда фича-тима делает не только фичи, но и до 20% времени уделяет прочим небольшим улучшениям и багофиксу. Такая практика необходима, чтобы у фича-тимов не возникало соблазна делать задачи «спустя рукава», если они будут уверены, что их ошибки им не вернутся. Это также необходимо, чтобы решение багов не было уделом или повинностью компонентных команд.
• Чтобы не отрываться от других команд и работать на общее дело, члены фича-тимов продолжают участвовать в перекрестном ревью кода, в проработке долгосрочных архитектурных решений, в регрессе приложений перед выпуском, в наполнении базы автотестов.

Теперь я ни за что не откажусь от работы с кросс-функциональными командами. Они доказали и продолжают доказывать свою эффективность. Если вы работаете только с компонентными командами, советую вам пересмотреть свой подход. Посмотрите еще в сторону примеров от Spotify.

Фото pixabay.com

Распределенные команды VS работа из офиса

Уже много историй рассказано про распределенные команды и компании, которые работают без офисов. Подобные команды и компании бывают как небольшими (5-10 человек), так и очень огромными. Современная тенденция на увеличение их числа. Во многих источниках публикуется в основном успешный опыт их применения.


Плюсы распределенной работы очевидны:

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

Однако работа удаленно добавляет и минусов:

• люди, незнакомые друг с другом лично, склонны относиться друг к другу настороженно, если не сказать враждебно. В случае команд в разных локациях возникает проблема “мы-они”. Команды могут враждовать, перепихивая вину за ошибки друг на друга.
• возникают мискоммуникации и недосказанности, информация не транслируется или транслируется с искажениями.
• разница в часовых поясах может добавлять времени в решении каких-то проблем: один человек уже сегодня не работает, а другой не может решить проблему без него.
• излишние ожидания: другая сторона может не понимать приоритетности задачи, поэтому задача отправляется в очередь и не решается здесь и сейчас.
• работа с коллегами из разных стран должна учитывать культурные различия сотрудников.
• сотрудники склонны планировать официальные встречи, чем договариваться по ситуации.

Современные способы коммуникации можно разделить по возрастанию эффективности следующим образом: электронная почта -> чат -> голосовые сообщения -> телефонный звонок -> видеозвонок -> личное общение -> личное общение возле доски.

Знакома ситуация, когда специалисты переписываются в чате, даже находясь в соседних комнатах? И не могут договориться.

Да, за последнее время стали появляться вполне себе вменяемые инструменты, которые облегчают совместную работу удаленно. Например Slack или Trello. Однако ценность личного общения не стоит недооценивать. Оно на порядок ускоряет решение любых задач.

Как же все таки поступать с командами?

В первую очередь желательно не допускать распределенности. Команда, которая физически работает в одной комнате, достигает гораздо большего, чем команда распределенная. В моей практике была ситуация, когда распределенная команда никак не могла обеспечить стабильность программного продукта - все специалисты решали свои локальные задачи, но не общую. В результате смена распределенной команды на вдвое меньшую офисную команду помогла добиться стабильности сервиса, а объем выпускаемого результата существенно возрос.

Что же делать, если команда все таки распределенная?

Существует несколько способов, как улучшить взаимодействие такой команды:

• Личное знакомство и личные встречи. Коллеги должны знать друг друга лично и периодически встречаться лично на нейтральной территории или в офисе одной из команд. Личный контакт помогает снимать барьеры общения уже после, когда работа продолжается удаленно. Личное общение особенно ценно на старте проекта.
• Ежедневные встречи по видео-связи помогают поддерживать “мордальный” контакт в команде.
• Тематические групповые чаты по задачам команды.
• Для командообразования: общий чат-болталка и регулярные личные неформальные встречи в баре или на природе, общие мероприятия.
• “Окно в другой офис”: постоянный канал видео-связи с другим офисом, что создает эффект присутствия другой команды рядом.
• Общая электронная Kanban доска задач.
• Общие ретроспективы и планирование работы лично или по видео-связи.

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

Фото pixabay.com

Как я сдавал экзамены PSM и SPS

Замечательный ресурс scrum.org позволяет проходить сертификацию на звание Professional Scrum Master (доступно 3 ступени) и Scaled Professional Scrum - специалист по масштабируемуму скраму. Ниже я расскажу как собственно подготовиться к этим экзаменам.

Сразу оговорюсь, что для сдачи экзамена не обязательно проходить какое-либо формальное обучение. Достаточно иметь представление о предметной области, а также опыт работы в проектных командах по Scrum.

Лично мне подготовка к экзаменам позволила упорядочить знания и многолетний опыт работы со Scrum. А наличие бейджей дало приятные бонусы в общении с командами. 

Professional Scrum Master (PSM)

Экзамен Professional Scrum Master проверяет ваши знания Scrum с точки зрения Scrum-мастера. Экзамен длится 60 минут, в течение которых вам потребуется ответить на 80 вопросов. Проходным баллом считается 85% правильных ответов. Таким образом минимум на 68 вопросов нужно ответить правильно.

Чтобы сдать экзамен на PSM I (первая ступень), необходимо следующее:

1. Детально, вдоль и поперек изучить Scrum Guide. Так как экзамен проходит на английском, то и Scrum Guide желательно изучать на английском.
2. Прочесть глоссарий Scrum, чтобы понимать терминологию
3. Прочесть как можно больше литературы по Scrum. Лично я рекомендую книгу, которая в pdf опубликована на Хабре. Книга очень легкая, со множеством картинок. Читается за пару вечеров. Дополнительно рекомендую изучить официальный форум Scrum.org.
4. Несколько раз потренироваться на официальном бесплатном опроснике. Добейтесь того, чтобы 2-3 раза подряд у вас было 100% правильных ответов. Каждый раз изучайте почему тот или иной ответ оказался неверным.
5. Можно дополнительно потренироваться на этом бесплатном опроснике. В нем представлены вопросы в несколько иной плоскости, что также полезно.
6. Зарегистрироваться на scrum.org и оплатить экзамен. Экзамен стоит $150. В ответ вам пришлют одноразовый бессрочный код. То есть у вас будет всего одна попытка, которой вы можете не пользоваться сколько угодно долго.
7. Так как экзамен проходит заочно, во время тестирования вы можете пользоваться любой литературой. Однако не стоит особо на нее рассчитывать, поскольку у вас будет всего по 45 секунд на вопрос.
8. Как только экзамен будет успешно сдан, вы получите поздравительное электро-письмо, а также увидите в своем аккаунте бейджик со сданного экзамена. На этот бейджик можно сослаться, например, в резюме или профессиональных сообществах.

Scaled Professional Scrum (SPS)

Экзамен Scaled Professional Scrum (SPS) проверяет ваши знания и опыт работы по Scrum с несколькими командами. В основу экзамена положен фреймворк Nexus, который описывает работу нескольких команд над одним бэклогом и одним продуктом. Экзамен длится также 60 минут, однако в отличие от PSM I потребуется ответить на 40 вопросов. Проходной балл по-прежнему 85%, поэтому необходимо ответить правильно минимум на 34 вопроса.

Чтобы сдать экзамен SPS, необходимо следующее:

1. Детально изучить Nexus Guide, а также повторить Scrum Guide, глоссарий Scrum и Professional Scrum Developer Glossary
2. Изучить полезные ресурсы по масштабируемуму Scrum: Scaling Scrum with Nexus,  SPS and Nexus – The Definitive Guide. Дополнительно рекомендую изучить официальный форум Scrum.org - там вы найдете много полезной информации, которая отсутствует в Nexus Guide.
3. Несколько раз потренироваться на официальном бесплатном опроснике. Добейтесь того, чтобы 2-3 раза подряд у вас было 100% правильных ответов. Каждый раз изучайте почему тот или иной ответ оказался неверным.
4. Рекомендую также потренироваться на следующих дополнительных опросниках:
1. Опросник в блоге Михаила Лапшина
2. Опросник в блоге The Scrum Master
3. Дополнительный опросник от Кена Швабера, который я нашел в его блоге.
5. Зарегистрироваться на scrum.org и оплатить экзамен. Экзамен стоит $250. В ответ вам пришлют одноразовый бессрочный код. То есть у вас будет всего одна попытка, которой вы можете не пользоваться сколько угодно долго.
6. Так как экзамен проходит заочно, во время тестирования вы можете пользоваться любой литературой. Однако не стоит особо на нее рассчитывать, поскольку у вас будет всего по 1,5 минуты на вопрос. Опросник предполагает множество вопросов на понимание различных ситуаций, с которыми вы столкнетесь, работая с несколькими командами одновременно.
7. Как только экзамен будет успешно сдан, вы получите поздравительное электро-письмо, а также увидите в своем аккаунте бейджик со сданного экзамена. На этот бейджик можно сослаться, например, в резюме или профессиональных сообществах.

Желаю вам удачи в сдаче экзаменов!

Кстати мои бейджи находятся здесь: https://www.scrum.org/user/280417.

Как узнавать про новые задачи в Jira

Если вы участвуете в крупном проекте или одновременно в нескольких проектах, то рано или поздно возникает необходимость вовремя узнавать о новых задачах и багах, которые создают ваши коллеги. Это в равной степени полезно как руководителю проекта, team lead-у, так и всем участникам команды.

Зачем оперативно узнавать о новых задачах:

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

Я рекомендую всем участникам проектных команд отслеживать изменения бэклога в ежедневном режиме, чтобы области ответственности пересекались. Благо, что даже на крупных проектах это не занимает много времени. По опыту своих проектов могу сказать, что команда из 70+ сотрудников на интенсивном, живом проекте создает примерно 50+ задач ежедневно. Ознакомление с ними занимает примерно 30-40 минут.

В своей работе я использую Jira от Atlassian. Это очень удобный баг/таск рекер. Jira имеет обширные инструменты для настройки email-уведомлений:

• Если вы Team Lead проекта, вам автоматически будут приходить уведомления по факту создания нового тикета. Это не всем подходит, т.к. team lead у проекта может быть только один.
• Если вы Component Lead, то есть отвечаете только за часть проекта, вы будете узнавать о тикетах, назначенных на этот компонент. Также неудобно, что и в предыдущем пункте
• Можно попросить администратора Jira создать Notification Scheme в вашем проекте, чтобы отправлять уведомления определенным членам команды или группам. Например, по факту создания тикета. Если что-то захочется поменять в Notification Scheme, придется снова обращаться к администратору

Для себя я выбрал более простой и индивидуальный способ узнавать о “новинках” - подписки на фильтры. Подписки можно настраивать самостоятельно, без администратора и независимо от вашей роли в проекте. Этот способ хорош еще и тем, что позволяет получать уведомления с нужной вам периодичностью и сразу по всем нужным проектам. Для меня оптимальна периодичность - раз в сутки.

1. Перейдите в меню Issues -> Search for Issues.

Отобразится серия фильтров, которые можно использовать, чтобы уточнить ваш запрос.

2. Я использую JQL для поиска, но можно воспользоваться и Basic фильтрами.

Чтобы при помощи JQL найти задачи, созданные за последние 24 часа (от текущего времени), нужно ввести такой запрос: "project = “Ваш проект” AND created >=-1d".

Или для нескольких проектов: "project in (“Ваш проект 1”, “Ваш проект 2”, “Ваш проект 3”) AND created >=-1d".

3. Далее необходимо сохранить ваш запрос под каким-нибудь именем (кнопка Save As)

4. Нажав на ссылку Details, кликните на “New subscription”

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

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

6. Вуаля. Подписка настроена.

Вам будут приходить письма примерно такого вида

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

Такой способ работы с задачами действительно удобен. Он не отнимает много времени, но позволяет быть в курсе новых задач на проекте. Попробуйте, рекомендую!

Фото заголовка pixabay.com

Команда и области ответственности

Периодически слышу реплики типа “Все же взрослые люди, должны понимать, что нужно делать!”, “Он знает что эта задача важна, почему он ее не сделал/сделал не так/не вовремя/подставьте свой вариант”. Такие реплики - про командную работу. Мы часто ждем каких-то определенных действий от своих коллег. Либо не ждем, а находимся в своем уютном мирке и не хотим выглядывать за его пределы. Коллеги при этом могут даже не догадываться, что от них что-то требуется.

Эту ситуацию очень четко характеризует известный анекдот:

Идут стрельбы. Дали автоматы, патроны, показали куда стрелять. Админ отстрелялся, подводят итоги. Мишень админа чистая.

Командир: - ?.

Админ, проверяя автомат: - С моей стороны пули вылетели. Проблемы у вас.

Или вот был у меня еще случай: один разработчик пометил задачу как сделанную и оставил в ней комментарий другому разработчику доделать что-то. Второй не увидел комментарий. В результате на продакшене мы получили серьезную проблему.

Говоря и делая подобное, люди подразумевают, что все за пределами их собственной области ответственности делается как-то само и автоматически. Разработал задачу - ее как-то протестируют. Протестировал фичу - ее как-то передадут пользователям. В конце концов, зачем нам нужны процессы и различные системы автоматизации, правда же? И зачем нужны все эти менеджеры, которые должны передавать информацию и координировать задачи?

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

Какие ключевые слова приходят вам в голову, когда вы думаете про командную работу? Лично мне такие: гребем в одной лодке, взаимовыручка, единство, синергия, общий результат.

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

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

Сделал свою часть Java-кода? Отлично! Теперь убедись пожалуйста, что разработчик БД провел все нужные оптимизации на базе.

Протестировал фичу и нашел кучу ошибок? Хорошо! Теперь совместно с разработчиком пойми, какие из них наиболее критичные, и убедись, что разработчик принялся их исправлять.

Понимаешь, что не успеваешь к сроку? Ладно. Позови РМ-а и вместе с ним пойми, что правильнее будет сделать следующим шагом.

Отмечу, что не всякий член команды принимает то, что в его область ответственности забирается его коллега. Это может восприниматься как излишний контроль. В таком случае на нескольких успешно выполненных задачах убедитесь, что человек “тащит” их вовремя и с нужным качеством, и “подставляйте корзинку для результатов”. Другая крайность, если коллега и не принимает других в свою область ответственности, и не выполняет свои задачи хорошо. Задумайтесь: а так ли нужен вам этот член команды в таком случае.

Вы спросите почему вы должны выполнять работу за кого-то другого и разделять чужую ответственность? Но это не выполнение работы другого. Это сопровождение задачи до тех пор, пока не будет получен финальный результат. Так правильно поступать потому, что это ускоряет решение задачи, позволяет довести их до конца и сводит к минимуму ошибки в коммуникациях и в работе. Так правильно поступать также потому, что вам не все равно по поводу общего результата. Верно же? А иначе зачем вообще ввязываться в проект и работать в команде?

Фото pixabay.com

Человек-катализатор

Замечали ли вы, что в некоторых коллективах работается как-то легче, чем в других? А какие-то команды более сплоченные, чем другие.

Сегодня поговорим про человека-катализатора. Это не что-то из области прикладной химии. Впрочем и про химию тоже. Про химию человеческих взаимоотношений.

Как известно из школьного курса, катализатор ускоряет химическую реакцию. Ускорение происходит как в положительную сторону (образуется новое вещество), так и в отрицательную (происходит неожиданный взрыв).

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

Мне не все равно, у меня есть цель

Я встречал разные команды на своем пути: большие и маленькие, однородные по квалификации и разношерстные. Всегда было то, в чем они похожи: ни одна команда не ставила себе целью работать плохо или навредить. Все члены команды считали, что они работают эффективно и с полной самоотдачей.

Однако у одних команд получалось выдавать результат хорошо, а у других хуже. Не секрет, что любой член ИТ-команды может работать от 1го до 5ти раз производительнее в зависимости от условий и обстоятельств на проекте. И любому заказчику и менеджеру конечно же хочется, чтобы команда всегда работала с максимальным ускорением.