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