Промахи случаются с обеих сторон: свою лепту вносят и заказчик, и исполнитель. Однако у заказчика больше возможностей влиять на процесс. Рассказываем, какие нюансы учесть, чтобы выпустить мобильное приложение вовремя, без конфликтов и потерь.
Программисты 90% времени проводят за бесчувственным компьютером, отдавая команды: открыть, закрыть, умножить, разделить. Отсюда и сложности со взаимопониманием: кажется, что эти специалисты замкнутые, капризные, грубые и говорят на инопланетном языке.
Что делать:
Коммитмент, нерезы, опердень, пивот, упырка, физики, юрики — не только айтишники произносят странные слова. Для них ваш бизнес-сленг так же непонятен, как для вас их компьютерный.
Что делать: расшифровывать терминологию своего бизнеса, в том числе сленг. Лучше письменно, чтобы исполнитель перечитывал объяснение. Иначе вместо списка частных клиентов можно получить Теслу, Эйнштейна и Стивена Хокинга.
Разработчик потому и пошёл в эту профессию, что там мало живого общения. Это, конечно, не единственная причина, но одна из них. Особенно угнетают звонки без предупреждения: проектируя сложный алгоритм, не хочется прерывать ход мысли.
Второй кошмар программиста — нигде не зафиксированные, постоянно меняющиеся требования: «Помните, как мы три месяца назад созванивались, и я просил добавить пять новых экранов? Где они?» Исполнитель предпочитает текст, потому что переписка помнит всё.
Что делать:
Парадокс: разработчик понимает сложную техническую документацию, но не дочитывает письмо с подробным описанием задачи.
Что делать: составлять картинки с пометками. Даже если на экране одна кнопка, которую нужно перекрасить из жёлтого в синий цвет. Сделать скриншот экрана, в Paint обвести кнопку, рядом подписать: «Перекрасить в синий».
А крупные задачи лучше разбивать на несколько мелких и объяснять постепенно.
Теоретически три человека перемоют гору посуды быстрее, чем один. На практике трое не поместятся у одной раковины. Так и в разработке мобильных приложений: распараллелить можно не всё.
Что делать: спрашивать напрямую. Например, так: «Вам нужен ещё один программист в помощь? Это ускорит разработку?»
Да, без документации можно обойтись: объяснять голосом, работать по Agile, рисовать на салфетке. А потом застрять на этапе приёмки работы, и вот на каких вопросах:
Готовить детальную документацию не обязательно, но нумерованный чек-лист иметь полезно: с ним больше конкретики и меньше эмоций. Придётся потратить пару часов на подготовку, но это время окупится. А без чек-листа конфликты и доработки растянутся на дни, недели, даже месяцы.
Что делать: формулировать замечания, опираясь на факты. Пример:
«Где проблема: пункт №5.
Как должно быть: при клике на кнопку “Кабинет” открывается личный кабинет.
Как есть: ошибка “Страница не найдена”.»
Желательно добавить скриншот.
К слову о доработках. Требуя «добавить только одну кнопочку, там работы на 5 минут», помните: нарисовать кнопку — 5 минут; запрограммировать то, что происходит при нажатии на неё — 5 часов.
Будем с собой честны: проблема не всегда на стороне исполнителя. Если заказчик оставляет широкий простор для интерпретации задач, то разногласий не избежать.
Что делать: прежде, чем идти к программистам, задайте себе уточняющие вопросы и постарайтесь на них ответить. Например:
Здесь на помощь придёт техника постановки задач SMART.
Нет времени объяснять? Тогда сразу искать разработчиков с запущенными финтех-приложениями в портфолио. Или нанять профессионального посредника — аналитика требований или менеджера проекта.