Эффективность любого сотрудничества напрямую зависит от уровня коммуникации: чем лучше выстроено общение — тем качественнее результат. Особенно важно придерживаться этой формулы, устанавливая контакт со специалистами IT-сферы. Как правило, программисты — это люди с техническим складом ума, а значит, любят конкретику, логичность и точность. Умение выстроить диалог в наши дни не менее важно, чем получить хорошее финансирование проекта или заполучить в команду профи. Навык четко доносить свои мысли — это своего рода скилл, требующий постоянной прокачки.
В этой статье мы поделимся рекомендациями, как правильно выстроить диалог и понимать друг друга в процессе работы над общим проектом, каких формулировок и действий лучше избегать, а что, наоборот, улучшит ваше общение с программистами.
Преимущества сотрудничества с разработчиком на фрилансе
Согласно исследованию Payoneer, рынок фриланса стремительно развивается. Не последнее место в этом процессе сыграла и пандемия. Все больше специалистов IТ-сферы предпочитают быть self-employed, не зависеть от внутренних распорядков и правил компаний. Конечно же, программисты-фрилансеры пользуются спросом у заказчиков, ведь на это есть свои основания:
- возможность выстроить личное общение, согласовать условия сотрудничества без третьих лиц;
- оперативно вносить правки в ТЗ напрямую (в случае крайней необходимости);
- согласование технических нюансов в процессе разработки (возможна замена определенных решений на альтернативные, более рентабельные в этом проекте);
- обмен опытом напрямую: программист с богатым портфолио может посоветовать, как правильно реализовать проект, ссылаясь на свой бэкграунд;
- расчет без посредников: заказчик точно знает, кому и за что платит;
- постоянная поддержка обратной связи;
- конструктивные пожелания и объективная критика: это, конечно, малоприятный момент, но в случае необходимости, заказчик может напрямую выразить свое несогласие с тем или иным решением, собственно, как и программист может объяснить, «почему так, а не иначе»;
- стоимость услуг фриланс-разработчика, как правило, ниже, чем услуг специалиста, который работает в агентстве или крупной IТ-компании.
Алексей Литвинцев
Как быть на одной волне. Фундамент успешного сотрудничества
Прежде чем открыть проект, заказчику стоит четко сформировать, в первую очередь для собственного понимания, общую рабочую картину и возможный финал сотрудничества. Конечно же, здесь не обойтись без правильно составленного технического задания. Для этого можно обратиться за помощью к специалистам или сделать самостоятельно (в сети есть достаточное количество примеров).
Без чёткого ТЗ — результат ХЗ
Когда выбран исполнитель проекта, начинается самое интересное. Стоит сразу же уточнить:
- какой стек технологий планирует использовать программист для выполнения задачи (если иное строго не обусловлено ТЗ и допускается применение альтернатив),
- есть ли какие-либо технические нюансы, которые могут существенно повлиять на процесс разработки,
- соответствует ли изложенное в ТЗ навыкам программиста.
На этом этапе общения стоит быть предельно точным и не допускать использования абстрактных фраз и понятий. Больше конкретики — лучше результат. Не забывайте о том, что общаетесь c «технарем».
Deadline, или Обратная сторона Луны
Сколько шуток и мифов вокруг понятия «дедлайн», уже и не сосчитать. Но, увы, в каждой шутке есть доля шутки, как известно, а все остальное правда. Поэтому прежде чем начать сотрудничество, обязательно уточните все вопросы, касающиеся сроков. Если для заказчика важны временные рамки, ему стоит подчеркнуть эту информацию сразу же. Не нужно использовать общие фразы из серии: «Чем быстрее, тем лучше», «Как только справитесь» и т. п.
Важно также понимать, что менять на ходу условия ТЗ и вносить тысячи правок в день — это плохая идея. Как правило, ничего хорошего в итоге не получится. Помимо затягивания сроков, скорее всего, возникнет ряд недопониманий между заказчиком и разработчиком, ведь последний вряд ли захочет переделывать по десять раз одну и ту же работу без изменения оплаты.
Смотрите ли вы в одну сторону?
Не бойтесь задавать вопросы, каким видит ваш проект программист. Совпадают ли ваши взгляды на финальный результат? Если вы нашли точки соприкосновения, смело начинайте работу.
Терпение и труд…
Всё перетрут, но не в нашем случае. Если заказчика что-то не устраивает, лучше сразу сказать об этом. То же правило стоит активно применять и программисту. Если вовремя обсудить возникшие недопонимания и трудности, можно предотвратить серьезные проблемы в будущем.
Как не стоит говорить, или Популярные проблемы при работе с программистами и возможные пути решения
Теперь представим, что вы и есть тот разработчик, которому предстоит общение с заказчиком напрямую. Конечно же, «битый воин» видал всякое и наверняка в своей практике встречался с разными типами людей. Тут сразу приходит на ум цитата из известной сказки: «Поди туда — не знаю куда, принеси то — не знаю что». Именно эта ситуация, увы, приобретает ярлык типичной, ведь достаточно часто попадаются заказчики, которые не могут описать, что конкретно они ожидают в финале сотрудничества.
А бывает и наоборот: наличие четкого ТЗ и выбранные клиентом технологии не позволяют реализовать проект на высоком уровне. И даже несмотря на рекомендации поменять стек, заказчик говорит категоричное «нет». Это лишь вершина айсберга. Наиболее частые проблемы, которые возникают в процессе общения программиста и клиента, перечислим далее.
«Я знаю, что можно так сделать. У моего знакомого есть аналогичный проект, и там использовали такие решения»
Согласитесь, очень странно, когда заказчик, который обратился за помощью к программисту, начинает учить его делать работу. Стоит послушать специалиста и смириться с тем, что разработчику виднее, какие технологии более рентабельны, что сейчас актуально, на каком языке стоит писать, какие фреймворки использовать и т. п. Если у заказчика есть какие-то конструктивные пожелания, нужно озвучить их сразу, но в то же время принять позицию более опытной стороны.
«Это же легко! Я знаю, что на задачу понадобится не больше недели»
Заказчик не вправе оценивать трудоемкость работы. Как минимум с той позиции, что он не разработчик и не знает всех особенностей реализации технических проектов. Хотите быть более продвинутым? Почитайте об Agile и Scrum подходах. Реально оцените сроки, пообщавшись с разработчиком. Но в то же время не позволяйте значительно выходить за ранее озвученные временные рамки.
Войдите в положение
Относитесь с пониманием к возможным проблемам, задержкам и форс-мажорам. В жизни случается всякое, и рабочие процессы — не исключение. Заказчику не стоит быть слишком суровым к единичным ошибкам, в то же время разработчикам лучше не злоупотреблять пониманием клиента. И наоборот — нельзя использовать программиста по максимуму, а уж тем более испытывать лимит его терпения слишком частыми изменениями в работе.
«А сколько ещё, а что уже… А на каком этапе?»
Эти и десятки других подобных вопросов как надоедливая мантра медленно, но уверенно уничтожают взаимопонимание и желание сотрудничать. Гиперконтроль и гипервмешательство — «плохие звоночки», которые рано или поздно выльются в конфликт. Заказчику не стоит быть слишком навязчивым, но в то же время остерегайтесь пускать все на самотек. Договоритесь с программистом о том, что у вас будет определенное время для контрольных созвонов. Или же пользуйтесь такими ресурсами, как Trello, чтобы быть в курсе процесса.
«У меня уже был один программист, вот его код…Подшамань что-то, добавь своё..»
Очень хорошо, если у заказчика уже есть какая-то база и понимание того, что из себя представляет проект. Но очень плохо, если он хочет, чтобы новый работник разбирался в чужом коде. Особенно, если логика его работы не понятна вовсе, а о комментариях прошлый разработчик даже не слышал. Если ситуация позволяет, лучше всего начинать работу с чистого листа или же предоставить специалисту понятный рабочий код.
«Этот новый фреймворк/язык/база данных будет лучше, я уверяю!»
Конечно же, любой программист заинтересован в собственном развитии. Кто же будет с радостью делать одно и то же под копирку? Если заказчик гибок в выборе технологий, он может позволить специалисту действовать на свое усмотрение. Главное результат! Но если же клиент четко знает, на чем должен быть написан проект, стоит корректно отказать разработчику и настоять на своём.
В завершение…
Подводя итог, хочется озвучить несколько советов, которые помогут эффективно коммуницировать и получить желаемый результат:
1. «Вместо стен стройте мосты». Не избегайте обсуждений и комментариев. Старайтесь всегда находить консенсус, адекватный диалог поможет решить даже самую запутанную ситуацию.
2. Каждый играет свою роль: не надо рассказывать профессионалу, как и что делать. Ведь раз вы знаете всё, так почему не делаете сами? В то же время разработчик не должен навязывать свои взгляды и рассказывать о том, что он переделал десятки таких проектов и знает как нужно.
3. Давать вовремя адекватную обратную связь, аргументировать свою позицию, позволять исправлять ошибки — это уже полпути к успешному сотрудничеству. Старайтесь найти золотую середину в возникшем конфликте и адекватно решить его без взаимных обвинений и оскорблений.
4. И напоследок. Случается так, что взаимное сотрудничество просто невозможно — так бывает. Главное, понять это еще до начала работы, чтобы не терять ни время, ни средства.
Напоминаем, что у нас на сервисе вы можете выбрать подходящего программиста для реализации своего проекта. Желаем успешного и продуктивного сотрудничества!