О компании

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

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

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

  • Установка макро-дедлайна

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

  • Расписание роадмапа до дедлайна или на 2-3 месяца

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

Еженедельные итерации/созвоны

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

План созвона:

  • Презентация/тестирование функционала, запланированного на прошлой неделе;
  • Команда выбирает что будет реализовывать на новой неделе.

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

  • Приоритетное закрытие задач от которых зависит реализация командой функционала к концу недели;
  • Занятие соло-долгосрочными задачами по архитектуре и рефакторингу.

Планирование

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

Ежедневные рабочие сессии в скайпе

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

P.S. Участник команды должен сам быть активен в получении необходимой ему информации. Если информацию не дают - надо напоминать, звонить пока не дадут.

Разработка

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

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

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

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

Финальное тестирование и релиз на прод

За пару недель до дедлайна весь функционал должен быть разработан и выложен на stage/dev. В этот момент вся команда в широком смысле слова подключается к тестированию. 

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

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

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

Для принятия решения необходимо привлекать все требуемые средства: устраивать созвоны и мини-хакатоны, реализовывать прототипы для проверки идеи.

Также команда самостоятельно управляет своим составом.

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

При необходимости рекомендуется вести список конкретных задач (например актуально для бэка).

Задача должна быть понятной и проверяемой. Не допускаются абстрактные действия.

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

Каждый участник может поставить другому любую задачу. Роль ответственного за все задачи в команде отсутсвует. Каждый несёт ответственность за весь проект целиком.

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

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

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

Для продукта создаётся презентация, в которой указаны:

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

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

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

Для описания АПИ используется swagger.

Swagger файл должен быть размещён в репозитории проекта.

Методология

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

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

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

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

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

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

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

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

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

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

Зачастую в ходе работы требуется поддержка коллег в ключе свежего взгляда на текущее положение дел.

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

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

Взаимопомощь поможет всем двигаться быстрее.

Оценка компании сотрудниками
4.8
Средняя оценка
96%
Средняя рекомендация
11 сотрудников дали оценку
6 оставили комментарии
Оценка в деталях
Откуда приходят в компанию
Travelab
1 сотрудник
Викимарт
1 сотрудник
Аллока
1 сотрудник
iDecide
1 сотрудник
В какие компании уходят
Информация отсутствует