О том, как бороться с вредными для пользователя «хотелками» заказчиков, рассуждает в своей колонке Senior Android-разработчик Вячеслав Кацубо.
Однажды мне понадобился инженерный калькулятор. Я зашёл в Play Market и начал устанавливать первый попавшийся. Смотрю список разрешений, которые просит приложение, а там – доступ к контактам. Что?! Я ведь только посчитать хотел! Открываю второе приложение, начинаю установку – получаю запрос на доступ к интернету. Вы что на сервере считать собрались? Третий – передо мной предупреждение о платных операциях. Как это понимать? Пять раз посчитать можно бесплатно, а шестой – за деньги?
Неужели люди, которые заказывают разработку таких приложений, всерьёз думают о том, что пользователи настолько тупы и будут устанавливать их, даже если калькулятор запрашивает доступ к контактам и смс?
Я ещё готов понять разрешение на доступ к интернету – допустим, надо зарабатывать на рекламе. Но телефонная книга? Осмелюсь предположить, логика такая. Заказчик решил, что монетизировать будет через рекламу, значит лучше, если она будет таргетированная. Для этого он прикручивает аналитику, которая отслеживает, какими операциями чаще пользуется человек: делением или подсчётом процентов. Если проценты, велика вероятность, что он считает что-то по кредиту. Соответственно, это надо учитывать в рекламных сообщениях. На всякий случай извлечь контакты и позвонить, узнать, вдруг на самом деле кредит нужен, или доллары поменять. А потом читаем смс и смотрим, что же там человек хочет...
Зайти можно ещё дальше. Если операция по расчету тяжёлая (синус с точностью до ХХ знаков), а человеку позвонили, можно приостановить её на время телефонного разговора, но для этого надо подкрутить опцию прослушивания звонков. И всё это про калькулятор!
Приблизительно такая же история с приложениями «фонарик». Просят дать доступ к wi-fi подключениям и месторасположению. И всё это, чтобы подсветить?
С ежедневником были как-то проблемы. Чтобы оставить себе заметку, надо было регистрироваться, синхронизировать со всеми устройствами. А если я не хочу синхронизацию и мне это надо только на мобильном телефоне? Или я в лесу, где нет интернета, вспомню, что надо себе поставить напоминалку «покормить кота Филю»?
Всё это к тому, что разработчики, руководствуясь пожеланиями заказчика, превращают простое и понятное приложение в сложное. А порой и вовсе встроить невстраиваемое: например, начинить калькулятор несвойственными ему функциями и сделать из него “мясокомбинат”. И это самая настоящая боль, с которой сталкиваешься не только как пользователь, но и как программист.
Наглядный пример. На всех современных девайсах есть функция расшарить. Но иногда заказчики хотят использовать другие инструменты для того, чтобы поделиться какой-то информацией. Присылают многостраничные гайды и просят сделать всё по инструкции, с оригинальным оформлением. Получается, мы к приложению весом 100 Кб подключаем библиотеку на 5 Мб, которая всего лишь красиво открывает окошко, зато по всем правилам.
И это занимает три дня вместо пяти минут, которые ушли бы на то, чтобы использовать встроенную в систему функцию шаринга.
Как помочь фонарику остаться фонариком?
1. Определиться, насколько важен заказчик.
Если отталкиваетесь исключительно от «больше часов – больше платят» и можете себе позволить схему «забил-сделал-забыл», тогда можно не тратить много времени. Если же заказчик стратегически важен, и вы думаете о перспективе, настоятельно рекомендую следовать пункту 2.
2. Зачем изобретать велосипед?
Этот вопрос разработчик должен задать заказчику, когда сталкивается с подобными ситуациями. И обязательно рассказать об уже существующих «велосипедах», из которых логично выбрать максимально подходящий и ехать на нём. Человек ведь может думать, что он хочет, а на самом деле – нет. Для этого ему надо показать возможные подводные камни.
Простой пример. Заказчик где-то увидел, что рекламные всплывающие окна хорошо работают и приносят деньги. И он слепо переносит это на свою игру-кликер. Пользователь кликает по центру экрана, в какой-то момент на экране появляется реклама, он по инерции нажимает и только спустя несколько секунд понимает, что дал доступ к своим контактам.
Практика показывает, если заказчик продолжает рьяно настаивать на своём, спустя какое-то время, когда посыпятся отзывы от пользователей, придётся возвращаться на старт и ехать на давно забытых велосипедах. Но совесть разработчика уже будет чиста, потому что он-то предупреждал и предлагал. А значит, грозит не баг фикс, а фич реквест. Согласитесь, намного приятнее.
3. А действительно ли это надо пользователю?
Ещё один вопрос, ответ на который может помочь выбрать правильную альтернативу. Правда ли человеку, которому понадобился фонарик, остро необходимо, чтобы длительность его свечения и места использования трекались на сервере?
4. Постараться, чтобы на проекте был влияющий на окончательное решение заказчика человек.
Это может быть технический менеджер, бизнес-аналитик, непосредственно разработчик. Проще говоря, неравнодушный, дотошный в лучшем смысле этого слова, глубоко разбирающийся в технических деталях специалист, который способен аргументированно объяснить заказчику, что такое хорошо, а что такое плохо.
5. Разработка должна осуществлять строго в соответствии с методологией.
Бесконечные скрамы придумали не только для того, чтобы контролировать таймлайны. С их помощью можно ещё и вовремя тушить пожары из фантазий заказчиков.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.