Принципы работы одной ИТ-компании, ориентированной на лидерство продукта

Частое «нет», стабильная команда и амбициозные цели.

Каждый по-своему выбирает магический поворотный момент, чтобы бросить курить, пойти на йогу или начать жить, работать, смотреть на вещи по-новому. Для кого-то это Новый год, а для кого-то следующий понедельник (и каждую неделю новый).

Мы подготовили этот лонгрид, чтобы поделиться принципами, которые мы используем во flespi, показать, как они помогают нам делать «нужные» вещи (и не делать ненужные), и дать вам повод задуматься: «А не попробовать ли что-то из этого с понедельника?».

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

Давайте сразу разберёмся с нашей бизнес-стратегией, поскольку она в значительной мере определяет применимость последующих тезисов. Мы фокусируемся на лидерстве продукта (product leadership), что для нас подразумевает создание передовых технологий, их непрерывное совершенствование и обучение лучшим практикам их использования.

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

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

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

• Статичность. В нашей команде нет открытых вакансий уже более года и не предвидится в ближайший год. Это значит, что все сотрудники работают в команде достаточно долго, чтобы разобраться во всех тонкостях продукта, стать независимыми и «заражёнными». В качестве побочного эффекта имеем меньшую необходимость во внутренней документации, поскольку все уже знакомы со стандартными процессами и процедурами. Мы ни в коем случае не говорим, что доки не важны, просто при интенсивной разработке в «режиме стартапа» возможность делать меньше чего-либо — это дар божий.
  
• Многофункциональность. Однонаправленная работа в рамках одного проекта в течение нескольких лет сделает вас экспертом, но может вдобавок погасить огонь в глазах и сдержать раскрытие потенциала. Поэтому в команде мы придерживаемся принципов спецназа — смена ролей, регулярные вызовы себе, выход из зоны комфорта и разноплановые задачи. Например, Ян, наш разработчик, выступает на конференциях, ведёт переговоры на выставках, пишет статьи, участвует в продажах и поддержке. Но всё-таки в первую очередь он разработчик.
  
  Конечно, степень многофункциональности разнится в зависимости от задач, личностных качеств и требований проекта. Тем не менее все мы в той или иной степени поддерживаем эту концепцию — это позволяет расширить профессиональные горизонты и почувствовать себя в шкуре своих коллег.

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

• Модерация с точки зрения архитектуры. В голубом океане, на просторах которого мы плывём, легко сойти с курса, будучи завлечёнными наядами-искусительницами («гениальными идеями»). Мы должны быть предельно бдительны, чтобы не терять ориентиры из виду. К счастью, у нас есть опытный дозорный (архитектор платформы, менеджер проекта, визионер, разработчик, называйте как хотите — это всё он). Как человек, создавший концепцию всей платформы flespi и видящий полную картину в мельчайших деталях, он рассматривает каждую предлагаемую идею, фичу или сущность через призму архитектуры платформы, чтобы увидеть, «ложится» она туда или нет. Даже очень важная фича, предложенная клиентом или членом команды, будет отклонена, если она потребует «костылей» или «заплаток» к существующим процессам или расшатает существующий «скелет» продукта. Однако это ни в коем случае не означает, что мы не прислушиваемся к запросам пользователей (смотри следующий пункт).
• Проактивное придумывание фич. Мы прислушиваемся. Но мы тщательно соотносим каждый запрос с ключевыми архитектурными принципами — то, что наши клиенты сделать не могут. Пользователь хочет достичь определённой цели; то, как мы поможем ему достигнуть этой цели, не важно для него, но важно для нас. Зачастую мы кристаллизуем желание клиента из беседы или переписки прежде, чем оно явно озвучивается самим клиентом. И если мы видим ценность и потенциал данной фичи, мы внесем её в план разработки.
• Не боимся менять. Не всегда получается всё сделать правильно (с первого раза). Цитируя Rag’n’bone Man, «мы же всего лишь люди». Иногда мы осознаём, что сделали что-то неправильно или неоптимально. Но мы никогда с этим не миримся и не игнорируем — мы исправляем. Даже если это ведёт к эффекту домино по всему проекту. Мы хотим быть честными перед собой и нашими пользователями, делая всё возможное для обеспечения наилучшей производительности. Никаких компромиссов в этом вопросе.
• Динамические приоритеты. Как многие ИТ-компании, мы разрабатываем продукт по итерациям и приоритезируем задачи. Однако мы позволяем приоритетам меняться. Исправления ошибок и другие срочные критические задачи всегда попадают в начало списка, независимо от плана. В зависимости от спроса или связанных тикетов некоторые задачи могут становиться более важными и получать высший приоритет. Другие могут быть переосмыслены и в результате понизиться в связи со сложившейся ситуацией.
• Утилизация тухлых задач. Некоторые тикеты могут мигрировать из одной итерации в другую. Если это повторяется достаточно долго (6-12 месяцев), мы просто от них избавляемся как от ненужных (и никогда не жалеем об этом). Эта практика помогает разработчикам лучше оценивать их фронт работ — не 200 разношёрстных тикетов, а 20 конкретных и нужных.
• Пятничные посиделки. В пятницу после обеда мы все садимся в нашей уютной переговорке и мило беседуем два-три часа. Каждый член команды проходится по всем ключевым задачам, над которыми он трудился на неделе, отвечает на возникающие вопросы, советуется с коллегами по спорным моментам и обозначает планы на следующую неделю. Этот отличный способ синхронизировать всю команду и обменяться мнениями.
  

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

