Давайте разбираться, что есть мобильное приложение нативным методом.
Всё просто! Нативный метод - это способ разработки продукта (мобильного приложения, онлайн сервиса). Такой метод характерен тем, что для каждого типа устройства и операционной системы пишется код на родном для них языке.
Ну во-первых: у iPhone и MacBook, например, не смотря на одну операционную систему, будут РАЗНЫЕ коды (язык один, а вот написано будет по-разному), написанные разными командами.
В своё время, лет 15-20 назад, мы боролись с устойчивым мифом о том, что сайт должен писать только программист! А лучше компания программистов! А сайты на конструкторе - это фу! Время шло и сейчас уже нормально и естественно воспринимается лендинг (сайт-визитка, сайт для продажи одного продукта) или полноценный сайт (с онлайн записью, личным кабинетом и интерактивным блогом) на Тильде. А скольких нервов стоило убедить заказчиков не тратить деньги на "настоящий" сайт в 2015 - уму не постижимо!
Конечно, мы сейчас говорим о уместности такого решения даже сегодня, когда технологии конструкторов практически всеобъемлющие. Проще говорить о ситуациях, когда решения действительно требуют того самого нативного кода и КОМАНДЫ. Это, кстати, вторая боль, так как стереотип о том, что команда, которая разрабатывает ваше мобильное приложение - это группа талантливых гиков из 70 человек, которые отрываются от вашего детища лишь под утро, чтобы хлебнуть матчи с топинамбуром, сидя в кресле-мешке. Такой образ долго и старательно рисовался нам из офисов гуглов и яндексов, а сегодня, кстати, они так отчаянно режут раздутые штаты сотруднков, аж свитера с вейпами разлетаются.
Но образ создан. И только так представляется команда, способная произвести хоть жалкое подобие автономному сайтику, открывающимуся по нажатию на отдельную иконку в вашем телефоне. Не более. Не более.
Забудьте)) Образ старательно поддерживается компаниями, которые разрабатывают приложения и сервисы на заказ, чем и живут. Вот у них и есть большие команды, так как единовременно может быть до 10 мелких заказов, а в промежутке эту ораву нужно кормить. При том еще и официально: по закону их заработная плата (в зависимости от региона) не может быть ниже 150 000₽ (это + 50 000₽ налога), а штат компании, например, для реализации тех же 10 заказов, составляет 40 человек. Потому и не воспринимается всерьез команда меньшая по составу. По опыту скажу, что один проект - это 10 человек для разработки и 3 для развития. Даже ооооочень большого проекта. Ужас, да?
Мир уже давно изменился и разработка разделилась на программистов, айтишников и вайбкодеров. О них я еще расскажу. Вовзращаемся к нативной разработке. Итак, что из себя это представляет, что это за 10 (на самом деле 7) волшебников?
Зарплаты пока не считаем, так как в нативной разработке участвуют программисты, а они не по 150. Увы, но они стоят своих денег. Только давайте без волшебных слов и заколдованных терминов, чтобы вас лишний раз не путать. Профессионализм... Он ведь в другом выражается, а не в навязчивой идее через слово вставлять: "разраб на свифте и кодер на яве выкатили на прод пятый релиз без комита лида". Ну никто так не хочет общаться! Даже внутри команды мы используем имена :)
Мы себе сейчас представляем прямо огромный и полноценный проект типа инстаграмов. Кто нужен, чтобы получилось. Блин, еще один комментарий: помним про одну женщину и 9 месяцев на то, чтобы родить и 9 женщин, которые нифига этот процесс не ускорят. Тут примерно тоже самое. Главное - это добиться синхронности при разработке функционала у мобильной версии и онлайн.
- Мобильная разработка. 2 разработчика для iOS и Android отдельно (пускай, как в нашем случае, это будут Swift и Kotlin, соответственно (языки программирования)). Два специалиста могут всё. Просто поверьте. У них есть уровни профессионализма (Джуниор, Мидлы и Сеньоры), но, за исключением официальной сертификации, иногда и джун может очень здорово справляться под качественным руководством. Это два специалиста, которые будут заняты одним проектом всё свое рабочее время до этапа запуска.
- Фронты. 2 разработчика. Эти ребята, синхронно с мобилками, пишут веб-версию и отдельную часть для управления (админку) всем сервисом. Языки варьируются относительно поставленных задач, но это точно React.
- Бэки в колличестве 2 экземпляра. Тут тоже язык может использоваться разный, но Phyton и Java - классика. В целом, они тоже заняты все время, но занимаются более точными штуками: все сложные функциональные узлы (интеграции, платежи, аналитика) соединяют между собой и проверяют на точность.
- Дизайнер. В идеале - это один человек, но какооооой! Как в мемчике: дизайнер один, проекта три :) Дизигнер заранее уже всем и всё подготовил, сдал, защитил, поплакал, переделал, ещё раз показал, подрался с фронтом, поплакал и ещё раз переделал. А потом пришёл заказчик и попросил белый фон заменить на более светлое что-то.
Почему речь изначально шла о десяти специалистах? Есть еще три важных момента во всей этой, пока красивой и несложной, истории: тестирование, продвижение, управление. Это, как правило, группа из 6-8 человек, которые перманентно ведут и развивают все проекты конторы. И к вашему проекту они будут подключаться, а не дышать вашим потенциалом (филантропа, миллионера и красавичка) круглые сутки.
Тестирование - очень важная часть проектирования и касается она не только того, на сколько все кнопочки правильно работают, но и как интерфейс "ведёт" пользователя, как система ведёт себя при ошибках от интеграций, как при огромных нагрузках, как при ошибках пользователя (отвал сети, слабый смартфон, кривой палец) - это всё, что обеспечивает жизнь проекту и тестирование не всегда - автомат.
Продвижение: тут очень много векторов работы скрывается, но попробуем тезисно сформулировать, чтобы понять, что входит. Анализ ДО начала всех работ, чтобы понять, как устроен рынок, на который вы нацелились: от начала, до его перспектив. Анализ конкурентов ( и гипотетических в том числе: среди тех, кто может за счет функциональных доработок встать в вашу лыжню) по бюджетам, аудитории, визуальному представлению - тут все рассматривается под микроскопом с отслеживанием и косвенных факторов, чтобы посмотреть или представить гипотетически их процессы эволюции (ошибки, удачи, стагнации). Ох, много описывать, лучше, если я сделаю отдельный пост на эту тему. В итоге, маркетологосеоасо специалист даёт так называемую "карту" проекта для всех участников аттракциона о том, что это должно быть для достижения цели, поставленной заказчиком (это не "зеленые кнопки" и "лента как в инсте, но не с сердечками-лайками, а с птеродактилями", а то СКОЛЬКО ДЕНЕГ И К КАКОМУ СРОКУ хочет получить заказчик). А дальше спецы следят за выполнением стороной заказчика всех точек на маршруте.
Управление. Это про сервер. Это про аренду функций у монополистов (онлайн платежи, карты и т.д.). "Держать" проект с большой нагрузкой - это очень дорого. очень. Ооооочень. Икс три к вашему бюджету на разработку - это смело. Это сразу, даже не стесняйтесь. И тут не только объем фоточек и самих юзеров, тут и аналитика, и обеспечение всего того, что бэкендеры наделали (п.3), и продвижение. Это дорого, сложно, но очень интересно. Тут и современные технолоджии в помощь, но с правильным их применением.
Не хотелось никого отговаривать или пугать, а хотелось рассказать о собственном опыте при создании большого сервиса, когда, казалось, что уже ну всё понятно и известно: что и как создаётся, разрабатывается, проверяется и запускается.
Отдельная часть всей этой истории больших проектов - это юридическая сторона. Вот об этом точно буду отдельно писать, так как вопрос важный и всеми тщательно скрываемый почему-то. Вот помахали перед вами NDA и вы успокоились, а зря :)
#revolution #reekb.ru #нативнаяразработка #itкомпания #мобильнаяразработка #max #нативкроссплатформа #swift #kotlin #разработкамобильныхприложений
Если удобней в ЖЖ читать, то вот: читать в живом журнале