Войти в систему
Войти с помощью соц. сетей:
Вы не Rovio. Если ваша PR-стратегия состоит из «создай что-нибудь, и они придут», то вам стоит хорошенько подумать еще раз.
Джанел Торкингтон, Appszoom
Ныне всемирно известный сервис Dropbox впервые появился на публике в виде трехминутного видеоролика. Видео демонстрировало будущие функции сервиса. За одну ночь число подписчиков пока еще не существующего продукта выросло с 5000 до 75 000 человек. Так авторы и инвесторы поняли, что сервис интересен пользователям.
Первый этап создания мобильного приложения — реклама и пиар, позволяющие заранее оценить уровень спроса и как можно быстрее получить обратную связь от потенциальных пользователей. Зачем ждать выхода приложения, теряя драгоценное время и клиентов? Чем раньше вы начнете раскручивать свое приложение, тем больше внимания привлечете к нему и тем больше пользователей получите. Как только вам будет, что сказать и показать потенциальным пользователям, от которых зависит популярность и коммерческий успех мобильного приложения, — сделайте это.
Среди дополнительных преимуществ раннего пиара — возможность собрать контакты целевой аудитории, узнать больше информации о предпочтениях потенциальных пользователей, устранить допущенные ошибки в презентации приложения. Наличие сайта и контактов его создателя значительно повышает доверие к владельцу мобильного приложения, а, следовательно, и к самому приложению.
Единственная причина, по которой немногие приложения раскручиваются еще до их запуска, — это страх. Люди боятся, что кто-то украдет их идею и успеет реализовать раньше, чем они. Некоторые боятся, что, если расскажут о своей идее, а реализовать ее по какой-то причине не получится, будет не только обидно, но и стыдно за пустые обещания. И те и другие часто держат идею приложения в секрете до его запуска. Естественно, это только мешает разработке и раскрутке приложения.
Джон Саддингтон, партнер The Iron Yard (акселератор стартапов), на краудфандинговой площадке собрал 113% средств из запрашиваемых $50 000 для запуска мобильного приложения Pressgram, способного обрабатывать приложения качественнее, чем Facebook и Instagram (больше функций — больше возможностей). Поскольку кампания по сбору средств на Kickstarter была более чем успешной, Саддингтон решил таким образом собрать деньги и на свой новый проект. Теперь представьте, что он решил никому не рассказывать о своей идее. Как бы он ее тогда реализовал? Иногда единственный способ создать и успешно продать приложение — заранее рассказать о нем как можно большему количеству людей: потенциальных пользователей, разработчиков, инвесторов.
Я не призываю выдавать самые ценные сведения конкурентам или обещать золотые горы пользователям. Можно пиарить будущее приложение, рассказывая о нем только в общих чертах, не выдавая секретов и не обещая того, что заведомо невозможно реализовать. Раздавая обещания, учитывайте свои финансовые возможности и возможности существующих технологий. Можно ограничиться намеками, поддерживая интригу до последнего момента, так что никто не будет знать, о чем идет речь, но многие с нетерпением будут ждать выхода приложения. Возможностей для рекламы и пиара много, главное — побороть страх перед конкурентами и заняться продвижением своего детища, как только было принято твердое решение, что новому мобильному приложению — быть!
Первое, что вы должны сделать — хороший промосайт. Его важными частями должны стать качественная SEO-оптимизация и реклама. Это необходимо для привлечения большего количества потенциальных пользователей. Правильная SEO-оптимизация также отсеет нецелевую аудиторию. Установленные разные системы веб-аналитики позволят хорошо изучить целевую аудиторию и определить тех, кто ею не является. С помощью веб-аналитики вы сможете узнать пол, возраст, интересы и потребности ваших пользователей и собрать большую базу ключевых слов для продвижения мобильного приложения, исключив неподходящие. Эти данные помогут вам эффективнее продвигать приложение через самые разные каналы.
Обычно на промосайте размещают форму обратной связи, в которой каждый посетитель может добровольно оставить свой имейл для получения новостей о приложении и уведомления о его выходе. Так вы получите имейлы потенциальных пользователей и сможете общаться с ними во время разработки приложения. Пропишите условия использования сайта, разместите их мелким шрифтом под формой, написав нечто вроде: «Оставляя нам имейл, вы соглашаетесь с данными условиями». В пользовательском соглашении можно прописать, что пользователи соглашаются получать новостную рассылку о вашем приложении и другие рекламные материалы. Можно предусмотреть, что люди согласны получать любые материалы и что вы можете продавать их имейлы третьим лицам, чтобы иметь возможность продать базу пользователей, но так лучше не делать, чтобы не отпугнуть потенциальных пользователей приложения.
В дальнейшем с помощью веб-аналитики вы сможете узнать, кто из посетителей заполнил форму обратной связи, а кто нет. Люди, оставившие имейлы, будут наиболее заинтересованными в вашем приложении, они и есть ваша целевая аудитория. Сделав выборку в веб-аналитике, вы получите о них больше полезной информации и сможете составить портрет покупателя, чтобы создать продукт и рекламные материалы для своей целевой аудитории, не разбрасывая ресурсы на широкую публику.
Для более подробного изучения целевой аудитории можно создать несколько версий промосайта. Каждый сайт будет иметь немного иную информацию о приложении. К примеру, каждый может делать акцент на разных преимуществах (выгодах, функциях) мобильного приложения. Таким образом вы сможете определить, какой из промосайтов был более популярен и, соответственно, решить, какая версия приложения будет самой востребованной.
Также вы можете разместить на сайте кнопку «Купить». Каждый, кто нажмет на нее, должен попадать на страничку с формой обратной связи либо регистрацией на сайте с объяснением, что приложения пока нет, но, как только оно выйдет, «мы вас проинформируем». Так поступают, чтобы определить реальное количество людей, готовых приобрести приложение, а не только тех, кто им интересуется. Люди, кликнувшие на кнопку «Купить», скорее всего, реально захотят купить готовое приложение.
Как только у вас появится сайт, вы сможете начать рекламную компанию в социальных сетях. В них стоит рекламировать как свое будущее приложение, так и промосайт. Создавайте отдельную группу либо страничку только для приложения. Набирайте друзей, оставляйте комментарии на страницах, которые посещает ваша целевая аудитория, делитесь интересными и просто веселыми материалами. Ваша задача — сделать страницу приложения посещаемой и узнаваемой.
Что можете сделать еще? Ходите на ИТ-тусовки, семинары и конференции. Выступайте или задавайте вопросы, представляясь и всячески пиаря себя и свое будущее мобильное приложение. По возможности «засветитесь» на телеканалах и в новостях. Отправьте пресс-релиз в СМИ: если вы напишите интересно, его обязательно кто-то опубликует.
Не забывайте, что на одном пиаре далеко не уедешь. На первом этапе люди поверят вам, если идея приложения им понравится. Дальше они начнут следить за вашими новостями, и вам придется постоянно рассказывать что-то интересное, иначе интерес публики ослабнет.
Вот о чем вы можете писать:
Ваши идеи, заметки, описание процесса работы, встречи, дела компании, скриншоты и зарисовки — все, что может сделать вас ближе и понятнее целевой аудитории.
Этот процесс чем-то напоминает ловлю рыбы: забрасываете крючок с наживкой и ждете, когда рыба клюнет, потом тянете, не давая ей сорваться с крючка.
На следующий день после запуска промосайта начните анализ результатов и не прекращайте его никогда. Записывайте все, что делаете, — эти данные помогут в дальнейшем анализе, станут источником новостей и интересных идей для пиара. Смотрите, кто интересовался приложением, как долго, на что они обращали внимание, а что игнорировали, когда больше всего интересовались, что остановило пользователя, почему и когда он ушел с сайта.
Следите за комментариями и статьями о вашем приложении. Всегда благодарите комментаторов за проявленный интерес, отвечайте на их вопросы и замечания. Собирайте любую полезную информацию по крупицам и в результате получите большой массив данных о своей целевой аудитории. Будущие пользователи помогут устранить грубые ошибки в приложении еще до запуска, сделать его качественнее и востребованнее.
Стоит выбирать очень тщательно, потому что есть много внештатных фирм по разработке. Вам может помочь понимание того, что самое главное для успеха вашего проекта, а затем внимательная проверка разработчиков и тщательный отбор. Поговорите с прошлыми клиентами, посмотрите портфолио, оцените примеры удаленной работы и изучите профайлы разработчиков, прежде чем выбрать фирму.
Рэнди Рэйесс, VenturePact
В последнее время появилось много создателей мобильных приложений, предлагающих разный подход к разработке и оплате. Заказчику, который плохо разбирается в этих вопросах практически нереально самостоятельно выбрать хорошего программиста. Думаю, ни для кого не секрет, что многие разработчики оказывают низкокачественные услуги по ценам, значительно превышающим среднерыночные. Поэтому перед заказчиком встает сложнейший вопрос: кому доверить разработку?
Самый простой ответ — сделать все самостоятельно. Да, это возможно. Нанять нужных людей, обеспечить их рабочими местами и пусть «работу работают». Однако это весьма затратный способ, к тому же отнимающий слишком много времени. Вначале придется найти необходимых сотрудников, провести собеседования, затем сплотить людей в одну команду, после чего начать работу и платить всем зарплату. А ведь еще нужно знать, кого брать, а кого нет, где и как найти хорошего специалиста и как отличить его от плохого. При таком подходе к разработке у вас не будет никаких гарантий, что вы сможете собрать подходящую команду и каждый ее участник окажется грамотным специалистом и отлично выполнит поставленные задачи.
Если в вашей компании есть дизайнер, программист или они оба, то это совсем не значит, что у вас есть команда для разработки мобильного приложения. Как я уже писал, для создания мобильных приложений нужны совершенно иные навыки и опыт, чем те, которые используют в своей работе дизайнеры и программисты, не занимающиеся разработкой подобных программ.
Раньше один программист мог написать код для чего угодно. Сегодня программистов много, одни пишут программный код для веб-сайтов, другие для компьютеров, третьи — для мобильных устройств. С дизайнерами похожая история. Есть дизайнеры для полиграфии, UX-UI, веб-сайтов и др. Каждый из этих специалистов отлично разбирается в своей родной отрасли, а в других или посредственно, или вообще никак. Если надумаете заставлять своего программиста писать мобильное приложение, потом не удивляйтесь, что разработка затянулась на неограниченное время и приложение будет совсем не таким популярным, как у конкурентов.
Если вы хотите собрать полноценную команду, и у вас есть на это бюджет, я как бизнес-хирург могу помочь собрать необходимых людей, сделать из них команду и поспособствовать правильной настройке внутренних процессов. Как всегда, вы можете это сделать, обратившись ко мне через мой официальный сайт http://semenchuk.com
Самым выгодным и оптимальным способом создания мобильного приложения является аутсорсинг, то есть наем специалистов со стороны. Есть фрилансеры и биржи фриланса, предлагающие сделать приложения по очень заманчивым ценам и обещающие качество запредельного уровня. На деле большинство фрилансеров выполняют низкокачественную работу, делают это долго и берут не так уж мало. Кроме того, один фрилансер не справится с разработкой качественного приложения. Довольно часто встречаются мошенники, берущие предоплату и затем исчезающие. Затягивание работы, использование чужих наработок, которые охраняются авторским правом, без вашего уведомления, создание приложений с большим количеством ошибок и недоработок — тоже не редкость. Для многих фрилансеров разработка приложений не основной способ заработка, а подработка, поэтому вы можете представить, как они работают (навыки, сроки, качество). Общаясь с фрилансером, вы никогда не знаете, с кем реально имеете дело, каков его реальный опыт и к чему приведет ваше сотрудничество.
Долго работающие опытные фрилансеры обычно объединяются и создают виртуальные компании. Виртуальные, потому что на деле никакой компании не существует, и хорошо, если хотя бы один из членов команды зарегистрирован как индивидуальный предприниматель. Такие компании обычно имеют свой сайт и работают только удаленно, без офиса. Они работают лучше, хотя фактически это те самые фрилансеры, только объединившиеся, поэтому результат их работы может быть совершенно непредсказуемым, так же как и результат работы фрилансера, работающего в одиночку. Вам могут сделать недорого очень качественное приложение либо же сделать очень дорого низкокачественное приложение.
Как говорит Александр Богданович, глава департамента разработки мобильных приложений XIM Wireless: «Фрилансер — это одна боевая единица. А компания гарантирует 100%-ное выполнение заказа, потому что в ее резервах есть определенное количество специалистов. И в случае выхода из строя одного человека есть целая команда, которая работает над данным заказом, что само собой является гарантом выполнения заказа. Поэтому команда — это неоспоримый факт выполнения заказа по сравнению с фрилансом».
Более оптимальный способ создания мобильного приложения — обратиться в компанию с офисом и постоянными сотрудниками. Да, это будет дороже, но вам гарантированно сделают работу согласно техническому заданию. Аутсорсинг достиг небывалых размеров. Сегодня необязательно набирать штат сотрудников: любую работу, от клининга до обеспечения безопасности, можно отдать на выполнение в другую компанию. Обращение в аутсорсинговую компанию по качеству, времени и финансам гораздо выгоднее, чем самостоятельная разработка.
Преимущества аутсорсинговой компании перед остальными разработчиками:
Опрос друзей и знакомых — это лучший способ найти подходящую компанию. Как показывает практика, через некоторое время кто-то из них поможет вам найти соответствующего разработчика. Всем, кто приходит по рекомендации, обещают самый высокий уровень обслуживания и самые низкие цены. Каждое слово нужно проверять, ведь разработка мобильного приложения не то же самое, что заказать рекламу в журнале или договориться с транспортной компанией о перевозке готового груза. Для создания приложения требуется организованный труд многих специалистов на протяжении продолжительного отрезка времени. Для этого у компании должен быть опыт, сотрудники, необходимые условия для разработки, поэтому вначале советую тщательно проверить найденную компанию.
Не останавливайте выбор на первой компании. Изучайте рынок разработчиков, ищите другие компании, общайтесь с ними. Так как стоимость приложения довольно высокая, а вам еще придется его развивать, улучшать и устранять ошибки, советую не полениться и тщательно выбирать, с кем сотрудничать. Общаясь с разными компаниями, вы почерпнете немало полезной информации, например, узнаете, что разные разработчики могут говорить совершенно противоположные вещи об одном и том же. И это нормально, потому что рынок молодой и на нем присутствует множество компаний с разным уровнем оказания услуг. Советуем пообщаться хотя бы с 10 разными компаниями, а еще лучше с 20–30. Таким образом вы лучше поймете, как общаться с разработчиками, и сможете выбрать лучшего.
Самый простой и быстрый способ проверить компанию — это, конечно же, поискать о ней информацию в интернете. Найдите сайт компании и тщательно его изучите. Обратите внимание на то, как часто на нем обновляется информация: если последний раз это было год назад, значит, дела компании не особо хороши. Просмотрите историю компании, контакты. Если есть раздел с сотрудниками — это большой плюс: изучите их биографии, обратите внимание на опыт и профессиональные навыки.
Помните, что большинство плохих разработчиков прекрасно осведомлены, что отзывы о них может найти кто угодно. Они могут прибегать к разным хитростям, чтобы негативные отзывы от реальных заказчиков не попались вам на глаза. Например, наймут людей, которые напишут множество позитивных отзывов, чтобы те перекрыли негативные отзывы. И кстати, они могут делать это бесконечно, ведь прибыль, получаемая от мошенничества, огромна.
Если компания существует на рынке не первый день, значит, у нее должно быть портфолио из созданных приложений. Многие компании любят хитрить и либо добавляют несуществующие работы, либо всячески пытаются накрутить количество работ, просто добавляя концепции и дизайны. В любом случае в портфолио важно не количество приложений, а качество их выполнения. Компания может выпускать приложения как горячие пирожки — по низким ценам и низкого качества, а может сделать немного качественных приложений, заниматься их развитием и поддержкой. Обязательно ищите ссылки на страницы с приложениями, читайте отзывы о них, смотрите их скриншоты и, естественно, опробуйте их в работе, чтобы понять, насколько приложения качественные на самом деле, насколько они вам нравятся и насколько хорошо выполняют свои функции.
Если в интернете вы не смогли найти ничего плохого о компании разработчиков, посетите их офис и по возможности посмотрите рабочие места сотрудников. В нормальных компаниях люди работают в хороших условиях, используя дорогие компьютеры и программы (это им позволяют их заработки). В офисе пообщайтесь со всеми, с кем только сможете. Не стесняйтесь задавать вопросы, любые, которые придут вам на ум: пригодиться может всякая информация.
Обратите внимание на манеру речи и поведение сотрудников. Представитель разработчика должен вести себя уверенно, не нервничать, быть вежливым и отвечать на любые вопросы. Если разработчик часто использует непонятные для вас слова и говорит быстро — это плохой признак: возможно, вас пытаются обмануть или по какой-то причине хотят запутать. Если вам что-либо непонятно или вы в чем-то сомневаетесь, задайте уточняющий вопрос или хотя бы сообщите об этом собеседнику. Хороший разработчик может легко и быстро объяснить что угодно относительно своей работы на простых примерах понятным для клиента языком.
Если вы живете в большом городе, то можете найти компанию-разработчика из провинции, делающую приложения значительно дешевле. Если у вас нет возможности регулярно туда ездить — не беда, работу можно организовать удаленно. Но в таком случае вы должны тщательно проверить компанию через интернет.
Итак, на что стоит обратить пристальное внимание?
Самый простой способ узнать уровень разработчика — спросить у него, как компания Google советует создавать приложения и как доносит эту информацию разработчикам. Дело в том, что Google выпустил руководство для Android-разработчиков о том, как лучше создавать и публиковать приложения. Если перед вами разработчик, который ничего не смыслит в разработке, он точно ничего не знает об этом руководстве и никогда его не читал. Руководство размещено в каталоге книг Google Play и называется The Secrets to App Success on Google Play (Second Edition). Также вы можете поинтересоваться текущим изданием этого руководства. Если разработчик давно не обновлял свои знания, значит, он не в курсе, что уже существует второе издание.
Традиционно всю работу выполняет кто-то один: один фрилансер или одна компания. Если есть возможности (для этого необходимо иметь опыт и сотрудника), то можно разделить работу между несколькими разработчиками. Например, ваш дизайнер создает дизайн, а остальную работу выполняют в сторонней компании, либо часть работы делает фрилансер, а все самое важное — компания. Это позволяет сэкономить на затратах, но одновременно создает дополнительные трудности в процессе разработки из-за необходимости согласования работы разных специалистов. Так стоит поступать только тем, кто действительно знает, что он делает и уже делал подобное в ИТ-сфере.
И последнее. Если вас что-то смущает или вы не уверены в выбранном разработчике, обязательно поговорите с ним об этом. Обговорите все, что вам не понравилось или показалось странным. Если ответы разработчики вас удовлетворят, начинайте с ним работать. Если он начнет вести себя неадекватно, говорить и обещать золотые горы либо вы не устраните свои подозрения, лучше сразу распрощайтесь и найдите другого. Если начнете работать с компанией, которая вызывает у вас сомнения, то со временем они, скорее всего, увеличатся. В результате, были сомнения оправданны или нет, вы будете недовольны выполненной работой. Поэтому следуйте золотому правилу: если что-то не нравится, откровенно обсуждайте или ищите другого разработчика.
Если вы так и не смогли найти компанию разработчика, напишите мне на [email protected] с описанием вашей задачи, и я порекомендую вам специалистов.
Убедитесь, что вы очень четко определили роли и обязанности. Платите за результаты, а не за часы работы. Регулярно сверяйтесь с командой и, если вы чувствуете, что ничего не получится, сразу прекращайте отношения.
Саймон Касуто, eLearning Mind
Всех, кто связан с компьютерами, принято считать не от мира сего. Когда-то давно именно так и было. Тогда программированием занимались только личности с определенным складом ума, это были ученые и первопроходцы, с которыми сложно общаться и договариваться. Сегодня ситуация кардинально изменилась, появились разработчики, умеющие вести переговоры и договариваться на выгодных для себя условиях. А еще эти самые разработчики очень редко общаются напрямую с заказчиком. Они выполняют свою работу. С заказчиком теперь говорят те, кто должен, — менеджеры по работе с клиентами, а с ними договариваться очень легко.
Не стоит думать, что у хорошего разработчика обязательно должен быть хороший менеджер по работе с клиентами. Многие компании специально ищут отличных продажников, способных продать кому угодно и что угодно. Их цель одна — получить как можно больше заказов, и среди заказчиков обязательно найдется тот, кого можно будет с легкостью облапошить. Задержитесь у менеджера по работе с клиентами, общайтесь с ним как можно больше и чаще. При всем своем умении манипулировать, они часто выбалтывают лишнее, потому что слишком любят болтать. Главное, начать беседу с ними так, чтобы их разговорить, а затем просто внимательно слушать и слышать сказанное между строк. Если сомневаетесь в искренности менеджера по работе с клиентами, постарайтесь понять — только он один такой неискренний или вся команда в целом?
Не стоит относиться к переговорам о разработке мобильного приложения как к чему-то обыденному, если с первой минуты знакомства все идет хорошо. Ваш прошлый опыт заказа услуг в других сферах в мире информационных технологий может сыграть с вами злую шутку: вы рискуете упустить важные детали, которые имеют значение только в процессе заказа разработки программных продуктов.
Часть заказчиков неосознанно относятся к заказу мобильного приложения как к покупке дорогостоящего товара в магазине, полагая, что это одно и то же. При покупке товара вы приобретаете готовый продукт, который уже полностью укомплектован, и не можете вносить в него изменения. Вы можете купить один и тот же товар в разных магазинах по разной цене, поэтому можно и поторговаться. До вас было множество других покупателей, способных дать объективные советы, какой товар вам лучше выбрать, поэтому вы можете прислушиваться к советам других людей.
Другие заказчики полагают, что заказ разработки мобильного приложения — то же самое, что и заказ услуги типа ремонта автомобиля. Можно сэкономить на запчастях и взять неоригинальные или обсудить все с самым лучшим разработчиком, а затем пойти и заказать точно такое же приложение у того, кто сделает дешевле.
Третьи, самые продвинутые, заказчики уверены, что создание мобильного приложения ничем не отличается от заказа на создание партии болтов и гаек нестандартного размера. Всего-то и нужно, что написать техническое задание, прикрепить к нему чертежи, а затем подписать договор.
Все это не подходит при заказе разработки мобильного приложения, потому что вы заказываете его производство и вольны выбирать, какие функции в него добавить. Такого же приложения, как у вас, ни у кого другого не было и не будет. Вы заказываете разработку уникального продукта. Ваше приложение всегда будет отличаться от других, поэтому чужой опыт мало чем поможет. Цена формируется иначе, и вы не сможете получить точно такое же приложение у другого разработчика, потому что каждый разработчик делает все по-своему. Если хотите получить хорошее мобильное приложение, то должны отложить в сторону все предыдущие знания и начать учиться практически с чистого листа.
Не слушайте советов от людей из своего ближнего окружения, которые якобы разбираются в мобильных приложениях. Один заказчик рассказывал забавную историю о «специалисте», не создавшем ни одного приложения, не разбирающемся ни в дизайне, ни в программировании и вообще далекого от информационных технологий, который был уверен в своей компетентности, потому что он давно пользуется смартфонами и видел много мобильных приложений. Как ни странно, многие заказчики больше прислушиваются к таким вот знакомым «специалистам», а не к реально разбирающимся в своем деле разработчикам. Результаты всегда плачевны.
Есть определенные правила, влияющие на успех или неудачу мобильного приложения. Есть необходимый минимум функций, который обязательно должен присутствовать в каждом приложении. А есть вещи, которые работают в обычном мире, но вредны для мобильных приложений. Задумайтесь хотя бы над одним вопросом: сколько специалистов принимают участие в разработке приложения? Сегодня для разработки полноценного мобильного приложения недостаточно нанять одного-двух программистов: их приложение окажется неконкурентоспособным и ничем не будет отличаться от тысяч других приложений, созданных энтузиастами. Вам необходимо или прислушиваться к тому, что вам советуют профессиональные разработчики, или самостоятельно изучать разработку мобильных приложений.
Итак, вы заказываете разработку нового приложения, а в этом деле подход «пришел, увидел и купил» не работает. Вам придется вести переговоры с разработчиками, а переговоры предусматривают добровольное участие в них двух и более сторон. Вы должны обсудить все нюансы и договориться на взаимовыгодных условиях, которые можно менять под ваши требования и учитывая обстоятельства, поэтому так важно, чтобы разработчики были заинтересованы в разработке вашего приложения.
Чтобы заинтересовать своим заказом хорошего мобильного разработчика, для начала вы должны знать, чего на самом деле хотите. Чем яснее вы представляете себе бизнес-цели, которые поможет достичь приложение, тем лучше. Если вы не можете сформулировать, что хотите получить от приложения, то разработчики вам в этом вряд ли помогут. Для лучшего понимания разработчиком своих задач, предоставьте ему необходимые материалы: описание идеи, наброски дизайна, текста, понравившиеся приложения, приложения конкурентов, информацию о вашем бизнесе и все, что поможет специалистам быстрее понять, чего вы хотите и как это лучше реализовать. Приходя с пустыми руками, вы обрекаете себя и разработчиков на долгие, утомительные, часто безрезультатные разговоры. Когда разработчик поймет, что вы хотите, он поймет свою выгоду, как он сможет выполнить поставленную задачу и будет готов приступить к работе. Не удивляйтесь, если разработчик захочет узнать все о вашем бизнесе и ваших клиентах. Чем откровеннее будет ваше общение, чем теснее будет ваше сотрудничество, тем лучших результатов вы добьетесь. Заинтересовав разработчика своей идеей, вы тем самым гарантируете себе, что он реализует ее качественно, быстро и даст вам много дельных советов.
Хорошие разработчики всегда загружены работой, она сама их находит. Они стараются не сотрудничать с заказчиками, которые им не нравятся и могут оказаться проблемными в общении, постановке задач или финансовом плане. Это другой мир, с другими правилами, где разработчик также выбирает заказчика, как и заказчик разработчика. Поэтому следите за тем, что говорите, как выполняете и выполняете ли вы свои обещания еще на стадии переговоров. Плохие разработчики берут всех клиентов, даже не задумываясь, потому что им всегда не хватает заказов, а также потому, что им плевать на то, выполнят ли они обещанное. Хорошие разработчики обычно не берутся за выполнение заведомо провальных заданий. Им это неинтересно. Кроме денег, им важно, чтобы их приложение было успешным и популярным. Хорошее приложение формирует хорошее портфолио, что приводит хороших клиентов, о чем всегда помнит хороший разработчик.
Некоторые разработчики выполняют только то, что оговорено, ничего более. Они могут делать хорошие приложения, но только в рамках ваших требований. Например, если заказчик скажет, что хочет видеть в приложении красный круг на белом фоне, они сделают красный круг на белом фоне и больше ничего. Они не спросят: «А зачем вам один красный круг?» Они не посоветуют: «Сделайте лучше три круга». Они не скажут, что красный круг в приложении сам по себе вообще никому не нужен. Они просто сделают то, что вы требуете, не задавая лишних вопросов, даже если это совершенно бесполезное приложение, на которое вы можете потратить десятизначную сумму и несколько лет. Они это могут сделать очень качественно, красиво, с использованием последних технологий. К тому же будут гордиться своей работой, считая, что если все сделано согласно техническому заданию, значит, все сделано идеально. С такими разработчиками сложно работать. Их заказчики — это люди, которые могут правильно составить техническое задание самостоятельно, поэтому скорее всего такие разработчики вам не подходят. Вам нужно, чтобы вас качественно проконсультировали по всем вопросам, касающимся создания приложения.
Хорошие советы получает тот, кто задает хорошие вопросы. Задавайте как можно больше вопросов, ведь чем больше вы спросите, тем быстрее и точнее сможете определиться с тем, что вам нужно и как это лучше всего сделать. Это чем-то похоже на покупку лекарств в аптеке. Вы говорите, что вас беспокоит боль в горле, и продавец сразу предлагает самое дорогое лекарство. Затем вы спрашиваете что-нибудь дешевле, и он тут же предлагает вам недорогое лекарство с тем же самым действующим веществом и побочными действиями. Но пока вы не спросите, он не предложит. А если еще поинтересуетесь, какой производитель или действующее вещество лучше, от какого меньше побочных эффектов, то сможете выбрать еще более действенное лекарство за те же самые деньги.
При покупке товара вы показываете, какой товар вам нужен, и продавец вам его продает. При заказе разработки приложения вам нечего показать, вы должны договариваться обо всем, чтобы получить именно то, чего ожидаете. Требуйте конкретики. Приходите с четкой задачей и договаривайтесь на определенных условиях. Для этого вы должны точно знать, сколько можете заплатить за разработку приложения. Сообщите ему свой бюджет, чтобы он предложил вам лучшее решение, учитывая ваши финансовые возможности. Узнав размер бюджета, разработчик сможет просчитать, сколько времени понадобится на разработку вашего приложения и на основе каких технологий оно будет создано.
Уважайте разработчика, забудьте про «Может быть, я закажу у вас приложение. Вы пока уделите мне 10 дней рабочего времени, а я подумаю». С таким подходом нормальные разработчики не захотят тратить на вас даже 15 минут. Даете конкретное задание и заставляете разработчиков назвать вам приблизительные сроки и цену. Если разработчик говорит: «Возможно, тут мы сделаем как-то иначе», значит, он пока не знает, как и что будет делать, и это нормально. Вероятно, ему нужно больше времени для прояснения ситуации. А может быть, он вас не понял. В любом случае перед подписанием договора устраните все недоразумения.
Торгуйтесь с разработчиками очень аккуратно. Когда вы покупаете конкретный товар, то можете торговаться, но когда вы заказываете изготовление этого товара, то можете наступить на классические грабли. Максимум, что вы можете сделать, — снизить цену за счет снижения качества или уменьшения количества функций приложения. Если вы начнете активно сбивать цену, то хорошие разработчики скажут, что заняты работой на ближайшие 10 лет и никак не могут взяться за разработку вашего мобильного приложения. Это явно не относится к завышающим в 10 раз цену разработчикам, но с ними не нужно торговаться, от них нужно сразу бежать.
Обязательно узнайте о загруженности потенциального исполнителя. У хорошего разработчика обычно много проектов, он честно об этом скажет и укажет приблизительную дату, когда сможет начать делать ваше приложение. У плохого разработчика всегда неограниченное количество свободного времени и нереально короткие сроки выполнения работы.
На этапе переговоров о начале работы над мобильным приложением сроки и цены можно назвать только приблизительные. Вы можете и должны узнать эти сроки, цены, условия. Более конкретные ответы на такие вопросы получить вы не сможете, потому что разработчик пока сам не знает, что он должен для вас сделать. Чтобы разработчик назвал конкретную цену, ему нужно обговорить с вами детали работы, составить договор, который включает техническое задание, а затем спроектировать ваше приложение.
Всегда помните, кто самый главный в разработке мобильного приложения. Это не вы. И не разработчик. Это будущий пользователь приложения. Приложение создается для пользователей. Не для вас или разработчика. Вас обоих интересует только прибыль, а пользователя — возможности, которые он получит, заплатив за приложение. Ваша цель при создании мобильного приложения состоит в том, чтобы максимально удовлетворить пользователя, а не свое эго или пожелания разработчика. Кто платит за пользование приложением — тот и главный.
Если вы думаете, что придете один раз, все обсудите и разработчики сделают вам приложение, то вы ошибаетесь. Переговоры заканчиваются только тогда, когда вы заканчиваете свои отношения с конкретным разработчиком. Приложение не делается за один день, не делается даже за одну неделю. Вы постоянно будете что-то обсуждать с разработчиком: сначала создание приложения, потом раскрутку, потом совершенствование.
При разработке любой программы всегда возникают сложности, которые можно либо решить переговорами, либо перейти на личности и оскорбления, потеряв время и деньги. Регулярно общайтесь, интересуйтесь, что уже сделано. С одной стороны, это не даст разработчикам забыть о вас и отложить ваше приложение в сторону, с другой — даст вам более глубокое понимание приложения и той работы, которую выполняют разработчики. Если установите с ними доверительные отношения, то сможете взаимовыгодно обсуждать любые вопросы и останетесь довольны сотрудничеством.
Не оскорбляйте разработчика и не учите его работать. У разработчиков невероятные возможности по созданию проблем для заказчика, выявить которые мало кто сможет, а доказать вообще нереально. Предотвратить их можно только нормальным уважительным общением. Если вам что-то не понравилось, то спросите, почему это сделано так, а не иначе. Возможно, вы неправы, а специалист как раз сделал все, как нужно. Возможно, разработчик чего-то недосмотрел. Откровенное обсуждение поможет все выяснить.
Интеллектуальная собственность подвергается атакам с совершенно неожиданных сторон. Кто мог представить, что бабушки Среднего Запада будут по интернету обмениваться пиратскими копиями инструкций для вязания?
Линус Торвальдс, главный архитектор Linus
В материальном мире, мире вещей, нас с детства обучают правилам поведения и законам, которые нужно соблюдать. Мы быстро узнаем, что, взяв конфету с прилавка и не оплатив ее, можно получить хорошего тумака. Мы вырастаем и прекрасно помним, что нельзя брать чужие вещи. Обычно у них есть владелец, которого очень просто идентифицировать. Если какая-то полезная вещь валяется на дороге, она быстро находит нового владельца. Каждый знает, что значит «чужая собственность», многие ее даже уважают, сообщая о найденных вещах владельцам или давая объявления о находке.
В мире интеллектуальной собственности, особенно в информационных технологиях, дела обстоят несколько иначе. Чужой интеллектуальный труд буквально лежит у нас под ногами. Например, идя по улице, вы видите результаты такого труда в виде дизайна, текста, звука, разговоров других людей. Мало кто задумывается, что результат интеллектуальной деятельности принадлежит тому, кто его создал.
Как показывает мой опыт, большинство людей туманно представляют себе, что интеллектуальная собственность принадлежит кому-то конкретному и ее нельзя использовать без его спроса. Нас этому не обучали в детстве и даже сегодня, с развитием информационных технологий, не обучают.
В школе мы узнаем, что списывать у одноклассников плохо, потому что за это можно получить плохую оценку. В вузе от нас требуют не просто переписывать прочитанное, а писать своими словами; использование рефератов, курсовых и дипломных работ, скачанных из интернета, грозит серьезными проблемами вплоть до отчисления. Будучи студентами, мы думаем, что нам не дают списывать и использовать чужие материалы только потому, что все учителя и преподаватели вредные. Есть и другие люди, думающие, что они так поступают потому, что хотят, чтобы мы научились чему-то сами, а для этого необходимо самостоятельно написать текст, а не использовать чужой.
К сожалению, нам не объясняют, что, переписывая чужой текст, мы тем самым нарушаем права интеллектуальной собственности. Любой текст, картинка и даже произнесенная речь принадлежат тому, кто их создал, и только он вправе распоряжаться им по желанию. Никто не может выдавать чужой интеллектуальный труд за свой, как ему вздумается, без разрешения автора, например использовать чужие фотографии в своем мобильном приложении, — это воровство.
Но как понять, кому принадлежит результат интеллектуальной деятельности? Вдруг он «бесхозный», и я могу его использовать, как мне захочется? Подобным образом думают многие пользователи интернета, где любой бесплатно может получить чужую интеллектуальную собственность — вот сайт с фильмами, вот с книгами, а здесь можно бесплатно скачать платное приложение. Все мы настолько к этому привыкли, что считаем естественным. Но это далеко не так.
Некоторый контент распространяется с лицензией, то есть с указанными правилами его получения и использования, а другой можно найти в интернете без лицензий. Это вовсе не значит, что вы вольны делать что угодно с контентом без лицензии. Любой контент кому-то принадлежит, и только владелец вправе им распоряжаться. Если вы видите название лицензии, значит, автор решил распоряжаться своим контентом по определенным правилам. Если лицензии нет, значит, он не уведомил общественность о том, как может распространяться данный контент, и если вы хотите его распространять, то вначале должны спросить разрешения.
Некоторые разработчики также считают естественным использовать чужую интеллектуальную собственность, не уведомляя об этом ни владельца, ни заказчика мобильного приложения. Они также ничего не знают о законах в сфере авторского права и интеллектуальной собственности. Их этому не обучили в детстве, а во взрослой жизни они видели только множество примеров того, как их друзья и партнеры по бизнесу без каких-либо проблем использовали чужой интеллектуальный труд, не платя за него ни копейки.
Вы должны быть точно уверены, что разработчик использует легально приобретенный контент или контент, созданный им собственноручно. Советую добавить в договор отдельный пункт об этом, а также о том, что всю ответственность за использование чужого контента при разработке приложения несет только разработчик. Это необходимо сделать, чтобы разработчик понимал, что вы знаете, что такое авторское право и смежные права, и не хотите в своем приложении использовать краденый контент.
Если при создании приложения используются материалы, принадлежащие кому-то иному, например иконки или программный код, то требуйте доказательств их приобретения в виде документа. Еще недавно использование краденого контента не влекло за собой крупных проблем, но ситуация меняется. Например, появился Роскомнадзор, заботящийся о соблюдении прав интеллектуальной собственности в интернете. Количество судебных дел о нелицензионном программном обеспечении выросло в разы. Попытки отсудить у кого-то крупную сумму за использование такого же дизайна, логотипа и названия теперь не редкость.
Вы можете выбрать название для приложения, под которым уже зарегистрированы товарные знаки. Возможно, есть патенты на технологии, которые вы захотите использовать в своем приложении. Возможно, вам придется зарегистрировать собственные технологии и заключать соглашение с каждым пользователем приложения. Ну и, естественно, вам нужно составить грамотный договор, защищающий ваши интересы при разработке мобильного приложения. Кстати, разработчики не всегда знают, что им можно делать с юридической точки зрения, а что нет, и как это должно быть сделано с выгодой для вас. И не забудьте зарегистрировать свой товарный знак в тех странах, где собираетесь использовать свое приложение. Если не зарегистрируете его официально, то это может сделать кто-то другой либо кто-то начнет использовать ваш товарный знак в своих бизнес-целях.
Если ваше приложение будет успешным, сразу найдется много желающих заработать на нем. Часть из них скопируют вашу идею, другие — отдельные функции или используют название и логотип, делая вид, что их приложение имеет прямое отношение к вашему. Найдутся и те, кто скопирует все без исключения: и название, и логотип, но сделает все худшего качества. Единственный способ найти выход из всех этих сложных юридических вопросов — найти хорошего юриста или обратиться к таким сервисам, как onlinepatent.ru (предварительно подав заявку онлайн), которые помогут защитить ваши права.
Юристы — единственная категория людей, которым незнание законов ничем не грозит.
Иеремия Бентам , философ-моралист и правовед
Хорошего юриста, как и хорошего врача, сложно найти, а стóят такие специалисты недешево. Но они помогают нам в тех сферах, в которых бы мы сами никогда не разобрались. И хотя юристы в отличие от врачей редко спасают жизни, зато они способны сохранить и даже приумножить наши деньги, а также избавить нас от множества проблем. Поэтому чем раньше вы обратитесь к юристу при разработке мобильного приложения, тем лучше.
Существует множество разных законов, как отечественных, так и международных, которых желательно придерживаться в отношениях с будущими пользователями мобильного приложения. Хороший юрист способен объяснить, как лучше всего оформить отношения не только с разработчиками мобильного приложения, но и с будущими пользователями.
Юристы бывают разные: у них, как и у врачей, есть специализация. Например, одни лучше разбираются в недвижимости, другие — в криминальных делах, третьи — в хозяйственных. Вам нужен юрист, отлично разбирающийся в информационных технологиях и авторском праве. Обратиться не к тому юристу — то же самое, что обратиться к проктологу вместо стоматолога.
Юриспруденция в отличие от математики не является точной наукой, хоть таковой и должна была бы быть. Законы часто трактуются по-разному и противоречат друг другу. Данную главу не стоит воспринимать буквально, Она написана для того, чтобы вы поняли важность правильно оформленных юридических отношений — будь то с пользователем приложения или с поставщиком контента. Прежде чем заключить договор с разработчиками, я настоятельно рекомендую получить консультацию у хорошего юриста, разбирающегося в специфике информационных технологий. Как автор этой книги я не несу никакой ответственности за результаты применения вами любым моих рекомендаций.
Умные люди, давно сидящие в интернете, сразу могут сказать, что юрист не нужен, ведь можно почитать сайты, затем найти похожий договор либо пользовательское соглашение и приспособить под свои нужды. Не советую так делать. К примеру, в интернете можно найти неплохой договор, созданный совместными усилиями пользователей социальной сети Хабрахабр. Вам будет очень полезно ознакомиться с текстом этого договора, а также материалами и комментариями к нему, чтобы понять, о чем вообще идет речь, как он может выглядеть и какие пункты соглашения вы можете добавить в свой договор. Но это не отменяет необходимости общения с юристом. Любой договор, как и любая сделка, важен своими деталями. Специалист по праву интеллектуальной собственности убережет вас от ошибок.
Для того чтобы правильно прочитать договор, всего-то и нужны: здравый смысл, логика и немного терпения. Здравый смысл поможет отнестись к тексту критически: если вы три раза прочитали договор и вам все понятно, но в пункте 13.13 вас явно обманывают — скорее всего, вас действительно обманывают.
Владимир Беляев, координатор «Центра управления законом»
Если вы думаете, что оплата разработки мобильного приложения автоматически делает его вашим, вы ошибаетесь. Также ошибаетесь, если думаете, что станете автором мобильного приложения, созданного кем-то другим. Я видел договоры, в которых было написано о передаче авторских прав, об их уступке и даже об отказе в чью-то пользу. Вот только по закону авторское право от человека к человеку не передается. Оно вообще не передается, поскольку является личным неимущественным правом, и передать его другому человеку невозможно ни по закону, ни по здравому смыслу. Тот, кто создал приложение, всегда будет его автором.
Презумпция авторства означает, что автором считается тот, кто первым заявил о своем авторстве, до тех пор, пока юридически не будет доказано обратное. Единственно верный способ сделать так, чтобы разработчик мобильного приложения или его частей, то есть автор или авторы, не могли распоряжаться результатами своего труда, — правильно оформить юридические отношения с ними. Заключите договор, в котором будет предусмотрено, что права использование мобильного приложения, созданного разработчиком, принадлежат только вам.
Неверно написанный договор, например, прямо противоречащий действующему законодательству, может быть признан в суде недействительным со всеми вытекающими последствиями. То есть заключая такие договора, вы платите свои деньги и отдаете свои идеи на создание приложение, рискуя все потерять.
Работать без договора, только на основе устных договоренностей, крайне не рекомендуется. Договор не столько инструмент устрашения, сколько помощник в устранении недоразумений. В нем перечислены права и обязанности обеих сторон, что делает работу над приложением более эффективной. Договор способствует выполнению обязательств не только разработчиком, но и заказчиком.
Знаете, чем грешат абсолютно все разработчики мобильных приложений? Срывом сроков. Это обыденное явление в ИТ, и не стоит его бояться. Откровенно говоря, никто не может вам выдать 100%-ную гарантию соблюдения сроков и качества работ, потому что это физически невозможно. При создании мобильного приложения, как бы детально ни было описано техническое задание, всегда возникает множество проблем, которые разработчик просто не в состоянии предвидеть. И только регулярное и тесное общение с разработчиком поможет вам понять, на какой стадии разработки находится ваше приложение.
Если нет договора, сроки будут сорваны на неопределенное время и никто не понесет за это никакой ответственности. В договоре вы можете указать, при каких обстоятельствах разработчик несет ответственность за срыв сроков работы и какую именно (доработка за своей счет, компенсация).
Если выбранные вами разработчики работают не первый год, у них уже есть стандартный договор. Советую как можно быстрее попросить у них его копию, чтобы отдать юристу на ознакомление. Если стандартного договора по какой-то причине нет, значит, разработчик готов оговаривать условия сделки на взаимовыгодных условиях. Можете предложить ему свой договор.
При ознакомлении с договором всегда помните, что вы не обязаны подписываться под каждым пунктом, предложенным разработчиком. Почти о любом пункте можно договориться, изменив так, чтобы всем было выгодно и удобно. Например, можно изменить формулировку конкретного пункта договора. Единственный пункт, который останется неизменным, — это пункт о необходимости своевременной оплаты разработчику, но даже по этому вопросу можно вести переговоры.
Не стоит слепо полагаться на чутье и опыт юриста. Договор подписываете вы, значит, вы несете ответственность за подписанное. Внимательно читайте каждый пункт, и, если чего-то не понимаете или в чем-то сомневаетесь, обязательно обсудите это со своим юристом и разработчиками. Каждая ваша устная договоренность должна быть четко и понятно сформулирована в договоре. Абсолютно каждая, без исключения. Поэтому к договору часто добавляют приложения, например бриф, техническое задание и подобные дополнения.
Основываясь на своем многолетнем опыте разработки мобильных приложений, наиболее важными пунктами в договоре на создание мобильного приложения я считаю следующие:
1. Передача исключительных прав.
Все права на использование, распространение, модификацию, копирование и любые другие действия должны переходить к заказчику. Особенно это касается исходных программных кодов на само приложение, а также исходных файлов для работы с изображениями, звуками и всем остальным. Получив «исходники», вы получаете возможность в дальнейшем с легкостью модифицировать любую часть приложения на свое усмотрение.
Бывали случаи, когда разработчики передавали все права только на часть интеллектуальной собственности, например только на дизайн. Тогда за разработчиками оставалось законное право продать исходные коды мобильного приложения кому-то иному, без дизайна или создав новый дизайн. Проследите за тем, что вам передали все права, а не часть.
Так как автором все равно остается разработчик, вы должны добавить пункт о праве использования приложения без указания имени автора.
Если вы поменяете разработчика, ни в коем случае не передавайте ему права на использование вашего исходного кода, контента либо приложения. Задача нового разработчика не использовать то, что вам принадлежит, а доделать либо улучшить то, что вы уже имеете.
С точки зрения производства мобильное приложение защищено от копирования намного лучше, чем обыкновенный товар, устройство или услуга. Его код можно надежно зашифровать, так что никто не сможет его разобрать на части и использовать эти самые части для производства своего собственного приложения. Однако если кто-то получит доступ к исходному коду приложения, то сможет создать даже не копию вашего приложения, а точно такое же приложение, как у вас. Или, например, если кто-то получит доступ к отдельным частям исходного кода, то сможет реализовать часть функционала вашего мобильного приложения.
2. Предусматривание ответственности за использование чужих материалов.
Ответственность за использование чужих материалов полностью лежит на разработчике. В противном случае он может незаконно использовать чужой код или другие материалы, а ответственность за это понесете вы.
3. Техническое задание.
Техническое задание должно идти в виде приложения к договору и быть описанным в договоре как часть условий соглашения. В техническом задании, о котором подробнее будет написано далее, вы можете перечислить детальные требования к каждой части мобильного приложения. Таким образом, техническое задание становится частью договора и условием, от которого нельзя отказаться.
4. Условия приема-передачи дизайна.
Дизайн мобильного приложения подписывается отдельным актом приема-передачи и оговаривается в отдельной секции технического задания. Это необходимо, потому что дизайн всегда требуется дорабатывать.
5. Перечень этапов разработки мобильного приложения.
Поскольку разработка мобильного приложения может быть довольно длительным проектом, советую в договоре описать этапы работы и сроки выполнения каждого этапа. Это позволит более эффективно придерживаться сроков выполнения договора.
6. Соглашение о неконкуренции.
Соглашение о неконкуренции должно идти в договоре отдельным пунктом. Например, вы можете указать, что разработчик не может использовать идеи и технологии из вашего мобильного приложения в других приложениях.
Вы не можете заставить разработчика не использовать ваши идеи, но можете дополнительно прописать запрет на использование созданного кода для вашего мобильного приложения в других проектах. По закону разработчик и так не имеет права этого делать, но многие из разработчиков об этом даже не догадываются. Отдельный пункт в договоре напомнит им о том, как это важно.
7. Условия нераспространения информации.
Обязательно оговорите условия нераспространения информации о вашем приложении. Обычно оно называется Non-Disclosure Agreement, что переводится как «договор о конфиденциальности», или «договор о неразглашении информации», в числе которых персональные данные, коммерческая тайна, условия сотрудничества и т.д. Такое соглашение гарантирует, что разработчик не будет рассказывать о своей работе, а также делиться вашими секретами и технологиями со всеми подряд. Важно также, что этот пункт действует и после завершения договора, то есть бессрочно.
8. Результат сотрудничества.
В договоре должна быть указана конкретная сумма и конкретный результат труда, который вы получите за эти деньги. Иначе вы рискуете попасть в постоянное «Доплатите, пожалуйста, и мы все доделаем». Если же исполнитель ошибся суммой, а такое также случается, то всегда можно внести изменения в договор на взаимовыгодных условиях.
Часто заключают договор с использованием почасовой оплаты. В таком случае убедитесь, что есть отдельный пункт, обеспечивающий прозрачный контроль за затраченным разработчиком временем при создании приложения. К примеру, контроль можно осуществлять через сторонний сервис, постоянно следящий за тем, что делает разработчик за своим компьютером, или же видео выполнения работы.
9. Условия оплаты.
Предоплата в разработке программных продуктов — дело естественное, и этого не нужно бояться. На самых ранних этапах разработчики выполняют множество задач, которые остаются за кадром. Об этой работе вы обычно даже не подозреваете, но и она должна быть оплачена. Предоплата позволяет исполнителям качественно работать с самого начала.
Если рассчитываетесь по безналичному расчету, то обычно с подтверждением оплаты проблем не возникает. Если платите наличными, советую получить от разработчика документ, подтверждающий факт оплаты. Документ требуйте в момент оплаты, а не когда-нибудь «завтра». Также на документе должны стоять печать и подпись от компании разработчика.
10. Акт выполненных работ.
Для каждого разработчика наличие акта выполненных работ очень важно. Это документ необходим при налоговых проверках в качестве подтверждения, что все работы по контракту были выполнены и договор считается закрытым. Ни в коем разе не подписывайте акт выполненных работ до того, как все работы будут выполнены, но и не вздумайте шантажировать им разработчика, чтобы он делал то, о чем вы не договаривались. Вам еще наверняка пригодятся его услуги, не нужно портить отношения.
Чем точнее в документе учтена специфика сервиса, тем меньше вероятность того, что у вас не найдется адекватного решения при возникновении конфликтной ситуации.
Павел Мищенко, юрист
Одного договора с разработчиком недостаточно. Вам также понадобится заключить письменные договоренности с каждым пользователем мобильного приложения. К счастью, для этого вам не нужно заключать отдельные договоры с каждым из них на бумаге. Вы заключите договоры в электронной форме. Для этого вам необходимо разместить текст договоров в самом мобильном приложении, дать возможность прочитать его каждому пользователю и выполнить действие, подтверждающее согласие с принятием условий договора.
Самые важные договоренности желательно показывать пользователю либо при регистрации учетной записи для пользования приложением, либо сразу после первого запуска. Некоторые используют сообщение о том, что при дальнейшем использовании приложения, пользователь автоматически соглашается с договором. Часто приложением невозможно пользоваться, пока пользователь не сделает пометку о том, что согласен с условиями соглашения, и это правильно.
Пользовательское соглашение, или, как его еще называют, лицензионное соглашение с конечным пользователем (end-user license agreement (EULA)), — это договор, регулирующий отношения между вами, правообладателем приложения и пользователем приложения. Он касается только условий использования мобильного приложения. Похожие соглашения есть практически в любом онлайн-сервисе и приложении для обычного компьютера. В народе их еще называют «лицензией». Имейте в виду, что из-за неверно написанного соглашения вам могут отказать в публикации приложения в магазине приложений.
Одним из самых важных пунктов лицензионного соглашения является отказ от ответственности (Disclaimer). В информационных технологиях его обычно добавляют в любое приложение и сервис, чтобы тем самым обезопасить себя от любых негативных последствий, возникших у пользователя при использовании программы. Это делается для предотвращения проблем у владельца приложения. Те, кто наперед продумывают все юридические последствия, абсолютно правы.
Почитайте соглашения, подписываемые крупными компаниями с пользователями их мобильных приложений. Компании нередко виноваты в ненадлежащей работе своих программ, но вообще не несут никакой ответственности перед пользователями. Берите с них пример, иначе пользователи начнут винить вас не только в каждой вашей ошибке, но и в своих собственных.
Менее важные договоренности, чем пользовательское соглашение, обычно становятся видимыми только после перехода по ссылке или нажатия на кнопку и содержат пункт о том, что если кто-то пользуется мобильным приложением, то автоматически соглашается с данными договорами. К таким договорам относятся публичная оферта и сообщение о конфиденциальности.
Оферта регулирует ваши отношения с пользователем по части оказания услуг и поставки товара, то есть условия купли-продажи. Информация о конфиденциальности описывает, какие данные собираются и как они будут использоваться. Так, например, если приложение собирает личные данные (имейл, имя, телефон и др.), то, скорее всего, вы должны будете уведомить об этом Роскомнадзор, в противном случае рискуете быть оштрафованными. Довольно часто, мобильные приложения отсылают собираемую информацию третьим сторонам, о чем можно найти отдельный пункт либо в лицензионном соглашении, либо в соглашении о конфиденциальности.
Техническое задание должно обеспечить полное понимание системы для любого человека, прочитавшего этот документ.
Вайсфельд Мэтт, автор книги «Объектно-ориентированное мышление»
Техническое задание пришло к нам из производства. Когда требуется создать какую-то деталь или устройство, то еще до его создания необходимо иметь ясное представление о том, как должен выглядеть результат работы, какие функции будет выполнять устройство, из каких материалов состоять и т.д. Производство немыслимо без технического задания (далее — ТЗ), так как значительно облегчает появление новых гаджетов, вещей и программ.
Никто не спорит, что при производстве вещей все нужно продумывать заранее, создавать чертежи и описывать результат. При производстве интеллектуального продукта, люди не до конца осознают, что его произвести еще сложнее, и все, что относится к производству материальному, также характерно и при производстве интеллектуальном. Также из-за безграмотности некоторых разработчиков появились идеи, что ТЗ не нужно или же это пустая трата денег и времени.
Часто заказчики сами создают ТЗ, не понимая, что у них для этого недостаточно опыта и знаний. Представьте, что вы составляете ТЗ не на разработку мобильного приложения, а на смартфон. Что вы можете в нем прописать, не будучи специалистом? Только то, что знаете как пользователь. Что знает пользователь? Только то, что может пощупать и опробовать лично, часто даже не подозревая, что другие люди могут пользоваться той же моделью смартфона иначе и для других целей. Я уже не говорю о нехватке специальных знаний в дизайне интерфейса и программировании.
Для разработки ТЗ заказчик может или самостоятельно изучить специфические вопросы, касающиеся разработки приложения, или воспользоваться помощью специалистов. Идеально, если ТЗ разрабатывается теми, кто на его основе будет создавать мобильное приложение. Обратившись к сторонней компании только за созданием ТЗ, вы вполне можете получить раздутый проект как по финансовой, так и по материальной части, не гарантирующий успеха. Составителю выгодно написать в ТЗ как можно больше ненужного и потратить на его создание как можно больше времени, потому что от этого зависит размер его дохода. Самостоятельно разработчик также не может создать ТЗ, даже имея на руках бриф или пожелания заказчика. Поэтому ТЗ всегда создается обеими сторонами, но главным остается разработчик. Именно он направляет заказчика, задает ему правильные вопросы для получения правильных ответов.
Есть заказчики, требующие создать вначале договор с прикрепленным к нему ТЗ, а затем говорящими: «Только тогда мы подумаем над тем, заказывать ли у вас». Дескать, иначе они не смогут понять уровень профессионализма разработчика или сразу хотят увидеть, что он способен предложить. Частично это правда, и по ТЗ действительно можно судить о разработчике, но ТЗ не создается на коленке за несколько часов. Это сложная работа, требующая участия многих специалистов и отнимающая много времени. Разработка ТЗ должна оплачиваться, иначе оно не будет качественным. При заказе и составления ТЗ, и разработки мобильного приложения стоимость составления ТЗ будет ниже, чем для тех, кто заказывает только одно ТЗ. Это связано с затратами времени специалистов: если они тратят его как на ТЗ, так и на производство приложения, то это окупается, в отличие от написания ТЗ без продолжения работы.
Государство позаботилось о правильности создания ТЗ, выпустив для этого соответствующие межгосударственные стандарты (ГОСТ, ОСТ). Вот только проблема в том, что они несколько устарели. Например, ГОСТ 34.602–89 «Техническое задание на создание автоматизированной системы» был выпущен еще в 1989 г. Не советую использовать ГОСТ как основу для создания качественного ТЗ, хотя вы можете почерпнуть там что-то полезное.
Как и договор, ТЗ в процессе работы над приложением может изменяться. Не стоит относиться к договоренностям так, будто они высечены на камне — эти времена давно прошли. Действуйте гибко. Если выгодно изменить договор, в том числе техническое задание, — меняйте. Жизнь часто вносит коррективы, и лучше вовремя приспосабливаться к происходящему.
Из-за отсутствия единых стандартов каждая компания делает ТЗ по-своему. С одной стороны, это дает невиданную гибкость, а с другой, ведет к полной неразберихе, и если заказчик захочет передать свой проект другому разработчику, то не исключено, что придется менять ТЗ. Ниже я расскажу только о самых важных частях технического задания.
1. Назначение, цели, задачи и результат.
Понятно и доступно опишите, зачем вам мобильное приложение и какие задачи оно должно решать. Обычно кратко описывают каждую большую задачу, а детализацию делают в описании подзадач.
2. Целевая аудитория.
Максимально подробно опишите будущих пользователей приложения. Многие создают собирательные образы наиболее распространенных типов пользователей, а некоторые даже описывают, как будет себя вести каждая из этих личностей, создавая так называемые user story, или истории пользователей.
3. Структура.
Описать структуру приложения, включающую все разделы, их названия, элементы каждого раздела и порядок их размещения. Необходимость каждого элемента и порядок его размещения должны быть обоснованы.
4. Макеты экранов (страниц).
В общем виде отображаются самые важные элементы каждого экрана, начиная с главного. Это можно сделать как на бумаге, так и в специализированном приложении или онлайн-сервисе.
5. Функционал.
Описать все функции: как они будут реализованы, как будут работать и зачем они нужны.
6. Дизайн.
Привести примеры понравившихся приложений, описать пожелания по оформлению.
Некоторые заказчики требуют описывать как можно больше деталей. Их можно понять, ведь они пытаются не только внести ясность, но и обезопасить себя от недобросовестных исполнителей. Однако разработчику чрезмерная детализация всегда добавляет проблем, потому что не все можно предсказать наперед и увидеть, как одно будет сочетаться с другим. Возможно, наоборот, не будет, поэтому иногда требуется создать прототип приложения. Конечно, это значительно усложняет разработку. Хорошие разработчики составляют ТЗ в меру детально, чтобы у них была возможность оперативно вносить изменения в конечный результат.
Войти с помощью соц. сетей: