Как определить, что нерентабельное изменение может быть прибыльным в долгосрочной перспективе? [закрыто]

Когда я пришел в компанию, там был проект, который коллега начал в том же году. Позвольте мне объяснить технический и нетехнический способ (выберите тот, который вы предпочитаете):

Технический фон

Наша компания хотела разработать мобильное приложение , и внешний консультант предложил использовать Cordova/Phonegap, так как он использовал его в качестве своего основного инструмента. Это позволило бы использовать принцип «код один раз, запускайте везде» и запускать его на Android и iOS, но время показало, что для настройки приложений требуется больше времени, чем ожидалось .

Кроме того, наш босс жалуется на проблемы с реагированием (например, отсутствие срабатывания кликов или зависание экрана на некоторое время) и проблемы, связанные с проблемами совместимости Cordova между различными устройствами.

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

Нетехнический фон

Наша компания хочет предоставить приложение, созданное с использованием действительно универсальной технологии. Это решение было принято, потому что нашему боссу сказали, что технология снизит затраты , если мы перенесем ее на Android и iOS. Однако после некоторого времени использования я увидел, что это не так уж и волшебно, и на самом деле требуется больше времени , чтобы «не сломаться» в каждом телефоне, который мы пробуем, а не создавать само приложение.

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

Вывод

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

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

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

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

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

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

Ответы (1)

Я использую полный стек Javascript, что позволяет мне пропустить проблемы, с которыми сталкивается ваша компания :) Сказав это:

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

  • У нативного подхода к приложениям есть свои недостатки, когда вам нужно разрабатывать и настраивать для каждой платформы отдельно. Если вы пойдете на Phonegap, вам придется пойти на компромисс. То же самое, если вы идете родным. В противном случае ничего не будет построено.

Решение, по какому пути идти, больше не техническое, а деловое. Деловое решение, которое допускает, что какой бы подход ни использовался, необходимо идти на необходимые компромиссы в интересах быстрого вывода продукта на рынок. Потому что, если он не выйдет на рынок быстро, у него есть все шансы быть убитым, а вместе с ним и ваша фирма, если это стартап.

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

Ваше руководство — это то, у кого есть все факты, и поэтому оно должно принимать решение. Им придется смириться со своим решением, и если дела пойдут наперекосяк, пасть вместе с ним. На данный момент они могут быть уже слишком глубоко, чтобы изменить свой подход.

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

+1 За то, что подчеркнули это как деловое решение. Большинство людей, которые хотят разрабатывать мобильные приложения в нативном коде, не выписывают чеки.
Хорошая метафора для работы с клиентами. Я бы предпочел рассматривать это как перезагрузку приложения, поскольку мы уже в сети с тысячами клиентов. Итак, мой вариант, наконец, просто представить это как функцию, о которой стоит подумать и надеяться на лучшее?
@korcholis Вопрос в том, есть ли у руководства время и ресурсы для выполнения перезагрузки, за которую вы выступаете, и если да, то не лучше ли выделить время и ресурсы для обеспечения работы существующего подхода? :) Это суждение, и опять же, руководство должно быть тем, кто сделает это лучше или хуже.