Тег #продуктовая сбросить

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

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

Продукт/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. Да, эта фраза родилась из шутки, невзначай брошенной для подбадривания коллектива в определённый момент, но она нашла намного больше отклика у сотрудников и стала их девизом.

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

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

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

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

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

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

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

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