Закон и право

Решение: разработать лучшие интеграции для малого и среднего бизнеса. Слабые места Trello

30.06.2019

Свой социальный редактор «Антихайп».

В закладки

Часть первая. Максимально понятная

Год назад мы поняли, что нас не устраивает ситуация с социальными сетями. Это очень больно - писать текст «подводок» в трёх разных интерфейсах, в Facebook, «ВКонтакте» и Twitter, делать отложенные публикации, следить за тем, чтобы записи не «каннибализировали» друг друга. Например, в случае с Facebook и его «умной» лентой охват одного сообщения может сильно упасть, если другое было опубликовано в то же время.

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

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

Пока не было идеи, мы пробовали сторонние сервисы. Этим летом, например, подключили сервис, который через пару недель тестирования случайно опубликовал нашу запись в Twitter «Дождя». В итоге мы от него отказались. Но это заставило нас ускориться.

У нашего бэкенд-разработчика и заместителя технического директора Бори Горячева появилась идея. Так как мы все в «Медузе» в большей или меньшей степени фанаты Trello, то решили своровать идею доски и немного подкрутить её под наши нужды. Фронтенд-разработчик Никита Комарков придумал название для редактора - «Антихайп».

Итак, каждый столбец - платформа, например, группа во «ВКонтакте». У каждого столбца есть таймер: 5, 10, 30, 60, 120 минут. В зависимости от новостного потока и платформы редактор выбирает нужный ему таймер.

Много новостей - 30 минут в Facebook, 10 минут в Twitter. Выходные - по часу везде. Каждая платформа может быть независимо от другой очищена, если произошло очень важное событие, и вся редакция работает по одной теме. Каждая платформа может встать на паузу - удобно, когда в спокойном режиме хочется собрать публикаций на ночь.

Каждая карточка или сниппет - это статус и ссылка на материал. Также динамическое время публикации, которое рассчитывается в зависимости от таймера платформы, даты последней публикации и количества сниппетов, стоящих перед этой карточкой.

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

Любой редактор материала может написать статус для своего материала сам в редакторе материала. И тогда при заведении статьи в столбец «Антихайпа» там сразу появится уже написанный статус.

Так выглядит редактирование сниппета:

Так это работает:

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

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

Так это выглядит:

Отдельная важная вещь - публикация видеоматериалов, которых на «Медузе» становится всё больше и больше. Раньше видеоотдел публиковал все ролики руками во все социальные сети - это очень трудоёмкий процесс. Иногда публикация одного видео может занять до 40 минут. Мы это исправили, причем исправили одновременно с запуском «Антихайпа».

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

Видео у нас много, а через «Антихайп» сейчас можно публиковать только материалы. При этом «Антихайп» не знает о том, что опубликовано, например, в Facebook напрямую. И если бы видеоредакторы продолжили выкладывать по пять видео в день по старинке, очередь в «Антихайпе» не соответствовала бы реальности.

Поэтому мы сделали редактор видео. Выглядит он так:

Видео загружается в «Монитор», так называется наша админка, который на его основе создаёт непубличное видео в YouTube. Если такой материал вывесить через «Антихайп» в Facebook или «ВКонтакте», в социальной сети появится не ссылка на материал, а само видео. Это крайне упрощённое описание видеоредактора. На самом деле при разработке мы столкнулись с полным адом, каждая из поддерживаемых нами соцсетей работает с видео не так, как другие. Нет, правда, это ад.

Аналитика

Мы стараемся максимально подробно измерять то, откуда читают «Медузу». Интересно, какая часть трафика из соцсетей приходит через сообщения в наших официальных аккаунтах, а какая - через собственные записи читателей.

Впечатления редакции

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

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

С «Антихайпом» всё это стало намного проще: ты передвигаешь карточку с нужным материалом выше или ниже в очереди, а система сама пересчитывает время выхода и публикует, когда нужно. Никакой возни с таймерами и расчетами, на какое время какой материал нужно запланировать.

В теории мы могли воспользоваться каким-то сторонним решением, но безусловное преимущество «Антихайпа» - тесная интеграция с «Монитором». Система видит даже материалы, которых нет на сайте, но которые были созданы специально для соцсетей. Ну и список платформ мы контролируем сами: не нужен LinkedIn - нет LinkedIn, понадобился Telegram - добавили Telegram.

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

Часть вторая. Боря рассказывает, как это устроено внутри

У нас есть приложение, в котором редакторы пишут материалы, формируют главную страницу и вообще работают. Это приложение называется «Монитор», можно почитать про него подробнее. Этому проекту уже три года, он написан на Ruby on Rails. Когда я думал о том, как писать «Антихайп», то понял, что у меня нет никого желания писать его на Ruby.

Поймите меня правильно: Ruby on Rails - отличная штука, но такие вещи, как параллельная работа, отложенные вычисления и что, наверное, самое важное, вебсокеты - не самые ее сильные стороны. Да, я в курсе про action cable, но что-то не хочется. И так как мы любим микросервисы, я решил, что пусть это будет elixir и phoenix framework. Я решил, что:

  • Пусть этот сервис работает с той же базой данных, что и «Монитор».
  • Пусть у него будет один эндпоинт для вебсокет-соединения.
  • Пусть его фронтенд будет в коде «Монитора» (react).
  • Пусть он будет запускаться отдельно от «Монитора». Деплой «Монитора» не влияет на работу «Антихайпа». В итоге «Антихайп», с точки зрения фронтенда, - один адрес для wss-соединения.

Модели

Конечно, встал вопрос: где делать миграции? База-то одна. Я выбрал Rails, тут нет какого-то плюса или минуса. Просто это показалось проще. На стороне phoenix есть два контекста - Monitor и Social. Monitor ответственен за те части, которые нужны из основного приложения: это схема post, таблица, в которой лежат все материалы «Монитора», и user, пользователи «Монитора». Social-контекст состоит из двух схем - platform и snippet.

Platform выглядит так

Так - Snippet:

Сниппеты упорядочены по ord, имеют статусы - pending, sent, deleted, sending. Они принадлежат пользователю (id редактора, который последним редактировал сниппет) и у них есть body, текст сообщения, которое уйдёт в социальную сеть. Ссылка на материал забирается из Monitor.Post.

Еще у сниппета есть meta - это JSON, в который, в зависимости от того, куда отправляется сниппет, пишется идентификатор от социальной сети и ссылка на публикацию в сети.

Таймеры

Наверное, самая сложная часть этого проекта - процессы, которые занимаются отправкой сообщений в нужное время. В erlang и elixir есть всё для того, чтобы делать такое малой кровью.

Когда приложение запускается, помимо эндпоинта для вебсокетов должны стартовать процессы, которые будут брать первый сниппет в очереди, отправлять его и запоминать новый таймер. Это, в свою очередь, означает, что нужен способ найти процесс и отправить в него сообщение. В elixir есть модуль ровно для этого. В application.ex делаем такое:

Registry это а local, decentralized and scalable key-value process storage. Эта штука позволяет обращаться к процессам не по Pid, а по имени. Так как этот проект не будет запускаться на нескольких нодах, registry - это то, что нам нужно. Сам Registy под капотом представляет из себя процесс, который хранит ключ, в нашем случае - id платформы и value: process id erlang-процесса, который занимается отправкой.

Сразу за registry запускаем супервайзер Poster. Из важного там:

При старте этого супервайзера он запускает процессы PosterProc, передавая им параметры для старта.

PosterProc умеет запуститься, когда платформа на паузе или нет, а также когда сервис перезапустился спустя какое-то время после последней отправки.

Для этого я считаю diff, и первая отправка с момента перезапуска «Антихайпа» будет совпадать с тем, что хранится в базе. convert_minutes - это просто функция, которая приводит минуты к миллисекундам. Самое интересное происходит в schedule_work.

При каждом вызове handle_info:work, args происходит вызов Process.send_after, он планирует следующую отправку. Каждый раз, когда это происходит, я запоминаю pid, который возвращает send_after, чтобы иметь возможность найти этот процесс и убить его, если вдруг редактор поставит платформу на паузу или поменял интервал у платформы. В итоге PosterProc всегда хранит в себе следующий стейт:

  • таймер - как часто шлем сообщения (в милисекундах),
  • pid процесса, который в итоге попробует отправить сообщение,
  • id - айди платформы, чтобы по нему найти следующий для отправки сниппет,
  • paused (true или false) - стоит ли этот процесс сейчас на паузе.

Чтобы контролировать процесс снаружи, есть три функции:

Функции pause, unpause и update_timer могут вызываться из процесса сокета, когда редактор меняет статус платформы. Они находят pid PosterProc’а по id из Registry и вызывают соответствующий handle_call.

Когда PosterProc все-таки доходит до момента, когда пора что-то отправить, он вызывает функцию Poster.post(platform_id). В ней происходит поиск первого сниппета в очереди платформы, и он пытается отправится:

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

Фронтенд

Мы любим react и redux. Объект, с которым работает фронтенд, выглядит примерно так:

Такая форма представления стейта очень удобна, так как любой action просто делает deep merge . То есть не важно, что именно происходит внутри бекэнда, он может в любой момент времени прислать сообщение с частью этого объекта, и эта часть просто вольётся внутрь, и всё перерендерится.

