Оценка проекта

Оценка временных затрат при разработке ПО может быть сложной задачей, но есть несколько хитростей, которые помогут получить точные цифры.

Помню, как меня впервые попросили дать оценку

Тогда это застало врасплох.

Меня завели в кабинет, где были мой начальник, его босс и кто-то из вышестоящего руководства, и мы сели за круглый стол, уставившись друг на друга.

Аналитики зачитали некоторые требования от клиента. Мы их коротко обсудили.

И тут мой начальник повернулся ко мне и спросил: Сколько времени это займет?

Я не знал, что сказать, меня к этому не готовили. Мне не сказали, что на этой встрече нужно будет давать оценку я думал, меня позвали поприсутствовать, чтобы я чему-то научился.

И вдруг на меня все смотрят и ждут ответа, а я растерялся и не знаю, что сказать.

Передо мной лежала бумага для заметок. Я взял один листок и начал писать какие-то числа без понятия, для чего, но точно не для этой оценки.

Где-то через минуту, которая показалась мне часом, я решил просто сказать первое, что пришло в голову: Не знаю часов 600?

Начальник рассмеялся, а затем сказал остальным рассчитывать на примерно 1200часов.

Не очень люблю вспоминать тот день.

Понятно, что мне еще многое предстояло узнать, но меня мучил один вопрос: как оценивать объем предстоящей работы?

Цель проведения оценки

Прежде чем приступать к оценке, нужно понять, для чего она будет использоваться. Вы сообщите цифры начальнику или вышестоящему руководству и что будет дальше?

Оценка объема работы используется в основном в двух целях:

• Планирование.

• Выставление счета клиенту.

Планирование

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

Они знают, какой объем работы какая группа разработчиков может на себя взять в месяц, квартал и год. И чтобы обеспечить занятость сотрудников, руководству нужно составить график работы над проектами. Данная вами оценка и поможет в таком планировании загрузки.

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

Представьте, что ваша команда должна выполнить пять проектов с оценками объемов работ 800, 400, 300, 200 и 50часов. Планируя загрузку, вы будете видеть, что не сможете к концу квартала выполнить все проекты. Менеджеры составят график, использующий определенный процент максимальной загрузки на случай, если разработка займет больше времени, чем предполагалось.

С оценками из нашего примера можно было бы взяться за проекты на 800, 400 и 50часов, и при этом осталась бы некоторая свобода для маневра.

Выставление счета клиенту

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

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

Примечание. Это применимо не ко всем компаниям разработчикам ПО: не все занимаются разработкой на заказ. Если вы не разрабатываете ПО на заказ, то оценки объема работ будут использоваться в основном для планирования.

Ключевые факторы при оценке

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

Фото AbsolutVision, площадка Unsplash

1. Не оценивайте, сколько времени понадобится ВАМ

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

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

Часто полезным будет предположить, что работу будет выполнять самый неопытный в команде.

2. Не занижайте завышайте

Помните, что в первую очередь оценка делается для планирования. Поэтому не нужно давать цифры, которые, по вашему мнению, могут быть превышены.

Если разработчики выйдут за отведенный вами срок, это нарушит график работ.

Находиться в границах 20% это нормально, но только если оценка оказалась завышена а не занижена.

К какой бы цифре вы ни пришли, добавьте к ней 20%: задачи обычно оказываются сложнее в реализации, чем кажется.

3. Повышение квалификации

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

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

Фото Matheus Frade, площадка Unsplash

4. Примеры аналогичных проектов

Проще всего давать оценку проектам, основанным на уже привычных для команды шаблонах.

Если у команды имеется некий опорный материал в виде ранее разработанного ПО, то объем работы может значительно снизиться. Разработчикам проще действовать по принципу копировать, вставить, заменить, и это отражается на скорости выполнения задач.

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

5. Не забывайте об аналитиках

Часто вас будут просить дать полную оценку, а она включает в себя время разработчиков, бизнес-аналитиков и специалистов по обеспечению качества.

В этом случае дать оценку только по разработчиками будет мало нужно учесть, что бизнес-аналитикам придется писать документацию, делать пользовательские истории и руководить обзорами спринтов.

Также потребуется учесть время, необходимое отделу контроля качества для тестирования. Возможно, у вас есть какая-то система автоматизации, которую нужно настроить и для этого проекта тоже? На всё это нужно время, которое также включается в оценку.

