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

Битрикс24

www.bitrix24.ru

15
Отследить-посылку

Отследить-посылку

отследить-посылку.рф

13
GIFTD

GIFTD

giftd.tech

12
Логомашина

Логомашина

logomachine.ru

11
Devicerra

Devicerra

devicerra.com

11
Aword

Aword

Приложение для изучения английских слов

11
Eczo.bike

Eczo.bike

www.eczo.bike

11
Flowlu

Flowlu

flowlu.ru

8
KEPLER LEADS

KEPLER LEADS

keplerleads.com

7
Convead

Convead

convead.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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