Тег #команда сбросить

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

Роли в продуктовой команде

Продукт/Product Owner — создаёт новые идеи для продукта, чтобы решать проблемы пользователя или увеличить прибыль продукта/компании.

Очень важно: всегда должен общаться с командой в формате: «У пользователя есть проблема, мы решаем проблему пользователя, мы помогаем пользователю достигнуть...».

Руководитель проекта/Delivery manager/IT Project manager — организует процессы работы в команде, отвечает за сроки и порядок выполнения фич, контролирует доставку фич до прода (пользователя). Работает и транслирует команде принятую методологию. Выполняет функции *Scrum-master*'а, но влияет на команду, работает с ней, а не просто «фасилитирует и передвигает карточки».

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

Аналитик/System analyst — раскладывает бизнес-требования на текущее поведение системы, систематизирует и структурирует требования. Проектирует решение.

Очень важно: чтобы проектирование решения было не в отрыве от команды. Решение всегда лучше проектируется всей командой, потому что один человек не может удержать все нюансы продукта в голове.

Дизайнер/UI|UX designer — отвечает за визуальное отображение и удобство функционала для пользователя. Работает с прототипами, собирает фидбэк от пользователя и думает над улучшениями.

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

Бекендер/Backender — отвечает за основную логику продукта, за его бизнес-поведение, скорость работы и отказоустойчивость.

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

Фронтендер/Frontender — отвечает за реализацию UI. «Переносит макеты в код :)». Созданные компоненты должны быть легко переиспользованы. Создаёт логику работы с бэкендом.

Очень важно: ревью дизайна через призму наличия компонентов в дизайн-системе и создания новых. Упрощать фантазию дизайна в зависимости от сроков задачи, не давать плодить компоненты-«одиночки». Диктует бэкенду контракты взаимодействия.

Тестировщик/QA — отвечает за качество в продуктовой команде, а это значит отвечает и влияет почти на всё. Ревью идей на оценке, ревью требований аналитики, ревью дизайнов. Ревью тест-кейсов (если у вас больше одного тестировщика). Разбирает проблемы с прода, воспроизводит их, что помогает быстрее разработке найти источник проблемы.

Очень важно: QA всегда должен быть заточен на то, что он является двигателем команды к качеству. Да, хк, хк и продакшен бывает часто, но указать, что нужно запланировать рефакторинг тех или иных моментов. Завести баги, с которыми можно выйти в прод, но не забыть, что их нужно исправить. Ревью всего в команде делает QA отличным источником знаний, особенно в случаях: «Как это работает, судя по коду не должно вообще работать».

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

Проще было пойти в бар в пятницу с коллегами, поиграть в кикер или настольные игры. Общения хватало в различных форматах. А что говорить про те моменты, когда вы в офисе до 2 часов ночи тушите прод — это было шикарное время, которое дало мне много друзей.

Переход на удалённую работу

Сейчас, в эру удалённой работы, встроить нового человека в слаженный коллектив очень сложно. Ещё сложнее из группы людей сформировать и воспитать команду. И тут, на мой взгляд, помогает культура внутри самого IT, самой разработки.

Очень важно разделить для себя: культура компании != культура IT. Потому что культура компании — это формальность, а культура IT — это неформальные отношения, определённые грани общения, которые могут выглядеть странно со стороны, но внутри это норма.

Вы и без меня знаете, о чём речь: - Шутки на весь офис - Шутки в курилке - Когда техподдержка приходит в разработку и говорит: «Ну что, смертники, фикс выдаём сегодня или на выходных отдыхать будем?» - «Кто релизит по пятницам, тот в бар не ходит» (с) и другие примеры

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

Роль неформальной культуры в коммуникации

Как-то в процессе работы я постоянно пытался донести свои мысли о том, как будет развиваться наша IT-команда, куда мы идём и как важен вклад каждого. Слова, слова... почему опять лозунги? Терпеть не могу лозунги. И каждый раз, когда представлял изменения в процессах, меня не покидало ощущение, что отклика мало — возможно, сотрудники видят только лозунги и не верят, что станет лучше и проще.

А эти действия казались мне лозунгами, потому что в голове они не сильно мапились на неформальную культуру, которую я создал в параллель, сам того не осознавая.

Когда ты руководитель, ты хочешь прийти и сказать: «Вот наш путь», но в глазах видишь вопрос: «Круто, а что сейчас-то делать?» И вроде бы ты рассказываешь, что делать дальше, как меняется ежедневная работа, а огня не хватает, отклик какой-то слабый.

Мы что-то обсуждали в очередной раз, какую-то проблему, и один мой коллега процитировал меня: «Получается: Красиво делай, некрасиво не делай». Вот оно! Это был внутренний девиз моего IT. Да, эта фраза родилась из шутки, невзначай брошенной для подбадривания коллектива в определённый момент, но она нашла намного больше отклика у сотрудников и стала их девизом.

Значение внутреннего девиза

«Красиво делай, некрасиво не делай» — как будто цитата из пацанского паблика, но блин, так просто и лаконично доносится сама суть. Нужно делать свою работу так, чтобы она тебе нравилась, чтобы тебе нравился не только результат, но ещё и сам процесс работы. И чтобы работа твоих коллег тебе тоже нравилась, а значит — не будь безучастным, участвуй и в их работе тоже.

Повествование моё на аудиторию изменилось тем, что в конце, когда я спрашивал мнение у моих коллег, друзей и единомышленников, я стал спрашивать: «Ну как, красиво будет?», а в ответ получал: «Да» или «Выглядит красиво, надо пробовать», «По сути вкусно». Маленькое изменение только для общих встреч, но насколько жизнь стала проще.

Этот девиз имеет не только словесные значения — коллектив знает и чувствует, что требования, которые выдвигаются для них: «Делайте красиво», я так же предъявляю и к себе в первую очередь. Мы все равны перед нашей неформальной культурой, и если кто-то начинает выбиваться из неё — его пытаются вернуть, либо он нас покидает, это нормально.

Практические выводы

Очень важно понимать внутреннюю неформальную культуру своего подразделения — и куда проще вам будет доносить информацию, даже рабочую и сложную, если она будет подаваться на ней. Если её нет, вам нужно её создать, но не искусственно, а просто: - Больше вместе работать - Решать какие-то задачи на созвоне, болтая на фоне - Устраивать командные мероприятия

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

Сейчас любой директор нашей компании может прийти в разработку и спросить: «Как у вас дела, как вы живёте в своей разработке?», ответом последует единогласное: «Живём по правилу: Красиво делай, некрасиво не делай».

Игра "теннисные шары" не имеет другого классного названия, потому что я не смог придумать :)

Цели игры

Игра направлена на развитие следующих навыков:

• Синхронизацию команды

• Мелкую моторику :)

• Выработку стратегии

• Подстройку (надстройку) стратегии под изменяющиеся обстоятельства

• Сплочение команды

• Выявление лидера

• Умение подстраиваться под команду

• Выявление конфликтов

• Умение работать в неопределённости

• Умение работать в конфликтных ситуациях

Суть и правила

Команда из 5 или более человек располагается за столом. Четырём игрокам выдается по 2 белых теннисных шара, пятому игроку выдаются 1 белый и 1 оранжевый шар.

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

Основные запреты:

• У игрока не может быть одновременно 3 шара

• На столе не должно быть шаров без движения

Фазы игры

Игра состоит из 5 фаз, каждая фаза усложняет правила и требует пересмотра и адаптации стратегии команды. На каждую фазу даётся от 5-10 минут, в зависимости от того, как команда справляется. Если на 5-ой фазе команда оказалась в тупике — игра останавливается.

