Как убеждать клиентов оплачивать ТЗ (или оценку проекта) и нужно ли это делать?
Очень часто сталкиваюсь с тем, что начинаю много и бесплатно вникать в проблемы клиентов, но это никто не оплачивает. Делаю это поскольку все хотят сроки и стоимость с первых же часов знакомства с их проектом, но на самом деле их не реально озвучивать без полного погружения в проблему и приходится всё равно озвучивать цифры с потолка. Получается замкнутый круг какой-то: чтобы получить проект и начать работать нужно озвучить оценку стоимости/сроков, вникнуть в проблему. Но чтобы всё это осуществить - нужно уже сделать кое-какую работу и зачастую очень важную и длительную (т.н. ресёрч).
И не факт, что в ходе исследования проекта не всплывёт какая-то ерунда. Например, клиенту хочется фича_нейм, которая завязана на вендора, но к которому, как выясняется позже, либо вообще нет API или API есть, но не позволяет сделать именно то, что хочет клиент. И клиент такой: "а, ну ок, тогда мы передумали запускать продукт, ведь без фича_нейм он не имеет смысла", а время на исследование уже потрачено впустую и никем не оплачено. Было уже слишком много случаев, когда, чтобы честно получить проект, я бесплатно исследовал вопрос клиента и выяснял, что его хотелки нельзя осуществить, т.е. я и проект не получал, и время зря убивал, но зато да, моя совесть была чиста, а клиент тоже со спокойной совестью шёл дальше выдумывать себе новые проекты.
Если называть цифры с потолка и тупо делать проект без его полного анализа вначале - то фича_нейм вообще может всплыть в самый не подходящий момент, когда уже всё почти сделано, много чего оплачено, но выясняется, что фича_нейм была критична для продукта, а сделать её никак нельзя.
Видел выход в том, что нужно убеждать клиента, мол любые консультации - это экспертиза и должна быть оплачена. Но когда я озвучиваю что-то подобное даже очень богатым клиентам - сливаются. А если называю сроки и стоимость с потолка, естественно без всякой экспертизы и погружения в проблемы/продукт клиента - разговор продолжается и в большинстве случаев, впоследствии таких нелепых разговоров и обещаний на пустом месте в духе: "я уже делал такое, будет готово к дате_х со стоимостью_y", проект назначается мне. Абсурд, ложь, но это работает - дальше можно увеличивать сроки и стоимость в разы походу дела, при условии, что работа идёт так, как нравится заказчику и у него есть деньги. И возникает такое чувство, будто клиенты сами изначально понимают, что их разведут в любом случае, накрутят 2-3 стоимости, затянут дедлайны и тд и выбирают среди исполнителей банально тех, кто красиво стелет или имеет похожие выполненные проекты. А вот изначально оплатить экспертизу, чтобы всё сделать по дзену: оценить реальную стоимость и сроки, а также риски, связанные с внезапной фича_нейм - никто толком не хочет.
Для себя пока нашёл временный выход - называть максимально возможный срок/цену, чтобы просто взять проект и при старте работ уже нормально посидеть над проектом и вникнуть во всё, зная, что всё будет оплачено с полна (если не всплывёт фича_нейм). Минусом такого способа является то, что когда я по-настоящему вникаю в проект - естественно появляется много вопросов к клиентам и они удивляются, мол, а как ты нам назвал оценку без данных подробностей, т.е. глупо выгляжу, теряется доверие ко мне. Кроме того, если в ходе такого анализа продукта обнаружится убийственная для проекта фича_нейм, я зафейлю проект, потрачу зря своё и чужое время, ведь на меня будут рассчитывать, думать, что работа кипит, я же изначально назвал все сроки и стоимость так, будто всё уже проверено и посчитано со 100% гарантией результата.
В вопросе фактически поставил знак равенства между ТЗ и оценкой проекта, хотя это конечно разные вещи, но суть вопроса, думаю, ясна.
Я думаю, не все проекты уникальные, так что можно их как-то обобщить и называть среднее.
Типа "Средний интернет-магазин - N часов", "Кастомная CRM для бизнеса в сфере X - Y часов", "Сверстать обычный лендинг - столько-то", "Сверстать лендинг с нескучными переходами - столько-то" и так далее
Василий Банников, пробовал, в итоге всё заканчивается кратным увеличением сроков и стоимости. Т.к. все хотят быть уникальными и у всех какие-то уникальности всплывают рано или поздно, которые нужно делать и на которые не было запланировано время.
Василий Банников, а главная проблема это то, что есть риск наткнуться на функционал, который клиент забыл озвучить вначале или неправильно его огласил при первом знакомстве и потом этот функционал всплывает в виде затянутых сроков (когда нет готовой либы и всё пишется с нуля) либо вообще фейлом всего проекта (когда ожидаемый функционал клиента/проекта завязан на вендора к которому нет API)
в итоге всё заканчивается кратным увеличением сроков и стоимости
Мне кажется, что это больше проблема процессов, чем фич.
Либо изначально клиент не знал и половины того что ему надо, либо вы каждый раз с нуля всё делаете.
Попробуйте всё новое, что вы делаете, абстрагировать, чтобы потом можно было переиспользовать в другом проекте.
когда нет готовой либы и всё пишется с нуля
Я бы не стал так драматизировать над фичами, для которых нет либ. Врядли там такие фичи типа "запилить pivot table с нуля" или "датагрид со всеми возможными фильтрациями и группировками"
Василий Банников, как правило клиенты озвучивают то, что им надо, но не в полной мере, т.к.:
1. Они не всегда знают чего хотят и бизнес-требования меняются. Если бы было изначально составлено ТЗ куда можно их тыкать носом, когда они там у себя в голове всё перекручивают - работать было бы проще. Но, наверное, бизнесмены настолько творческие люди, что такое понятие как ТЗ и прочие рамки их отпугивают.
2. Они не всегда понимают технических деталей. И даже опытному разработчику потребуется время на ресёрч, чтобы их понять (изучить API вендора, например). И это время должно быть как-то оплачено, ведь это делается до написания даже единой строки кода, до старта проекта.
Я в посте указал про злосчастную фича_нейм, которая может просто убить проект либо затянуть по срокам. Яркий пример такой фичи - клиенту нужен магазин, но выгружать товары в него нужно с сайта поставщика. Делается магазин любым стандартным автоматизиованным способом не_с_нуля и делается коннектор к поставщику. А потом бац - выясняется, что много чего с сайта поставщика выгрузить либо нельзя, либо структура данных настолько отличается от того, что нужно для конкретного магазина, что приходится к коннектору писать ещё и свою базу, в которой хранить нормализованные данные для запросов с клиента (чтобы проект не тормозил, не генерил каждый раз данные на бэкенде, и клиент быстро получал правильные, обработанные данные сразу с базы). Это конечно не rocket science, но уникальность разных API и структур данных заставляет каждый раз наступать на одни и те же грабли - обещаешь клиенту, что будет готово в час х, а потом изучаешь API вендора и понимаешь, что придётся к магазину дополнительно насоздавать всяких костылей и всё затягивается. Если бы экспертиза такого рода оплачивалась изначально, то было бы проще называть конечный срок и стоимость, а также же будут названы все риски, в стиле "какие-то поля будут отсутствовать у некоторых продуктов, вы уж поймите" (реальный случай: у поставщика в 90 из 100 продуктов есть определённые поля, а у 10 из 100 - нет, но этого никто не заметил, а потом клиент фыркает, мол, плохо сделали, ничего не работает)
Василий Банников, абстрагировать не получается, - если вы конечно не однотипные лендинги клепаете...
У меня проект онлайн конференций, а перед этим кадровый проект, перед этим - управление автомобилями, а перед этим - платежная система, система распознавания образов, управления сетевыми билингами и т.п. Сильно переиспользовать компоненты все равно не получается, А в каждом проекте какая-нибудь киллер-фича - да всплывет, в которой приходится увязать, насчет которой при старте проекта и не подозреваешь...
С автором согласен - для более-менее реальной оценки проекта нужно вникать в проект, либо начинать делать прототип базового функционала.
Ну либо брать с потолка и умножать на 3...
Владимир Куц, я вот что думаю, возможно наша проблема в том, что мы пытаемся совместить 3 должности: бизнес-аналитик, разработчик и продажник. И даже у этих троих, когда они работают каждый на своём месте, не всегда всё гладко выходит. Скорей всего надо специализироваться на какой-то одной бизнес-нише или нескольких, а остальные отметать. И тогда проще называть сроки и стоимость, но даже тут возможны киллер-фичи, конечно же, но всё равно проще работать, зная специфику сферы клиента.
Делай ресерч бесплатно, но перед тем как сказать оценку и стоимость добавь к оценке стоимость ресерча, размазанную по тбудущим таскам. + умножь на коэффициент, т.к. не каждый проект получаешь. Тогда и убеждать не надо и бесплатно не работаешь.
Требуете от клиента четкого описания задачи.
Если задача простая - на основании описания набрасываете ТЗ, согласовываете с клиентом, и работаете.
Если задача сложная и требуется детальный анализ и куча работ для написания ТЗ - сообщаете об этом клиенту.
Просто говорите - что нужно четкое техническое задание, и либо клиент его сам сделает, либо вы сделаете за отдельную плату.
Да я пробовал уже много раз и доходчиво объяснять людям: вы же когда строите дом - заказываете проект, смету, которая учитывает почву и рельеф местности, положение коммуникаций, водозабора и тд, в которой посчитаны все материалы и виды работ, так почему вы не хотите заказать смету на создание вашего онлайн-проекта, чтобы также грамотно всё спроектировать и учесть риски? Воспринимают в штыки.
Максим, и дом могут построить без сметы и анализа. И получается всё точно так же - всплывают непредвиденные сложности, особенности, увеличиваются сроки и стоимость проекта. Не каждый заказчик готов оплачивать проектно-изыскательские мероприятия.
Не каждый заказчик готов оплачивать проектно-изыскательские мероприятия.
Вот это больше всего и удивляет, ведь деньги на разработку проекта есть у всех и переплачивать 2-3 цены готовы большинство, а нормально заказать ТЗ что мешает? Явно не деньги, как правило, а что-то иное.
Пума Тайланд, хаха, ну мне почему-то это кажется очевидным, люди хотят жить в безопасности или в шалаше, где им будут падать кирпичи на голову? для этого и нужна смета, думал все это понимают, поэтому использовал этот пример.
Максим, ну то есть вы рассказываете какую то фигню и клиент должен сам додумать один минус что кирпич может упасть? С этой точки зрения можно ничего не рассказывать пусть сам додумывает
Любому клиенту очевидно что если строить один этаж то ничего не развалится и никакой кирпич не упадет. То есть там по прочностным характеристикам только один на миллион промахнется. Вот это клиенту очевидно, а ваш довод с кирпичом хрен догадаешься
Можно попробовать с чуть другого ракурса:
обследование->ТЗ
обследование - платно, но его стоимость возвращается по реализации
(классика в разных ремонтах - "диагностика 500р, при ремонте у нас - бесплатно")
заодно это возбудит в клиентах сенсоры "о, скидка")
Тут выше было подобное сравнение - "вы же когда строите дом - заказываете проект, смету, которая учитывает почву и рельеф местности, положение коммуникаций, водозабора и тд, в которой посчитаны все материалы".
Да, заказываю. И не поверите - всё бесплатно. Два частных дома мне уже так построили. Плюс множество сопутствующих работ и отделки по аналогичной схеме - сначала бесплатная смета с бесплатным выездом, потом работа с минимальной предоплатой, не более 20-30% и далее поэтапная оплата.
И обычно почти никаких косяков в процессе.
Иногда, если что-то сложное (или, наоборот, работы небольшие), выезд-замер-обследование стоит денег, но если работы по итогу делаем, то эта стоимость вычитается из конечной стоимости, то есть фактически бесплатно. При этом исключительно редко разрываешь отношения после замера-обследования - потому что перед этим замером примерная стоимость (или варианты) всё-равно уже озвучены и при обследовании просто подтверждается стоимость или выбирается конкретный вариант из озвученных ранее.
В общем, конкуренция делает свое дело - хочешь клиента - надо хоть немного потрудиться, чтобы его заполучить. А имея достаточный опыт, вполне можно быстро и достаточно точно посчитать примерную стоимость с учетом даже тех хотелок, о которых клиент еще даже не догадывается, но обязательно захочет в процессе.
Видел выход в том, что нужно убеждать клиента, мол любые консультации - это экспертиза и должна быть оплачена. Но когда я озвучиваю что-то подобное даже очень богатым клиентам - сливаются.
- одно из двух: либо вам мало лидов льется, либо клиентам не видна ценность вашей экспертизы из ваших блогов, сайтов и аккаунтов в соц. сетях.
Работайте в обоих направлениях, и они перестанут сливаться. Вернее, тех, кто не слился, будет более, чем достаточно. Платная первая консультация, потом работа в рамках почасовки.
С количеством лидов проблем нет. Но я уже просто сам боюсь брать проекты, где нет готового ТЗ и разбивки тасков.
С соцсетями не работал никогда, т.к. нет нужды в потоке клиентов.
Уровень экспертизы подтверждается отзывами на бирже.
Основная проблема в том, что в рамках одной консультации невозможно запихнуть анализ бизнеса клиента, его продукта и фич, которые он хочет в онлайне. А это нужно для того, чтобы получить полную картину и назвать адекватные стоимость и сроки (а также не зафейлить проект вообще, ведь за не сделанную фичу отвечать потом мне и никого не волнует, что клиент что-то не так объяснил в чате от 5 января, когда на дворе 5 июня, а я его тогда не так понял и пошло-поехало).
Максим, если с количеством лидов проблем нет, просто каждому лиду шлите счет на составление ТЗ первым же письмом вместо здравствуй. У вас будут заказы в итоге? Если да, тогда у вас, действительно, нет проблем с количеством лидов. Если нет, вы сами себя обманываете.
По поводу экспертизы: отзывы на бирже фриланса подтверждают только тот факт, что кто-то вас успешно попользовал и довольно дешево, а не вашу экспертизу. Экспертиза - это ваш авторский контент, которого больше нигде нет. Такой, чтобы каждый потенциальный клиент прочитав, говорил себе: блин, я готов потратить любые деньги, но только чтобы работал именно этот чувак.
Ну у меня вообще-то цены гораздо выше рыночных раза в 2-3 (из-за того, что много рисков закладываю в стоимость). Поэтому я бы не сказал, что дёшево.
На бирже у меня в аккаунте не только отзывы, но и отображены конкретные проекты, плюс в ответах на предложения поработать (сам уже давно не ищу заказы) высылаю свои топовые работы. Большинство потенциальных клиентов со мной работать хотят, но все тупят с ТЗ, вот и всё. Я уже не раз проводил эксперимент: начинаю что-то говорить про ТЗ - сливаются, видимо находят варианты "по проще". А если молчу про ТЗ, т.е. сам веду себя "проще" и тупо начинаю работать в первый же день - клиент видит результат и рад. Делаю вывод - клиенты, особенно западные, слишком заняты, чтобы тратить время на ТЗ, для них это мутная тема и им просто нужен готовый продукт, решающий их задачи. Но иногда эта простота губительна, конечно же. Речь идёт об интернет-магазинах и кастомных решениях для готовых магазинов, если что. В задачх посложней возможно и клиент более грамотный и ситуация иная.
Ошибки допущенные на этапе Проектирования - САМЫЕ ДОРОГИЕ.
Разработка БЕЗ ТЗ допустима для ограниченного круга задач.
Разработка проекта в любой форме неотъемлемая часть решения любой задачи и следовательно ВСЕГДА должна присутствовать в прейскуранте.
Простой