Например, сниппет отправляется. Можно было бы сделать логику на фронтенде - сделать таймер, который после изменения стейта сниппета со status: pending на status: sending ждет пять секунд и скрывает. В нашем случае бекэнд просто сначала отправляет { snippets: { 1: {status: sending }}} и через пять секунд асинхронно присылает { snippets: { 1: {status: sent }}} или что-то другое. Как показала практика, такие вещи куда проще делать на бекэнде, чем на фронте.

Для дрег-энд-дропа мы используем react-dnd. При дреге мы хотели менять атрибут только одно сниппета. React-dnd даёт большее количество средств для понимания что происходит в какой момент времени. Задача свелась к тому, чтобы найти два сниппета, между которыми встанет новый, и сделать новый ord, который равен (ord2 - ord1) / 2 (По этой причине ord - float). В итоге при любых манипуляциях со сниппетами мы посылаем один update c новым ord.

Постскриптум

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

В заметке я вкратце упоминал о новом виде отображения списков Планировщика под названием “Карточки” — теперь наступило время рассказать о нем поподробнее.

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

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

Вкратце: суть сервиса в том, что вы можете создавать доски (boards), на которых расположены карточки (cards). Карточки располагаются не хаотично, а в вертикальных столбцах — списках (lists). Trello позволяет создавать карточки и перетаскивать их между списками.

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

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


На всякий случай скажу, что эту «доску» под названием «Работа над задачами» сделал я сам. Как видите, я добавил в нее 3 списка: “Новые”, “В работе” и “Выполненные”. В крайнем правом столбце находится служебная информация о пользователях, подключенных к данной доске, а также лог происходящих в ней событий.

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

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

Теперь давайте посмотрим, как с аналогичными задачами справляется ПланФикс.

Похожих вещей у Trello и Планировщика ПланФикса достаточно много:

  • в Trello доска — в ПланФиксе планировщик
  • в Trello список — в ПланФиксе… тоже список
  • в Trello карточка — в ПланФиксе задача

Вот как выглядит планировщик “Работа над задачами”, который я специально сделал по содержанию таким же, как в примере с Trello:

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

Например, списки. Если в Trello список не содержит ничего, кроме названия, то в ПланФиксе список представляет собой фильтр, который управляет отбором и отображением задач. Давайте для примера посмотрим, как устроен список “В работе” — кликнем на его названии и увидим окошко с параметрами списка:


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


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


Еще один важнейший момент: как и в Trello, в ПланФиксе карточки-задачи можно перемещать из одного списка планировщика в другой. Но, в отличие от Trello, ПланФикс при этом меняет параметры перемещаемой задачи. Например, если переместить задачу из списка “В работе” в список “Выполненные”, ее статус изменится на “Выполненная” — и останется таким, вне зависимости от того, в каком интерфейсе системы вы будете просматривать эту задачу:


Почему задача в моем примере поменяла свой статус, а не исполнителя, к примеру? Потому, что попадая в список, задача меняет свои параметры на те, по которым отбираются задачи в этот список — а в списке «Выполненные» у нас стоит единственное условие «Статус задачи = Выполненная».

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

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

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

Ну а тех, кому этого недостаточно, мы рады приветствовать в ПланФиксе 🙂

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

С чем сейчас работает руководитель проекта? Какие инструменты использует, чтобы планировать, собирать данные, контролировать ситуацию, готовить отчеты?

Чаще всего это MS Project, Excel и почта. Прекрасные средства, я и сам очень долго ограничивался ими. Но на большом проекте, особенно в распределенной команде, работать становится труднее. Слишком много телодвижений нужно совершить, чтобы поставить задачи, собрать статус по ним, откорректировать план и дать обратную связь.

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

  • Asana
  • Trello
  • SmartSheet
  • Мегаплан
  • Clarizen
Вообще, программ для управления задачами настолько много, что перебирая и пробуя их, до выполнения задач можно и не добраться. Надеюсь, эта статья сократит вам путь к тому приложению, которое будет именно для вас.

