Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Вопросы Проекты Вакансии
Студия мобильной и веб-разработки
Рекомендуем
Продвинуть свой проект
Лучшие проекты за неделю
29
Эбиа

Эбиа

www.ebia.ru

16
Enlite

Enlite

enlited.ru

16
Amarket

Amarket

amarket.io

15
likearea

likearea

smm.li

14
Relap

Relap

relap.io

12
RockinRobin

RockinRobin

www.rockinrobin.co

12
E-Commerce and Venture projects

E-Commerce and Venture projects

Продажа товаров от производителей оптом и в розницу

11
Perezvoni.com

Perezvoni.com

perezvoni.com

11
Cookiezz

Cookiezz

cookiezz.com.ua

Показать следующие
Рейтинг проектов
Подписывайтесь на Спарк в Facebook

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

3 411 0 В избранное Сохранено
Авторизуйтесь
Вход с паролем
b_53ecc3b7af4d4.jpg
Если вы хотя бы раз заказывали у подрядчиков выполнение любых работ по разработке, то знаете, что правильная постановка задач обеспечивает половину успеха в реализации вашей идеи. Мы решили на основе собственного опыта составить список рекомендаций для заказчиков — на тот случай, если у вас нет навыков составления ТЗ или оформления четких требования и спецификаций по разработке.

1. Определитесь с целевой аудиторией, платформой и форм-фактором устройств

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

Вторая распространенная ошибка — уверенность в том, что для планшета и для смартфона надо «одно приложение». Это не так: дизайн, юзабилити, техническая сторона реализации, «начинка» приложения — всё это разное в зависимости от выбранной мобильной ОС, форм-фактора и типа устройств. Дело даже не в диагонали и разрешении экрана: есть масса нюансов в сценариях использования и удобстве работы (это даже не касаясь нюансов написания кода и прототипирования / тестирования разных версий приложения для разных типов устройств). Кроме того, нельзя сделать «одну версию для всего»: у разных мобильных ОС разные требования к приложениям, чтобы они попали в магазины приложений после релиза и корректно работали на устройствах под управлением этой мобильной ОС.

2. Определите три ключевых задачи, которые должно решать ваше приложение

Варианты правильной постановки задачи для разработчика:
  • «наше приложение должно обеспечивать возможность оплаты за совершенный заказ в нашем интернет-магазине»
  • «мы хотим совершать загрузку отснятых спортивных видеороликов при помощи нашего приложения на сервис видеохостинга YouTube»
  • «наши читатели должны получать доступ к определенным новостям и новым статьям в зависимости от их текущего местоположения»

Варианты неправильной постановки задач:
  • «мы хотим сделать красивое приложение, чтобы пользователи могли общаться между собой» (Как общаться? В соцсетях? При помощи встроенного чата? Какие пользователи? Кто они? Чем их мотивирует ваше приложение в итоге? Вы сами себе не ответили на все эти вопросы — как разработчик может на них ответить?)
  • «мы видели отличное приложение у наших конкурентов, хотим себе такое же» (вы и вправду уверены, что команда одних разработчиков может «залезть в голову» к дизайнерам и девелоперам из другой команды, да еще и просто скопировать все один-в-один из приложения, исходный код которого никому не доступен?)
  • «мы не очень разбираемся, давайте вы сами ТЗ составите, а мы глянем и скажем, подходит ли нам» (если у вас нет четкого понимания, зачем вам мобильное приложение — то просто не делайте его).

3. Есть ли у вас стратегия интеграции мобильного приложения?

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

4. Составьте ТЗ (или хотя бы его подобие). Если у вас нет навыков составления ТЗ — запросите бриф у разработчиков

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

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

5. Избегайте микроменеджмента

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

6. Отвечайте на письма всегда и желательно — в течение 24 часов

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

7. Задавая вопрос «а почему так дорого?» без выполнения всех предыдущих советов из этого списка, вы портите и без того непростую ситуацию

Не бывает «дешевой разработки под ключ». Не бывает «быстро и недорого». Бывает откровенная халтура без тестирования, с обилием «мусорного» кода, с кодингом «на коленке» и криво прикрученным интерфейсом. Стоимость разработки — не прихоть разработчика или ценник «с потолка»: в нее заложены затраты на основные и дополнительные работы, на тестирование, на выплату зарплат и материально-техническое обеспечение рабочих мест самих программистов. Студия не «наживается», а делает продукт, о котором просит заказчик, с учетом рыночных механизмов.

8. Дополнительные «улучшения» всегда стоят дополнительных денег

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

9. Ненаписанное в электронном виде или в печатному документе вряд ли существует где-то, кроме как в вашей голове

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

10. Будьте вежливы, не бойтесь задавать вопросы и обсуждать условия

Разработчикам — вопреки всем анекдотам и стереотипам — можно и нужно задавать вопросы даже о самых элементарных вещах, но при этом не стоит давить или «показывать, кто главный», Тот факт, что вы принесли с собой деньги, не означает, что надо «закидывать ноги на стол». Заказчик не первый и не последний в жизни каждой студии, а уважение, вежливость и конструктивное обсуждение экономят время, деньги и нервы всем сторонам процесса и могут стать залогом долгосрочного и продуктивного сотрудничества. Чего мы вам и желаем :)


+2
Добавить в избранное Сохранено
Авторизуйтесь
Вход с паролем
Комментариев еще не оставлено
Выбрать файл
Читайте далее
Загружаем…
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать