Как общаться с разработчиками мобильных приложений

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

Забота о разработчиках

Воодушевляйте

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

Что делать:

1. Уделять внимание и демонстрировать заинтересованность. Быть на связи, не бросать исполнителя один на один с задачей.
2. Не афишировать контакты разработчиков: передавать пожелания и замечания коллег через одного посредника.
3. Объяснять назначение каждой функции, рассказывать, какую пользу она принесёт, как без неё было плохо и как с ней станет хорошо.
4. Набраться терпения. Помнить, что это программист, а не тамада: ему платят за код, а не за разговоры и веселье.

Поясняйте термины

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

Что делать: расшифровывать терминологию своего бизнеса, в том числе сленг. Лучше письменно, чтобы исполнитель перечитывал объяснение. Иначе вместо списка частных клиентов можно получить Теслу, Эйнштейна и Стивена Хокинга.

Созванивайтесь деликатно

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

Второй кошмар программиста — нигде не зафиксированные, постоянно меняющиеся требования: «Помните, как мы три месяца назад созванивались, и я просил добавить пять новых экранов? Где они?» Исполнитель предпочитает текст, потому что переписка помнит всё.

Что делать:

1. Запланировать регулярные звонки, например: «Скайпы по вторникам и четвергам в 15:00». Вопросы накапливать, а потом обсуждать в назначенный день. Если нужен срочный внеочередной звонок, то предварительно написать сообщение и получить согласие.
2. Заложить голосовую консультацию в оценку трудозатрат. Предупредить, что время разговоров оплачивается.
3. Письменно зафиксировать принятые во время звонка решения.

Иллюстрируйте

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

Что делать: составлять картинки с пометками. Даже если на экране одна кнопка, которую нужно перекрасить из жёлтого в синий цвет. Сделать скриншот экрана, в Paint обвести кнопку, рядом подписать: «Перекрасить в синий».

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

Оценивайте ресурсы

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

Что делать: спрашивать напрямую. Например, так: «Вам нужен ещё один программист в помощь? Это ускорит разработку?»

Забота о себе

Документируйте требования

Да, без документации можно обойтись: объяснять голосом, работать по Agile, рисовать на салфетке. А потом застрять на этапе приёмки работы, и вот на каких вопросах:

• Разработчик сделал всё, о чём договаривались?
• Разработчик жалуется, что заказчик просит сделать больше, чем договаривались. Это действительно так?
• Как доказать разработчику, что он не выполнил оговорённое требование? Или выполнил, но не так?

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

Что делать: формулировать замечания, опираясь на факты. Пример:

«Где проблема: пункт №5.
Как сейчас: ошибка “Страница не найдена”.
Как должно быть: при клике на кнопку “Кабинет” открывается личный кабинет».
Желательно добавить скриншот.

К слову о доработках. Требуя «добавить только одну кнопочку, там работы на 5 минут», помните: нарисовать кнопку — 5 минут; запрограммировать то, что происходит при нажатии на неё — 5 часов.

Уточняйте требования

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

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

• Хочу, чтобы отчёт формировался быстро. А «быстро» — это сколько: 1 секунда или 2 минуты?
• Хочу красивый интерфейс. А какие понимаются под «красивыми»? Где примеры красивого и некрасивого дизайна?
• Нужно приложение для молодой аудитории. А «молодые люди» — это какой возраст: 15 лет или 35?

Здесь на помощь придёт техника постановки задач SMART.

Нет времени объяснять? Тогда сразу искать разработчиков с запущенными финтех-приложениями в портфолио. Или нанять профессионального посредника — аналитика требований или менеджера проекта.