Эдвард Деминг проводил на своих семинарах следующую демонстрацию. Сначала он просил своих слушателей, часто очень опытных управленцев, перечислить известные им методы мотивации и честно записывал их.
Затем вызывал одного из зала, завязывал ему глаза, подводил его к миске в которой были белые и красные шарики, и предлагал выбрать десять красных, не снимая повязки. Естественно, у человека не получалось.
Тогда он начинал применять разные способы мотивации по списку:
-Материальная мотивация! Я дам тебе 10 долларов, если ты выберешь только красные шарики!
-Отрицательная материальная мотивация! Я оштрафую тебя на 10 долларов, если ты выберешь хоть один белый шарик!
-Эмоциональная мотивация! Джонни, я верю в тебя, ты крутой парень! Я знаю, ты выберешь только красные шарики! Друзья, давайте хором: «Джонни! Джонни! Ты крутой! Ты справишься!»
-Карьерная мотивация! Я уговорю твоего начальника повысить тебя по службе, если ты выберешь только красные шарики!
-Мотивация отпуском! Я разрешу тебе уйти домой раньше, если ты выберешь только красные шарики!
Все равно шарики не выбирались. Этой демонстрацией Деминг хотел сказать, что без технологии, без инструментов, вслепую невозможно добиться успеха, независимо от того насколько умен и мотивирован сотрудник.

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

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

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

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

Asana

Один из проектов Google, а ныне разрабатываемая отдельной компанией Asana лаконична, в начальном варианте бесплатна, проста и удобна. Задумана как средство организации работы и коммуникации команды.

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

Статусов у задачи по большому счету два - Открыта и Завершена. Когда мы пользовались Asana, пришлось договариваться, что означает Завершена - исполнитель считает, что он закончил работу, или руководитель согласен, что задача действительно выполнена? Часто эти мнения расходятся, и возможны варианты. Мы решили, что исполнитель закрывает задачу, когда закончил работу над ней, а руководитель может ее переоткрыть с комментариями, если он считает, что стоит еще над ней поработать. Для большого количества задач и большой команды, это, конечно, очень ненадежно.

Выводы

В качестве персонального планировщика и таск-трекера небольшой команды - прекрасное средство! Простой интерфейс и бесплатный вариант использования облегчают запуск. Развитые средства коммуникации позволяют отказаться от почты и эффективно общаться.

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

Возможны варианты платного использования (21-25$/месяц порциями по 5 пользователей), которые увеличивают лимиты по объему загружаемых файлов, дают больше возможностей по распределению прав доступа и управления пользователями, но меня эти дополнительные опции не заинтересовали. На мой субъективный взгляд они не релевантны - эти возможности не нужны для небольших команд, а для большой я бы Asana не использовал.

Trello

Trello - еще более простой и в каком-то смысле более красивый таск-трекер по сравнению с Asana. Использована модель доски, на которой развешиваются стикеры с задачами в нескольких колонках (Запланировано, В работе, Выполнено), как в agile командах.

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

В начальном варианте использования Trello бесплатно. В платном варианте (3.75$/месяц/пользователь) добавляются дополнительные возможности по администрированию и обеспечению безопасности и ограничению доступа.

Выводы

Использование Trello оправдано в тех же ситуациях, что и Asana. Больше подходит тем командам, которые работу по scrum. Дает более наглядную картинку о ситуации в рамках порции работ, которая умещается на одной доске, когда количество задач в этой порции исчисляется несколькими десятками.

Smartsheet

Я не использовал Smartsheet в реальной работе и тем не менее решил упомянуть это приложение (www.smartsheet.com). Причина в том, что оно цепляет с первого взгляда. Представьте себе Excel, скрещенный с MS Project и выведенный в онлайн. От Excel здесь абсолютная простота и гибкость электронных таблиц, в которых можно создать нужные вам колонки, добавить формулы, отформатировать и раскрасить клеточки.
При этом вы можете посмотреть то, что вы создали в диаграмме Гантта или в календаре, связать задачи, отслеживать исполнение.

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

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

Выводы

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

Мегаплан

Мегаплан (megaplan.ru) пошел чуть дальше, чем предыдущие приложения. Это система, претендующая на полный цикл управления, начиная с управления взаимоотношениями с клиентами и заканчивая учетом финансов. При этом создатели сохраняют предельную простоту, так необходимую для небольшого предприятия, в котором нет претензий на уникальность бизнес-процессов.

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

Структура задач в Мегплане весьма гибкая. Задача может быть сама по себе, может находиться в составе проекта, есть подзадачи, в внутри задачи есть еще «Дела» - аналог чек-листа, как и в Asana, и в Trello. Дела могут быть не только внутри задачи, но и сами по себе. Естественно, есть еще вехи.

Очень хорошо сделан ввод упомянутых Дел. В текстовой строке набираешь текст и система сама его структурирует и превращает в отметку в календаре. Например, текст «Встреча с заказчиком в субботу в 14:00» система интерпретирует как необходимость добавить в ваш календарь событие под название Встреча с заказчиком, в ближайшую субботу в 14:00". Или «Звонок послезавтра в 12:15».

