«Пачка» — это корпоративный мессенджер, который делает компания из Санкт-Петербурга. Идея в том, чтобы в России был собственный современный мессенджер для диджитал-работы. Мы пообщались с основателями «Пачки» Григорием Любачевым и Максимом Индыковым: как у них организована работа над проектом, на чём всё сделано и как сейчас грамотно начинать работать в ИТ.
Это коммерческая статья, то есть ребята из «Пачки» дали нам денег на выпуск материала и рекламу своего сервиса. Если вы перейдёте по этой ссылке, они увидят, что реклама в «Коде» работает, а вы — поддержите российский цифровой продукт.
Вот ссылка целиком, с нашими UTM-метками:
https://www.pachca.com/?utm_source=media&utm_medium=article&utm_campaign=code
Кстати, про работу UTM-меток мы писали недавно в статье, тоже можно заодно почитать.
Вообще «Пачка» — это мессенджер, там обмениваются сообщениями в чатиках, всё заточено под работу. Есть встроенная звонилка, интеграция с нужными сервисами, приложухи для всех платформ и бесплатная версия, а также нормально реализованы ветки. Ну и это российский софт, то есть платить можно рублями.
А ещё есть канал «Пачки» в Телеграме: https://t.me/pachca_team
Зачем нужен ещё один мессенджер
«Пачка» нужна, чтобы сделать единое пространство для общения с командой. Это жизненная необходимость современной работы, когда у тебя есть много данных, много людей, кросс-функциональные и распределённые команды. В современной жизни ты в любом случае пользуешься каким-то мессенджером, но в работе лучше пользоваться инструментом, который заточен под работу.
Нас спрашивают: ребята, зачем вы делаете «Пачку», когда есть Телеграм, в котором уже всё это есть? И на самом деле, в очень маленькой команде Телеграм — это хорошее решение.
Но с каждым дополнительным сотрудником начинается всё больше проблем. Даже базовое администрирование всех этих чатиков: добавить человека, убрать человека, а этого добавить только по ссылке, а тот уволен и его нужно исключить — чем больше людей, тем больше всяких мелких проблем.
Ещё есть большой шанс утечки куда-то не туда: например, форварднул важные документы не тому человеку. В Телеграме у тебя нет, условно говоря, рабочего круга контактов, внутри которого ты можешь пересылать рабочую инфу, а за пределы — уже нет. В Телеграме у тебя открытое пространство. И очень много служебной информации утекает вот так, из-за случайного пересыла.
В нормальном корпоративном мессенджере кроме самих чатов есть всякие дополнительные фишки, например карточка сотрудника. Ты можешь с коллегой познакомиться, понять, кто он и откуда.
Для сравнения: ты в Телеграме можешь быть Jane Zero. И когда ты приходишь к кому-то новому в команде, у вас вот этот неловкий момент: «Джейн Зиро — это кто?» Человеку нужно запомнить, что Джейн Зиро — это дизайнер Женя. А в корпоративном мессенджере ты сразу говоришь, что ты Женя Зиновьева, дизайнер. Тебе не нужно там ни от кого скрываться и шифроваться, потому что это не твой личный мессенджер, а рабочий.
Опыт рабочего общения очень сильно отличается от личного. И комбинировать их в одном сервисе — сложно. Телеграм всё равно вынужден фокусироваться на личном, а не на рабочем, как бы он ни пытался разложить всё по папкам. У нас нет таких компромиссов, мы можем делать нормальный инструмент именно для работы.
На чём написана «Пачка»
В 2013 году, когда мы начинали всё делать, вариантов стека было немного. Это либо писать на чём-то классическом типа PHP, либо писать на Java, либо писать на Python. На тот момент Python-комьюнити было слишком специализированное, с сильным уклоном в математику. А вот фреймворк Ruby on Rails в стартаперской движухе, особенно на Западе, был вообще на огромном подъёме. Когда тебе нужно решить какую-то задачу, ты просто гуглишь её решение и сразу понимаешь, как там всё устроено. Мы в итоге тоже сделали всё на Ruby.
Дело в том, что по Ruby настолько понятное и подробное описание, как что сделать, всё красиво оформлено и разобрано — бери и используй. Этот фреймворк оформлялся людьми, которые ценят красоту и лаконичность всего. Если мы говорим, что какие-то инструменты заточены под что-то хорошо, то Ruby on Rails был очень хорошо заточен под стартапы. Куча готовых решений, которые шикарно описаны в документации и примерах.
Бэкенд: Ruby и монолит
На Ruby у нас написан почти весь бэкенд, причём это монолит. Конечно, какие-то вещи сделать удобнее в других технологиях — это Go и Node.js. Но внутри их всего 10%, не больше. Node.js нужен для работы с сокетами — поддерживать коннекторы и обмениваться сообщениями о событиях. А Go мы используем, просто потому что нравится на нём иногда писать :-) Какие-то мелкие вещи в проекте выносим тоже в него.
Теперь по поводу монолита. В Рельсовом сообществе есть два подхода: это хороший монолит или много хороших микросервисов. Когда у вас стартап или что-то переходящее из стартапа в серьёзный проект, то сделать хорошие микросервисы очень сложно, очень дорого и на самом деле невыгодно. Гораздо надёжнее и выгоднее сделать хороший монолит.
От монолитов все стали уходить, потому что у всех были плохие монолиты, которые не позволяли им работать. Плохой монолит — это когда ты физически ощущаешь, что не можешь сделать какую-то фичу в какое-то разумное время. Сейчас поясним.
Ты понимаешь, что чтобы тебе что-то сделать, надо разбираться минимум несколько недель, при этом не сломав всё остальное. В этот момент все берут и переписывают всё с нуля, потому что поддерживать такое просто невозможно. В то время и появилась мода переписать всё на микросервисы.
Ещё пример плохого монолита — когда ты понимаешь, что у тебя команда настолько большая, что все в ней мешают друг другу. Зоны ответственности команды пересекаются настолько, что блокируют друг друга в коде. Ты видишь, что у тебя все задачи заблокированы друг другом и все ждут. В этот момент все тоже переходят на микросервисы.
У нас маленькая команда, а Ruby позволяет писать монолит хорошо. Это основатель, создатель фреймворка Давид Хейнемейер Хенсон предложил в какой-то момент концепцию Majestic Monolit, которую они как раз используют в своих проектах. Это именно их видение того, как правильно использовать Ruby on Rails в продакшене — иметь хороший монолит, написанный с использованием определённых паттернов проектирования. Поэтому мы всегда старались писать аккуратно, покрывать весь код тестами, что позволяло нам обойтись без микросервисной архитектуры.
Фронтенд и десктоп: React и красивые интерфейсы
Для фронта мы выбрали React, потому что на нём пишется всё, что нам нужно. Это наш золотой стандарт. Есть аналоги, они, возможно, хуже или лучше, но это чисто вкусовщина. Мы умеем готовить React очень хорошо и можем использовать все его возможности, поэтому пишем на нём.
В этом плане нам просто нужна технология надёжная, проверенная временем и которая используется в большинстве компаний. Всегда можно взять эксклюзивное, уникальное. Но зачем, если можно сделать очень красивый интерфейс на хорошем инструменте?
Десктопное приложение мы сделали вообще просто: версия для десктопа — это веб-страница, собранная при помощи сборщика Electron. Так сейчас многие делают: берут сайт и оборачивают его в Electron, а потом уже поверх сайта пишут нативные элементы, которые делают приложение полноценным десктопом.
Про мобильные приложения
Первую версию мессенджера для мобильных устройств мы полностью собирали кросс-платформенную, лет 5 назад. Технически это было для iOS и для Android собранное веб-приложение.
Но, делая кросс-платформенные решения, ты не можешь полностью соблюсти всю специфику платформы, на которой что-то разрабатываешь. Для iOS есть свои гайдлайны интерфейсов, то, как программа должна работать и выглядеть. Для Андроида — абсолютно другие, весь UI должен быть иным.
Делать кросс-платформенное решение, которое полностью различается интерфейсом, нет смысла. А в таком приложении, как у нас, UI — это основа и большая часть кода. Поэтому мы в какой-то момент полностью с нуля начали писать разные платформы. Это даёт возможность реализовывать хороший пользовательский опыт на каждой из них. Это намного дороже, но зато получается крутой результат.
Сложности разработки
Наша основная проблема — слишком большая разнородность компаний, которые пользуются нашим продуктом. Есть компании из трёх человек, и у них рабочее пространство маленькое, там нормально работают какие-то одни решения — интерфейсные, технологические, смысловые. Например, когда вас трое, вам не нужна разветвлённая система прав, группы пользователей и система администрирования сотрудников, вы втроём и так разберётесь.
А есть компании, где больше 10 тысяч человек. И нам нужно сохранить одинаковый опыт использования для тех и для других. Просто представьте, например, каково добавить в чаты 10 тысяч человек: сколько там уровней доступа, разделения ролей, сколько там чатов в принципе; какой объём данных они генерируют каждый день; каким должен быть поиск по этим чатам.
Для примера возьмём архитектуру отправки сообщений с сервера. Самое простое решение — по очереди рассылать сообщения всем в чате. Есть условный стек сообщений на отправку и есть Вася, Миша, Петя. Вася получил стек сообщений, Миша получил стек, Петя получил стек. Пока что всё хорошо и никто не замечает ни зависаний, ни тормозов.
Вдруг к сервису подключается компания, где в чате 5 тысяч человек. И всё, старое решение легло. У тебя скопился стек из 5 тысяч сообщений, которые нужно отправить на 5 тысяч пользователей в каждый момент времени. Это 5 миллионов событий. Сколько нужно времени твоему серверу, чтобы обслужить эти 5 миллионов событий? А что если кто-то из этих 5 тысяч человек начнёт отправлять новые сообщения, пока не пришли старые? Получается, что для компании из 5 тысяч человек нужна какая-то другая архитектура обмена сообщениями.
Но ты не можешь маленьким дать одну архитектуру, а большим — другую. Тебе нужно одно хорошее решение, которое потом нужно раскатывать на всех. Но это до тех пор, пока не придёт компания с 50 тысячами сотрудников. Или придёт кто-то другой с очень нестандартным профилем — тогда снова часть старых решений не сработает и нужно будет пилить что-то ещё.
Единственное решение таких проблем — это постоянно следить за своими мониторингами, наращивать их возможности, чтобы постоянно понимать, что у тебя происходит в проекте: что не работает, каково среднее время запросов и так далее. Это основная серьёзная проблема, которая бывает у нас. Мы что-то делаем, а потом смотрим, чтобы это хорошо работало у всех.
Квалификация разработчиков
Раньше, если я хотел устроиться в Яндекс или Гугл, то мне нужно было обладать очень высокими знаниями, быть очень крутым специалистом с большим опытом. Раньше про это мем был: где мне взять три года работы, чтобы устроиться на первую работу. Но при этом если ты хотел работать в стартапе, то тебе ничего знать не надо было — там тебя всему научат.
Сейчас всё наоборот: чтобы устроиться в большую компанию, не обязательно нужен опыт, большие компании любят джунов. Потому что в больших командах очень маленькая зона ответственности, у тебя огромная иерархия, а цена твоей ошибки очень невелика.
Чтобы работать у нас, у тебя должен быть большой опыт и ты должен быть универсальным в плане понимания проблемы, уметь разобраться во всём. Например, в большой компании тебе можно не знать, как устроен сервер и что он делает, это задача девопса. А в «Пачке» тебе нужно сходить куда-то по сети, посмотреть на логи сервера, разобраться, как работают мониторинги, понимать, как устроен Linux.
Как организованы задачи в компании
Мы конкурируем с корпорациями, у которых ресурсов больше, и все классические процессы организации работы заточены под них. Но для нас это не работает, потому что мы слишком маленькие и у нас нет столько денег и сил, чтобы стать похожими внутри на больших ребят. В итоге у нас постепенно появилась своя система организации рабочего процесса, который для нас идеально подходит.
Например, у нас нет сроков. У задач даже нет такого поля, куда можно ввести дату. Нет циклов для поддержания какого-то ритма — всех этих недельных итераций, чекпойнтов, майлстоунов и прочей общепринятой схемы работы. Мы придерживаемся принципа: что у тебя в голове, то должно быть и в процессе.
Всё начинается с того, что появляются какие-то факты — мы называем их вводными. Это может быть баг, который заметила поддержка, или прикольная фича, которая пришла в голову. Это может быть даже просто предложение от клиента, которое он оставил в форме обратной связи.
При этом у нас нет менеджеров, продактов, техлидов или других людей, которые занимаются обработкой вводных, — всё делаем вместе. Мы все эти вводные уточняем и доводим до состояния «понятно». Затем всё, что понятно и где не требуется дизайн, летит сразу на канбан-доску, где это можно брать и делать.
Напоследок: пожелание начинающим разработчикам
Личный опыт показывает, что самое лучшее для начала и развития — это всегда пытаться сразу сделать что-то рабочее. Не придумать какой-то проект, а пытаться изучить технологию, которая сразу даст результат.
Если ты хочешь вкатиться в бэкенд просто так, то у тебя мозг будет взрываться от того, что ты что-то там делаешь, но не видишь результата. Ты делаешь бэкенд, а где что происходит и как это влияет хоть на что-то — непонятно, потому что чаще всего бэкенд работает незаметно для пользователя. И нужно искать такие варианты изучения, где ты можешь эти знания применить сразу в работе.
Для бэкенда я всегда советую написать телеграм-бота. Для этого не нужно делать графический интерфейс, не нужно придумывать внешний вид кнопок, но решение сразу будет работающим проектом. Там сразу видно, сработала твоя идея и знания или нет.
Кому не нравится бэкенд, можно для старта заняться мобильной разработкой. Здесь у тебя тоже есть сразу на руках готовый результат твоей учёбы. Ты можешь его показать кому-то, похвастаться, сделать скрины, мол, я сделал такое приложение, пускай даже не что-то прорывное. Но ты сразу видишь свой результат — и это сразу даёт силы и мотивацию двигаться дальше.
Рекламити
Посмотреть и попробовать, что получается у ребят из «Пачки», можно на их сайте. Если же больше хочется наблюдать за командой и их работой, то можно подписаться на канал «Пачки» в Телеграме.
