Работать с людьми всегда трудно: человеческий фактор стреляет внезапно. Мы не можем прогнозировать со 100% вероятностью, что человек в какой-то конкретной ситуации поступит каким-то конкретным образом. Не можем минимизировать вероятность возникновения ситуаций, где человеческий фактор сработает. Или можем? Если можем, то в каких случаях? И самое главное — как?
Большинство проблем в отношениях “заказчик-разработчик” возникают из-за недосказанности, недопонимания, а иногда — из-за нежелания разбираться в вопросе до конца. Даже самый профессиональный программист с тысячей положительных отзывов не сможет выдать идеальный для клиента результат, если не поймет, какая задача перед ним стоит.
А чтобы разработчик понял, нужно научиться корректно ставить задачи. Но что это, вообще, значит? Сейчас разберем.
У разных людей разное представления обо всем
Особенно о таких абстрактных вещах, как красота и "атмосферность". Недостаточно написать в задаче “сделайте, чтобы было красиво”. У вас и у программиста разные представления о том, что такое “красиво”. Когда вы говорите “красивый сайт”, вы представляете, допустим, сочетание ярких цветов, много картинок, необычный шрифт. Когда разработчик слышит “красивый сайт”, он видит совершенно другую картинку: например, он фанат минимализма.
И что получается в итоге? Вы думаете, что корректно поставили задачу, расслабляетесь и ждете результат. Разработчик выполняет задание, отправляет работу вам, и вы… недовольны. Хотели одно, получили другое, и теперь надо вносить кучу правок — все злятся и теряют много времени.
Чтобы такого не происходило, учитывайте разницу восприятия. Если говорите “красивый сайт”, то объясняйте, что конкретно должно быть на сайте, чтобы он считался красивым с вашей точки зрения. Называйте конкретные цвета, приводите конкретные примеры. Можно даже скидывать ссылки на другие сайты и пальцем показывать, что именно вам нравится: подложка для текста, шапка и т.д.
Подробно и четко отвечайте на вопросы разработчика
Давайте начистоту: чтобы ваш проект удался, вы сами должны четко представлять, как он будет работать, как выглядеть и какие функции выполнять. То есть вам нужно посидеть, подумать, составить техническое задание (ТЗ) и только потом ставить задачу.
Но даже в таком случае есть вероятность, что у разработчика возникнут вопросы. И это нормально: вопросы помогут лучше понять задачу и впоследствии получить лучший результат. Если вы, конечно, на них четко и подробно ответите.
Это же правило работает в обратную сторону. Если у вас есть вопрос к разработчику, ставьте его подробно и четко. Не “почему что-то там не работает”, а “в таком разделе сайта на такой странице не работает вот это”. Такая постановка сократит время поиска, и разработчик решит вопрос гораздо быстрее.
И помните, что подробности — это не про эпитеты и метафоры, а про конкретику.
Готовьте техническое задание
Долгие обсуждения и подробные объяснения — хорошо. Но еще лучше, когда есть техническое задание. ТЗ — документ, где заказчик по пунктам прописывает, как и что должно работать в продукте, который он собрался выпускать. Похоже на задачу, но есть значительные отличия.
ТЗ — большой и подробный документ по продукту в целом, где написано, что получит в результате заказчик и что нужно сделать разработчику. А задача — более узконаправленное действие по конкретной части продукта. То есть ТЗ, если оно хорошо составлено, будет одно, а задач — много. Именно в процессе написания ТЗ становится понятно, сколько действительно продукт стоит.
Если есть желание написать “вы же профессионал, сами сделайте как надо”, остановитесь, глубоко вдохните, выдохните и вспомните первый пункт. “Как надо” — абстрактное понятие, а значит, разработчик может понять вас неправильно.
Не пугайтесь, рассказывать разработчику, как писать код, не придётся. С технической стороной он разберется сам: именно потому, что профессионал. А вот объяснить, что должны видеть и получить в итоге ваши будущие клиенты, необходимо.
Фиксируйте договоренности и обсуждения
На бумаге или в электронном виде — неважно. Важно именно зафиксировать. Если это есть только в голове, про это легко забыть. А когда важные обсуждения записаны, поставить задачу, структурировать ее гораздо проще.
Не стоит, к слову, воспринимать переписку как способ поставить задачу. В чате можно обсудить детали и обменяться мнениями, а задание должно быть четко разложено по пунктам, структурировано и зафиксировано именно как задача в CRM-системе или органайзере, в котором вы договорились работать.
Конечно, давать задания разработчику можно и по электронной почте. Но об этом лучше договориться сразу. И в таком случае лучше писать на почту только по задачам, а детали обсуждать, например, при личной встрече или по телефону. Чтобы письмо подводило итог обсуждений и обозначало конкретные задачи.
Об изменениях в ТЗ сообщайте прямо сразу
Ни один человек в мире не умеет читать мысли других людей. Разработчики — не исключение. И если вы понимаете, что в конечном продукте должно быть что-то не так, как это прописано в техническом задании, говорите об этом сразу. Разработчик не сможет проникнуть в вашу голову и догадаться, что конкретно должно измениться, и в итоге вы получите совсем не то, что хотели.
Помните, что менять ТЗ по 10 раз в день — плохая идея для вашего же проекта. Сначала нужно определиться, что вы хотите и как это должно работать, и только затем заказывать проект. Иначе все потратят кучу времени, а результата не будет никакого.
Доработки и улучшения стоят денег
Когда что-то меняется в ТЗ, и это “что-то” нужно переделывать, разработчику нужно потратить время. А значит, вам за него придётся доплачивать. Не путайте обновление версии продукта с доработкой или полным его изменением еще на стадии разработки.
По нашему опыту, доработка в 95% случаев — внесение эксклюзивных решений в уже существующий функционал. А обновление — усовершенствование уже существующего (хотя обновление тоже может быть с доработками).
Наглядный пример. К вам в турфирму приходит клиент и говорит: “Хочу в Турцию”. Вы обсуждаете с ним подробности (отель, дополнительные экскурсии по желанию) и делаете конкретное предложение. Он его принимает, оплачивает тур и уходит. И за неделю до вылета звонит и заявляет: “Я тут подумал, что хочу ещё и в Египет в рамках этого же тура заглянуть, отвезите”.
Это даже звучит абсурдно, правда? Не будете же вы из своего кармана деньги доставать и возить туриста из страны в страну, как ему вздумается. Он ведь уже купил сформированный пакетный тур!
Вот и с доработками так же. Чаще всего они уникальны, а за рабочие часы, когда эта уникальность создается, надо платить деньгами. Учитывайте это и при составлении технического задания, и при внесении туда изменений.