Событие может быть назначено не только себе, но и другому сотруднику, если в строке пишешь имя пользователя. Тогда событие будет помещено не в ваш календарь, а календарь сотрудника. Можно тоже самое делать не с клавиатуры, а мышкой - система предлагает список на выбор: Встреча, Звонок…; Сегодня, Завтра, Послезавтра…; 8:00, 9:00…

Есть забавные вещи, которых вы не увидите в других системах. Например, в списке статусов, которые можно назначить задаче, есть «Провалить». Или по каждой задаче можно назначить бонус за своевременное выполнение и штраф за провал. И то и другое может быть в деньгах или «моралях».

У задачи есть Старт, Длительность, Финиш и Дедлайн. Можно еще поставить признак «Горит». Плановые трудозатраты по задаче пишется текстом, соответственно собрать общую трудоемкость по всем задачам ветки не удастся.
Можно связывать задачи, указывав предшествующие, и просматривать график в диаграмме Ганта.

Некоторых вещей, к которым мы привыкли в MS Project здесь нет. Например, не хватает базового плана. История по изменению задачи тоже не ведется. Поэтому сравнить, что было и что стало и по каким причина, не получится.
Понравилась помощь по системе, которая сделана для нормальных людей, а не для «айтишников». Подсказки собраны по статьям: как сделать это, как сделать то-то. Но общего справочника по функциям иногда не хватает.

Отлично работает служба поддержки. Как только регистрируешься в системе, звонит представитель поддержки продаж и предлагает свою помощь.
Стоимость системы колеблется в значительных пределах в зависимости от количеств пользователей и набора функций. Минимальная цена для 5 пользователей и варианта использования «Совместная работа» - 1450 руб/мес. Полный набор функций «Бизнес» для 5 пользователей - 3200 руб/мес. При покупке на более длительный период месяц обходится дешевле.

Выводы

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

JIRA

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

Применение JIRA для управления проектами и задачами менее распространено, чем, скажем, для управления запросами и инцидентами. Изначально JIRA была создана как баг-треккер, и в этом она очень хороша, особенно с дополнением в виде плагина Service Desk.
Но мы использовали JIRA для управления задачами на проектах. Высокоуровневый план делали в MS Project, а все текущие задачи велись в JIRA. Из высокоуровневого плана в JIRA перекочевывали вехи и ключевые задачи. Есть плагин для синхронизации с MS Project, но после тестирования, я отказался от его использования.

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

По сути JIRA очень проста. Есть запросы (issues) разных типов, которые могут означать и задачу, и ошибку, и новое требование. У запроса есть атрибуты, можно прицепить файл, связать его с другим запросом, вести по нему переписку, посмотреть историю изменений.

Что делает это приложение действительно мощным инструментом, так это Бизнес-процессы (workflow), с помощью которых отслеживается жизненный цикл запросов. При этом процесс может быть разным для разных типов запросов, разных проектов, и его можно настраивать в зависимости от свойств запроса и роли пользователя. В некоторых из компаниях JIRA используют как BPM-машину (управление бизнес-процессами), и делают на ней систему, обеспечивающую документооборот, управление договорами, согласование командировок и т.д.

Минусом для управления проектами является то, что в JIRA практически отсутствуют возможности управления сроками. Планирование сроков приходится делать вовне, в MS Project. В JIRA по оставшемуся объему работ можно оценить примерную возможность выполнения запланированных работ к определенной вехе, и для этого есть встроенные отчеты и диаграммы. Но для полноценного календарного планирования этого недостаточно.

Стоимость JIRA колеблется в широких пределах: 10$ в месяц за 10 пользователей, 300$ в месяц за 100 пользователей и до 24 000$ за сервер для корпоративного использования. Можно работать в облаке, можно ставить на собственный сервер. Плюс к основной цене прибавляются плагины, некоторых из которых крайне полезны, как уже упомянутый Service Desk, а также JIRA Agile (в прошлом GreenHopper), средства для управления разработкой и т.д.

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

Выводы

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

Минусы. Не всем нравится интерфейс, который смотрится несколько старомодно. Использование для управления проектами требует некоторого приспособления к возможностям приложения и некоторого воображения. И стоимость. Купив все необходимые плагины и связанные приложения, в итоге можете затратить в 2-3 раза больше, чем стоит сама JIRA. С другой стороны, все корпоративные приложения стоят недешево, и ценник Atlassian в этом отношении очень гуманный.

Clarizen

Израильская компания Clarizen , основанная в 2006, выпускает одноименную систему. В ней редким образом сочетается возможность управлять портфелем проектов (PPM - Portfolio Project Management) и организовать совместную работу (CWM - Collaborative Work Management). Хорошо сделанный интерфейс помогает видеть и картину по компании в целом, так и каждую задачу в отдельности.
Это приложение, пожалуй, ближе всего подходит для удовлетворению потребности и руководителя проектов, и проектной команды, и руководства компанией.

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

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