Заключение

Чтобы научиться давать оценку объему работу, нужно время. Этот навык, как и любой другой, требует практики.

Со временем оценки будут даваться вам всё легче. Запомните перечисленные моменты, научитесь понимать, сколько времени занимает разработка определенных элементов, и полагайтесь на свой опыт.

Если резюмировать самое главное, запомните вот что:

задача всегда сложнее, чем кажется, и лучше переоценить объем работ, чем недооценить.

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

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

---

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Бывают ситуации, когда компании-заказчику нужно рассчитать сроки реализации IT-проекта как можно быстрее например, на старте переговоров с инвесторами. Однако, даже быстрая оценка должна содержать все предстоящие трудозатраты: на разработку, тестирование, управление и возможные риски рисковый резерв. В этой статье мы рассмотрим процесс оценки на примере веб- и мобильных проектов.

Как происходит оценка проекта

Детальная оценка это трудозатратный процесс, в котором участвуют эксперты из разных направлений. Например, в нашей практике это группа из 5 специалистов разработчиков, аналитика, дизайнера. Возглавляет группу модератор, который следит за тем, чтобы оценка была корректной и соответствовала потребностям заказчика. Задачи модератора:

• созваниваться с клиентом для уточнения требований, согласования вариантов решения и стека технологий;

• курировать процесс оценки;

• предлагать варианты реализации;

• оценивать и закладывать риски;

• определять состав команды разработки;

• составлять предварительный роадмап проекта.

Подробная оценка занимает в среднем 3-5 рабочих дней. За это время мы определяем возможные ограничения и риски, стек технологий, состав команды, ориентировочные сроки работы и ее стоимость. После этого переходим к обсуждению оценки с клиентом. По нашим наблюдениям, на этом этапе могут происходить различные уточнения по следующим причинам:

• требования клиента изменились, например, он подготовил более детальное ТЗ и макеты;

• была выявлена необходимость реализовать продукт поэтапно, начиная с MVP, с учетом бюджета или дедлайнов;

• иногда нужно изменить технологический стек, если клиент сообщает новые бизнес-задачи или особенности инфраструктуры.

Риски и трудозатраты на управление

При оценке нужно учитывать трудозатраты на управление проектом (Project Management или PM), в том числе:

• распределение и контроль выполнения задач

• проведение митингов;

• коммуникации с заказчиком продукта и устранение препятствий;

• ретроспективы с командой;

• демо с заказчиком;

• работа с метриками и оценка рисков.

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

• команда часто перерабатывает, причем больше, чем на 10-15%;

• ТЗ постоянно меняется, а тестовая документация при этом не обновляется;

• фактическое время выполнения задачи сильно превышает планируемое.

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

Оценка трудозатрат

При разработке тех или иных новых модулей команде предстоит выполнить различные виды работ, в зависимости от типа проекта:

1. Приемка приложения

2. Аналитика и дизайн

3. Непосредственная разработка и интеграция с другими IT-системами

4. Тестирование и обеспечение качества (QA)

Мы поставили перед собой задачу выяснить, как в среднем распределяются трудозатраты по фазам разработки. Для этого мы проанализировали выборку веб- и мобильных MVP-проектов, разработанных в 2020 году. Трудозатраты на их реализацию составили от 2000 до 4500 часов.

Веб-приложение

Мы посчитали, в каком соотношении в этих проектах распределялись трудозатраты по разным видам работ (в процентах):

• Аналитика 7%

• Backend 30%

• Frontend 24,6%

• Тестирование 15%

• Управление 22%

Как показывает практика, разработка занимает около 50-60% от общих сроков реализации веб-приложения.

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

Мобильная разработка

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

В веб-проектах трудозатраты распределились так:

• Аналитика 3,8%

• Backend 18,9%

• iOS 16,1%

• Android 25,8%

• Тестирование 25,1%

• Управление 10,3%

По нашим оценкам, Backend- и мобильная разработка в среднем составили около 60% трудозатрат.

По сравнению с веб-приложениями, мобильные проекты зачастую более трудоемкие из-за реализации и тестирования сразу на нескольких платформах. Сроки тестирования для них выше в среднем на 10% по сравнению с веб-проектами, потому что парк устройств постоянно растет.

Особенности расчетов

Рассчитать сроки разработки можно с помощью разных инструментов, в том числе вручную в Excel. Для нас наиболее удобным методом стала автоматизация расчетов, для этого мы разработали собственный сервис Estimate, о котором ранее уже рассказывали на Хабре. Этот сервис позволяет подключать шаблоны и учитывать особенности каждого вида проектов. С помощью сервиса можно рассчитать, сколько часов необходимо на каждую фазу или этап разработки, на реализацию отдельных фич.

Пример оценки в Estimate

Заключение

В этой статье мы рассчитали особенности распределения трудозатрат в разных видах продуктов. В наших веб-проектах разработка составила в среднем 50% от общих трудозатрат, а в мобильных проектах около 60%.

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

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

Главная сложность в разработке приложения накодить его функционал. Например, сделать редактирование текста для приложения-блокнота. Так я полагал, когда был моложе и наивнее.

С тех пор я запустил три приложения руками разработчиков и ещё одно собственноручно. Не бог весть какой опыт, но иллюзий поубавилось. А реализация функционала видится мне теперь самой простой и прогнозируемой задачей из всех.

Хочу поделиться краткой выжимкой из своего опыта: какие неожиданные сложности вас ждут, если вы делаете мобильное приложение впервые.

---

О базовых продуктовых рисках говорить не буду. Понятно, что если вы не найдете свой product-market fit, то всё остальное уже не будет иметь значения. Поэтому давайте предположим, что вы придумали перспективную идею приложения, сделали грамотный кастдев, изучили рынок и конкурентов, продумали монетизацию, просчитали юнит-экономику и бизнес-модель, наняли толковую команду. Вроде все схвачено Или нет?

Содержание

1. Выбор фреймворка

Ещё до написания первой строчки кода вы встанете перед судьбоносным выбором: делать приложение нативно под каждую платформу (iOS / Android) или на кроссплатформенном фреймворке?

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

Кроссплатформенный фреймворк тоже поди выбери

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

Что почитать по теме?

• Кроссплатформенная мобильная разработка: история вопроса

• Больше всех пахала лошадь, но председателем колхоза так и не стала

• Как правильно переходить границу: кроссплатформенность в мобильном приложении

• Натив или гибрид? Специалисты Яндекса отвечают на главный вопрос мобильной разработки

• Когда имеет смысл писать кроссплатформенные приложения: появление и исчезновение React Native в Lingualeo

• Новое приложение Медузы. Почему Flutter?

• Почему Flutter побеждает?

2. Устаревание кода

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

Обновлять приходится всё: фреймворк, SDK, библиотеки, работу с внешними API, поддержку новых версий iOS и Android.

Свежий пример

Если не обновить код вовремя произойдет одно из двух:

• Ваш релиз не пройдет ревью, то есть вы не сможете обновлять приложение.

• С ревью проблем не возникнет, но что-то в приложении перестанет работать.

Кому-то это покажется мелочью ну что там, код иногда нужно переписать.

Подумайте об этом в таком ключе: вам придется оплатить неделю-другую разработки и не получить вообще никакого business value в продукте. Более того, вы вынуждены отложить все действительно важные продуктовые задачи. И делать такое приходится регулярно.

Что почитать по теме?

• Разрабатывать приложения под Android словно быть (демонетизированным) ютубером

• В macOS 10.15 более не поддерживаются 32-битные приложения. Что вы можете сделать?

• Уровень Android API, обратная и прямая совместимость

• Кремлевские девойки

3. Требования стора

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

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

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

Например, однажды мы полтора месяца вели переговоры с Apple. Переписывались, созванивались, объясняли, как работает приложение, высылали документ с описанием нашей бизнес-модели Всё это время мы не могли зарелизиться, а наши пользователи сидели с непофикшеными багами. По итогу пришлось вырезать из приложения функционал, который делал жизнь пользователей проще. Забавно, что приложение жило с этим функционалом уже пару лет и претензий со стороны App Store не было.

Кроме того, Google и Apple регулярно придумывают новые правила и меняют старые. Сами правила далеко не всегда разумны. Иногда они портят жизнь и вам, и пользователям, да еще и требуют сложного внедрения. А появляются такие правила в основном для того, чтобы никто не мог предъявить сторам никаких претензий.

Что почитать по теме?

• За что Android-разработчики ненавидят Google

• Почему я как разработчик ненавижу iOS

