Connect with us

Разработка

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

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

AppTractor

Опубликовано

/

     
     

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

Gravatar-Circle-150x150

Вы только что подписали договор с новым клиентом.

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

Вы надеетесь улучшить свою репутацию, представив этого клиента в своем портфолио. И они будут упоминать вас в пресс-релизах, что приведет к возникновению «сарафанного радио».

Ваш идеальный клиент и проект

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

  • Идея хороша. Это не очередной клон Facebook.
  • Похоже, что и бизнес модель выглядит прилично. Это не просто нагон бесплатных пользователей.
  • Клиент нанял дизайнера, чтобы он нарисовал прекрасные PSD.
  • Есть и интерактивный прототип в InVision.
  • Он даже изложил много мыслей и сценариев использования.

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

И вы начинаете разработку

После подписания договора дизайнер делится набором прекрасных PSD через Dropbox. Они выглядя фантастически. Вы рады работать с таким прекрасным дизайнером.

И вы собираетесь приступить к нарезке PNG…

Но понимаете, что нет PSD для iPhone 6S Plus и 3х разрешения. Нет проблем. Просто объясняете дизайнеру и просите его сделать версию 3х.

Все сделано. PSD поправлены. Давайте вернемся к работе.

И вы собираетесь приступить к нарезке PNG…

Вы обнаруживаете, что некоторые элементы с тенями не сделаны как отдельные слои. Вам нужны прозрачные PNG для скроллинга table view. Но вы не можете нарезать их без фонового изображения. Вы можете попробовать исправить это с вашими ограниченными навыками Photoshop. Но лучше, конечно, попросить дизайнера исправить это.

Отлично. Теперь все слои правильные и вы можете вырезать прекрасные PNG с прозрачным фоном.

И вы собираетесь приступить к нарезке PNG…

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

Время вернуться к клиенту и обсудить некоторые из этих тонкостей. Действительно ли он хочет все это в MVP или это можно оставить до следующих версий? Они действительно полезны или это просто свистелки и пищалки?

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

И вы собираетесь приступить к нарезке PNG…

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

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

После встречи возникает еще больше вопросов.

Показывать обновления пользователю в дашборде нормально. Но надо ли оставить этот раздел пустым, если у него пока нет друзей? Что он должен показывать, если приложению не удалось получить данные, так как пользователь в поезде или в туннеле? Что должно происходить, если бэкенд падает? Должно ли показывать сообщение с ошибкой? Или оно все должно также тихо падать? Может стоит показывать закэшированную версию из Core Data? Какая политика синхронизации?

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

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

После того, как PSD закончены, вас просили дать два числа – количество часов и стоимость часа. Клиент ходил по рынку и пытался нанять разработчика, которому он хотел бы заплатить, и с которым ему комфортно было бы работать.

Надвигается провал

full-project-1

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

Это новый проект в Xcode, так что вам не надо мириться со всем хламом, оставленным предыдущим разработчиком. У вас полная свобода в плане дизайна, архитектуры, рефакторинга и юнит тестов.

Однако чертовски трудно превратить PSD в реальный код, который:

  • Работает достаточно быстро на iPhone и iPad с разными размерами экрана и разным разрешением, разным объемом памяти и свободного места.
  • Не падал бы сразу и на симуляторе и на физических устройствах, которые приложение должно поддерживать.
  • Обрабатывало бы все нюансы и шероховатости разных версий iOS SDK.
  • Полностью покрывало бы весь набор юнит тестов, касающихся всех бизнес-правил и случаев использования.

Если что-то случается:

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

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

О нет, вы плохой разработчик.

Это правда все ваша вина?

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

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

Это действительно ваша ошибка? Действительно стоит вас обвинять?

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

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

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

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

Задержите дыхание. Я покажу вам определяющую причину вашей неудачи.

Сравнивая веб и мобильную разработку

technology-792175_1920

В веб-приложении вы фронтенд или бэкенд разработчик.

В мобайле вы разработчик.

Image1

В веб-приложении фронтенд разработчик режет PNG из PSD. Он пишет HTML и CSS. Он кодит JavaScript. Он заботится о множестве платформ и бразуеров. И он создает адаптивный дизайн, работающий на десктопах и мобильных устройствах.

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

Может ли дизайнер создавать интерфейс, используя Xcode?

Auto Layout требует понимания кода и iOS SDK. Будет очень трудно для непрограммиста создавать пользовательский интерфейс мобильного приложения.

