Мы живем в век высоких технологий. То, что буквально вчера делали руками, сегодня автоматизируется и робототизируется. ИТ-специалисты по праву становятся самыми высокооплачиваемыми профессионалами в мире, число айтишников с каждым днем растет.
Но насколько глобальный IT-прогресс касается России? Удается ли стране продавать высокие технологии за рубеж с таким же успехом как нефть и газ?
В стране с ИТ все очень скромно
Если на 2018-2019 годы в России пришелся пик развития высоких технологий, то с 2020-го ИТ-отрасль плавно погрузилась в стагнацию. Ее доля в ВВП снизилась с 2,9 % до 2,8 %. Но это еще не предел — к 2025 году ожидается снижение показателя до 2,6 %. Для сравнения — данные по ВВП Соединенных Штатов:
• 2018-2019 — 6,5 %;
• 2021 — 6,8 %;
• 2025 — 7,2 %.
Медленное развитие ИТ-отрасли в России напрямую связывается с экономическим кризисом из-за глобальной пандемии коронавируса. Но эксперты подчеркивают, что высокие технологии в РФ все-таки не безнадежны: и стартапы, и серьезные предприятия демонстрируют активный интерес к облачным технологиям, машинному обучению.
Предполагается, что Россия займет достойное место в «гонке вооружений» по созданию сверх масштабных моделей машин. Но это только прогнозы. Настоящий уровень развития ИТ в России оценивается как очень скромный. Виной тому — два важных фактора:
1. ИТ-компании «с русскими корнями» в первую очередь заинтересованы вести деятельность за рубежом, ведь это шанс привлечения хороших инвестиций. Получается, что де-факто успешный проект российский, а де-юро — иностранный.
2. Действующие ИТ-компании проводят реорганизацию, открывая свои фирмы за рубежом в целях оптимизации налоговых платежей. Хоть в РФ существуют свободные экономические зоны, нельзя сказать, что в стране созданы все комфортные условия для развития сферы высоких технологий.
Как исправить ситуацию? Специалисты называют несколько путей:
• обеспечение честной конкуренции на рынке IT-услуг;
• корректировка торговой политики государства;
• вытеснение с арены иностранных компаний, уклоняющихся от уплаты налогов в российскую казну.
5 главных проблем российской ИТ-сферы в 2021 году
Несмотря на то, что в период локдаунов возрос спрос на онлайн-платформы, мобильные приложения и онлайн-услуги, сфера высоких технологий начала 2021 год с серьезными проблемами:
1. Урезание бюджетов. На такие меры пришлось пойти порядка 70 % работодателей: из них 30 % сократили бюджеты на 10-25 %, а 10 % — на 25-50 %. Причиной стали длительные локдауны, необходимость перевода ответственных работников на удаленку, многократное увеличение расходов на ПО.
2. Уменьшение доли инвестиций. Из-за той же пандемии инвесторы менее охотно принимают решения о вложениях в стартапы, тщательно изучают проект перед инвестированием. Только в 2020 году объем вложений в российские ИТ-стартапы (по сравнению с 2019-м) уменьшился с 497 млн долларов до 183,8 млн долларов. Причина — не только в российском, но и в общем, глобальном экономическим кризисе.
При больших проблемах с экономикой вложения даже в самую перспективную сферу в любом случае будут снижаться.
3. Недостаток высококлассных специалистов. Компании борются за настоящих профессионалов на международном уровне. Чтобы не остаться без кадров, отечественным работодателям нужно выстроить собственную систему обучения и подготовки талантливых специалистов. Свой вклад должны внести и сами айтишники — они не смогут стать востребованными, если не начнут заниматься непрерывным самообразованием.
4. Угрозы кибербезопасности. Для 11 % компаний кража конфиденциальной информации, риски взлома внутренних систем стали проблемой №1.
5. Усталость от коронавируса. Нескончаемые карантины, локдауны не прошли бесследно и для самих работников. В обществе до критической точки нарощена усталость от пандемии и связанных с ней ограничений. Необходимость работы из дома, невозможность личного общения с командой, потеря социальных связей негативным образом сказываются и на эффективности, и на лояльности сотрудников.
Так как ИТ-сфера — самая прогрессивная в мире, ее специалисты первыми почувствовали на себе психологические последствия от пандемии. Чтобы удержать ценные кадры, российским компаниям нужно внедрять новые прогрессивные системы мотивации.
ИТ-специалистов становится все больше
Впрочем, есть и позитивные изменения: с каждым годом количество отечественных ИТ-специалистов стабильно увеличивается. Россия входит в пятерку стран Европы, лидирующих по росту айтишников:
1. Германия.
2. Великобритания.
3. Франция.
4. РФ.
5. Нидерланды.
В сравнении с Соединенными Штатами ситуация выглядит следующим образом:
• Россия. На 2021-й в ИТ-сфере задействовано 384 тыс. работников, к 2025 году их число возрастет до 420 тыс. человек.
• США. На 2021-й в ИТ-сфере задействовано 4,6 млн работников, к 2025 году их число возрастет до 5,8 млн человек.
Несмотря на то, что количество российских айтишников растет с каждым годом, их влияние на экономику страны довольно незначительное. Главная причина — в низкой квалификации отечественных ИТ-работников. На данном этапе развития российская система образования не способна быстро реагировать на постоянно изменяющийся спрос.
Утечка мозгов на запад
Следующая проблема преследует Россию еще с эпохи девяностых: талантливые ученые, инженеры, изобретатели и программисты стремятся найти работу в иностранных компаниях или вовсе переехать за рубеж. Причины явления очевидны:
1. Западные компании предлагают з/п порой в разы выше российских.
2. В развитых странах талантливым ученым и айтишникам доступны все ресурсы для новых открытий и изобретений.
3. В западных странах меньше бюрократических сложностей. Таланту не нужно собирать тонну бумажек, чтобы получить возможность работать.
При этом западные работодатели отмечают, что даже самые способные российские программисты готовы работать за меньшее вознаграждение, чем айтишники из других стран. Это объясняет, почему иностранные корпорации заинтересованы в «вербовке» талантов из России.
О будущем ИТ-отрасли
Нет и капли сомнений, что ИТ-отрасль будет в огромных масштабах развиваться и расширяться в грядущем. Спрос на ИТ-профессионалов в Европе растет и будет расти:
• 2018 год — работодателям требовались 5,5 млн работников;
• 2021 год — 6,4 млн;
• 2025 год — будут нужны 7,6 млн айтишников.
Что касается конкретно России, эксперты готовы дать несколько прогнозов:
1. Как в мире, так и в нашей стране будет наблюдаться масштабное перераспределение ИТ-кадров.
2. Самый высокий спрос — в экспертах по созданию, обслуживанию ИИ.
3. Потребность в ИТ-специалистах, работающих с людьми-пользователями, напротив, ощутимо уменьшится.
Источник: b-mag.ru
Какие проблемы сейчас стоят перед ИТ-отраслью и как их решать
Развитие ИТ-отрасли в России переживает новый этап. Он напрямую связан с санкциями и острой необходимостью масштабнейшего в истории страны импортозамещения.
Многое из иностранного ПО перестало обновляться, новые лицензии не продают, риски критических ошибок угрожают госкомпаниям и крупному бизнесу. Существующее положение вещей вскрывает целый ряд проблем, которые в прошлом мешали, но были не слишком критичны для развития технологий. Сегодня же их решение детерминирует дальнейшее развитие ИТ-сектора в стране и всего, что связано с использованием ПО, поддержка и поставки которого прекратились. Иными словами, от этого во многом зависит будущее промышленного производства, добычи ресурсов, образовательного, научного и технологического развития.
Взглянуть на ситуацию с открытыми глазами
Невозможно решать проблемы, не осознав их, не поняв причины и механизмы их возникновения, не обозначив их границы. По моему убеждению, для развития ИТ в России критически значимы следующие:
— утечка кадров за пределы страны;
— отсутствие конгруэнтности и доверия ИТ-специалистов к российским компаниям;
— коррупционное лоббирование продуктов, не решающих в полной мере задачи бизнеса, государства и общества;
— разработка корпоративных продуктов силами небольших ИТ-подразделений внутри крупных компаний, прямо связанных с отраслью;
— острая внутренняя конкуренция за ИТ-специалистов, при значительной разнице в зарплатах между банками (финтех компаниями) и всеми остальными;
— отсутствие компетентного управления многих компаний национального ИТ-сегмента.
Утечка кадров за пределы страны
Корень проблемы в том, что выросло поколение 90-х, среди которого множество людей убеждены, что добиться в России качества жизни и профессиональных результатов, сопоставимых с теми, которые возможны за пределами страны — крайне тяжело. Несмотря на то, что зарплаты российских айтишников выше, чем доходы подавляющего большинства граждан, они ниже, чем у многих их коллег за границей.
Создаётся иллюзия, что релокация или эмиграция гарантированно решат все проблемы, характерные для российской действительности. На самом деле всё достаточно сложнее. Зарубежные, в частности, западные компании приглашают лишь особо ценных единиц, предлагая зарплату, сопоставимую с зарплатой местных специалистов, прочих воспринимают, как способ уменьшить расходы на персонал.
Т.е, если опытный senior java-инженер в Великобритании может рассчитывать на 90 — 120 тыс. фунтов в год, то выходцу из постсоветских стран, в частности, из России, вряд ли предложат больше 70% от этой суммы, вероятнее всего — меньше. Но даже учитывая, что этот заработок выше, чем в России, на него часто нельзя обеспечить качество жизни сопоставимое с тем., которое может позволить себе тот же специалист в России, имея годовой доход средний по стране.
Отчасти это решает проблему, как и спорадически возникающая русофобия, связанная со спецоперацией. Специалисты приезжают, испытывают сложности с адаптацией и, нередко, возвращаются в Россию. Между тем, так происходит не всегда.
Отсутствие доверия
Существует устойчивый стереотип о том, что российские компании — это исключительно “галеры”, на которых работодатели стремятся получить максимум за минимальные деньги. От этого растут притязания, а мотивация, напротив, снижается. Проблема тесно связана как с отставанием российского ИТ в применении методов отслеживания повышения лояльности сотрудников, так и с недобросовестными работодателями, которые действительно существуют в российском ИТ.
Получить 3 личных копейки, потеряв 100 рублей компании
Коррупция — общественный порок, который характерен для всего российского социума и ИТ-отрасль не исключение. Возможностей продвинуть малоэффективное или недостаточно функциональное решение более чем достаточно. Таким образом кто-то зарабатывает, а у крупной компании или отрасли возникают дополнительные проблемы. Сейчас важно, чтобы у лиц, принимающих решения, особенно на местах, было достаточно поводов, чтобы пресекать такие попытки. Решение проблемы находится в зоне ответственности регуляторов и тех, кто способен применять административный ресурс.
“На коленке” не лучше
Не менее крупная проблема – попытки создавать нужные продукты для крупных предприятий силами собственных небольших команд, часто не слишком компетентных для того, чтобы довести продукт до полноценной коммерческой реализации. Написанные на коленке утилиты и приложения плодятся как кролики у рачительного фермера, не масштабируются, плохо поддерживаются и быстро устаревают.
Как итог, крупная компания, например из ресурсодобычи или промышленности, может использовать огромный зоопарк собственных и чужих продуктов без малейшего шанса на дальнейшую интеграцию, унификацию и сколько-нибудь эффективное применение. Да, эти продукты решают текущие задачи, но первое же не спрогнозированное развитие событий бизнеса, изменение условий и такие продукты становятся не актуальными. В итоге, эффективность падает, постоянная смена продуктов делает стоимость владения сопоставимой со стоимостью разработки полноценных коммерческих продуктов, способных к масштабированию и развитию или покупки их у стороннего вендора.
Финтех, высасывающий кадры
Конкуренция за действительно талантливых и опытных специалистов огромна. Стремясь выжать из рынка лучших, финансовые организации, обладающие огромными ресурсами, задирают зарплатные планки. Многие банки уже работают как полноценные ИТ-организации и их способности платить больше можно только позавидовать. Обратной стороной их победы в конкуренции за разработчиков и ИТ-менеджеров стала критическая нехватка опытных и подающих надежды специалистов в других отраслях, часто критически важных для российской экономики.
Как продуктовым, так и аутсорсинговым компаниям, не способным сделать конкурентные предложения, приходится довольствоваться остатками от тех, кого не трудоустроил, например, Сбербанк или Альфа. Это приводит к тому, что недоукомплектованные команды дольше создают продукты, растёт нагрузка на QI-тестировщиков. Последних также не бесконечное количество, они как и прочие специалисты отрасли стали активно релоцироваться. В компании приходят люди, которые вчера закончили краткие ИТ-курсы и которых часто сложно назвать полноценными специалистами.
В борьбе за кадры участвуют не только профильные компании, но и отраслевые гиганты, прямо не связанные с ИТ. При этом некоторые из них не гнушаются использовать подкуп сотрудников и получение через них конфиденциальных данных нужных специалистов. В нашей практике был случай, когда HR-менеджер попросту слила базу сотрудников крупной компании, получив в качестве гонорара должность с немаленькой зарплатой в этой же компании.
Не умеют управлять ИТ-бизнесом
Пожалуй, самой острой проблемой является неумение российских руководителей полноценно управлять организациями, создающими новые ИТ-продукты. Компаний, воплотивших в России успешные долгоживущие ИТ-продукты, не так много. Значительно больше тех, которые продавали чужие решения или немного их кастомизировали.
Возможность быстрее заработать именно таким образом породила огромное количество руководителей, ориентированных на быстрый, пусть и небольшой финансовый результат, не требующий глубокого понимания того, как следует разрабатывать и развивать новые продукты. Быстрая прибыль от спекулятивной, по факту, деятельности — секрет успеха многих российских ИТ-бизнесменов.
Получая деньги в менее рискованном бизнесе, не требующем колоссальных инвестиций, работать удобнее. Предоставляемые государством преференции и деньги далеко не всегда могут компенсировать убытки при актуализации рисков мало-мальски крупного проекта.
Опыт ЕАЕ-Консалт показывает, что многие руководители, которые неплохо работают в рамках выделенного под проект бюджета, но испытывают колоссальные сложности, попадая в агрессивную и требовательную рыночную среду.
Инвестирование — спасательный круг
Форсировать появление полноценных ИТ-продуктов, особенно корпоративного софта поможет обильное инвестирование. Это могут быть как государственные фонды, типа РФРИТ, так и частные инвесторы. Известно, что для того, чтобы создать полноценный, имеющий коммерческое будущее ИТ-продукт в России, нужно не менее $10 млн.
Часто условия инвестиций, которые предлагаются частными инвесторами в России, делают разработчиков и продукт его фактической собственностью. Это затрудняет развитие наиболее перспективных проектов, так как компании, разрабатывающие действительно новые, передовые продукту стремятся сохранить контроль за его развитием.
Госинвесторы использовали прямо противоположный подход, стремясь ограничить вложения и растянуть бюджет на множество проектов. Фонд одобрял строго ограниченный процент от суммы, необходимой разработчикам для старта (около 20%), а остальную сумму приходилось искать самим. Часть не слишком упрямых команд приняли решение отказаться от разработки перспективных и нужных рынку продуктов.
Происходило так в связи с тем, что условия госинвестирования были неподъемными или предполагали те риски, которые небольшие компании не могли себе позволить, а частное инвестирование было маловероятным или предполагало ещё более неудобные условия.
Кто виноват и что делать
Речь о том случае, в котором виноватых искать смысла не имеет, нужно признать проблемы и начинать их решать. В первую очередь важно:
— Сформировать комьюнити профессиональных ИТ-руководителей, в идеале определить критерии и стандарты к их компетенциям.
— Обеспечить меры государственной поддержки специалистов тех ИТ-компаний, которые заняты в реализации проектов федеральной значимости, работающих над критически значимым ПО для промышленности, госсектора, ресурсодобычи и т.д.
— Продолжить поддержку специалистов и меры мотивирования молодежи к получению востребованных специальностей. Такая программа уже существует, но требует доработки, например, льготы по кредитованию важны в основном для сегодняшних студентов, но к моменту, когда они закончат обучение — она уже перестанет действовать.
— . РФРИТ уже пошёл по этому пути и если раньше можно было рассчитывать лишь на 50% от стоимости проекта, сегодня фонд может субсидировать 70% и больше. Но только один, пусть и федеральный фонд. Для заметных изменений необходимо много частных и государственных инвесторов. Тем более, что в итоговом результате — в развитии отрасли заинтересованы все стороны.
— Создать условия, удобные для коррупционного лоббирования и разработки “на коленке”. Это тяжелые законотворческие задачи, они во многом связаны с развитием стандартов в области ИТ. Определяя стандарты для продуктов и для условий их создания, формируя критерии качества и надежности ПО, можно решить, если не все проблемы с лоббированием и внутрикорпоративными утилитами на три дня, то большую часть из них.
Источник: www.it-world.ru
Типичные проблемы IT-стартапов, которые мешают быстро развиваться, и как их избежать
На онлайн-конференции ФРИИ «Как построить бизнес на основе технологий» Звиад Кардава, ответственный за developer relations в Google, рассказал о проблемах технологических стартапов в разработке, развитии продукта и управлении процессами, и как их можно решить или избежать.
Мы живем в динамичном мире, где некогда медлить: стараемся быстро сделать MVP, выйти на рынок, увеличивать конверсию и присутствие. Такой подход оправдан, но в процессе у основателей стартапа могут возникать проблемы, которые в дальнейшем будут мешать.
Три области, в которых у стартапов бывают проблемы:
1) Менеджмент и процессы
Если за короткое время команда выросла из 5 человек в 50, работать по прежней схеме у неё не получается: нужно задавать новые бизнес-процессы и управлять ими — уметь расставлять приоритеты для компании и продукта, определять ключевые метрики показателей успеха и «просадки» вашей компании/продукта.
Самая частая ошибка в процессах — когда CTO тратит большую часть времени непосредственно на разработку. Конечно, CTO должен обладать хорошими техническими навыками, и когда в стартапе только 3-5 человек, участвовать в разработке совершенно нормально. Но когда в команде уже 50 человек, СТО должен руководить процессом разработки, тесно взаимодействовать с тим-лидами отделов разработки, тестирования, а не заниматься большую часть времени непосредственно разработкой. Этот человек — генералист, который разбирается во всех технологиях, умеет разговаривать с командой и выстраивать правильную разработку, пробует свои продукты и новые технологии.
2) Развитие продукта
Здесь могут возникать проблемы с приоритизацией фич, тестированием и адаптацией продукта. Отслеживание развития продукта помогает нам понять, правильно ли мы поступаем: при выпуске новой версии или фичи необходимо измерять показатели, двигаться итерациями и не останавливаться долго на чем-то одном. Отслеживание и оценка продуктовых метрик очень тесно связаны с маркетингом: можно сделать очень хорошую фичу, но очень плохо ее продать, и наоборот заострить внимание команды на разработку фичи, которая на самом деле никому не нужна. Такие подходы как A/B-тестирование и аналитика позволяют понимать клиентов и продукты.
Например, компания, которая пыталась сделать подобие Netflix для жителей регионов с низкими доходами с дешевой подпиской для мобильных телефонов, увидела с помощью аналитики, что есть достаточно большое количество пользователей, прерывающих воспроизведение контента через минуту или меньше после начала просмотра при первом запуске. Команда пыталась выпускать новые фичи, менять дизайн, применять machine learning, но проблема оказалась значительно проще: у этой группы пользователей просто не было при себе наушников. Когда они включали контент на улице или в публичном месте, им было просто некомфортно его смотреть без наушников.
3) Разработка
Очень часто разработчики любят всё строить с нуля — в нашей стране программисты могут решить любые технические проблемы. Но зачастую это тратит слишком много времени. Если готовые компоненты есть в открытом доступе или платно, используйте их. Это позволит сфокусироваться на разработке уникальных особенностей вашего продукта.
Например, если вы делаете какое-то мобильное приложение, зачастую будет достаточно использовать Firebase. В нем есть все необходимое: аналитика, хостинг, пуши, база данных, Cloud function, инструменты для продвижения, crush-reporting, инструменты для A/B тестирования, экспериментов и многое другое. Cloud functions часто достаточно для реализации несложной backend логики. Вам не нужно самому создавать или поддерживать эту инфраструктуру, все что вам нужно делать — это правильно объединить компоненты (такой подход называется backend as a service и позволяет значительно сэкономить время разработки и выхода на рынок).
Также никогда не стоит экономить на «инструментах» для разработки: они помогут сильно ускорить ваши процессы. Это относится не только к средам разработки (IDE), но и к инструментам для тестирования или инфраструктуре. Например, Github, Gitlab, Bitbucket позволяют CTO делать code review, заводить issue и удобно разрабатывать в распределенной команде. Если вы решили хранить код у себя, настройте хороший репозиторий, например, Gitlab, возьмите приличное железо.
Своя команда или аутсорс?
Многие стартапы, нацеленные на технологические продукты и платформы, зачастую относятся к аутсорсу негативно. В России достаточно много разработчиков, высокие среднерыночные заработные платы, но все это даже в сумме с большим опытом не гарантирует, что разработчик будет соответствовать вашим ожиданиям: любой человек может ошибиться, и даже люди с большим техническим опытом иногда неправильно принимают решения и могут подвести всю команду.
Хорошие инженеры и программисты — зачастую очень плохие дизайнеры. А хороший UI/UX очень важен для продукта, поэтому вы спокойно можете отдать UI/UX на аутсорс, и при этом оставить inhouse-разработку, главное — сохранить баланс.
Важно понимать, какие конкретно люди или компании вам нужны для аутсорса — частные дизайнеры и специалисты, небольшие студии мобильной разработки или большие компании, специализирующиеся на аутсорсе. Небольшим стартапам я бы не рекомендовал большие компании: как правило, у них другой фокус и принцип работы.
Что не так с продуктом: основные проблемные зоны
В понятие frontend, условно, входит всё, что хоть как-то взаимодействует с пользователем. В одном случае это может быть пользовательский интерфейс в виде веб или мобильного приложения, в другом — API вашей платформы, приложения, маркетплейса. Удобный API — это хороший UX/UI, который очень важен. Дальше уже идет архитектура, фреймворки и языки.
Можно сколько угодно спорить, чем один язык, фреймворк или подход лучше другого, но пользователям совершенно все равно, на чем написано ваше приложение. Главное для них — красивый и понятный интерфейс, быстрая работа продукта.
Что делать, если UX/UI плохой?
Можно проконсультироваться с профильными специалистами на аутсорсе, пригласить дизайнера сделать вам верстку, протестировать, как пользователь взаимодействует с экранами и переходит с одной страницы на другую, а потом — дорабатывать продукт inhouse и периодически с кем-то консультироваться.
Тестировать юзабилити с помощью друзей — тоже один из вариантов консультации по UX/UI. Попробуйте дать вашим родственникам, например, маме, протестировать приложение или веб-страницу. Если у нее не возникнет никаких проблем с использованием, и вам не надо будет подсказывать, значит, вы близки к успеху.
Новых пользователей необходимо адаптировать. Если приложение после установки сразу же запрашивает у пользователя доступ к контактам, файлам, камере, он воспринимает это действие как подозрительное, поскольку не понимает, зачем это нужно.
Хорошая практика — когда приложение запускается без запроса на доступ к чему-либо и отправляет его только по мере необходимости и после того, как пользователь некоторое время взаимодействовал с ним. Например, у вас гейминг-платформа, после установки вы предлагаете пользователю поиграть в игру, и в процессе он понимает, что может соревноваться с друзьями и делиться результатами. Если приложение начнет запрашивать доступ к контактам именно в этот момент, скорее всего, он согласится.
Другой пример — платформа, на которой нужно зарегистрироваться. Все мы живем в телефонах и на ходу, поэтому просить людей заполнить большую и неудобную форму полностью — плохая стратегия. Вместо этого можно добавить conversational UX (диалоговое взаимодействие с пользователем): подключить API.ai (dialogflow.com) или Facebook messenger. Тогда все, что нужно пользователю — залогиниться из фейсбука или через Google, и дальше отвечать на вопросы, нажимая на кнопки с вариантами ответа. Это позволяет пользователю заполнять форму на ходу.
Хороший UX/UI — это:
- Конкурентное преимущество. Люди перестают пользоваться некоторыми приложениями только потому, что они неудобные.
- Более высокие рейтинги: они приносят более высокую конверсию и монетизацию. Если пользователям нравится приложение, и оно становится популярным, магазины приложений добавляют его в подборки более охотно. Чем лучше платформа, тем меньше обращений пользователей в техподдержку.
Web Payments помогает сделать веб-страницу с удобной подпиской и оплатой без редиректа на страницу оплаты. Web Credentials позволяет автоматически оставаться в системе, если пользователь хоть когда-то в ней логинился.
Ещё одна интересная технология — Android InstantApps, полностью нативное приложение со всем функционалом, которое не нужно ставить: вы можете получить его прямо из поиска, по ссылке, с маячка, в Telegram и тд. После перехода по ссылке приложение открывается моментально, и пользователь может что-то купить, подписаться и сделать. И уже потом — установить приложение, если захочет. Это расширяет возможности взаимодействия с пользователем и увеличивает охват рынка.
Но следить за новыми технологиями — не значит применять всё подряд в продукте. В последнее время всем очень хочется применить нейросети или заявить об этом. Это может быть хорошо для PR и маркетинга, но если продукт не нацелен на эти технологии, или у вас нет в них опыта, не стоит тратить ваше время и пытаться сделать магию: вы должны понимать, что делаете, и что делают специалисты.
Если вам нужны какие-то стандартные вещи типа распознавания голоса, транскрипции, перевода, анализа картинок и т.д., вместо разработки и обучения своих моделей ML быстрее и проще использовать уже готовые. В Google Cloud Platform и у других платформ есть качественные модели с хорошим и легким API.
2) Backend и инфраструктура
Очень важно с самого начала заложить правильную архитектуру для Backend. Сейчас все ориентируются на так называемую микросервисную архитектуру. Это подход к построению backend, а не какой-то один шаблон, поэтому возможны разные вариации, но, в целом, такой подход оправдан.
Если коротко, при микросервисном подходе единое приложение (backend) строится как набор небольших сервисов, каждый из которых работает в собственной среде и коммуницирует с остальными, используя легковесные механизмы. Очень часто для связи используется HTTP/REST, но я рекомендую посмотреть и изучить GRPC — открытый фреймворк для удаленного вызова процедур, который работает на всех платформах и со всеми языками и значительно эффективнее HTTP. Также крайне важно правильно выбрать и базу данных.
Все это значительно сэкономит силы и средства, в том числе на хостинге, т.к. вы можете использовать более дешевые контейнеры вместо виртуальных машин, а также позволит вашему бэкенду оставаться гибким и масштабируемым.
Был стартап, который выбрал MySQL, потому что у одного из разработчиков был опыт работы с этой СУБД, и он посчитал, что этого будет достаточно. Потом выяснилось, что им нужно хранить данные в формате JSON, и им пришлось это делать в MySQL, хотя он не умеет эффективно работать с JSON. Потом кто-то предложил взять MongoDB, потому что у нее есть документоориентированность. MySQL начал тормозить, и не разобравшись в причине, они взяли PostgreSQL, так как слышали что это хорошая реляционная БД. Так у них появилось три базы данных.
Через какое-то время все три базы начали «тормозить». И команда решила, что критические и горячие данные можно держать в Redis (NewSQL). Также у них был поисковый движок elasticsearch… Итого: мы имеем стартап с четырьмя разрозненными базами данных. Поддерживать их достаточно неудобно и дорого.
Нормальным решением для такого стартапа будет СУБД PostgreSQL, которая умеет нормально работать как с SQL данными, так и с JSON. В идеальном случае в команде должен быть отдельный специалист по БД — DBA. Или человек достаточно опытный в этих вопросах, который знает такие технические детали.
Дальше идут фреймворки, отдельные готовые компоненты, сервисы и языки.
На тему выбора правильных фреймворков и, особенно, языков сломано много копий.
Выбирать язык программирования нужно по задаче или территориальному признаку: если вы находитесь не в Москве или Санкт-Петербурге, где можно найти разработчиков любого уровня, выбирайте в зависимости от вашего региона: если в вашем регионе сильное Node.js или Python-коммьюнити, и они подходят под ваши задачи — выбирайте что-то из этого. Искать программистов на Erlang там, где их нет, не стоит.
Многие пренебрегают практиками continuous integration и continuous delivery. Этого не стоит делать — они повышают качество продукта, снижают количество багов и помогают сделать систему и процесс разработки более «прозрачными» для всех участников команды.
Дальше стоит вопрос: выбрать железо или облако? Лучше выбирать облака, готовые сервисы и платформы — в конечном итоге при правильном использовании они обойдутся дешевле, сэкономят время, и сами по себе более доступны и выигрышны с точки зрения сокращения издержек.
Мнение о том, что облака сильно дороже железа, — необоснованно. Если вы пересчитаете и учтете все возможности сервис-провайдеров, то поймете, что они предоставляют хорошую инфраструктуру и окружение для взаимодействия (больше о том, как выбрать хостинг для стартапа, читайте в этом материале ФРИИ).
При выборе хостинга, базы данных и других компонент инфраструктуры важно помнить: пользователю все равно, на чем написано ваше приложение, и где оно хостится. Главное — чтобы оно работало быстро и позволяло пользователю взаимодействовать с фронтендом.
Даже с помощью простого PostgreSQL, MS SQL или MySQL вы можете решить большинство своих задач. Stack Overflow, которым пользуется огромное количество разработчиков, хранит свои данные в 4-х базах данных: основной (для всего), вспомогательной и двух репликах. И этого хватает для жизнеобеспечения всего Stack Overflow.
Можно найти большое количество тьюториалов и материалов по архитектуре, CI/CD, DevOps подходам, контейнерам, базам данных и масштабированию. Изучение этих вещей займет не так много времени, но в дальнейшем очень поможет сократить время, затраты и риски. Настройка контейнеров вместо виртуальных машин ускоряет в том числе и разработку, даже если у вас нормальная архитектура, и есть какой-то CI/CD: вам не нужно будет каждый раз настраивать себе окружение, вы просто скачаете готовый контейнер, сможете с ним работать, а потом в этом же контейнере тестировать, выпускать в продакшн, а затем масштабировать.
API менеджмент — одна из самых главных проблем новых продуктов, про которую все забывают. Самый простой способ её решить для разработчиков, когда нет времени заморачиваться сложными вещами, — запихнуть API в контейнеры. Это позволит не только версионировать API, но и легко масштабироваться при нагрузке на разные версии API.
Нельзя рассчитывать на высокую доступность, полагаясь на одного сервис-провайдера.
В современном мире у любого сервис-провайдера могут возникнуть проблемы. Поэтому использование одного провайдера или только своего железа ведет к тому, что вы не можете считать себя высокодоступными сервисом или платформой.
Использовать несколько сервис-провайдеров — абсолютно нормальный подход. Например, Kubernetes можно развернуть на все облака: Google Cloud, Amazon итд, и у вас будет хорошая доступность сервиса.
Подумайте о масштабировании заранее.
Конечно, если у вас есть пара виртуалок сейчас, потом вы можете развернуть ещё несколько. Но когда вы нацелены на бурный рост, это может повести за собой неприятности: монолитное приложение и большое количество пользователей могут стать проблемой.
Именно правильная стратегия выбора компонентов в самом начале позволила PokemonGo пережить большую нагрузку: они ожидали 5X трафик в самом худшем варианте развития событий, реальный же трафик за первые дни составил 50X. Выдержать такую нагрузку стало возможным благодаря Kubernetes и Cloud Datastore: Kubernetes можно разворачивать практически на всех облаках, у него огромное количество пользователей и большое коммьюнити. А Cloud Datastore — это высокомасштабируемая база данных NoSQL, которая автоматически масштабируется для при нагрузке на ваши приложения. Вам не нужно ничего делать и переживать.
Подробнее про разворачивание и масштабирование PokemonGo можно прочитать по ссылке.
- Не игнорируйте отзывы пользователей и реагируйте на них;
- Думайте об альтернативах. Например, вы можете использовать conversational UX вместо классических форм регистрации;
- Используйте готовые компоненты, сервисы и платформы;
- Всегда делайте для пользователей больше, чем они ожидают.
Источник: habr.com