Российское ПО или каково пить сладкий чай без сахара
Этот велосипед формально на ходу, на нём можно приноровиться ездить. С потерями и ранами, но можно. А нужно?
Когда-то давно я решил пить чай и кофе без сахара. На первых порах было очень сложно и выручал дорогой сахарозаменитель в микротаблетках: 2 штуки и прямо сладко. Очень быстро я стал замечать, что вкус напитков испортился, появилась какая-то неприятная, неописуемая химозинка, которая потом долго держалась во рту и вызывала жажду. Попробовал другой — тот же эффект. В итоге после пары месяцев мучений, стевии и прочих сладких добавок я стал наслаждаться всеми видами чая без сахара, а кофе бросил и пью редко, но с обычным сахаром — вкусно! И если вы думаете, что статья про лишний вес или сахарный диабет, вы ошиблись. Статья про заменители. Точнее, про российское программное обеспечение. Как вы поняли, и сладко, и, похоже, но есть та самая химозинка. Из-за которой противно употреблять. Попробуем разгадать её формулу.
Я нашёл девять слагаемых этой формулы. И они меня, откровенно говоря, опечалили. Скажу сразу, я субъективен и не работал с ПО всех типов и не говорю, что все в чём-то нехороши — например, я видел удачные российские системы управления сервисом, ITSM, CRM, ERP, BPMS и т.д. Но и в эти добротные системы проникает особый дух отечественной разработки, отчасти связанный с пожеланиями пользователей. Впрочем, обо всём по порядку.
И так сойдёт
Это едва ли не главная проблема отечественной разработки. Конечному пользователю предлагается то программное обеспечение, которое ему нужно, но при этом нет ни протестированного UI/UX, ни обкатки на бета-версии, ни продуманных элементов управления. Фактически пользователь получает функцию, которая ему нужна, а удобная она или нет — дело второе. И чем уже и профильней программное обеспечение, тем больше разработчику плевать на пользователя. Есть конкуренция, есть строгие правила стора или маркетплейса — всё будет совершенно иначе, интерфейс будет продуман, протестирован и раскатан постепенно, со сбором багрепортов. Нет конкуренции (ПО для узкопрофильной деятельности, например, заводов, медицинских центров и т.д.), можно сделать абы как: им нужно, они разберутся. А потом, конечно, много удивления, почему простые пользователи приходят на профильные форумы и таки проклинают поделие, в котором приходится ежедневно работать.
Главное — продать
Вот она, заветная формула! Не буду томить вас ожиданием, но это основное отличие многого российского ПО от зарубежного: они ищут путь улучшения, наши ищут путь продажи. Иногда даже удивляешься, как в компании с весьма посредственным программным продуктом оказываются отличные продажники, которые светят лицом на мероприятиях, готовят офигенные стенды для выставок, пилят приятные и увлекательные рекламные материалы. В общем, благодаря им блестит всё, пока не сунешься внутрь. Кстати, в российской бизнес-ментальности меня всегда поражала способность и готовность купить программное обеспечение без тестов и сбора требований — просто как колбасу в магазине: «Беру!». Конечно, такое поведение покупателей не добавляет программистам стимула позаботиться о нормальной версии. Хотя я видывал вещи и похлеще: программисты заботились о демо-версии и демо-базе, а потом софтина на первых 200 записях крашилась и подвешивала всю систему. К счастью, в конце 2010-х контора прекратила своё существование.
Контрпример из разработки для европейского рынка (команда смешанная): релиз программы для В2С-рынка откладывался 34 дня, потому что команда разработчиков, дизайнеров и клиентских менеджеров не могла выбрать нужное расположение и цвет кружочка, по нажатию на который — выпадает основное меню программы.
А давайте прикроем то, что не очень?
Если программное обеспечение рассчитано не на узких специалистов, а на более или менее широкий сегмент (руководителей, менеджеров и т. д.), наступает время подсыпать на фронтенд алмазной пыли — навести внешнюю красоту, чтобы прикрыть кое-какие косяки функциональности. В начале 2000-х в моде были виджеты валюты, погоды и часов, сейчас на смену им пришли красивые дашборды и графики. Как правило, эти элементы производят вау-эффект на управленцев нетехнической сферы, которые прямо на презентации прикидывают, как эти столбики будут смотреться на большом экране в переговорке. А должны прикидывать, соответствует ли софт требованиям и как скоро окупятся инвестиции в него.
Самое лютое из «столыпинских деревень», что мне приходилось видеть в ИТ, это нарисованный перевёрнутый треугольник вместо реальной воронки продаж — то есть пользователи вносили данные в систему, а картинка не менялась, потому что статичная. Я своим глазам не верил! Кстати, в 2020 году эта штука ещё была на месте. А это значит что? Значит, разработчик этой программы как-то выживает, кто-то покупает… В общем, ой.
Я так сказал!
Да что вы знаете о роли личности в истории, если ваш начальник не кричал, что будет только так, как считает он, потому что он молодец, а вы сперва свой бизнес откройте… Слышали такое? Я — да. Иногда руководители смотрят на пользователей из своего кабинета или судят о них, например, по статьям на Хабре, или считают откровенными дурачками (или, наоборот, компьютерными гениями). Они уверены, что знают о паттернах поведения всё и навязывают своё мнение, не слушая остальных. Разубедить — невозможно. А потом пользователь вообще не может понять, для кого разрабатывалась программа, требует обучения, жалуется на профильных сайтах и отзовиках. Короче, у пиарщиков таких компаний всегда много работы.
Мечтатели
Абсолютно оторванная от земли категория разработчиков. Именно они могут впихнуть в обычный корпоративный софт нейросети, обработку датасетов, предиктивную аналитику и т. д. Для них разработка — настоящая олимпиада, в которой они день за днём побеждают себя. Сильные команды, красивый код, отлаженный и безупречный бэкенд…
А конечный пользователь учитывает в системе ящики с шампунем, мылом и стиральным порошком и ужасно страдает от того, что не работает почта и интеграция с телефонией. И ему совершенно наплевать на Байеса, математику, нормальное распределение и озёра данных, потому что он ими не пользуется. А его вендор или даже внутренний разработчик играет в разработку программы для межгалактической корпорации. Ему важно набить свой софт необычайно крутыми кишочками —, а проще говоря, он не анализирует и не рассматривает требования, он тупо разрабатывает то, что ему интересно и нескучно. А копаться в Астериске и почтовых API — ппц как скучно. Это, конечно, задача для плебеев, гений должен заниматься высоким. Если в команде не найдётся приземлённых спасителей, остаётся убеждать клиента, что Байес гораздо важнее прохождения и записи звонков. Это же Байес, теория вероятности! Ничего вы не понимаете в колбасных обрезках…
Плохое тестирование
Творец сотворил программу, творец отдыхает, какая к чёрту верификация?! Я знаю немало компаний, программное обеспечение которых не просто существует, а на слуху, но при этом не тестируется профессиональной командой QA. Нет, конечно, там нет концепции «фигак-фигак и в продакшен вечером в пятницу», но тестируют либо сами разработчики, либо сотрудники компании, либо группа самых лояльных клиентов (лояльность обычно покупается за большую скидку или бесплатную поддержку).
Такой подход к контролю качества приводит к неожиданным багам, которые вылезают на живом проде и колом ставят работу у того клиента, кто отловил и воспроизвёл — как говорится, нашёл критикал — заслужил перерыв. Сомнительная экономия на тестировании приводит к недоверию со стороны пользователей, потере времени на отладку, фикс и апдейт, а также к совершенно авральным и скандальным часам исправления всех проблем впопыхах. Клиенту при этом совершенно наплевать на политику разработчика, ему нужен просто нормально работающий софт. Да, даже если он бесплатный, потому что корпоративный сектор весьма нехило платит за техническую поддержку «опенсорса». Почему я говорю про корпоративный сектор? Всё просто: обычный, частный пользователь после пары глюков просто забросит некомфортное приложение и поищет аналог.
Молодая динамичная команда…
…потому что опытного разработчика мы не потянем. Есть компании, в которых опытных разработчиков на руках носят — вы легко вспомните В2С-сервисы, финтех и ритейл, где всё хорошо. Это видно по продукту. А есть компании (крупные в том числе), где дешевле взять пучок программистов, обучить, выжать из них человекочасы и объём кода, а потом уже мидлами выпустить в рынок, потому что им нужно развитие, в том числе материальное. Обычно в таких компаниях есть 1–2 опытнейших тимлидов и куча падаванов, которые кодят, что скажут, и особого голоса в проектировании не имеют. Разумеется, архитектура приложений, код и качество программ от этого лучше не становятся.
Автоматизация = ручной работе
Увы, есть программы как в бизнес-секторе, так и в инженерной и промышленной среде, где руками быстрее или как минимум — столько же по времени. Иногда настолько долго обрабатывается информация (право, кому нужен этот рефакторинг!), иногда нужная информация или функций скрыта в дебрях кликов (и снова непродуманный UI/UX). К счастью, такие программы я встречаю всё реже, но тем не менее они существуют как в частном секторе, так и в коммерческом. Надеюсь, разработчики читают Хабр и обратят на это внимание.
Нет вопросов, иди и фигачь
Наконец, компании-разработчики не задумываются о двух важнейших вопросах: почему мы создаём этот софт и для кого будет работать приложение? Если нет понимания того, какие именно группы пользователей будут у программы, что они хотят от разработки, что их замотивирует выбрать именно это ПО, когда похожих больше десятка, вендору на рынке будет плохо. Адаптация решения и его политики коммуникации под конечных пользователей — залог дружбы и успешного старта работы с приложением. Остальные пункты, изложенные выше, следуют потом.
А вот понимание «почему» компания далась в ту или иную разработку, даёт понимание целей и проблем, которые программа будет решать. Ответ на этот вопрос даёт свой дух и идею. Особенно это чувствуешь, когда заходишь в команду, работающую за границей (или — парадоксально — в российскую, работающую на импорт), и в отечественную команду. В первом случае идея и дух включены в действия каждого сотрудника («я знаю, для кого я это делаю и зачем»), во втором — «концепция и дух не для суровых самураев».
На самом деле, я, вероятно, местами пережал и учёл свой опыт лет за 10. В последнее время мне нравится всё больше российского ПО. Однако вкус сладкий, но химозинка по-прежнему остаётся. Думаю, сейчас, в условиях снижения конкуренции, возможны варианты как улучшения разработки (во избежание конкуренции с новичками рынка), так и ухудшения (а куда денутся). Думаю, в зависимости от сектора и текущего расклада на рынке будут и те, и те случаи. Надеюсь, хотя бы покупатель и пользователь научится разбираться. Но об этом — в следующий раз.