• Как я разочаровался в Google Play

• App Store не позвонит. Или как я сделала своё приложение, но оно не попадёт к пользователям

• Я сделал PWA и выложил в трёх магазинах приложений. И вот что я выяснил

4. Видимость в поиске

Не важно, насколько классное приложение вы сделали, если его никто не скачает. Например, когда я впервые зарелизил свое приложение оно появилось в выдаче только через 10 дней, на 143 позиции!

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

Но если вам нужен органический трафик тогда добро пожаловать в алый океан. Просто настроить ASO будет недостаточно, придется придумывать хитрые схемы продвижения. И конкурировать с приложениями, которые уже продвигаются годами.

К тому же, сторы держат алгоритм ранжирования в секрете и он может меняться со временем.

Что почитать по теме?

• Продвижение мобильных приложений: выученные уроки

• Как продвигать мобильное приложение в 2019 году: 4 практических способа + полезные инструменты

• ASO: ранжирование в App Store и Google Play (найди 10 отличий в алгоритмах)

• Как повысить рейтинг приложения в Google Play?

• О том, как выпустить отличное iOS приложение, которое никому не нужно

• Как я слил 1000$ в продвижение игры и что из этого получилось

5. Мобильная аналитика

Аналтика это всегда непросто.

Google Analytics стремится засемплировать ваши данные, события Amplitude блокируются браузерами пользователей, а в атрибуции каналов сам черт ногу сломит.

Но с мобильной аналитикой всё ещё хуже.

На самом деле узнать можно, но через боль и страдания

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

Например, вы прицепили к своей рекламной ссылке utm-метку. Пользователь по ней кликает, переходит на ваш сайт, а вы четко понимаете, откуда он пришел. Но если по той же ссылке пользователь попадет в стор, на страницу вашего приложения то вы никак эту utm-метку не получите. То есть вы даже не можете отличить органического пользователя от платного!

По той же причине у вас будут проблемы с реферальными ссылками.

Эти проблемы решаемы, но такими мудреными способами, что вам захочется всё бросить и уйти в монастырь web-разработку.

Пример решения: как определить, откуда пришел пользователь

Кроме того, если у вас есть и сайт, и приложение аналитика поведения пользователей может оказаться нетривиальной задачей. Особенно, если вам нужно построить сквозной дашборд.

Что почитать по теме?

• Сравнение аналитических систем для мобильного маркетинга

• Мобильный маркетинг: расхождения в статистике установок

• Переход от Google Analytics к Firebase

• Запуск мобильного ретаргетинга с Appsflyer: настройки, отчеты и ссылки

• Универсальные ссылки: дворец из подводных камней

6. Внешняя аутентификация

До сих пор многие сайты используют email как единственный способ регистрации. Но большинство приложений просто не может себе такого позволить.

Прежде всего, это неудобно для пользователя: вся это возня с подтверждением email, вводом пароля с экранной клавиатуры и так далее. А для некоторых проектов, вроде небольших мобильных игр это вообще смерти подобно. Пользователь, увидев сложную регистрацию, просто удалит такую игру и установит следующую.

Поэтому приходится прикручивать другие способы входа через FB, VK, Apple, Google, Telegram. Но это сторонние сервисы, которые живут своей жизнью. А значит, ваша аутентификация может сломаться только потому, что Facebook что-то изменил на своей стороне. А он изменит, не сомневайтесь.

Самое интересное начинается, когда вы разрабатываете приложение в дополнение к существующему web-сайту. Вам нужно будет как-то связать аккаунты пользователя на сайте и в приложении.

Например, Apple заставит вас сделать вход через Apple ID. Только вот на сайте у вас вряд ли был Apple ID. Как связать эти аккаунты? По email? Ок, вы будете запрашивать еще и email во время регистрации в приложении через Apple ID. Но пользователь мог зарегистрироваться в Apple под другим emailом. Или просто запретил передавать email в настройках.

Тут столько подводных камней, что хватило бы на отдельную статью.

Что почитать по теме?

• Внедряем Sign in with Apple систему авторизации от Apple

• Использование OAuth и API VK в Go

• Авторизация с помощью Facebook и Vkontakte в одностраничном приложении на Backbonejs + Express

• Авторизация пользователя на вашем сайте через Telegram для Django

