• Большая подборка полезных ресурсов для продакт-менеджеров

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

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



      Избранное


      Название Почему стоит читать
      Good product manager, Bad Product Manager, Ben Horowitz Классическое эссе о продуктовом образе мышления. Читать для вдохновения.
      Лидерство
      Be a great product leader Ещё одно классическое эссе о лидерстве и ответственности продуктовых менеджеров.
      Лидерство
      Intercom on Product Management Исчерпывающая книга о продуктовом подходе от Intercom.
      Стратегия, практика
      SaaS metrics 2.0 — A guide to measuring and improving what matters Обстоятельная статья о самых важных SaaS-метриках.
      SaaS, метрики, рост
      Дао продакт-менеджера в Profi.ru + Чек-лист образовательного контента для PM от IT-Agency Хорошая подборка ресурсов о знаниях и навыках продакт-менеджера.
      Список

      Читать дальше →
    • Наш подход к раскраске потоков

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

        Сейчас у нас 47 000 пользователей ежедневно, около 30 серверов в production, 2 000 API запросов в секунду и ежедневные релизы. Сервис Miro развивается с 2011 года, и в текущей реализации пользовательские запросы обрабатываются параллельно кластером разнородных серверов.


        Читать дальше →
        • +13
        • 2,6k
        • 2
      • Эволюция кластерного взаимодействия. Как мы внедряли ActiveMQ и Hazelcast

          В течение последних 7 лет я вместе с командой занимаюсь поддержкой и развитием ядра продукта Miro (экс-RealtimeBoard): клиент-серверным и кластерным взаимодействием, работой с базой данных.

          У нас Java с разными библиотеками на борту. Запускается всё вне контейнера, через Maven-плагин. В основе — платформа наших партнёров, которая позволяет работать с базой данных и потоками, управлять клиент-серверным взаимодействием и т.д. БД — Redis и PostgreSQL (мой коллега написал о том, как мы переезжаем с одной БД на другую).

          С точки зрения бизнес-логики приложение содержит:

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

          В 2011 году, когда мы только начинали, весь Miro находился на одном сервере. На нём было всё: Nginx, на котором крутился php для сайта, Java-приложение и базы данных.

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

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



          Дальше расскажу о сложностях, с которыми мы столкнулись при развитии кластеров и масштабировании Java-приложения и инфраструктуры.
          Читать дальше →
        • О важных “невидимых" вещах — доверии, культуре и ценностях

          Я — Head of Product в Miro (экс-RealtimeBoard). Я люблю дерзкие цели и постоянно думаю о том, где нас ждут новые горизонты, как улучшить результаты, как завтра стать лучше, чем мы были вчера. И ещё я много думаю о том, насколько важна в этом увлекательном путешествии команда. Мы много внимания уделяем тому, чтобы все в команде понимали цели компании, стратегию и наш прогресс в их достижении.

          “Если хочешь идти быстро — иди один, если хочешь дойти далеко — идите вместе”. Говорят, это африканская пословица.



          Сейчас популярно внедрять OKRs (Objectives and Key Results), KPI и прочие методы повышения эффективности. Иногда оказывается, что эти фреймворки не работают или требуют много микроменеджмента и становятся больше pain in the ass, чем реальным помощником в достижении результата.

          На конференциях мне часто задают вопросы о том, как правильно делать OKRs, как это работает у нас в Miro и просят «покажи табличку» с OKRs. Как правило, табличкой это, конечно же, не решается.
          Читать дальше →
          • +18
          • 2,8k
          • 2
        • Как мы мигрировали базу данных из Redis и Riak KV в PostgreSQL. Часть 1: процесс

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



            Долгое время основной базой данных в Miro (экс-RealtimeBoard) был Redis. Мы хранили в нём всю основную информацию: данные о пользователях, аккаунтах, досках и т.д. Всё работало быстро, но мы столкнулись с рядом проблем.

            Проблемы с Redis

            1. Зависимость от сетевой задержки. Сейчас в нашем облаке она составляет порядка 20 мск, но при её увеличении приложение начнёт работать очень медленно.
            2. Отсутствие индексов, которые нужны нам на уровне бизнес-логики. Их самостоятельная реализация может усложнить бизнес-логику и привести к неконсистентности данных.
            3. Сложность кода также усложняет обеспечение консистентности данных.
            4. Ресурсоёмкость запросов с выборками.

            Эти проблемы вместе с ростом количества данных на серверах послужили причиной для миграции БД.
            Читать дальше →
          • Невидимый деплой монолитного приложения в продакшн на AWS. Личный опыт

            Я – Lead DevOps Engineer в Miro (экс-RealtimeBoard). Поделюсь тем, как наша DevOps-команда решила проблему ежедневных серверных релизов монолитного stateful-приложения и сделала их автоматическими, невидимыми для пользователей и удобными для собственных разработчиков.

            Наша инфраструктура


            Наша команда разработки — это 60 человек, которые делятся на Scrum-команды, среди которых есть и команда DevOps. Большинство Scrum-команд поддерживают текущую функциональность продукта и придумывают новые фичи. Задача DevOps — создавать и поддерживать инфраструктуру, которая помогает приложению работать быстро и надёжно и позволяет командам быстро доставлять новый функционал до пользователей.

            Читать дальше →
            • +16
            • 3,4k
            • 4
          • Реализация SSO через SAML с примером

            Введение


            Доброго времени суток, дорогой читатель. Я уже давно хотел написать статью на хабре и вот наконец-то этот момент настал. Из последних тем, которыми я занимался и о которых мне есть что рассказать — это была реализация SSO для сервиса realtimeboard.com — замечательный продукт для совместной работы удаленной команды в одном месте, который хочется постоянно развивать и совершенствовать. Хочу здесь сразу уточнить, что в принципе SSO через Facebook и Google уже было в сервисе до моего прихода. Моей же задачей было реализовать его через протокол SAML.


            SSO (Single Sign-On), — технология единого входа пользователей, благодаря которой владея одной лишь учетной записью пользователь может посещать множество различных сервисов.


            SAML — это популярный XML-протокол для реализации SSO. Как правило большие организации (enterprise) используют именно его, как проверенный и надежный вариант.


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

            Читать дальше →
            • +11
            • 18,6k
            • 6

          Самое читаемое