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

Быстро – значит, раньше, чем заказчик примет решение о выборе исполнителя (другого исполнителя, раз вы еще не готовы ответить ему на самый главный вопрос).
Точно – значит, достаточно близко к реальной стоимости проекта, которую можно было бы озвучить после согласования ТЗ (а еще лучше после выполнения проекта, когда уже известно точное количество потраченного на разработку времени).
Ну и, наконец, что значит Без ТЗ? Понятно, что проектов совсем без ТЗ (в стиле «пойди туда, не знаю куда, принеси то, не знаю что») практически не бывает. Другое дело, в каком виде заказчик предоставляет вам это самое ТЗ.

Исходя из своего опыта, могу выделить следующие:

Уровни проработанности технического задания

Уровень 0

Заказчик не в состоянии предоставить хоть что-то, похожее на ТЗ. Бывает, что задачу он формулирует одной фразой – «Разработать CRM для театральной школы» или «Сделать примерно как на kakoy-to-site.com, но с небольшими изменениями». Вероятно, заказчику кажется, что в этой фразе содержится нужное количество информации для оценки объема работ, поэтому его удивляет, что вы не готовы сразу назвать стоимость ваших услуг.

Уровень 1

Словом «ТЗ» заказчик называет несколько картинок-прототипов, нарисованных от руки или в Excel. Стоит уточнить, что прототипы в Excel – это особенность заказов по моей специальности (базы данных и CRM), и в какой-то степени они решают задачу понимания, что нужно заказчику. В других случаях качество самих прототипов может быть выше, но суть остается та же – это просто картинки с небольшим описанием, но без детального разъяснения, что и как должно работать. Возможен также противоположный вариант ТЗ уровня 1 – краткое описание функциональных блоков без каких-либо указаний, как всё это должно выглядеть.

Уровень 2

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

Есть у ТЗ такого уровня и другая проблема. Бывает, что заказчик слишком подробно описывает не только логику работы системы, но и свои представления о том, каким образом эта логика должна быть реализована – какие технологии вам следует использовать, какие алгоритмы применять. Иногда указанные требования чем-то обоснованы (к примеру, заказчик планирует в дальнейшем самостоятельно поддерживать систему, поэтому хочет, чтобы вы использовали только знакомые ему технологии), но, как показывает практика, часто заказчик просто не знает, как обычно реализуют подобные вещи, и написал первое, что пришло в голову. Если вовремя не прояснить этот момент, вы рискуете зря потратить время, пытаясь воплотить предложенную схему, притом что исходная задача решается гораздо проще.

Уровень 3

Наивысший уровень, который только можно представить. Как правило, достигается после внимательного изучения вами деталей ТЗ, выявления всех спорных моментов и согласования окончательного варианта с заказчиком. Ура?! Оказывается, даже в этом случае не стоит расслабляться: в любой момент (в процессе разработки или в процессе опытной эксплуатации) у заказчика могут возникнуть пожелания, которые ему кажутся незначительными, а на деле могут потребовать радикальных изменений системы. Или какой-то функционал может подразумеваться заказчиком, но не быть явно прописанным в ТЗ, потому что «это очевидно».

Проблема в том, что часто у вас есть ТЗ только первого или даже нулевого уровня, и при этом заказчик требует назвать стоимость и сроки.

Как правильно оценить проект в таких условиях?

Для того чтобы желанный проект достался вам, нужно уметь быстро назвать правильную цену. Какую цену можно считать правильной?

С одной стороны, она должна быть не ниже себестоимости, иначе нет смысла браться за проект. Конечно, могут быть исключения из этого правила. Например, когда вы только начинаете свой путь на фрилансе и работаете на репутацию и портфолио, вам важна не столько цена, сколько возможность получить «плюс в карму». Но этот вариант мы сейчас не рассматриваем – предполагаем, что речь все-таки идет о бизнесе, который должен работать в плюс.

С другой стороны, высокая цена может отпугнуть заказчика, если другие претенденты предложат ему значительно более низкую цену. Здесь тоже может быть исключение. Если заказчик уже имеет положительный опыт работы с вами и знает, что вы ставите адекватную цену и за эту цену выполните задание качественно и в срок, то, возможно, даже при более высокой стоимости он выберет вас. Однако в таком случае заказчик, скорее всего, обратится к вам напрямую, и вам не придется участвовать в конкурсном отборе.

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

Какие ошибки могут быть допущены на этапе оценки работ (из моего опыта):

1. Если ТЗ слишком краткое для точной оценки (уровень 0 или 1), можно начать задавать заказчику уточняющие вопросы и слишком увлечься этим. Обсуждение ТЗ может затянуться на неопределенное время. В этом случае заказчик, во-первых, устает – зачем отвечать на ваши вопросы, если еще неизвестно, будете ли именно вы выбраны исполнителем? Во-вторых, заказчику кажется, что обилие вопросов означает отсутствие у вас опыта в решении подобных задач – так зачем вообще связываться с вами?

2. Если вам повезло и ТЗ достаточно подробное (уровень 2 или 3), то хочется оценить проект с учетом всех описанных деталей. Берем задание, выделяем этапы работы, каждый этап разбиваем на маленькие понятные задачи, которые легко оценить. В итоге должна получиться максимально точная оценка проекта – информации для этого вполне достаточно. Однако при таком подходе вы забываете о том, что оценка нужна не только точная, но и быстрая. Пока вы оцениваете все мельчайшие детали ТЗ, у заказчика возникает ощущение, что вы о нем забыли – не пишете ему, не задаете вопросов, ничего конкретного не предлагаете. А когда вы, наконец, выдадите ему готовую оценку проекта, может оказаться, что он уже нашел исполнителя (который не так долго думал) и все ваши усилия пропали зря.

3. Если уже известны цены, предложенные другими исполнителями, вы ориентируетесь на них и боитесь предложить цену выше. В этом случае может получиться так, что заказ вам достанется, но делать его придется себе в убыток – вам это надо?

4. Если, глядя на ТЗ, вы видите, как можно улучшить эту еще не разработанную систему, вы предлагаете заказчику сразу учесть те потребности, которые, почти наверняка, возникнут в процессе реализации проекта. Ошибка в том, что очевидные для вас детали могут быть незаметны или пока неважны для заказчика, и вашу заботу он расценит как желание навязать ему ненужный функционал за дополнительную плату.

Как я оцениваю проекты сейчас:

Для начала я определяю основные крупные функциональные блоки проекта, без детализации. Такие блоки, как правило, у проектов одинаковой направленности получаются очень похожими. Например, в любой CRM есть база клиентов, заказы, менеджеры, разграничения прав и т.д. Отличаются эти блоки конкретным набором полей, поведением при выполнении действий, но примерный объем работ получается одинаковый. В процессе работы над проектом я сначала трачу время на запланированные работы по всем функциональным блокам, затем (если осталось время) могу пойти навстречу возникшим пожеланиям заказчика. Когда установленное время подходит к концу, указываю заказчику на договоренность «сделать только то, что явно прописано в ТЗ». Как правило, заказчик соглашается, что работа выполнена, а если пожелания очень хочется реализовать, то мы договариваемся о следующем этапе работ, который оплачивается отдельно.

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

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

Заключение

Понятно, что умение оценивать проект крупными блоками и при этом видеть потенциально опасные детали, приходит с опытом. А для начала достаточно придерживаться двух правил:

Всегда помните свою основную цель

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

Заранее обезопасьте себя от необоснованных претензий заказчика

Если вы предполагаете, что в процессе работы могут вскрыться какие-то нюансы, которые значительно повысят сложность (и, соответственно, стоимость) разработки, сразу сообщите заказчику, что за оговоренную сумму вы сделаете только то, что явно прописано в ТЗ, а всё остальное готовы обсудить позже.

Автор: natnal

Источник