1. Фаза-1: шары розданы, задача — перемещая шары сделать так, чтобы оранжевый шар сделал круг. 2. Фаза-2: запрещено держать шары в руках, можно только катать по столу. 3. Фаза-3: нельзя принимать шары от игрока справа. 4. Фаза-4: оранжевый шар должен перемещаться через одного. - Усложнение перед фазой-5: команде выдается ещё 2 оранжевых шара. 5. Фаза-5: если у тебя оранжевый шар, или ты только что катнул оранжевый шар, принимать оранжевый шар.

Вопросы для рефлексии

После игры команде задаются следующие вопросы:

1. Что понравилось, что не понравилось, какие ощущения от игры?

2. Что получалось легко, а что было сложно?

3. Почему не получилось, почему получилось?

4. Были ли проблемы при обсуждении стратегии?

5. Легко ли было договариваться?

6. Что вы чувствовали, когда видели, как ваш коллега ошибался?

7. На каком этапе удалось максимально синхронизироваться?

У игры есть победная стратегия, но я её вам не расскажу :)

Рекомендую к просмотру тем, кто работает над выстраиванием процессов в команде или компании.

Почему стоит посмотреть

Потому что в фильме главные герои берут на вооружение сомнительную систему, в которую верят только они. Преимущество данного подхода: метрики, расчеты, по сути — данные. Основываясь на данных, они принимают решения.

Основные моменты системы

Система долгое время не работает по различным причинам, хочу выделить основные для себя:

• Сопротивление со стороны скаутов и тренеров — в вашей работе это ваши коллеги и начальство.

• Переходный этап очень сложный сам по себе и в основном тянется на энтузиастах и их энергии.

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

• Умение вести переговоры и торг — сцена, где происходит торг с 2 командами и владельцем клуба — высший пилотаж переговоров, когда ты хочешь получить необходимые тебе элементы системы для победы (результата). В моей карьере при формировании команды часто приходится вести такие переговоры.

Дополнительные уроки

• Напарник очень важен — даже обсуждать идеи вслух с кем-то, а не только с собой, даёт другое мнение либо подтверждение вашего.

• Ограниченный бюджет — все стартапы проходят через это, когда хочется "выиграть лигу", а у тебя денег на команду. "Есть богатые команды, есть бедные, потом 50 м г...а, а затем мы." (с) по сравнению с другими.

Спойлерить, чем закончится фильм, я не буду, приятного просмотра :)

https://youtu.be/N7NOcxG0Ekg

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

Начальный этап

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

Переход к автоматизации

С ростом сложности продуктов и увеличением частоты обновлений возникла необходимость в автоматизации тестирования. Это позволило: - Ускорить процесс проверки регрессий. - Снизить нагрузку на ручное тестирование. - Повысить стабильность выпускаемых версий.

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

Интеграция в процессы разработки

Следующим этапом стала интеграция тестирования в цикл разработки (CI/CD). Тестировщики начали работать в тесном взаимодействии с разработчиками с ранних стадий проекта, что способствовало: - Раннему выявлению дефектов. - Сокращению времени на исправление ошибок. - Формированию культуры качества во всей команде.

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

Современные тенденции

В настоящее время тестирование в Kaspersky эволюционирует в сторону использования искусственного интеллекта и машинного обучения для: - Предсказания потенциальных проблем. - Оптимизации тестовых сценариев. - Анализа больших объёмов данных о качестве.

Такие инновации позволяют командам адаптироваться к быстро меняющемуся рынку и повышать эффективность процессов.

Значение для продуктов

Эволюция тестирования напрямую влияет на качество и надёжность продуктов Kaspersky, обеспечивая безопасность для пользователей в условиях растущих киберугроз. Постоянное совершенствование подходов помогает компании сохранять лидирующие позиции в индустрии.

Подробнее об этом можно узнать в видео: https://youtu.be/j5u_sv_Uzrk

Никита Дубко из Яндекса предлагает рассматривать роль руководителя через призму «Мастера D&D» — ведущего настольной ролевой игры Dungeons & Dragons.

Суть подхода