Дизайнер должен:

  • Установить Xcode и настроить все сертификаты и профили.
  • Понять, когда использовать bar controller, navigation controller, split view controller, page view controller.
  • Знать, когда использовать table view, а когда scroll view.
  • Знать различия между статической и динамически прототипируемой ячейкой таблицы.
  • Создавать подклассы UITableViewCell.
  • Хорошо понимать все встроенные контролы.
  • Уметь настраивать ограничения в сториборде и изменять их в коде.
  • Соединять IBOutlets и IBActions.
  • Создавать навигацию, используя переходы.

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

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

Если сложно от дизайнера ожидать создания пользовательского интерфейса в Xcode, может быть есть мобильный фронтенд разработчик, который делает это?

Но, насколько я знаю, такой роли не существует. Но почему нет?

С точки зрения программирования есть очень много связей между storyboard и кодом.

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

Но подождите, есть и еще кое-что…

Мобильный разработчик создает сертификаты, provisioning профили, добавляет приложения в iTunes Connect, генерирует билды для TestFlight, отправляет приложение на ревью. Больше похоже на работу dev-op. Но как разработчик приложения, вы берете всю ответственность и работу на себя. Но с фиксированным временем, ожиданиями и оплатой!

Мобильная разработка = фронтенд разработка + бэкенд разработка + dev-op

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

Когда клиент хочет создать веб-приложение, он понимает необходимость хорошего дизайна, правильного HTML и CSS, серверного бэкенда и наличия dev-op для работы всего этого. Когда клиент хочет мобильное приложение, он знает только о дизайнере и разработчике.

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

А вы, вероятно, не думали об этом с такой точки зрения.

Что вы можете с этим сделать?

1392074355-5-questions-ask-before-developing-mobile-app

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

Вы также видите, что невозможно разделить эти роли из-за тесной связи storyboard-а и кода.

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

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

Улучшайте ваши коммуникационные навыки

Вы не хотите настраивать себя на неудачу. Вы хотите настраивать себя на успех. Для этого вам необходимы реалистичные ожидания с самого начала.

Вам надо обучать своих клиентов сложности, а не внутренней работе.

Вместо:

Координатная система iPhone 6S Plus это 414х736 точек. Но физическое разрешение только 1080х1920. Для отображения 3х ассетов на retina экране, надо отрендерить изображение 1242х2208 точек во время растеризации, а потом уменьшить его до 1080х1920 для отображения на экране.

Говорите:

Пожалуйста, попросите дизайнера сделать PSD с 3х ассетами с холстом 1242х2208. Если вам потребуется больше информации, вы можете послать ему эту ссылку с объяснением размеров экрана iPhone.

В настоящее время существует одно (а не три) разрешение, с которым надо работать. Больше подробностей вы можете узнать из приложенной ссылки.

Меньше – больше. Ссылка стоит тысячи слов

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

Когда ваш потенциальный клиент первый раз представляет вам проект, он рассказывает вам идею, идеального пользователя, функции и требования. Он хочет знать сколько времени займет проект и сколько будет стоить. Легко сказать ему, что он займет 6 месяцев и будет стоить 50,000 долларов (или вашу почасовую ставку).

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

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

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

Означает ли это, что вы можете потерять проект, если ваша оценка превышает бюджет клиента?

Да. Но.

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

Установите ваши рекомендации для дизайна

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

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

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

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

Повышайте свои дизайнерские навыки

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

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

Как убедиться, что все правильно?

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

Архитектура раньше тестов

Я говорил, как применять Clean Architecture к проектам на Swift и как писать юнит тесты с TDD. Я призываю вас изучить материал и задавать вопросы. В тоже время, не бойтесь экспериментировать с собственными методиками.

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

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
2 комментария

2 Comments

  1. Valentin Taranenko

    26.05.2016 at 03:47

    Шел 2016й год а дизайн все еще в psd. Есть же sketch и zeplin. Судя по тексту проблема в том что заказчик первый раз взялся за проект, и разработчик студент который первый раз приложение собирает.

  2. Dmitrii

    26.05.2016 at 05:12

    Какая-то фигня написана, на самом деле.
    Разумеется для мобильного проекта стоит нанимать дизайнера с опытом разработки мобильных приложений. И разумеется, дизайнер не должен уметь пользоваться XCode, но должен знать Apple UI Guidelines и хотя бы примерно представлять какие в системе есть контролы и что они умеют делать.

    Что касается нарезки – уже 1-2 года как XCode понимает векторный PDF, не надо использовать PNG.

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

    Что касается неудач в целом – в аппсторе больше 1.5млн приложений, от этого и надо плясать. Мало кому нужен 10й мессенджер на телефоне или очередная тупая игра. И проблема тут явно глобальнее чем отсутствие нарезки под модель телефона.

