Пару лет назад «Ведомости» писали о «защищенном российском мессенджере», который собираются внедрять в государственные структуры. Даже пересказ этой новости одним предложением отдает в голове звуком стройно шагающих молотков. Представляешь, как где-нибудь за высоким забором, с ежами у проходной и двумя часовыми, по тревоге поднимают часть программистов в погонах и бросают в бой на благо импортозамещения.
Стереотипы — ужасная вещь, я знаю.
Мессенджер вместе с «Билайном» разрабатывала компания Staply. Сейчас они оставили эту затею, и перенесли наработки в новый продукт — «Мобильное предприятие». Оказывается, это маленькая команда удаленщиков, которые не приемлют микроконтроль настолько, что живут без менеджеров и даже тимлидов, работают когда хотят и откуда хотят.
Как им это удается, я расспросил технического директора Staply Максима Индыкова (maks_ohs).
Компания попала в недавний рейтинг лучших работодателей в ИТ «Моего круга» со средней оценкой 4,81 по всем двенадцати критериям, из которых сотрудники Staply выше всего оценивают современные технологии, адекватную зарплату, профессиональный рост, признание результатов труда и связь с топ-менеджментом.
Что такое Staply
Максим Индыков
— Все началось около шести лет назад. Я заканчивал ИТМО, «Информационные технологии». Это солянка из всех предметов — вплоть до составления учебных планов, истории, философии, математики, физики, программирования. Тогда мы думали с ребятами, чем интересным можно заниматься. У нас было несколько попыток, и первый проект, который имел какой-то вес, назывался Cloudiverse.
С ним ребята заняли второе место на хакатоне TechСrunch. Суть была такая — берётся файл, разбивается в браузере на куски, каждый кусок шифруется, и эти зашифрованные кусочки отправляются в разные облака. Кусочек — в Dropbox, кусочек — в Google Drive, и кусочек остается локально. Чтобы собрать всё обратно, нужно знать ключ и знать, где лежат кусочки.
Это делалось на фоне хайпа по Сноудену. Но на самом деле проект был интересен нам больше с технической точки зрения — необычно большой по тем временам работой на клиенте. Но потом тема с безопасностью как-то угасла.
— Вашей мотивацией был именно хайп или какое-то убеждение?
— Хайп вообще нет — это просто был приятный бонус. Мотивировало сделать интересный проект. И когда мы его показывали, всем было интересно. Вроде простая идея, но при этом она хорошо визуализируется в головах людей. Вот файл разбивается, и остается просто набор символов. Не придерешься вообще никак.
— А как вы попали в TechCrunch?
— Просто отправили заявку и все. Поймали бесплатную раздачу билетов онлайн и успели зарегистрироваться. Мы всегда стараемся делать максимально просто. Без поисков обходных путей, без хитрых схем. А почему TechCrunch? Хотелось попробовать лучшего. В те времена это был хороший хайповый хакатон.
Нас тогда было мало — три человека. Я (разработчик), дизайнер, организатор. Ещё был один человек, он занимался патентами.
Все шло довольно быстро. После мы начали разрабатывать сервис — чат для переписки, примерно как Slack. Просто делали хороший удобный мессенджер. И как раз в то время произошла история с импортозамещением, где-то в 14-м году.
Мы тестировали продукт в «Росэнергоатоме» и в правительстве Московской области. Основная фишка была в том, что он ставился на внутренние сервера. Полностью коробочное решение. Оно позволяет реально безопасно общаться, потому что выхода в интернет просто нет. Поэтому большие корпорации его пробовали.
Про эту тему вышла пара новостей, в «Ведомостях» написали. Мы и сами писали очень много — на «Хабр», на VC — и как-то так пиарились. Не покупали никогда никакой рекламы, просто делали статьи с хорошим материалом, интересными темами. Я писал о программировании, Дима — наш юрист — писал о юридических историях проекта. Делились с сообществом тем, что знаем.
У нас тогда не было больших ресурсов на разработку и поддержку. Нас было мало, и мы начали расширяться, искать людей, собирать команду, всему учиться.
Что за продукт сейчас делает Staply
Сейчас у Staply три продукта — редактор коммерческих предложений «Октаплан», Emny — один из сервисов VK для поиска работы. И главный продукт — «Мобильное предприятие». Все три делает команда из тридцати человек.
«Мобильное предприятие» — это сервис для малого и среднего бизнеса, куда входит целый набор инструментов: чат для сотрудников, call-трекинг, аналитика звонков, система постановки задач, CRM-система, блокнот, рекламная аналитика и много чего еще.
«Кейс использования довольно простой», говорит Максим. «Владелец бизнеса размещает номера в рекламе — в газете, по радио, на телевидении. Под каждый номер у него отведен отдельный канал, по каждому идут звонки. Сотрудник может разобрать там заявки и там же продолжает работать с клиентом.
Может поставить задачу своей команде, например, перезвонить клиенту, договор подписать, вести клиента по воронке продаж, менять его статусы на канбан-доске.
По этому клиенту сотрудники могут общаться в группах, в чатах, создавать обсуждения. В чатах есть мини-блокнот для хранения информации, общих для всей команды заметок».
Как говорит Максим, основная фишка сервиса в том, что он простой, ничего не надо настраивать, и все уже есть из коробки.
— Как быть с тем, что все пользуются «Слаком»?
— Это совершенно другая ниша. Мы хоть и разрабатываем нечто подобное, но никогда с ними не конкурировали, не ставили себе такой цели.
— Почему?
— Slack — это вещь для тех, кто предпочитает всякие интеграции, любит что-то настраивать. Я говорю не только об IT-сообществе, думаю, он много где используется. А «Мобильное предприятие» — продукт для тех, кто настраивать ничего не любит, не умеет или не хочет.
Во-первых, это малый и средний бизнес в регионах. Люди хотят, чтобы все работало из коробки сразу, как надо
— А чем вы пользуетесь сами, в чем общаетесь?
— В том, что и разрабатываем — в «Мобильном предприятии». Используем каждый день, чтобы самим понимать, где какие проблемы, где что улучшать. Ну и Skype для групповых созвонов — это неотъемлемая часть. Был бы он только попроще…
— Я читал, что вы пробовали запускать мессенджер сначала в Америке, но не пошло. Почему?
— Когда все только начиналось, мы пробовали работать на весь мир. Локализация отбирала много сил. Продукт постоянно меняется, нужно поддерживать два вида текстов, переводить. На том рынке у нас не было полномасштабной работы. Продвигались очень просто — статьями. Hacker News, наверное, был основным источником трафика.
IT-пользователи — это первые тестеры. Но не было выходов именно на бизнес. И не получилось, наверное, потому, что акцент сильно сместился на Россию. Стало понятно, что здесь тоже интересно, и можно много чего сделать — дать людям, которые до сих пор пользуются «Экселем» или даже блокнотами, какой-то простой сервис.
Удаленная работа на личной ответственности
— Как получилось, что вы распределились удаленно?
— Все, кто начинали это дело, жили в Питере. Цели делать офис никогда не было. Но и обязательно удалённо — тоже. Хотелось просто собрать хорошую команду. Очень много хороших людей в плане программирования живут в Екатеринбурге, Новосибирске, Казани. Так и сформировали полностью удалённую команду.
Изначально мы ставили себе задачу максимально избежать микроменеджмента и контроля. Микроконтроль может убить органическую среду в компании. Когда все просыпаются в девять, садятся в офисе, раздают задачи, начинают их делать, уходят, не могут куда-то уехать по своему желанию, перенести работу на потом. Поэтому мы стараемся избегать контроля, и до сих пор это нам удается.
— Мне кажется, для многих компаний такое звучит как кошмар — работать и без контроля, и без офиса.
— У нас даже нет менеджеров и тимлидов. Если нет никаких горящих вещей, то человек может просто взять, куда-то поехать отдохнуть. Никаких проблем, если это предсказуемо. Человек может работать откуда удобно.
Но для некоторых это тоже сложно. Когда есть офис, за тебя все организовывают, все твое расписание и работу. А здесь надо заниматься этим самому. Самому не перерабатывать, самому работать, когда надо. Это большая ответственность, которая ложится на каждого человека. Никто не организует твою жизнь за тебя.
— Как вы справляетесь?
— Когда нет давления сверху, снизу и сбоку, на первый план выходит ответственность за свои обещания, поступки и слова. Сейчас, в рамках систем постановки задач, всяких KPI, личная ответственность задвинута на второй план.
У нас все друг другу доверяют и знают, что вот этот человек — если он сказал, он сделает. Если он не успевает, значит скажет, что не успевает.
— А если он не сделал?
— То это рассматривается индивидуально. Здесь нет контроля, но есть модерация процесса. Наблюдение, принятие структурных решений. У нас всего тридцать человек. Наверное, с такой командой еще можно совладать.
Мы всегда старались максимально не разрастаться. Бывали случаи, когда людей на проектах становилось больше, но тогда все размывалось.
— По каким городам вы распределились?
— Наш дизайнер живет в Италии. А дальше — Питер, Москва, Екатеринбург, Красноярск, Краснодар и т.д.
— Часовые пояса не мешают?
— Нет. Мы не требуем постоянного нахождения на рабочем месте с девяти до шести. Нужно просто выполнять вещи, которые ты пообещал сделать, находить точки соприкосновения с командой, договариваться об удобном времени для всех.
Мы — основатели — тоже сидим по домам, встречаемся в городе. А с командой — обычно на конференциях. Допустим, один день сидим на конференции, слушаем, а на следующий день уже обсуждаем рабочие вещи в коворкинге. В Москве, наверное, «Таблица» самый оптимальный вариант для таких посиделок.
Бывает, проработав с человеком полгода, даже не знаешь, как он выглядит. Это всегда очень смешно — встретиться на конференции. Смотришь такой: «Привет. Это ты? Мы же договорились у фонтана встретиться!»
— А как у вас люди поделены на команды?
Примерно поровну — по пять-шесть человек. Тот, кто начал разрабатывать проект, является центром знаний — и вокруг него коллектив, которому интересно в данный момент это разрабатывать. Проекты внутри компании открыты, каждый может посмотреть, что где происходит, помочь, или тоже вступить в разработку.
Команды текучие, но все равно каждый работает только в поле своего продукта. Когда разработчик работает на трёх проектах сразу, это очень сильно угнетает и выматывает. Со всех сторон от него что-то хотят. Я видел, как на людей в других компаниях вешали по десять проектов, и у них было страшное выгорание.
— Ты так рассказываешь, и создается впечатление, что у вас полная свобода. Делай что хочешь, когда хочешь и как хочешь. Никаких менеджеров, давления. Но когда я читал вашу страницу на HeadHunter, складывалось совсем другое впечатление. Дедлайны, роадмап, ежедневные созвоны.
— Давление производится само собой. Но это отличается от заказной разработки. Там заказчик выдвигает требования, нужно сделать к такому-то числу, и за сделанное он заплатит. Это не сильная мотивация. Ну заплатит он компании, а разработчику в чем интерес?
А вот когда команда знает, что у партнёра на даты куплена реклама, знает, что там тоже команды работают и ждут нас — появляется внутренняя мотивация, ответственность. Ты уже работаешь не за деньги и дедлайны, а отвечаешь за то, чтобы у других тоже все получилось.
И появляется внутреннее давление, которое организует людей. Команда сама начинает предлагать, что делать, как распределять и как успевать.
— От этого не размываются обязанности? Разработчик вместо того, чтобы писать код, начинает переписываться, думать над организационными моментами. И в итоге хорошо ничего не сделает.
— Такие случаи действительно бывают. Но есть и другая сторона. Бывает человек написал свою часть, и помогает организовать над ней работу внутри. Это даже круто — он офигенно понимает, что действительно там нужно. Ведь с менеджерами обычно как: «Дайте-ка мне статус, я пойду подумаю». А тут программист сам внутри процесса и знает, где что можно успеть.
Это к вопросу о том, что у нас реально нет тимлидов. Тимлид появляется сам в плане хард скилов, а если есть еще умение общаться, выстраивать взаимоотношения, он автоматически становится ведущим.
— Нет менеджеров, нет лидов. Но чем тогда занимаешься ты как технический директор?
— Последнее время, в основном, наймом. Собеседования отнимают очень много времени, особенно если надо провести несколько раундов.
А обычно — просто технической модерацией разработки, наблюдением. Я умею быстро делать прототипы, знаю, что могу сделать их за день, поэтому прототипирую фичи.
Для работы мы используем сервис Notion, полностью ведём там свою базу знаний, расписываем этапы. Вот я занимаюсь организацией этих этапов, общаюсь с партнёрами. В общем, стараюсь не держать знания в себе. Когда ты что-то узнал и быстро оформил в базу знаний, все становится гораздо проще, особенно в удалённой команде.
— В классической схеме, когда менеджер ждёт статуса, а заказчик релиза — разработчики могут переступить через себя и доделать, даже если недовольны качеством. А в ваших условиях не расцветает бесконечный перфекционизм? Когда ещё недостаточно качественно, и выкидывать срочно не обязательно?
— Если срок можно перенести ради качества, то мы лучше перенесём. Вариант с дедлайном без тестов и проверок все равно потом приведёт к обратному эффекту, к усталости, большому техническому долгу.
— На том же HeadHunter у вас написано, что если дедлайн поставлен, двигать его не надо.
— Ну это каждый раз индивидуальный случай. Дедлайн можно двигать, главное обо всём сообщать. Все наши попытки что-то организовать я могу свести к одному — человек должен быть предсказуем.
Если команда может предсказать поведение человека, она может ему доверять. Если она знает, что человек выполняет свои обещания, и он их реально выполняет — окей. Если у человека дедлайн, и он пишет, что не успевает — не важно по каким причинам, — тоже окей. Если он пишет за час до релиза, то это плохо, это уже абсолютная непредсказуемость. Обсуждали одно — получили другое. Главное — коммуникация. Написать, сообщить, сказать — всегда можно что-то придумать.
— Правда, что у вас задачи все ставят всем?
— Да.
— А путаница не начинается?
— Раз в неделю есть крупный созвон, когда мы анализируем и думаем, что должны сделать хорошего за неделю. Соответственно, задачи ставятся внутри команды. Сначала мы обсуждаем роадмап развития продукта. Обсуждение это довольно глобальное, в нём участвуют вообще все.
Например, я говорю: «Нам нужно сделать модуль с смс рассылкой». И все вступают в обсуждение — как мы это сделаем, когда, кто это будет делать. В результате формируется оформленный в базе знаний план, и мы стараемся его держаться. Мы не расставляем дьюдейты и дедлайны. У нас есть скорее общий дедлайн, который мы сами для себя выбрали.
То есть мы договариваемся и просто стараемся уложиться в свой же план.
— Все отвечают за все?
— Да.
— Это часто выливается в то, что никто ни за что не отвечает.
— Конечно, такое может быть. Но как бы человек ни занимался всем, у него есть своя специализация. Фронтенд разработчик отвечает за фронтенд. Что он сам сделал — за то и отвечает.
А коллективная ответственность (хотя мне это слово вообще не нравится) это скорее в нужный момент сказать: «Слушай, а ты не то делаешь, ты делаешь лишнюю работу, можно проще». Наверное, ответственность — это помочь другому не делать лишнего.
Поэтому искать людей сложно. При такой удалённой работе очень важна хорошая коммуникация, чтобы человек был открыт. Ведь если есть жесткая структура, иерархия, куда человек может встать, как винтик в качестве специалиста, но абсолютно без навыков коммуникации — то он может ни с кем не общаться, получать задачи и хорошо выполнять свою работу.
Но на удалённой работе недостаточно просто быть хорошим специалистом — надо уметь находить контакт, общаться.
Креативный найм интересных людей
— Где же вы набираете таких людей?
— В основном «Мой круг», чуть меньше HeadHunter, каналы в «Телеграме» — в общем везде, где есть программисты. Разве что LinkedIn не используем.
Мы пишем, как мы это называем, «креативные вакансии». Например, ставили туда зашифрованный текст, рассказывали какие-то истории. Или вакансии, где не обычный текст, а диалог. Зачем писать «нам нужен разработчик», когда можно писать что-то необычное!
Это способ попытаться найти людей, которым с нами будет интересно.
А бывает, что хорошие специалисты прямо рядом. Однажды я нашел Андроид-разработчика, когда мы катались на Розе Хутор на лыжах.
— Интересные люди — это здорово. Но техническую фильтрацию они же должны проходить?
— Мы пробовали собеседовать максимально быстро, очень грубо фильтровать, и уже на испытательном сроке смотреть, как человек работает. Вдруг кто-то просто не умеет проходить собеседование? Этот подход не сработал.
Человек включается в работу, и уже размывается понимание — получается у него или не получается. Быстро этого не заметишь. Поэтому сейчас проверяем фундаментальные знания. Не гоняем по фреймворкам, а спрашиваем основы, как все устроено, как работает. Тот же HTTP-протокол — он один на всех. Или как работают индексы в базах, как сами базы устроены — не просто делать запросы, а понимать, какие процессы происходят при этом, понимать, как устроены заголовки.
Многие даже не знают, как устроены банальные кодировки, почему именно UTF-8, почему именно «восемь».
— Ты думаешь, это реально нужно знать — почему именно «восемь»?
— Я думаю, это фундаментальное понимание основ, это действительно важно. Человек может быть хорошим специалистом, но он столкнётся с проблемами, которые требуют низкоуровневого знания.
Например, почему этот запрос работает так медленно. Человек вроде хорошо писал SQL-запросы, но нужно покопаться, понять, что можно изменить в самой структуре базы, найти, почему именно этот индекс так медленно работает.
Человек, который не знал фундаментальных основ, сразу теряется. Ему становится очень сложно. Разумеется, это не такой грубый фильтр, что не ответил — сразу всё. Нет никакого чек-листа.
Если он не знает одно, но знает в других областях — окей.
— Тестовое задание даете?
— Опять же по-разному. Наверное, тестовые задания — это попытка отфильтровать людей, которые просто не заинтересованы. Если человек хорошо показывает себя в интервью, мы можем сказать, что тестовое не нужно. А бывает по интервью вообще не оценить.
Очень часто, процентов 70 всех откликов с киданием репозитория на Github — это просто какая-то отписка, потому что внутри репозитория лежит пустота, самописные проекты пятилетней давности и всё. Поэтому тестовое нужно, чтобы посмотреть, как человек пишет код, как он его оформляет, как документирует.
Наше тестовое задание, особенно если оно на бэкенд, довольно общее — описать простой Rest API с вызовом внешнего сервиса и его задокументировать. Никаких логических сложных вычислений — главное показать, как ты умеешь строить код.
Дальше максимум три дня, и даем ответ. А за испытательный срок стараемся понять, действительно ли всё хорошо, не перехитрил ли нас человек.
— А перехитряли?
— Да, конечно. Были случаи, когда человек очень хорошо имитировал деятельность. Постоянно писал: «Сейчас доделаю, залью, сейчас-сейчас, все будет». Мы ждали, спрашивали: «Ну так сделаешь?» А он: «да-да, сейчас». И приходилось расставаться.
Переход с Ruby на Go
— Расскажи, какие технологии вы используете?
— Изначально у нас был Ruby on Rails, на котором я что-то разрабатывал. Минимальный набор дополнительных прикладных вещей, простые хранилища MySQL — все банально и стандартно.
Со временем мы начали уходить в сторону Go. Я это воспринимаю как решение всего сообщества, естественную миграцию. Многие хорошие специалисты стали учить Go, многие компании увидели это, и начали открывать вакансии, начали переводить на Go свои сервисы.
Все выросло в снежный ком, и мы постарались не упустить момент. Сейчас Ruby-сообщество уходит — кто в Elixir, кто в Go. Поэтому у нас два языка.
— Как думаешь, почему все выбирают именно Go?
— Я тоже много кому задавал этот вопрос. Из субъективного — людям нравился С, а Go это такой С-подобный язык. Из объективных причин — потому что Go не позволяет писать очень сложно. Плюс он очень быстрый — это хорошая экономия ресурсов, мощности серверов.
— Когда я спрашиваю своего друга, за что он не любит Go, он просто говорит «Там нет дженериков», и дальше отказывается говорить.
*закадровый смех*
— Дженерики должны появиться, их все ждут. Но пока вроде обходимся своими средствами. Я думаю без них многие обходятся. Чего нет, того нет.
Но аналогов Go не знаю. Эликсир? Хорошая технология, основанная на Эрланге. Но она развивается скорее как надстройка над Эрлангом, все равно сохраняется некая многословность, попытки исправить старый синтаксис.
А в Go синтаксис простой и понятный.
Во фронтенде все стандартно — React со всеми его технологиями. Пробовали ещё Vue, обсуждаем TypeScript.
Работа с «Билайном» и госкорпорациями
— У вас на сайте написано, что Staply принадлежит компании Primavera. При этом Staply работает с «Билайном». Так как у вас все устроено?
— Все очень просто — с «Билайном» мы партнёры. Каждый делает то, в чем он силён. Билайн — это телефония, АТС, вся инфраструктура. А мы — рабочее пространство, клиентская часть сервиса.
На самом деле телеком — это очень сложно, это очень большая структура. Внедрение новой фичи в корпорации всегда проходит тяжело. С одной стороны — сложность разработки, с другой стороны — сложность в интегрировании в масштабную систему, где есть биллинг, безопасность. Здесь мы стараемся все вместе делать. Но, конечно, каждый отвечает за свою сторону.
— Вам не трудно с ними стыковаться?
— На самом деле нет. Мы гораздо быстрее и мобильнее. Они работают в долгую перспективу — мы динамичные и можем подстраиваться под их сроки.
— Не бывает такого, что приходит менеджер из «Билайна» и «просит дать статус»?
— Конечно же бывает, это нормально. Нужно же понимать, как дальше двигаться.
— Я читал, что вы вместе пытались делать «Госмессенджер».
— Да, было дело. Но, к сожалению, «Институт развития Интернета», который начал и курировал вопрос по «Госмессенджеру», приостановил проект.
Очень хотелось бы вернуться. Работать с крупными компаниями — очень интересно.
— А нет опасения, что уклон в госсектор испортит вам бренд?
— Пока не портило. Почему госсектор так плохо воспринимают — наверное, там совсем по-другому ведётся разработка. Все выглядит монструозно сложно. Но делать хороший продукт — даже для госсектора — это все равно приятно, потому что нет цели максимально продать себя.
Чтобы продавать, надо накручивать и усложнять фичи ради фич. А госучреждениям нужен простой сервис. Они привыкли, что им постоянно продают миллиард сложных функций, но понимают, что простое решение может быть эффективнее.
Это не значит, что должен быть минимум фич. Просто должны быть закрыты основные сценарии.
Самое сложное в этой разработке — большое количество пользователей внутри одного коллектива — не в рамках сервиса, где могут быть и миллионы — именно в одной компании. Организовать работу 3000 человек — это самое сложное. Поэтому нужно серьезно этим заниматься.
Сейчас проект в ожидании своего часа. Однажды мы его сделаем.
— А нет моральной тяги? Например, выехать на импортозамещении — это же не очень честно.
— Смотря как этим пользоваться. Если сделать чисто ради галочки и реализовать в ужасном качестве, то, конечно, это подло. А попытаться сделать действительно хорошую вещь и воспользоваться неким переломным моментом, при этом реально улучшить людям жизнь и работу — тогда все произойдёт само. Заказчики увидят, что у тебя действительно удобнее и дешевле.
Может не быть никаких ускорений из-за внешних условий, может не быть ничего. Но должен быть хороший продукт, который решает реальную задачу.
