Упрощайте, не надейтесь на чат-ботов, откажитесь от лишних фич — советы разработчикам от основателя Caramba Switcher

21 июня 2018 года мы стартовали проект по созданию нового, автоматического переключателя клавиатуры Caramba Switcher. До этого я 16 лет делал Punto Switcher, и некоторые из читателей наверняка так или иначе знакомы с этой программой.

Через пару дней после запуска новость о нашем новом проекте написали в vc.ru, потом там же вышло большое интервью, и понеслось! За год программа была установлена на 40 тысячах компьютеров. Для нас это что-то невероятное, так как на продвижение программы мы потратили примерно 126 рублей: попробовали таргетинг в Facebook. Получили в результате одного пользователя, и больше с рекламой не развлекались.

За минувший год у нас вышло более 50 обновлений, появились версии Caramba Switcher LAB и Corporate, поддержка ещё нескольких языков и много чего другого. То, с какой готовностью сообщество откликалось на наши идеи и помогало шлифовать шероховатости и неровности, стало для нас главным вдохновляющим фактором.

Спустя примерно полгода после запуска версии для Windows мы выпустили первую закрытую бета-версию для macOS. Несколько сотен добровольцев помогали нам тестировать программу и мужественно переносили все баги и глюки, за что мы их очень благодарим. Вчера эта версия вышла в публичную бету — будем рады, если вы её попробуете!

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

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

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

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

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

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

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

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

Поэтому анонсировать стоит только реально сделанное, когда остается только нажать кнопку «Опубликовать». Так не теряется «дофаминовый эффект» — приятное чувство при открытии чего-то нового, своего рода анбоксинг.

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

Естественно, идея удержания любой ценой породила и у пользователей некий майндсет: «Я уйду к конкурентам»; «вот только что вы лишились кастомера». Каждый человек, будь то пользователь или разработчик, должен иметь свободу и радость выбора. Не стоит бояться, что человек куда-то пойдёт и там найдёт своё счастье :)

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

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

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

Мы обнаружили интересный принцип, который назвали «long tail pressure», или «давление длинного хвоста». Часто на начальном этапе разработки софта или сервиса есть несовершенства, которые никак не видны.

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

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

Если продукт не обновлять, не чистить, не заниматься им, то он покрывается некой «пылью». Удивительно, что это также касается нематериальных объектов, например, софта, где вроде бы пыли не видно. Почему-то люди всё равно ощущают запустение. Они хотят иметь дело с чем-то живым, даже если оно ещё несовершенно. Именно живость — признак развития. И если на сайте перестают обновлять даты в копирайте, то даже это уже плохой симптом.

Сайт — отдельная тема. Желательно постоянно его тюнинговать, особенно тексты: выжимать из них воду, полировать неровности. Иногда мы это делаем несколько раз в день, особенно если приходит репорт с непонятками. Через сайт происходит первое общение с пользователем.

Заметили — чем понятнее становится сайт, тем меньше недоумений. Первая волна пользователей явно читает то, что написано на сайте. На просмотр нового сайта тратится от 30 до 60 секунд: поэтому желательно, чтобы текста было ровно столько, чтобы его можно было прочитать за минуту.

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

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

В минимализме вся сложность прячется в высоком качестве материала, полировке и в новом развороте старой идеи. Это заметно в продуктах Apple и в продуктах японской дизайнерской компании Muji. Вся сложность и качество спрятаны внутри. Apple часто даже не рассказывает про свои новые функции, на них натыкаешься случайно и всегда радуешься, тот самый «дофаминовый выстрел» :)

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

Одним из носителей информации по поводу изменений обычно является версия продукта. Изначально номера версий были понятны — Word 6 становился Word 7, и это что-то говорило пользователю и было значимо. Потом номер версии ушёл из названия и стал дополнительным обозначением, сообщающим, что в продукте были произведены небольшие изменения, например, WinRar 2.1.

Затем появилась третья цифра, обозначающая багфикс. С этого момента пользователю стали показывать технические вещи, которые важны лишь для разработчиков. Апофеозом стал показ четвёртого числа после точки — номера сборки или ревизии кодовой базы в SVN. И что людям будет понятно из этого ряда цифр?

Мы решили нарушить эту традицию и сделать номер версии ясным для пользователя. Номер версии «Карамбы» — это дата производства продукта, как в глазированном сырке. Номер версии передаёт единственно важную и нужную информацию — о её свежести: Caramba Switcher 2019.06.20.

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

Это привело нас к понятию «right time» — времени, когда пользователю что-то может быть предложено, например, обновление. Обычно после совпадения нескольких паттернов: нескольких минут отсутствия активности работы на клавиатуре, кликов мышки, отсутствие показа видео.

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

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

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

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

Прилетают просьбы про совсем уж экзотический софт, а основную массу мы добавили за первый месяц после запуска. Так что «софт без настроек» — это не ущемление кого-то в правах, а совместная работа с пользователями для создания коллективного удобства для всех, кто пользуется Caramba Switcher!

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

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

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

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

В том числе проблема может возникать не только в софте и компьютере, но и в сознании пользователя. «Я вам вчера писал, что не переключает, извините! Сегодня я проверил — оказывается, что переключает!» Такие когнитивные глюки объяснимы — когда сидишь за компом без перерывов по 12 часов в сутки, то всякое возможно! Знаем по себе :)

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

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

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

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

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

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

Достаточно часто нам пишут: «Сделайте, чтобы значок был красного цвета», или «Хочу перевод транслита на лету». Сделать это мы, конечно, можем, но это придётся поддерживать в работоспособном состоянии годами. Что отвлечёт нас от по-настоящему важной задачи — качественного автопереключения.

Вот представьте, что основная функция автомобиля перестанет работать из-за того, что в него добавили, скажем, навороченный ароматизатор воздуха. Что скажут производителю люди, которые из-за этого не смогли попасть на работу? Конечно же: «Зачем вы этот ароматизатор туда добавили вообще?». А потому что люди просили!

Конечно, бывают приятные исключения. Недавно человек написал: «А вы кроме даблшифта оставьте Break на отмену, без всяких настроек, пусть будет два варианта, последний — для тех, кто привык». Вот это гениально и просто — и было сделано за две минуты. Мы сами почему-то не додумались.

Продолжая наше совместное путешествие по разработке и улучшению Caramba Switcher, мы сразу честно хотим сказать нашим теперешним и будущим пользователям, чего мы не имеем возможности делать — «новый, старый Punto». В «Карамбе» не будет: ручных настроек по включению и выключению множества опций, звуков, флажков, автозамены.

Всё это есть в уже существующих на рынке продуктах — в Punto Switcher, в Everylang, в Mahou. Это чудесные программы, и мы будем рады, если они подойдут вам больше.

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

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