Disclaimer Сразу говорю, что не претендую на профессионализм статьи, т.к. зеленоват ещё для авторитетности мнения. Тем не менее некоторые вещи успел повидать.
Часто на разнообразных форумах, посвящённых играм вижу такие жалобы "неужели разрабы не могли сделать нормально?!", да их все, наверное, видят. Только ленивый ещё не пожаловался на оптимизацию в PUBG и засилье читерами, на люто забагованный Fallout 76 и на глючную винду с её последними обновлениями.
Каждый знаток обычно анализирует так, что вот мол было вложено сколько-то денег, что мол занималась этим вот такая-то контора и все равно вышло хреново. И заключается все это объяснением, что "разрабы" просто хотели срубить бабла по-лёгкому и всех нас тут развели как лохов. Никого не хочу оправдывать. Все эти претензии реально имеют моральное право на существование, ибо, если за определённые деньги предлагают определённое качество, то хотелось бы его все таки получить. Но мне хочется рассказать от лица разработчика, как выглядят такие факапы и почему они могут случаться. И виноваты ли в этом "разрабы" и хотят ли именно "разрабы" навариться на пользовательском несчастье.
1. Руководитель проекта имеет мало опыта
Довольно очевидная прична, но неужели в команде не находится ни одного здравомыслящего разработчика, который что-то с этим сделает? Вразумит руководство, возьмет дело в свои руки? Что же они там, все бездари что ли? На самом деле вот вам пример. Команда делала веб-приложения. Руководство узнало, что с помощью специального инструмента можно превратить веб-приложение в приложение для iOS и Android с минимальными затратами. Один из разработчиков заметил, что это может выйти боком, так как технология необкатанная. Все же перевели, так как был аругмент "так дешевле", а разработчик не смог отстоять свое мнение в силу различных обстоятельств (но он и не обязан в конце концов). Первое время все работало неплохо. Потребовалось расширение приложения, но из-за ограничений изначальной технологии добавить новые функции быстро не получается, а если и получается, то появляются тормоза и баги. Приходится либо переделывать приложение с нуля на нативных технологиях целевых платформ, либо терпеть ненависть пользователей. Ну а пользователям в свою очередь остается терпеть баги и тормоза. Такие решения приходят в голову людям без опыта наступания на подобные грабли. Бывают, конечно, и удачные примеры таких приложений, а бывают и не не очень.
2. Недостаток финансирования
Опять же банальная версия, но мало кто понимает, как недостаток денег сказывается на процессе. Многие думают, что всё заканчивается на том, что просто нанимаются неопытные программисты, но это не всегда так. К примеру, команде для ускорения разработки нужно купить сторонний код, быстро работающий и уже отлаженный. При нехватке денег, команде придётся писать код с нуля, надеясь, что когда проект запустится, то из прибыли часть денег выделят на покупку уже отлаженного кода, который улучшит приложение. Этого момента можно ждать годами, пока пользователи страдают.
3. Предметная область приложения не основная для команды разработки
Это не значит, что разработчики плохие профессионалы. Взять и нанять новую команду с нуля очень сложно, а вот переучить текущую сложно, но не очень. К примеру, для разработки нового приложения в сфере авторемонта взяли как раз освободившуюся команду после проекта в сфере интернет-маркетинга. Разработчики применили предыдущий опыт на новом проекте, но некоторые нюансы оказались несовместимы с новой бизнес-моделью. Архитектура проекта получилась стройной, но сложной для расширения именно в новой области. Мы, как пользователи, видим это в медленной скорости добавления новых функций и исправления старых багов.
4. Ограничения технологий
Мало кто задумывается об этом, а тем не менее это довольно частая проблема. Частично она компенсируется опытом, но все предусмотреть невозможно, и уже доведённый практически до конца проект может сильно потерять в качестве. Например, вы делаете игру на каком-то движке. Вам необходимо для погружения создать хорошую затенённую локацию. Но есть проблема - текущая версия движка не поддерживает модель освещения, которая реализована в другом движке. Приходится писать свою модель. Об этом вы знали, и заранее заложили в конечные сроки этот момент. Но вот незадача, в процессе разработки этой модели, вы узнаете, что библиотека, которая дает вам доступ к графическим возможностям движка неверно реализует какую-то функцию. Вы пишете тех. поддержке движка, которая разводит руками и просит подождать до следующего релиза. Может полгода, а может год... До этого момента проект может не дожить, поэтому вы выпускаете неоптимизированное сделанное на коленке нечто.
5. Внезапные обновления ПО, на основе которого делается приложение Практически все программное обеспечение в мире зависит от какого-то другого программного обеспечения. Например, любая программа на вашем компьютере зависит от ОС. Очень часто приложения, которые вы используете строятся на основе каких-то других сервисах, о которых вы и понятия не имеете. К примеру, очень многие автоматизирующие офисную работу приложения используют внутри себя функции уже разработанных программ, таких как Exel и Word и если в них вдруг что-то поменяется, не так как вы ожидали, то вы ничего с этим не сможете сделать. Как примеру Kate Mobile ничего не смогла поделать с изменившимся VK API. Им просто пришлось выключить часть функционала.
Пост получился длинноватым, поэтому я разделю его на две части. Во второй части будут рассмотрены довольно неочевидные причины технического характера. Если статья вам понравилась, то напишите об этом или поставьте палец вверх, а если не понравилось, то тем более напишите. Буду благодарен за обратную связь. Всем спасибо за прочтение и удачи!
