Вы читаете очередной, третий по счёту, пост цикла, посвящённого ошибкам при создании цифровых продуктов. Сегодня я расскажу о классическом случае неверного выбора средств программной реализации - и если вы думали, что это касается только разработчиков, то обязательно дочитайте статью до конца. Благо, она совсем короткая.
Вводные
Эта история случилась в тот прекрасный период, когда я активно занимался консалтингом: помогал разным компаниям и стартапам налаживать процессы, CX/UX и выстраивать разработку. По понятным причинам каждый раз мне приходилось довольно глубоко погружаться в новый проект. И каждый раз я сталкивался с одним и тем же: команда разработки вообще не была в курсе проекта. То есть, они, конечно, понимали, что делают: у них были сценарии, макеты, концепция, даже функциональное описание системы. Но они совершенно не знали, куда движется этот поезд.
В тот раз меня пригласил бывший клиент. Он запускал новый бухгалтерский стартап, и где-то посередине разработки у него возникли сомнения, что всё идёт по плану. Моей задачей было быстренько провалидировать процессы, пощупать UX, помочь с выбором ряда DevOps-решений. В сам код лезть было не нужно. Но я, конечно, не удержался.
И не зря.
Не стану описывать все косяки, которые всплыли в процессе, приберегу их для следующих постов. Нас интересует только один, технический. Но чтобы рассказать о нём, сперва придётся кратко изложить суть продукта.
Команда разрабатывала мобильное приложение, которое, среди прочего, умело распознавать QR- и штрих-коды. Вообще, это не являлось главной функциональностью, но работа с камерой насквозь пронизывала все пользовательские сценарии. И распознавание было одним из трёх потенциальных векторов развития продукта.
Клиент всё правильно спланировал: сначала выпускался "пилот" (такой MVP на стероидах), в котором было "ядро" и несколько "щупалец". После запуска и ряда исследований можно было с уверенностью решить, какое из "щупалец" нужно развивать. Так вот сначала приложение должно было уметь читать только коды, но потом дело могло дойти до распознавания специальных таблиц и даже произвольного текста.
Что-то пошло не так
Как вы уже, вероятно, догадались, проблема крылась в выборе программного модуля для распознавания информации на фотографиях.
В наше время никто не пишет весь код "с нуля". Даже коммерческий, даже на небольших проектах. Человечество накопило достаточно готовых решений на все (или почти все) случаи жизни. Вопрос только в том, подходит ли оно вам и совместимо ли с тем, что уже внедрено в продукт. Если очень сильно упростить, то большинство программ сейчас создаётся из готовых "кирпичиков", а разработчики лишь пишут "цемент", чтобы эти "кирпичики" между собой сцепить. Я не принижаю роль программистов, ведь кто-то же создал эти "кирпичики", да и порой "цемента" в проекте куда больше. Ну и UI, понятное дело.
В общем, на том проекте для распознавания кодов использовался как раз такой "кирпичик". Он умел классно и быстро выполнять свою работу, но имел очень небольшой набор функций. Расширить которые было никак нельзя из-за ограничений в лицензии. А на нём, между прочим, была так или иначе завязана добрая треть ключевых функций приложения.
Понимаете, к чему клоню? Стартап жив, пока он динамичен и мгновенно реагирует на изменения рынка или новые вводные. Если бы после релиза и исследований выяснилось бы, что приложению нужно-таки распознавание таблиц, то пришлось бы искать новый плагин распознавания, более гибкий. И у бизнеса оказалось бы только два пути:
- Заменять старое решение на новое и переписывать все места, где использовался атавизм – это долго, дорого и больно.
- Ставить новое решение "рядом" со старым и городить костыли, чтобы их подружить и обеспечить единое пользовательское взаимодействие – а это уже полный провал при развитии и поддержке продукта.
Клиенту очень повезло, что мы выяснили этот момент до завершения разработки и релиза. Сэкономили некоторое количество времени и денег. И да, спустя полгода приложение отрастило-таки "щупальце" с распознаванием таблиц. Мои старания не были напрасны.
Выводы
На самом деле, эта статья не об ошибке выбора плагина. Эта статья о том, что единое информационное поле всех участников команды – необходимый атрибут успеха продукта. Что доносить проектную идеологию и планы по развитию нужно не только аналитикам и дизайнерам, но и тем, кто, казалось бы, просто пишет код по готовым сценариям.