О компании

Создаем решения, а не функции

Примавера – продуктовая компания, основанная в Санкт-Петербурге. Мы создаем собственные IT-решения для бизнеса, а также помогаем партнерам развивать совместные продукты.

Cтатьи о нас: 

Организация работы

В плане организации работы мы пробуем разные варианты и сейчас остановились на адаптированной версии Shape Up от Basecamp.

Работа строится по следующему сценарию:

Основной цикл разработки - 5 недель, которые разделяются на два периода:

    • 4 недели - блок запланированной разработки продукта
    • 1 неделя - блок свободной разработки продукта (он же блок подготовки)

Большая штука

Мы предлагаем новый рабочий термин - Большая Штука (это конкретный блок работы с общим описанием и набором конкретных задач, которые необходимо выполнить).Ах, да, еще один - Большештучная-команда (это люди, которые участвуют в реализации Большой штуки).

Запланированная разработка

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

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

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

Коммуникации

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

Созвоны

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

Свободная разработка и подготовка

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

Но это "свободная неделя разработки", а не свободная неделя компании =)

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

Разработка

Разработка строится от визуальной составляющей к реализации АПИ.

  • Идея
  • Дизайн
  • Верстка
  • Проектирование АПИ. Принимает участие вся команда. Результатом должен быть swagger файл со спецификацией.
  • Реализация фронтенда
  • Реализация бекенда

Мини релиз и оценка результата

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

Ключевые аспекты работы

Три наших главных принципа:

  1. Говорить и воспринимать правду.
  2. Не делать лишней работы самому и не давать делать другим.
  3. Стремиться к доверию в коллективе, учиться доверять людям.

Принятие решений

Команда самостоятельно принимает решения по разработке. От участников команды ожидается проактивность, активное предложение идей/улучшений для обсуждения. Для принятия решения необходимо привлекать все требуемые средства: устраивать созвоны и мини-хакатоны, реализовывать прототипы для проверки идеи. Также каждая команда самостоятельно управляет своим составом.

Таск-трекинг

При необходимости рекомендуется вести список конкретных задач (например, актуально для бэка). Задача должна быть понятной и проверяемой. Не допускаются абстрактные действия.Каждый участник команды решает самостоятельно, какие задачи брать в работу, основываясь на запросах от других участников команды. Каждый участник может поставить другому любую задачу. Роль ответственного за все задачи в команде отсутствует. Каждый несёт ответственность за весь проект целиком. Участник команды должен чётко формулировать свою задачу и иметь возможность простым языков объяснить её, а другие участники должны иметь возможность проверить её исполнение.

Документация к продукту

Участники команды должны знать продукт, и план его развития. Для продукта создаётся презентация, в которой указаны:

  • Описание продукта
  • Его внешний вид (дизайн, макеты)
  • Интеграции с другими продуктами
  • Road-map разработки
  • Видео с презентацией продукта команде (опционально)

Для каждого проекта необходимо описание в файле README.md:

  • Описание проекта
  • Описание сущностей, с которыми взаимодействует проект
  • Ссылки на доп. документацию (API, таск-трекер и т.д.)
  • Пошаговая инструкция для запуска

Для описания АПИ используется swagger.Swagger файл должен быть размещён в репозитории проекта.

Методология

Набор методик для обеспечения качества и масштабируемости:

  • используем только stable версии библиотек;
  • пишем только интеграционные тесты АПИ;
  • для каждого проекта реализуем механизм автоматического резервного копирования;
  • заранее планируем механизмы резервирования на случай отказа оборудования или используемых интеграций с внешними системами;
  • команда должна понимать, как в экстренной ситуации помочь другому участнику команды, отсутствует понятие зоны только своей ответственности.

Коммуникация

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

  • тему/план дискуссии
  • точки приложения усилий после созвона, если есть (кто, что, когда делает и т.д.)
  • резюме(выводы) дискуссии(достигли понимания в том-то, приняли решение такое-то и т.д.)

Эта информация должна быть публичной и общедоступной.

Мини-хакатоны и парное программирование

Не всегда однозначно понятно, сработает то или иное решение или нет. Для этого можно устраивать небольшие хакатоны (когда вся команда фокусируется на определенной задаче), на несколько дней, которые помогут выработать решение proof of concept. В ходе этих хакатонов можно также опробовать новые технологии и понять, насколько они интересны и продуктивны. Как дополнительный бонус, профессиональная встряска обеспечена!Зачастую в ходе работы требуется поддержка коллег в ключе свежего взгляда на текущее положение дел.Иногда текущего анализа кода коллег недостаточно, чтобы выйти на успешное понимание той или иной проблемы.В этом может помочь парное программирование, которое помимо прочего, вносит свежий взгляд на решение той или иной проблемы, с которой столкнулся ваш коллега.Взаимопомощь поможет всем двигаться быстрее.

Вакансии
Нет вакансий
У компании нет открытых вакансий
Оценка компании сотрудниками
4.64
Средняя оценка
89%
Средняя рекомендация
10 сотрудников дали оценку
5 оставили комментарии
Оценка в деталях
Откуда приходят в компанию
GroupM
1 сотрудник
Social Quantum
1 сотрудник
Аллока
1 сотрудник
The Boston Consulting Group
1 сотрудник
В какие компании уходят
CRON
1 сотрудник
Spar-online
1 сотрудник
FutureComes Family
1 сотрудник
Progress Engine
1 сотрудник
AGIMA
1 сотрудник