• Отсутствие мануала. Это, наверное, не совсем то, что вы ожидали увидеть, но мы реально оцениваем наши ресурсы и чётко понимаем, что поддержка мануала в актуальном состоянии для такого динамичного проекта была бы пыткой. Поэтому мы пошли другим путём.
• Живой блог. Мы пишем одну или две статьи в неделю. Стабильно. Мы пишем о разном — от глубоко технических лонгридов до более практических how-tos по интеграции и работе с оборудованием и до обзорных маркетинговых и бизнес-материалов.
• База знаний. Это детальный путеводитель для наших пользователей, с помощью которого они могу постичь теоретические основы платформы, найти пошаговые инструкции для решения конкретных задач и узнать о наиболее эффективных способах отладки. Новые материалы для базы знаний готовятся на основании вопросов пользователей, на которые нам надоедает писать однотипные ответы.
• Тесная взаимосвязь. Страницы нашего коммерческого сайта, материалы базы знаний и статьи блога густо перелинкованы, чтобы пользователь беспрепятственно перемещался по сайтам по интересующей его теме.
• Open-source-проекты. Мы — коммерческая компания, но мы любим делиться технологиями, идеями и разработками с сообществом. Для этого мы делаем некоторые наши библиотеки и вспомогательные инструменты публично доступными на GitHub. Так мы хотим завоевать доверие разработчиков, интересующихся платформой flespi, показывая им некоторые её внутренности и давая возможность адаптировать их под свои нужды.

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

• Часть работы разработчика. У нас в команде нет отдельных тестировщиков. Разработчики сами отвечают за тестирование фич, над которыми работают.
• Последовательное покрытие тестами. Как только разработка фичи окончена, она должна быть полностью покрыта автоматическим тестами. Этим занимается разработчик данной фичи, поскольку именно он лучше всех знает особенности и возможные варианты её использования.
• Проверка статуса платформы. Это комплексный тест работоспособности всей платформы, выполняющийся каждую минуту. Так мы убеждаемся в доступности всех сервисов и корректной работе всех функций. Если что-то пошло не так, тест публикует сообщение «downtime started» в наш Telegram-канал SRE (в который может вступить любой пользователь); затем тест перезапускается каждые десять секунд и сообщает «downtime ended» при удачном завершении.
  
  После детального анализа каждой ситуации мы публикуем подробное объяснение по каждому случаю с указанием причины и шагов, которые мы предприняли, чтобы не допустить подобное в дальнейшем. Мы убеждены, что прозрачность и признание ошибок — залог долгосрочного успеха компании.

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

• Онлайн-чат. Мы сделали его сами и добавили только ту функциональность, которая нужна именно нам (например, быстрый доступ к учётной записи и логам пользователя). Клиенты видят чат прямо в панели администрирования flespi (там, где они проводят большую часть времени). Время первого ответа на запрос клиента в наше рабочее время исчисляется секундами.
  
  Этот инструмент в разы удобнее электронной почты, в первую очередь потому, что он интегрирован в сам продукт, по которому задаются вопросы, и клиентам не нужно переключаться между вкладками, чтобы начать общение с нами.
