Перечень проблем в разработке ПО

Хорошая заметка про разработку в "Российское ПО или каково пить сладкий чай без сахара". https://habr.com/ru/company/ruvds/blog/672530/

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

И так сойдёт

Конечному пользователю предлагается то программное обеспечение, которое ему нужно, но при этом нет ни протестированного UI/UX, ни обкатки на бета-версии, ни продуманных элементов управления. Фактически пользователь получает функцию, которая ему нужна, а удобная она или нет — дело второе.

Есть конкуренция, есть строгие правила стора или маркетплейса — всё будет совершенно иначе, интерфейс будет продуман, протестирован и раскатан постепенно, со сбором баг-репортов.

Главное — продать

Одни ищут путь улучшения, другие ищут путь продажи.

А давайте прикроем то, что не очень?

Если программное обеспечение рассчитано не на узких специалистов, а на более или менее широкий сегмент (руководителей, менеджеров и т. д.), наступает время подсыпать на фронтенд алмазной пыли — навести внешнюю красоту, чтобы прикрыть кое-какие косяки функциональности. В начале 2000-х в моде были виджеты валюты, погоды и часов, сейчас на смену им пришли красивые дашборды и графики. Как правило, эти элементы производят вау-эффект на управленцев нетехнической сферы, которые прямо на презентации прикидывают, как эти столбики будут смотреться на большом экране в переговорке. А должны прикидывать, соответствует ли софт требованиям и как скоро окупятся инвестиции в него.

Я так сказал!

Иногда руководители смотрят на пользователей из своего кабинета или судят о них, например, по статьям на Хабре, или считают откровенными дурачками (или, наоборот, компьютерными гениями). Они уверены, что знают о паттернах поведения всё и навязывают своё мнение, не слушая остальных. Разубедить — невозможно. А потом пользователь вообще не может понять, для кого разрабатывалась программа, требует обучения, жалуется на профильных сайтах и отзовиках.

Мечтатели

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

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

Плохое тестирование

Творец сотворил программу, творец отдыхает, какая к чёрту верификация?! Я знаю немало компаний, программное обеспечение которых не просто существует, а на слуху, но при этом не тестируется профессиональной командой QA. Тестируют либо сами разработчики, либо сотрудники компании, либо группа самых лояльных клиентов (лояльность обычно покупается за большую скидку или бесплатную поддержку).

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

Молодая динамичная команда…

…потому что на опытного разработчика мы не потянем. Есть компании, в которых опытных разработчиков на руках носят — вы легко вспомните В2С-сервисы, финтех и ритейл, где всё хорошо. Это видно по продукту. А есть компании (крупные в том числе), где дешевле взять пучок программистов, обучить, выжать из них человекочасы и объём кода. Разумеется, архитектура приложений, код и качество программ от этого лучше не становятся.

Автоматизация = ручной работе

Есть программы как в бизнес-секторе, так и в инженерной и промышленной среде, где руками быстрее или как минимум — столько же по времени. Иногда настолько долго обрабатывается информация (право, кому нужен этот рефакторинг!), иногда нужная информация или функций скрыта в дебрях кликов (и снова непродуманный UI/UX).

Нет вопросов, иди и фигачь

Компании-разработчики не задумываются о двух важнейших вопросах: почему мы создаём этот софт и для кого будет работать приложение? Если нет понимания того, какие именно группы пользователей будут у программы, что они хотят от разработки, что их замотивирует выбрать именно это ПО, когда похожих больше десятка, вендору на рынке будет плохо. Адаптация решения и его политики коммуникации под конечных пользователей — залог дружбы и успешного старта работы с приложением.

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

Еще раз упомяну - по мотивам "Российское ПО или каково пить сладкий чай без сахара". https://habr.com/ru/company/ruvds/blog/672530/