Большие возможности для кастомизации открывает возможность так называемых Custom Actions. Фактически, это подпрограммы, которые помогает автоматизировать рутинные действия, например, разбить задачу на несколько, связать их последовательно и назначить на каждую ресурс. Научиться делать новые custom actions несложно, похоже на макросы в Excel.

Для Clarizen написано некоторое количество плагинов для расширения функциональности и интеграции с другими приложениями (например с Salesforce, JIRA…). Либо можно делать собственную интеграцию с помощью веб-сервисов.

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

Минимальная стоимость пользователя - 30$/мес для варианта с некоторыми ограничениями. Серьезное использование требует уже 45$/месяц/на пользователя. А есть еще вариант 60$ для варианта без всяких ограничений и с расширенной поддержкой.

Но ни в одной системе я не видел таких возможностей для управления ресурсами! В случае, если у вас множество разнородных проектов и общий пул ресурсов, очень трудно сбалансировать эффективное использование рабочего времени и надежное планирование сроков выполнения задач. Clarizen позволяет видеть картинку в целом, и в одной форме подвигать задачи по любому из проектов, и перекинуть задачу на другого исполнителя, и назначить дополнительный ресурс на задачу. И все это с минимальным загромождением экрана и использованием drag&drop.

К сожалению автоматических процедур, которые бы облегчили подбор оптимального расписания, в системе нет, приходится двигать задачи вручную. Однако, учитывая сложность подбора оптимального графика, когда нужно учесть приоритеты задач, интересы заказчиков, квалификацию ресурсов, поправки на неопределенность и неточность исходных данных, вряд ли это может быть полностью автоматизировано. Если кто-нибудь пользовался выравниваем ресурсов в MS Project, поймут, что я имею в виду.

Выводы

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

Заключение

Все рассмотренные программы хороши для своего применения. Asana и Trello подойдут в том случае, если требуется отследить текущие задачи - поставить, проконтролировать их выполнение, организовать переписку по ним. Обе системы бесплатны, если не требуется большого объема дискового пространства и дополнительных функций администрирования.

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

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

В обзор не попало очень много достойных систем. Наверное, стоит еще упомянуть Redmine, Адванта, Comindwork, Liquidplanner, Innotas, AtTask…

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

В 2011 году Джоэл Сполски (Joel Spolsky), основатель компании Fog Creek, объявил на конференции TechCrunch Disrupt о запуске нового продукта, получившего название Trello. Он представлял собой цифровой аналог белой доски (веб- и мобильное приложение), куда вы могли помещать листочки с заметками. Вместо того чтобы перемещать такие заметки на настоящей доске, вы могли манипулировать ими в окне своего браузера.

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

И непонятно, почему в итоге Trello пришлось продать Atlassian за 425 млн. долл., когда он мог бы стать следующим SaaS-приложением стоимостью в 1 млрд долларов.

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

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

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

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

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

Почему Trello пришлось продать

В основе Trello лежит концепция «канбан-доски» (kanban board). Канбан — это система бережливого производства, которую Toyota популяризировала в 40-х годах. Основная идея заключалась в том, что каждая «карта» представляет собой изделие, деталь или инвентарь. Когда карта помещалась на доску, это означало, что что-то было физически перемещено от поставщика на территорию завода.

На практике это выглядит так:

Изначально было технически трудно воссоздать веб-аналог доски, с которой совместно могли бы работать целые коллективы. Другие SaaS-инструменты, существующие на тот момент, представляли собой большую базу данных, снабженную визуальным интерфейсом (Salesforce, к примеру). Это, по сути, создавало архитектуру, где вы структурировали данные по таким критериям, как потенциальные покупатели, клиенты или задачи.

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

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

Результат был потрясающе прост. Вы вносили изменения в доску, перетаскивая или убирая карту, и это изменение тут же транслировалось во весь мир.

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

GitHub запустил канбан-доски в сентябре 2016 года:

Asana анонсировала канбан-доски в ноябре того же года:

Airtable запустил канбан-доски в ноябре 2016:

Джастин Розенстайн (Justin Rosenstein), сооснователь Asana — главный конкурент Trello — как-то сказал: «Мы определенно даем Trello полный кредит доверия. Это, безусловно, отличный продукт, который проделал огромную работу в развитии этого новаторского видения». Но Джастин был крайне против подражания Trello: «Мы видим в Trello функцию, но не полноценный продукт».

У Trello были все шансы стать компанией стоимостью в 1 млрд. долл., если бы он был похож на приложения «системы учета».

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