В этой аналогии руководитель не просто отдаёт приказы, а создаёт для команды интересный и вовлекающий контекст, подобно тому, как Мастер D&D готовит мир, сюжет и вызовы для игроков.

Ключевые принципы

• Создание среды для действий: Задача лидера — предоставить команде необходимые ресурсы, чёткие правила игры (процессы) и понятные цели, а затем дать свободу в выборе способов их достижения.

• Фокус на вовлечении: Как и хороший Мастер, руководитель должен следить, чтобы каждый участник команды был вовлечён в процесс, находил в работе что-то интересное для себя и чувствовал свой вклад в общий результат.

• Гибкость и адаптивность: План, как и сценарий игры, может меняться по ходу дела. Важно уметь гибко реагировать на новые обстоятельства и идеи команды, поддерживая динамику и интерес.

Практическое применение

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

[Видео](https://www.youtube.com/embed/uE6F4_pxU9o)

О чём видео

В видео Александр Зиза и Вирна Штерн из Aletheia Digital обсуждают ключевые аспекты планирования командной работы. Они делятся практическими подходами и инструментами, которые помогают организовать эффективное взаимодействие в команде.

Основные темы

• Цели и приоритеты: как ставить чёткие цели и определять приоритеты задач для всей команды.

• Коммуникация и процессы: важность налаженных коммуникационных каналов и рабочих процессов для избежания недопонимания.

• Инструменты и технологии: обзор полезных инструментов, которые упрощают планирование и отслеживание прогресса.

• Адаптация и гибкость: почему командам нужно оставаться гибкими и адаптировать планы под меняющиеся условия.

Ключевые выводы

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

Ссылка на видео: https://www.youtube.com/watch?v=NKHgLrpWKqQ

О чём видео

В новом выпуске подкаста «Один результат на две команды» гостями стали Вирна Штерн и Александр Зиза из Aletheia Digital. Они обсуждают ключевые аспекты взаимодействия между командами в проектах.

Основные темы обсуждения

• Совместная работа — как достигать общих целей при разных подходах.

• Коммуникация — важность прозрачности и регулярных встреч.

• Результаты — измерение эффективности и адаптация процессов.

Видео доступно по ссылке: https://youtu.be/Fscbq8UrXZo.

Вирна Штерн и Александр Зиза из Aletheia Digital обсуждают стратегии ведения переговоров, когда вы находитесь в слабой позиции. В этом видео они делятся практическими советами, которые могут помочь достичь желаемого результата даже при неравных условиях.

Ключевые принципы

• Подготовка и анализ: тщательно изучите интересы другой стороны и свои собственные цели. Это поможет найти точки соприкосновения и возможные уступки.

• Создание ценности: сосредоточьтесь не только на цене, но и на других аспектах, которые могут быть важны для оппонента, например, сроки, качество или дополнительные услуги.

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

Практические шаги

1. Определите свои BATNA (*Best Alternative to a Negotiated Agreement* — наилучшая альтернатива обсуждаемому соглашению). Знание ваших вариантов вне переговоров придаст уверенности.

2. Задавайте открытые вопросы, чтобы лучше понять потребности другой стороны и выявить скрытые возможности.

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

Эксперты подчеркивают, что даже в слабой позиции можно добиться успеха, если подходить к переговорам стратегически и творчески. Видео доступно по ссылке: https://youtu.be/agT9jtpuxaA

В видео Алексей Пименов (RealResult) делится своим взглядом на рабочий процесс как на процесс накопления знаний, а не просто выполнение задач.

Суть подхода

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

Практические аспекты

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

• Анализ ошибок: неудачи стоит рассматривать как ценный источник информации для будущих улучшений.

• Создание базы знаний: накопленный опыт следует структурировать в доступные материалы, которые можно использовать повторно.

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

Значение для специалистов

Для менеджеров и разработчиков это означает переход от реактивного режима "тушения пожаров" к проактивному построению систем, которые предотвращают проблемы. Видео доступно по ссылке: https://youtu.be/ux4Gl234qMk