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

Аватар
Johnny Walker
Chief Editor
24 января 2020 Updated on  Обновлено   1 февраля 2023

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

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

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

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

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

Что делать:

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

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

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

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

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

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

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

Что делать:

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

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

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

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

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

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

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

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

Забота о себе

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

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

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

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

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

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

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

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

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

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

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

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

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

map

Связаться с нами