You must be logged in to post a comment Login

Leave a Reply

Новости

Digest MBLTdev: Новости для iOS разработчиков №170

В течение недели топовые iOS-разработчики Руслан Гуменный, Саша Черный и Саша Зимин, а также директор по продукту VK Иван Козлов собирают для вас интересные и полезные ссылки на статьи, необходимые для прочтения каждому начинающему и опытному разработчику. В каждом выпуске – новости, коды, инструменты, дизайн и прочее.

e-Legion

Опубликовано

/

Автор:

Что, коллеги, много ли у вас писем от всевозможных сервисов на тему политики конфиденциальности и подобному? За последнюю неделю, полагаю, много. Всё потому, что 25 мая 2018 года вступает в силу общий регламент по защите данных, он же General Data Protection Regulation (GDPR). Приложений это тоже касается, ждите новых всплывающих окон. Посмотрим, какой будет эффект. Станут ли документы короче, избавятся ли формулировки от юридического языка, появится ли возможность явно видеть, что происходит с твоими данными. Хорошо бы.

4

The iOS Testing Manifesto

Манифест — не манифест, но краткий обзор разных видов тестов с правилами, что в них стоит делать, а что нет. Ах ты ж, и правда, манифест.

MEDIUM.COM

ConsentKit

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

GITHUB.COM

Launch arguments in Swift

Терминал жил, жив и будет жить. Если вы уважаете командную строку, не хотите покидать контекст родного Swift и периодически на вас нападает желание написать какую-нибудь утилиту, танцуйте! Статья по работе с аргументами командной строки в Swift для вас.

WWW.SWIFTBYSUNDELL.COM

Типографика в iOS

Отличная статья по работе с текстом в iOS.

HABR.COM

UI-тесты в iOS проекте. Есть ли профит и для чего их вообще внедряют?

Доклад с AppsConf про UI-тесты. Живой опыт от ребят с интернациональным приложением, в котором UI сильно меняется от страны к стране.

HABR.COM

2

Continuous Integration Services for iPhone Apps in 2018

Обзор CI сервисов, на которых можно собрать ваш проект. Примечательно, что есть Bitrise, который бесплатно даёт 200 билдов в месяц.

IOSREVIEWED.COM

3

Illustration in the App Store

Автор восторгается иллюстрациями в App Store и рассуждает об их ценности.

WWW.SUBTRACTION.COM

Why UX, UI, CX, IA, IxD, and Other Sorts of Design Are Dumb

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

MEDIUM.MUZ.LI

16f106c0eaa442b184873f18f426a916

NFNG talks: интервью с Валерией Коваленко

Интервью с Head of Product в Qlean, в котором хорошо раскрыты внутренние процессы Qlean (даже React Native вспомнили).

WWW.YOUTUBE.COM

Предыдущие выпуски Digest MBLTDEV и подписка доступны на официальном сайте. Всё бесплатно и никакого спама, честно!

Комментарии
Продолжить чтение

Медиа

Android Dev Подкаст. Выпуск 66. Новости. Даггер мертв?

Поговорили за дебаг меню и их необходимость, как писать Dependency Injection графы руками, управлением девайса с компьютера и Android Studio 3.2.

AppTractor

Опубликовано

/

Автор:

Поговорили за дебаг меню и их необходимость, как писать Dependency Injection графы руками, управлением девайса с компьютера и Android Studio 3.2.

Комментарии
Продолжить чтение

Разработка

Интересные материалы для разработчика мобильных приложений #214 (21-27 мая)

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

AppTractor

Опубликовано

/

Автор:

Как я делал свой учет финансов под Android с блэкджеком, СМС и ФНС

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

Обновления Material Design: как жить дальше

Google I/O 2018 оставила огромное количество материала для осмысления. Что нового? Как жить дальше? Устарело ли моё приложение? Могут ли кнопки быть шестиугольными? Дизайнеры снова больше не нужны? Осмысливать приятней не спеша и маленькими порциями. Эта порция — про дизайн.

 iOS

 Android

 Разработка

 Аналитика, маркетинг и монетизация

 AI, Устройства, IoT

 Вакансии

Комментарии
Продолжить чтение

Новости

Интересные материалы: 24.05

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

AppTractor

Опубликовано

/

Автор:

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

Комментарии
Продолжить чтение

Реклама

Наша рассылка

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.