• Больше внимания сложным вопросам. Похоже на дискриминацию? Возможно. Но мы разрабатываем высокотехнологичный продукт, а не приложение с волшебной кнопкой «Сделать мне хорошо». flespi — это набор инструментов для разработчиков, поэтому мы не можем учить основам. Во-первых, у нас нет на это человеческих ресурсов, а во-вторых, наш опыт показывает, что такие пользователи редко задерживаются надолго, поэтому усилия неоправданны.
• Говорить «нет». Этот пункт связан с предыдущим — мы не делаем ничего за пользователей, мы учим их делать всё самостоятельно. Это один из наших ключевых принципов работы. Мы убеждены, что когда человек следует инструкциям, он лучше усвоит информацию и изучит матчасть, чем если мы предоставим ему готовое решение. Да, им может быть сложно, но в следующий раз они станут более подкованными клиентами, и уровень их вопросов повысится.
  
  Мы много работаем на тем, чтобы сделать процесс самопомощи более гибким и интуитивным — с помощью подсказок, наращиваемой базы знаний, обучающих видео, пошаговых инструкций и чек-листов.
  
  Мы любим своих клиентов. Но любовь проявляется не через трепетное стремление оградить от любого дискомфорта, а через желание научить справляться со сложностями.

flespi — это PaaS-решение, распространяемое по месячной подписке. Вот некоторые особенности ведения бизнеса.

• Онлайн-присутствие. Наша целевая аудитория — это в основном технические специалисты, поэтому мы делаем ставку на digital для создания узнаваемого бренда и имиджа эксперта в телематическом сообществе. Мы также присутствуем со стендом на главных отраслевых мероприятиях, таких как GITEX, MWCA, CEBIT, и так далее, чтобы заявить о себе, поговорить с потенциальными клиентами и показать, что мы надёжные и «осязаемые» бизнес-партнёры.

• Фильтр клиентов. Можете называть нас переборчивыми. Когда плохо клиенту и плохо нам — это неудачный вариант сотрудничества. Первый фильтр — языковой. Быть опытным разработчиком в мире, где большая часть мануалов и статей написана на английском, невозможно без уверенного владения этим языком. Все наши сайты и материалы представлены на английском языке, и мы ожидаем, что это не доставит неудобств пользователю.
  
  Второй фильтр — экспертность (смотри пункт «Больше внимания сложным вопросам» выше). Мы уверены, что можем дать больше опытным специалистам в отрасли. Мы рады направить новичков на путь истинный, но в основном ссылками на наши статьи и внешние ресурсы.
• Никакого давления. Мы не используем никаких «продажных» методик, чтобы дожать клиента и продать продукт. Наоборот, мы всячески стараемся убедиться, что мы нужны и максимально подходим друг другу (каждый раз как жену выбираем). Если flespi — это не то, что ему нужно, однажды он будет разочарован, начнёт жаловаться или требовать «индивидуального подхода», поскольку переход с flespi на другую платформу практически исключён. Мы стараемся избегать подобных ситуаций любой ценой.
  
  Наша цель как экспертов в отрасли — помочь клиенту найти наилучшее решение, даже если это означает посоветовать продукт конкурента.
• Цена не обсуждается. Условия использования платформы явно прописаны на нашем сайте и едины для всех. Так мы избегаем утомительных переговоров. Если пользователь не осознаёт, как flespi может помочь сэкономить тысячи, возможно, flespi ему и не нужна.
• Автоматизация. Мы автоматизируем все повторяющиеся процессы в компании — блокировка, откат до бесплатной версии и апгрейд пользовательских аккаунтов, выставление счетов, напоминания об оплате и другие — чтобы исключить человеческую ошибку и сэкономить время.
• Мы платим комиссии. Сейчас мы принимаем платежи только через PayPal и покрываем все комиссии за обслуживание для наших клиентов. Потому что мы знаем, как неприятно платить $110 за услугу стоимостью $100. Мы уважаем наших клиентов и хотим, чтобы они платили ровно столько, сколько указано на нашей странице с ценами.

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

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