Немного общей статистики

Android VS iOS

Чтобы с самого начала ограничить пыл заказчика: почти 90% мобильных устройств в России – это Android. О чем эта цифра должна говорить вам, как заказчику? О том, что если вы сомневаетесь в успехе своего приложения, то не надо тратить двойной бюджет на две платформы. Сделать надо сначала под Android.

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

Делать под iOS в первую очередь можно и нужно тогда, когда вы ориентированы с первого релиза на покупки в приложении, на американский рынок или на российского потребителя с доходом выше 100 000 рублей в месяц. Ваша целевая аудитория – welcome!

Секунды против вас

Время единовременной сессии пользователя с устройством в 2015 и 2016 годах сократилось с 11 до 9 секунд соответственно. Объясняю на пальцах: пользователь достал, посмотрел и снова вернул в карман.

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

Программирование – это работа

Работа живых людей. Независимо от рынка труда и разницы в стоимости тех или иных специалистов, в одной и той же студии приложение для Android и это же приложение для iOS не могут стоить по-разному!

Если вам за android-версию озвучивают цену 300 000 рублей, а за iOS 450 000, то это как минимум сигнал к переговорам, а как максимум повод задуматься: скорее всего, у студии нет своего разработчика iOS или обоих разработчиков и они просто заказывают на стороне. Один просит одних денег, другой – других, а студия хочет сохранить свою маржу, отсюда и разница в итоговой цене.

«Бумажный этап» или с чего начать

Каждый разработчик был бы безумно счастлив, если бы заказчики сами умели писать ТЗ. Качественные, подробные. Но это только мечты, потому что ТЗ – это итог двусторонней работы. Не будет ТЗ без конкретного разработчика, потому что кроме ваших «хотелок», там должны быть учтены и моменты, о которых знает и которые умеет реализовать только конкретный разработчик.

Нет смысла рыть интернет с запросом «шаблон ТЗ для приложения». Не надо вам этого. Возьмите десяток листов бумаги и карандаш. Ручку, если кому удобнее. Каждый лист бумаги – это экран мобильного. Слишком большой? Ну так и рука ваша – это не Photoshop.

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

Вы поразитесь, насколько этот примитивный метод сократит ваш путь до итогового качественного ТЗ.

Для продвинутых заказчиков

Когда «бумажный» этап пройден, но вам очень хочется, чтобы приложение ожило, можно попробовать Marvel App. На мой взгляд, это бомбическая вещь. На компьютере в Paint вы можете нарисовать, или скачать шаблон у меня из публикации.

На этом самом шаблоне в том же самом примитивном Paint вы рисуете свой макет (прототип). Каждый экран. Кнопки – кружки или квадратики. Пункты меню – прямоугольники. Перерисовали все свои бумажные экраны? Каждый в отдельном файле. Должно получиться минимум с десяток, а то и больше файлов.

Нарисовали? Что дальше:

1. Перекидываете себе эти файлы в мобильное устройство.
2. Грузите Марвел и в проект импортируете все созданные изображения.
3. С помощью тычка пальца в каждую кнопку и меню link вы делаете связи между вашими экранами.
4. Когда все закончите, нажимаете треугольничек play в правом верхнем углу, и (эврика!) у вас получился почти профессиональный прототип приложения, которым можно поделиться с друзьями для оценки функционала, поделиться с бизнес-партнерами, поделиться с будущим разработчиком, чтобы он знал, что вы от него хотите. Для него такой макет – это в сто раз лучше кучи слов, которые вы напишете в письме или расскажете по телефону.

«Мясо» или реальный поиск исполнителя

Как искать – всем понятно: Яндекс, Гугл, рекомендации, фриланс. Все средства поиска хороши по-своему. В итоге вы будете переписываться и разговаривать по телефону, скайпу или другим популярным способам.

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

Общение по электронной почте с сохранением истории переписки

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

Критерий 2. Подписание NDA

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

Критерий 3. Официальное предложение

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

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

«Жареное мясо» или процесс согласования договора и ТЗ

Юридические вопросы

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

Очень желательно предусмотреть порядок сдачи работ по каждому этапу:

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

Согласование ТЗ

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

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

• В ТЗ должны быть указаны общие технические и графические требования к платформе и в целом к окружающей нас действительности. И у Google, и у Apple есть свои рекомендации по оформлению приложений и по их функциональным особенностям. Разработчики знают об этих рекомендациях. Хорошие разработчики знают их на зубок. Средние знают, что они существуют. Плохие просто знают, что «что-то там есть». Какой вам нужен разработчик – определитесь сами.
• Какие версии операционных систем должны воспринимать ваше приложение, какие серверные мощности вам нужны, каким способом приложение будет «общаться» с базой данных и прочее. Опять же, рекомендую обратиться к статистике и опыту разработчика. Если он говорит, что Android 4.4 – это 80% от всего андроида в России, значит, не нужно вам 4.3, если у вас старый телефон. Если он говорит, что с учетом специфики вашего приложения хоститься лучше за границей, значит, наверное, так лучше. Благо, нет проблемы купить заграничный хостинг.
• Дальше в ТЗ будет детальное описание каждого экрана вашего приложения и действий, которые будут на нем происходить. Как бы это ни было нудно, придется все это вычитывать. Это важная кропотливая работа, но она того стоит, ведь ТЗ – это неотъемлемая часть вашего договора. Это приложение к договору!

Как итог: договор и ТЗ – одно целое, грамотно составленное и вовремя подписанное, с соответствующей постатейной сметой! Смета включает в себя вид работ, количество часов, стоимость часа и общую итоговую сумму. Выдержки из .

Еще не всё… Важные моменты

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

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

Важно!

А ещё вам, как грамотному заказчику, со студией разработки или непосредственно с дизайнером необходимо подписать авторский договор. Зачем?

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

Любой дизайнер может подать иск и требовать от заказчика прекратить использование произведения дизайна и выплатить компенсацию размером от 10 до 50 000 минимальных размеров оплаты труда. Так что вам стоит призадуматься заранее. 99% заказчиков просто везет, что в России дизайнеры, во-первых, юридически безграмотные, а во-вторых, просто добрые.

Ещё один момент – поэтапная оплата за выполнение работ. Никаких 30% или 50% предоплаты. Предоплата может быть только за первый этап работы, чтобы разработчик был убежден в вашей честности. Остальные этапы – по факту сдачи. Если разработчик сливается на этом – вам не нужен такой разработчик (знаю, за этот пункт именно разработчики меня закидают помидорами, но я сейчас пишу для заказчиков).

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

Я понимаю, что IT-сфера развивается и может быть iOS станет кардинально другим через полгода. Но заказчику должно быть важно, чтобы его приложение работало стабильно для тех версий тех платформ, под которые его писали. И так как код не изнашивается, то в чем проблема дать на него пожизненную гарантию?

Проблема только в одном – в умах ленивых разработчиков, которые не закладывают рекламационные риски в стоимость своего человека-часа и не хотят общаться со старым клиентом по старым проблемам через 2-3 года после релиза приложения. Денег-то им за это не заплатят – «это ж гарантия».

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

Итог: без вас ничего не выйдет

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

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