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

В 1:32 утром по непонятным нормальному человеку причинам я проверяю свою почту — меня пригласили написать статью на тему Developing for good, класс!

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

Что же выбрать! Но… упс.

Перечитываю е-мэйл. Developing for good: Productivity. Я не понял, откуда появилась «Продуктивность». Придется отложить свои идеи на другой раз, а в этой статье я буду говорить о лучших бизнес-практиках для разработчиков приложений. Особенно тех, что касаются продуктивности — видите, как я быстро перескочил на новое направление.

Вот оно, я надеюсь, вам понравится. Но мне нужно предупредить вас — я не разработчик. ОМГ, вы, кажется, кричите, как я только смею. Если вы еще читаете, то я дизайнер. Всегда был им и буду. Я создал бизнес по разработке мобильных приложений 6 лет назад, имею несколько коммерчески успешных проектов, как своих, так и с клиентами, и недавно сделал b2b-инструмент, чтобы облегчить другим разработчикам приложений создание их продуктов.

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

Барабанную дробь, пожалуйста…

Дело вообще не в коде!

Я чувствую ваше возмущение. Но дайте мне возможность объяснить, что я имею в виду.

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

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

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

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

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

Процесс

Нужно подчеркнуть, что мои клиенты часто были индивидуалами, мы их можем назвать App-preneurs (солидно звучит) или маленькими компаниями с 8 или менее сотрудниками.

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

Вот процесс, через который идет ваш клиент:

• вдохновение
• оценка стоимости
• поиск разработчика
• частичная оплата его услуг
• начало разработки
• паника — будет ли вообще это приносить деньги?
• небольшое изменение приложения
• еще изменение, больше паники
• выплата остатка
• выпуск приложения
• молитвы со скрещенными пальцами

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

Процесс 2.0

Чуть поумнее:

• вдохновение (это часто случается до того, как нас позовут, но не всегда)
• разработка идеи
• разработка идеи
• разработка идеи
• выбор бизнес-модели приложения
• тесты концепции
• оценка стоимости
• как я могу за это заплатить
• получение средств
• поиск разработчика
• частичная оплата его услуг
• начало разработки
• выплата остатка
• выпуск приложения

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

Кто такой дизайнер

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

Честно, я этого им не говорю, потому что реакция «Я не дизайнер» очень бурная — так можно и потерять клиента. Но это все же правда.

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

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

Я не отвечаю за дизайн?

Если вы не отвечаете за дизайн, я думаю, вы должны. Но это другой разговор.

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

Тестируйте на ранних этапах

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

В худшем случае (это почти никогда не случается), окажется, что вы и ваш клиент правильно поняли друг друга, вы двигаетесь в верном направлении и можно продолжать.

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

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

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

Помощь уже здесь

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

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

Три средства, которые нужно держать в уме:

Prototype on paper – отличный инструмент, который позволяет фотографировать черновики, создавая из них демо лучших моментов в приложении.

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

OSIOS — новичок. Единственное средство, которое было создано специально для разработчиков мобильных приложений. Включает в себя инструменты для макетов приложений. Чтобы быть совсем откровенным, должен признаться, это мой проект.

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

Уроки

Вот что мы сегодня узнали:

• Сначала дизайн, потом разработка.
• Дайте клиенту короткую анкету для заполнения. Это сэкономит время продумывания, как лучше это сделать, и обеспечит вас всей критически важной информацией. И позволит вам в будущем сравнивать проекты, что будет полезно для роста вашей компании.
• Добейтесь ясности по проекту как можно раньше. Визуализируйте важные элементы приложения.
• Лучший способ все прояснить — сделать рабочий визуальный макет.
• Для обсуждения проекта используйте письма. Это самодокументация и позволит избежать в будущем споров.
• Все изменения должны быть четко обговорены.
• Отслеживайте запросы на изменения, чтобы их нельзя было оспорить потом.
• Используйте диаграммы для отслеживания прогресса и траектории проекта.
• Обсуждайте проект на двух уровнях. Глобально и экран за экраном.
• Сделайте прототип приложения, если он совпадает с подтвержденным макетом, чтобы потом не было слишком много изменений, не было задержек и споров вообще.
• Анкетируйте выходные впечатления клиентов для того, чтобы отслеживать прогресс своей компании.

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

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

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

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

Симон К Вильямс, со-основатель OSIOS, владелец AppManSecrets, автор книги «Rich App, Poor App».