Trello никогда не становилась этой «системой учета». Это была сильная визуальная метафора, которая в итоге была скопирована конкурентами. Канбан-доска перестала быть какой-то UX-новинкой, которую к тому же было нетрудно воспроизвести.

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

Trello мог бы вырасти вдвое, начав предлагать платные тарифы отдельным пользователям. Основатели могли бы адаптировать продукт под потребности малого бизнеса. Или для крупных фирм и корпораций. Любое из этих действий могло бы увеличить рыночную стоимость компании до миллиарда долларов. Рассмотрим каждую из перспектив по отдельности.

Вполне реально построить компанию, рыночная стоимость которой превысит миллиард долларов, с freemium-моделью, ориентированной на потребителей. В 2013 году сервис Dropbox был оценен в 8 млрд. долл., при доходе в 200 млн. долл. и 200 миллионах пользователей спустя 6 лет после запуска. Это случилось даже до того, как Dropbox успел запустить бизнес-тариф — прибыль компании в основном складывалась от перевода «бесплатных» пользователей на платный тариф ($10 в месяц).

Спустя три года после запуска темп роста пользователей Trello по-прежнему опережал аналогичный показатель Dropbox, достигнув отметки в 10 миллионов пользователей в 2015 году (Dropbox на тот же период имел 4 миллиона юзеров). Но для Trello было гораздо труднее перевести «бесплатных» пользователей на тариф «Trello Gold».

1. Возможность кастомизации фона доски.

2. Возможность добавлять в карту вложения весом до 250 мегабайт (в бесплатной версии этот объем ограничивался 10 Мб).

3. Стикеры и эмоджи.

Хотя эмоджи по душе многим, это недостаточное основание, чтобы платить деньги за программное обеспечение. Бесплатный план Dropbox давал 2 Гб дискового пространства. Их платный план предоставлял 1 Тб места — в 50 раз больше того, что получали пользователи бесплатно.

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

Решение: углубиться в изучение freemium-использования сервиса

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

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

  • есть ли конкурент, способный предложить то же самое — или уже предлагающий?
  • каков потенциальный доход людей, использующих приложение таким образом?

Проведя исследование вашей клиентской базы и клиентов конкурента, вы можете выделить те группы вариантов использования, демонстрирующие наивысший показатель пожизненной ценности (LTV).

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

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

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

2. Продукт Trello был не стал незаменимым для малого и среднего бизнеса

Даже без успешного продвижения на потребительском рынке Trello все еще мог стать обязательным инструментом рабочих процессов в SaaS, усилив свое присутствие на b2b-рынке. Проблема заключалась в том, что Trello никогда достаточно не позиционировал себя в качестве инструмента, полезного в рабочих процессах компаний, чтобы оправдать плату за свое использование.

Первый платный план, который был запущен Trello, — «Business Class» для предприятий малого и среднего бизнеса в 2013 году. Они установили единую для всех цену — 200 долл. в год с организации — пока не перешли к более традиционной модели ценообразования SaaS за каждого пользователя.

Тариф «Business Class» стоил каждому пользователю $10 в месяц (счет выставлялся раз в год) и давал ему доступными следующие возможности:

  • неограниченные интеграции по доскам;
  • дополнительные возможности совместной работы;
  • настройки конфиденциальности и режим «только для чтения».

Когда Дэвид Кэнсел (David Cancel), сооснователь сервиса Drift, в своей презентации отдельным слайдом отметил, как дорого обходится компании использование Trello — $1700 в год — вся команда была шокирована. Как говорит Дэвид, «есть только пара людей, использующих Trello каждый день. Между тем, однако, мы платили сумму, которая складывалась из числа людей, которые были указаны в оплачиваемом плане. Был очевиден тот разрыв между тем, сколько мы платили, и тем, какую ценность получали».

Дэвид перевел всю команду с платного тарифа на бесплатный.

В статье, напечатанной в Forbes, Майкл Прайор (Michael Pryor), CEO Trello, сказал: «Я не хочу, чтобы люди зависали в Trello по 10 часов ежедневно. Мы не продаем рекламу, поэтому нам нет смысла повышать показатель вовлекаемости, как какая-нибудь социальная сеть».

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

Но что должна была сделать Trello?

Решение: разработать лучшие интеграции для малого и среднего бизнеса

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

Представьте себе возможность открывать и закрывать вопросы Github внутри Trello. Представьте, что если бы все ваши лиды с Salesforce автоматически открывались и закрывались на досках Trello в зависимости от ваших действий в системе Salesforce. Trello мог бы стать приборной панелью, дашбордом, где отображались бы данные, получаемые от всех остальных используемых в компании инструментов — то, что было бы действительно ценно.

