2021 год был годом бурных инвестиций в IT. Бизнес вкладывал огромные деньги в проекты, чтобы опередить конкурентов. Сейчас ситуация кардинально изменилась: происходит пересмотр и сокращение бюджетов. Деньги начинают идти туда, где они принесут реальную выгоду. Вместе с тем сократился и горизонт планирования. В 2021 году на масштабных проектах, например, в дистанционном банковском обслуживании (ДБО) фичу могли разрабатывать до 9 месяцев. Сейчас это невозможно: все учатся делать быстрее, и планируют бюджет только на один квартал.
О том, как повысить эффективность разработки, я недавно рассказывал на конференции «Управление информационными технологиями и безопасностью» и хочу поделиться краткими выводами.
1. Подобрать оптимальный с точки зрения текущей ситуации способ решения бизнес-потребности
Небольшие компании могут поискать способы закрытия бизнес-потребностей без разработки. Попробуйте использовать готовые решения. Зачем создавать и продвигать свое приложение для заказа еды из ресторана, когда можно сделать интеграцию с сервисами доставки. А может быть, вы возьмете готовое – «коробочное» мобильное приложение? У этого варианта есть свой минус: на старте нужно проанализировать ваши процессы, и подстраивать их под логику выбранного решения.
По нашему опыту, каждый владелец «коробочного» ПО рано или поздно начинает переписывать его по частям. Это может быть приемлемо, только если объем доработок не превышает 30%. Если на компромиссы не готовы, готовое решение брать не рекомендую.
При выборе технологии создания мобильного решения можно рассмотреть разные альтернативы.
- Мессенджеры и социальные сети. Если вы активно используете мессенджеры в работе и общении с клиентами, рассмотрите вариант создания чат-бота. Возможно, его будет достаточно на первое время. Социальные сети сегодня предоставляют все больше механизмов взаимодействия с пользователями. В качестве альтернативы можно рассмотреть mini App от VK.
- Когда есть потребность в приложении для ваших сотрудников, и внутри компании вы активно используете какую-нибудь ERP-систему типа 1С, стоит посмотреть в сторону 1С mobile. Да, может, там будет не самый красивый интерфейс, но ваша бизнес-потребность быстро закроется.
- Если у вас есть веб-сайт и нужно мобильное приложение с похожим функционалом, сделайте мобильный сайт, заверните его в progressive web application (PWA). При качественно сделанном сайте, построенном на микросервисной архитектуре, итоговый результат будет хорошим. Даже мне как разработчику порой бывает трудно понять, что передо мной: мобильный сайт или мобильное приложение.
- Полноценное мобильное приложение, которое будет хорошо работать в офлайн-режиме, иметь точную геолокацию и другие важные для пользователя опции.
На чем разрабатывать IT-решение в этом случае?
Когда нужно поддерживать две платформы iOS и Android, лучшим выбором будет Flutter. Наш опыт показывает, что экономия часов при разработке под две платформы на этом решении может составить до 50%. Причем до недавнего времени разработка на нем под одну платформу была быстрее, чем нативная. Причина в том, что Flutter использует современную технологию построения пользовательского интерфейса. Android и iOS относительно недавно начали переход на аналогичную технологию Jetpack Compose и SwiftUI соответственно.
Но на рынке не всегда можно найти квалифицированных специалистов по Flutter-разработке. В этом случае решением может стать аутстаффинг или аутсорсинг. Как показывает практика, если специалист нужен на краткосрочную задачу, выгоднее временно усилить текущую команду, чем нанимать в штат.
2. Делать проще
В англоязычной литературе есть акроним KISS («keep it short and simple» — «делай кратко и просто»). Нередко IТ-проекты обрастают талмудами документации с описанием каждого микросостояния и микроповедения. Закладывают микросервисную архитектуру, где она не нужна. При планировании нового IТ-продукта полезно вспомнить о принципе проектирования и программирования KISS.
В текущих условиях можно просто сосредоточиться на главном – на том, что закроет основную потребность бизнеса, обеспечит получение дохода. Например, автоматизация 100% бизнес-кейсов требует времени, а время разработчика стоит немало. Иногда можно сделать автоматизацию 95% бизнес-кейсов, а 5% отдать на support для ручных действий и значительно сэкономить по деньгам и времени.
На мой взгляд, есть три причины усложнения и затягивания разработки:
1. Низкая квалификация специалистов. Специалисты с недостаточной квалификацией далеко не всегда создают простые красивые решения. Иногда они используют новомодные технологии, но не знают, какие ограничения у технологии есть, и не задумываются о том, как можно решить задачу альтернативным способом.
Для решения этой причины нужно повысить квалификацию сотрудников или усилить свою команду – привлечь внешних разработчиков с нужной вам экспертизой.
2. Хантинг и частая смена специалистов на проекте. Разработчик, работающий год и более на проекте, ценнее, чем недавно пришедший. Он погружен в бизнес-процессы, знает, как сделать оптимальнее, быстрее и то, что реально нужно пользователю. Работая на проекте, специалист все больше узнает про пользователя, его потребности. В идеале рекомендуем периодически направлять разработчиков в support. Это позволит им взглянуть на результат своей работы глазами пользователя.
Здесь могу сказать только одно – не спешите менять команду, гоняясь за моментальной прибылью. Есть риск потерять гораздо больше. И если команде не хватает ресурсов, иногда лучше усилить свою команду привлечением специалистов с необходимой квалификацией, чтобы решить ваши бизнес-задачи.
3. Специалисты не соотносят затраты бизнеса на разработку ПО и будущую прибыль от создаваемого решения. Разработчики любят «вылизывать» код, делать рефакторинг. QA-специалисты хотят найти все возможные ошибки, а аналитики – максимально детально описать задачи и фичи. Безграничные бюджеты, которые компании направляли на разработку в 2020-2021 годах, усугубили ситуацию. На больших долгоиграющих проектах специалисты стремятся заложить все возможные риски при создании нового функционала.
Если подобрать способ реализации фич, исходя из экономической эффективности, можно разрабатывать приложения в 1,5-2 раза быстрее. Предположим, есть веб-сайт. Задача – добавить поле «адрес проживания» в профиль пользователя, чтобы эту информацию мог использовать сотрудник компании. Можно сделать ввод адреса через сервис автозаполнения, добавить гео-карты и потратить на это несколько дней работы. А можно просто добавить текстовое поле и потратить на это один час.
* * *
Сейчас программирование необходимо смещать к экономической выгоде. Перед нами стоит задача – научиться быстрой разработке IT-решений и «поставить на рельсы» обучение этому навыку.
А вы что думаете? Поделитесь своим мнением в комментариях.
Читайте также:
Мне показалось, что тут только один способ обозначен - лепить из того, что есть под рукой. Проще и надёжнее.
Ну что ж - спора нет, бывает и это подходит. Правда порождает массу других проблем.
У меня только один вопрос: А для кого эта статья?
Менеджеру она не подойдёт, он скорее заказчик, нежели разработчик. Малому предпринимателю или директору департамента тоже не подойдёт - они смотрят на вопрос несколько из других соображений, для них IT - это инструмент. Программисту тем более не подходит, ещё и тем что автор де-факто пренебрежительно к ним относится.
Даже следующей строкой:
Функционал функционалу рознь. Я понимаю у всех бывают эмоциональные кризисы, выгораешь и проваливаешься в аппатию, что ничего делать толком не хочется. Но каким надо быть бестолковым менеджером, чтобы настолько затягивать процесс разработки?
Статья, как я понимаю, написана программистом, и затрагивает вопросы выбора базы для разработки мобильных приложений. В больших компаниях, как правило, работают на стационарных компьютерах и в других операционных системах, где и подходы иные. Но, что главное, для хорошей, быстрой и качественной разработки надо иметь в команде человека, который хорошо разбирается в прикладной области (аналитика). Разработка без такого специалиста приведет к удлинению сроков, конфликтам с заказчиком, снижению эффективности и неоправданным затратам.