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

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

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

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

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

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

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

• Идея хороша. Это не очередной клон 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 закончены, вас просили дать два числа – количество часов и стоимость часа. Клиент ходил по рынку и пытался нанять разработчика, которому он хотел бы заплатить, и с которым ему комфортно было бы работать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В веб-приложении фронтенд разработчик режет 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 для работы всего этого. Когда клиент хочет мобильное приложение, он знает только о дизайнере и разработчике.

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

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

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

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

Вы также видите, что невозможно разделить эти роли из-за тесной связи 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. Я призываю вас изучить материал и задавать вопросы. В тоже время, не бойтесь экспериментировать с собственными методиками.

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