Вместо этого все главные функции Trello были скопированы. Отвечая на вопрос о создании доски для визуального решения вопросов, вице-президент по разработке продукта в GitHub объяснил так: «Все ожидали появление этого продукта и засыпали нас вопросами, почему у нас его нет». Так и появилась доска в GitHub.

Если вы разрабатываете горизонтальное SaaS-приложение вроде Trello, сегментируйте пользователей по интеграции:

  • какие интеграции API люди используют?
  • сколько данных поступают в продукт и сколько выходит?

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

Рынок SaaS для малого и среднего бизнеса — высоко конкурентный. И любому бизнесу сегодня довольно просто перейти с одного решения на другое. Вам либо придется маневрировать, чтобы выйти победителем из этой конкурентной гонки, либо попытать счастья на рынке enterprise-решений.

3. Trello ничего не предложили крупному бизнесу

Двигаться вверх и ориентироваться на корпоративный рынок — это отработанная модель для SaaS. Slack последовали этим путем, запустив «Enterprise Grid». Trello смогли бы поднять свою рыночную стоимость до 1 миллиарда долларов, поступив также: быстрее переключившись на корпоративный рынок.

Менее чем через год после того, как Trello начали реализовывать свою стратегию продаж, связанную с корпоративным рынком (в 2015 году), компания перешла рубеж в 10 млн. долл. по показателю ARR. В интервью вице-президент по продажам в Trello, Кристен Хабакт (Kristen Habacht), говорил, что Trello следует довольно простой стратегии расширения бизнеса на корпоративном рынке:

«Мы смотрим на те компании, чьи сотрудники уже используют Trello. Основная часть нашей стратегии исходящих продаж заключается в том, чтобы просто добраться до этих аккаунтов и сказать: «Эй, у вас более 2 000 человек на Trello? Не хотите поговорить об этом?».

$10 000 000 в ARR — это не что-то, отчего можно отмахнуться. Но проблема корпоративной стратегии продаж Trello была в том, что строилась лишь на том факте, что люди в предполагаемой компании-клиенте уже используют Trello. Отдел продаж, маркетинга, по разработке продукта — все они могли использовать кучу разных досок Trello. Но куда сложнее подписать на это всю компанию.

Решение: стать системой учета на предприятии

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

Один из способов — взять на вооружение стратегию Slack. По мере роста компании Slack начал усиленно думать над тем, как перейти от работы с индивидуальными клиентами к коллективам и корпорациям.

Большая трудность, с которой столкнулся Slack, — в отличие от продаж CRM или маркетингового аналитического инструмента, почти все в небольшой команде имеют право вето на производительность инструмента. Так Slack провел шесть месяцев в состоянии закрытой бета-версии, наблюдая за клиентской базой и взращивая в них потребность, в первую очередь, в средстве внутренней коммуникации. Они оптимизировали свой онбординг-поток вокруг метрики в 2000 писем, отправленных в рамках организации. Сегодня 93% этих компаний все еще используют Slack.

Как enterprise-продукт Slack позволял организациям создавать более или менее любой тип структуры. Функционально Slack являлся другим продуктом для корпораций. Команды внутри компании могут организовываться в рабочие области (workspaces) и формировать подразделения в соответствии с организационной структурой предприятия. Поскольку Slack всерьез озаботился выяснением того, чем можно привлечь более крупных клиентов, стало возможным обнаружить ключевые проблемы, которые можно было бы решить при помощи Enterprise Grid.

Большие компании любят гибкость и возможность кастомизации. Как и Slack, Trello могли бы отменить стандартную модель ценообразования для корпораций, открыв для них возможность самостоятельно настроить Trello под их организационные диаграммы. Преимущество Trello было в том, что их продукт был универсальным и простым в использовании. Обеспечивая структуру компаний между департаментами, Trello легко мог бы стать тем связующим звеном, позволяющим сделать компанию еще более целостной.

Заключение

Конечно, легко рассуждать постфактум. Вот только не стоит забывать, что создание SaaS-бизнеса ценой более 10 млн. долл., а в случае с Trello — 425 млн.долл., — огромное достижение.

Компания Fog Creek финансировала Trello из своего кармана. И с момента своего запуска на конференции TechCrunch Disrupt проект был успешен. Прежде чем сервис начал приносить какие-то деньги, за 2 года база пользователей выросла до 500 000 человек, а за 4 года — до 4,75 миллионов пользователей. Разработчикам удалось создать удивительный продукт, который опережал свое время. Он был прост, элегантен и легок в использовании. Воздействие, которое оказало Trello на всю SaaS-индустрию, неоценимо.

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

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