• Аутентификация OAuth2 в приложении посредством Google Sign-In. Непрерывный доступ к API Google

7. Адаптивный дизайн

Хочется, чтобы приложение смотрелось прилично хотя бы на актуальных смартфонах. Только вот смартфонов этих тысячи, и отличаются они не только разрешением, но и пропорциями, и плотностью пикселей. А есть еще и особенности конкретных моделей, вроде моноброви у iPhone X.

Кроме того, встречается как натуральный Android (например, у Samsung или Google), так и смартфоны, использующие ядро Android + свою интерфейсную обертку (например, Xiaomi). Где-то клавиши навигации аппаратные, где-то виртуальные, а где-то их вообще нет.

Поэтому не думайте, что адаптировать дизайн под весь этот зоопарк простая задача. Для каждого разрешения нужно:

• растянуть интерфейс и контент под размеры экрана;

• масштабировать изображения без потери качества;

• масштабировать элементы управления, чтобы ими комфортно было пользоваться;

• выдерживать размер шрифтов так, чтобы тексты были читабельны;

• избежать наслоения элементов;

• не дать целевым кнопкам уйти за пределы экрана;

• продумать поведение экранной клавиатуры.

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

Помимо всех этих радостей, есть ещё и планшеты. Вы можете о них не думать, но владельцы планшетов обязательно подумают о вас.

Типичный владелец планшета

Что почитать по теме?

• Руководство для дизайнера по DPI

• О размере экрана, пикселя и элемента

• Оптимизация графики для Retina-экранов

• 32 отличия дизайна мобильного приложения под iOS и Android

• Поясняем за чёлку в Android P. Что делать с Android Cutout?

8. Организация тестирования

Тестирование приложения заметно отличается от тестирования сайта. Причем не в лучшую сторону. Поэтому если вы планировали, что ваши web QA быстро просмотрят приложение перед релизом и всё будет хорошо вероятно, вас ждет разочарование.

Вот на что стоит обратить внимание:

• Разнообразие устройств и разрешений.

• Большой разброс версий операционных систем.

• Мобильные механики: мультитач, работа в фоне, аппаратные кнопки, экранная клавиатура.

• Ресурсы телефона: производительность, расход заряда, утечки памяти.

• Плохая скорость интернета или его отсутствие.

• Внезапные прерывания: смс, звонки, разряд аккумулятора.

• Работа push-уведомлений.

Типичная ситуация, когда баг возникает только на 10% устройств. Вы узнаете об этом только из жалоб пользователей. А у вас такого устройства просто нет. Как тогда воспроизвести баг и понять, что удалось его починить? Можно использовать эмуляторы, но они не эмулируют аппаратную часть. Есть ещё фермы устройств, но они тоже не идеальны например, не позволяют пощупать свой продукт.

На нашей практике был случай, когда пришлось прямо в карантин, всеми правдами и неправдами доставлять конкретную модель Xiaomi нашему разработчику, работавшему на удаленке. Потому что никак иначе не удавалось пофиксить проблемные кейсы в приложении.

К качеству мобильного тестирования особые требования: в отличие от web, вы не сможете быстро пофиксить баг, если QA его пропустили. Придется снова собирать билд, отправлять его на ревью, ждать эпрув.

Что почитать по теме?

• Что общего у мобильного QA и осьминога

• 7 лучших ферм устройств для тестирования мобильных приложений

• Управление фермой Android-устройств. Лекция в Яндексе

• Гиперкуб. Как мы обеспечили разработчиков тестовыми устройствами и не потеряли их

• Как настроить расширяемую систему для регрессионного тестирования на телефонах: опыт мобильной Почты Mail.Ru

• Мобильное тестирование, автоматизация тестирования, тестирование API: с чем нужно уметь работать в 2021 году

9. Поддержка версионности

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

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

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

Нет-нет, постойте, вот вам задачка на подумать: если вы релизите бэкенд в понедельник и в тот же день отправляете билд в сторы то в Google Play приложение обновится в среду, а в Apple Store через неделю. То есть у вас невольно получится три разных даты релиза и несовпадение версий фронтенда и бэкенда как это вообще должно работать?

Что почитать по теме?

• Версионность веб-приложений

• Версионная миграция структуры базы данных: основные подходы

• Генерируем номер версии и билда на иконке iOS приложения

• Инструмент автоматизации управления версиями

