{"id":14270,"url":"\/distributions\/14270\/click?bit=1&hash=a51bb85a950ab21cdf691932d23b81e76bd428323f3fda8d1e62b0843a9e5699","title":"\u041b\u044b\u0436\u0438, \u043c\u0443\u0437\u044b\u043a\u0430 \u0438 \u0410\u043b\u044c\u0444\u0430-\u0411\u0430\u043d\u043a \u2014 \u043d\u0430 \u043e\u0434\u043d\u043e\u0439 \u0433\u043e\u0440\u0435","buttonText":"\u041d\u0430 \u043a\u0430\u043a\u043e\u0439?","imageUuid":"f84aced9-2f9d-5a50-9157-8e37d6ce1060"}

5 советов, как наладить коммуникацию заказчика из оффлайн с исполнителем из digital и начать общаться на одном языке

Думаю, и так понятно, что разработка собственного мобильного приложения — процесс трудоемкий и, что самое главное, требующий высокой компетенции, если не своей собственной, то хотя бы тех людей, которые были привлечены к работе. В моем случае я нашел компанию White Tiger Soft, которая взялась за разработку нашего мобильного приложения грузоперевозок «Грузик». Я специально пообщался с разработчиком перед публикацией данной статьи, чтобы они мне откровенно рассказали, как я выглядел в их глазах.

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

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

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

1. По возможности четко составить ТЗ.

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

2. Реально оценивать сроки выполнения работ.

Как бы ни хотелось как можно скорее заявить миру о своей новинке, нужно понимать, что исполнитель скорее всего скажет, что процесс разработки займет чуть ли не вдвое больше времени — и это нормально. Лучше настраиваться на такой исход событий. А если же удастся сделать все быстрее, то это будет приятным моментом.

Касаемо моего проекта, то у нас такое действительно было, но связано было с платежной системой. Платежка не работала порядка 3 месяцев, если мне не изменяет память. То есть вообще релиз должен был быть раньше. Таким образом разработка была, можно сказать, заморожена. Мы не могли продолжать работу над основными функциями приложения.

3. Заранее подготавливать список вопросов и фиксировать ответы на них в письменном виде.

Цитата исполнителя: «Несущественных вопросов - не было. А вот повторение одних и тех же моментов - да. Бывало такое, что вроде все выяснили, а через неделю-две приходилось еще раз выяснять один и тот же момент. Это были фильтры, алгоритмы поиска в основном.»

4. Прислушиваться к мнению исполнителя.

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

5. Не менять коней на переправе.

В любом случае, в процессе работы вы столкнетесь с трудностями, т.к. это неотъемлемый аспект почти всего в жизни. Возникнут трудности с пониманием друг друга, со сроками и т. д. И голову все чаще и чаще будут посещать мысли по поводу того, чтобы еще помониторить рынок агенств — разработчиков и оценить вариант со сменой исполнителя. Как правило, это не приведет к вас к тому, что другое агентство выполнит ваш заказ в разы быстрее. Скорее всего — наоборот. Вы вернетесь в самое начале, в самый первый пункт своего плана действий и весь процесс начнется заново.

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

0
2 комментария
Евгения Бахвалова

_

Ответить
Развернуть ветку
Юлия Силаева

💪

Ответить
Развернуть ветку
-1 комментариев
Раскрывать всегда