«Принцип занозы». Истории Caramba Switcher
Заметил, что в работе над IT-проектами любят эффективность решений оценивать статистически — в процентах. «Увеличили что-то на четверть процента» — часто можно такое услышать. Понятно, что при миллионах потребителей это вопрос прибыли, и даже четверть процента означает серьезные деньги. Двигаясь в этом, вроде бы успешном, направлении, не замечают как начали насиловать пользователей каким-то нечеловеческим решением, улучшающим набор средневзвешенных числовых показателей. И когда пользователи вдруг начинают уходить, всем внутри проекта как-то непонятно, почему:)
Человек – это не цифры и не график на доске. Любое биологическое существо живет по особенным законам. Простой пример: заноза по отношению к телу человека имеет ничтожные размер и вес. Но если такая крошечная заноза оказалась в пятке, то она выключит человека из нормального состояния — он не сможет ходить!
Есть люди, которые собрали множество интересных материалов, много знают глобального, но когда сами берутся что-то делать – по однозначно правильным рецептам, – то что-то все равно не получается. Мне видится, что одна из причин в непонимании «принципа занозы». Даже в большом проекте на миллионы пользователей, несущественная мелочь может запустить процесс разрушения проекта. Именно биологическое отторжение может создавать неприязнь к продукту.
Незначительное на вид неудобство делает продукт непригодным для использования, и то, что сперва приносило небольшое разовое повышение прибыли, оборачивается материальными и репутационными убытками на десятки процентов. Чаще всего причиной такого фиаско становится корпоративный бюрократизм, размывающий видение того, каким должен быть продукт. Все фокусируются на процессе и его обслуживании, и заноза плавно проскальзывает в пятку пользователя, затерявшись среди KPI менеджеров и техлидов.
Однако бывает и так, что проблему создает не корпоративизм в целом, а один лояльный компании, но, при этом, не очень умный сотрудник. Таких примеров я повидал много – приведу в пример один из них.
У одной большой компании была потребность серьезно продвинуть свой продукт. При этом было легко определить людей, которые этим продуктом уже пользуются, и не тревожить их лишний раз. Но один сотрудник компании, достаточно далекий от принятия серьезных решений, но тем не менее обладавший определенной свободой действий, считал, что такая проверка не нужна – "слишком сложно", или "сейчас не время этим заниматься", или "да что там, пользователь еще разок увидит, не беда". Стоит ли говорить, что подобные мелочи привели к тому, что за несколько лет репутация компании в этой области была испорчена. Что самое удивительное – эти решения принимались не теми людьми в компании, которые реально могли бы увидеть их несуразность. То, что злило пользователей годами, появилось сугубо из-за фантазий одного сотрудника, который с молчаливым упорством, и ссылаясь на придуманные проценты, отстаивал свое желание ничего не делать и ничего не менять. Именно такое решение для многих пользователей стало "занозой", убрать которую в принципе можно было пятью строчками кода.
Конечно, случаются большие принципиальные ошибки в планировании, заблуждения системных архитекторов и разработчиков, ссоры основателей, "героические подвиги" типа разделения приложения Foursquare на 2 недо-приложения – но множество проектов получили смертельную занозу и погибли из-за мелочей, которые были легко устранимы.
Недавний собственный пример. При разработке Caramba Switcher мы приняли решение слова-исключения собирать автоматически без прямого вмешательства пользователя. Это удобно для тех, кто не хочет тратить время разбираясь с настройками программы – таких большинство. Обычно в такие исключения люди руками добавляли аббревиатуры, что логично и понятно – никакая языковая модель их нормально не опишет. Мы сделали так, что Caramba Switcher запоминает их самостоятельно, составляя локально на каждом компьютере уникальный пользовательский словарь. В исключения мы решили закидывать слова, которые пользователь исправил после автопереключения – либо стерев и перепечатав, либо исправив через Double Shift. Самообучение происходит по особой, непростой логике, исключающей возможность испортить логику основного блока автопереключения. Но вдруг выяснилось, что особой категорией являются логины, которые вводятся при регистрации или при входе на сайт. Емейл определяется сравнительно легко — по наличию @ и по наличию top-level домена .com, .ru, а вот логин набирается строчными буквами и может содержать в себе аномалию для английского или немецкого языка, и поэтому будет переключаться в русский. Вроде бы мелочь (казалось бы, кто сейчас пользуется логинами, когда есть кнопка "войти через Facebook"?) – но у некоторых пользователей это приводило Caramba Switcher в состояние непригодное для работы. Человек не будет менять свой логин, которому много лет, а скорее откажется от новой программы. Часто логин нужен при работе в корпоративном окружении – для входа на рабочие платформы или порталы – и его приходится вводить по много раз в день… В общем, мы эту проблему идентифицировали благодаря нашим верным пользователям.
Вот пример "занозы" – увидеть её или случайно догадаться было бы трудно. И даже увидев, можно недооценить и отложить исправление, ведь в общей массе кода Карамбы — это мелочь, так как нужно изменить всего пару логических условий… Нет, вынимать занозу нужно сразу же! Потому что всё, что взаимодействует с человеком, начинает жить по биологическим законам, а не по законам математики, статистики и формальной логики.
Публикуя истории на vc.ru, мы хотим предоставить возможность людям следить, как развивается наш стартап по созданию автоматического переключателя Caramba Switcher. Как на развитие продукта влияют различные объекты и ситуации, с которыми наша команда встречается в повседневной жизни.