10. Работа офлайн

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

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

Что с этим делать? Как минимум выдать ошибку и объяснить пользователю, что происходит. Как максимум сделать офлайн-режим или скачивание данных на устройство (как это сделано у Google Maps или 2GIS, например).

Но офлайн-режим это не только работа без интернета. Это еще и система синхронизации с сервером. В общем, задача не самая тривиальная, придется повозиться.

Что почитать по теме?

• Автономность в первую очередь

• Поиск без интернета. Новая бета приложения Яндекс

• Как мы запустили offline-версию сайта RG.RU

• Переходим В OFFLINE FIRST с использованием Core Data и Managed Document(s)

• Amelisa. Оффлайн и реалтайм движок для React и Mongo

• Оффлайн-режим на iOS и особенности его реализации на Realm

11. Push-уведомления

Уведомления самый удобный способ взаимодействовать с мобильными пользователями вне приложения. Вряд ли вам удастся пренебречь таким инструментом.

Но прикрутить механику отправки пушей это только полдела. А вот вторая половина:

• Как вы будете отправлять пуши? По расписанию, по триггерам или вручную? Не исключено, что вам понадобятся все три способа.

• Если уведомления отправляются по расписанию нужно учитывать время и часовой пояс получателя. От разбуженного среди ночи пользователя не ждите слов любви.

• Если пуши отправляются по триггерам реализация самих триггеров может оказаться трудоемкой задачей.

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

• Вероятно, вам понадобится отдельная логика отправки пушей: очередь, приоритеты, ограничения.

Все вышесказанное будет не особо эффективно, если только 10% пользователей согласятся получать уведомления. Поэтому отдельный квест: как грамотно запросить разрешение на отправку. Ведь если пользователь нажмет Запретить исправить это почти невозможно.

Что почитать по теме?

• 5 ошибок в реализации push-уведомлений для мобильных приложений

• Безопасные push-уведомления: от теории к практике

• Основы успешной реализации push-уведомлений для мобильных приложений

• Пара способов отправить уведомления на смартфон со своего сервера

• Внедряем кросс-платформенные пуш-уведомления: дополнительные возможности

12. Перевод и локализация

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

Локализация почти всегда выглядит простой задачей, и почти всегда это не так.

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

Стоит ли говорить, что перевод это только часть локализации?

Что почитать по теме?

• Локализация приложения за 10 шагов

• Локализация приложений: как мы подружили перевод и разработку

• Локализация мобильных приложений: основные сложности и лайфхаки

• Что разработчику нужно знать о локализации приложения

• UX при локализации приложений: пособие разработчика

• Гайд по тестированию локализации и интернационализации, а также большой и полезный checklist

13. Защита приложения

Если вы делаете приложение попроще, чем Telegram / Monobank / VK то вряд ли вопрос безопасности не дает вам уснуть. Тем не менее, по моему опыту, даже маленькие приложения ломают.

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

Более наглые ребята могут ломать ваше приложение прямо в сторе. Говорят, что особенно легко это делать в Google Play. Есть разные способы, расскажу, как было у нас.

Между покупкой в приложении и фактическим подтверждением платежа от стора есть окно, примерно от часа до суток. Конечно, если пользователь сделал оплату мы не можем заставлять его ждать сутки, прежде чем дать доступ к контенту. Поэтому мы выдаем доступ сразу.

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

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

В ожидании вашего релиза

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

Что почитать по теме?

• Топ-10 уязвимостей мобильных приложений и способы их устранения

• Безопасность данных в разработке мобильных приложений

• Разработчик, помни трафик твоего приложения смотрят

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

• Безопасность Android-приложений. Лекция в Яндексе

• Двухфакторная аутентификация, которой удобно пользоваться

That's all Folks!

Мне не хотелось бы, чтобы статья демотивировала тех, кто собрался делать свое первое приложение. Её задача помочь трезво оценить объем предстоящей работы и показать неочевидные проектные риски. Иногда именно неверная оценка сложности проекта губит хорошие продукты.

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

Как работает синергия рисков

---

P.S. Я в общих чертах обозначил, на что стоит обратить внимание. Но чтобы разобраться в любой из этих тем лучше почитать специализированные статьи. А если вы помните хабростатью, которая хорошо раскрывает любой из перечисленных вопросов поделитесь ссылкой и я добавлю её в пост.