Как убеждать клиентов оплачивать ТЗ (или оценку проекта) и нужно ли это делать?
Очень часто сталкиваюсь с тем, что начинаю много и бесплатно вникать в проблемы клиентов, но это никто не оплачивает. Делаю это поскольку все хотят сроки и стоимость с первых же часов знакомства с их проектом, но на самом деле их не реально озвучивать без полного погружения в проблему и приходится всё равно озвучивать цифры с потолка. Получается замкнутый круг какой-то: чтобы получить проект и начать работать нужно озвучить оценку стоимости/сроков, вникнуть в проблему. Но чтобы всё это осуществить - нужно уже сделать кое-какую работу и зачастую очень важную и длительную (т.н. ресёрч).
И не факт, что в ходе исследования проекта не всплывёт какая-то ерунда. Например, клиенту хочется фича_нейм, которая завязана на вендора, но к которому, как выясняется позже, либо вообще нет 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 цены готовы большинство, а нормально заказать ТЗ что мешает? Явно не деньги, как правило, а что-то иное.
Пума Тайланд, хаха, ну мне почему-то это кажется очевидным, люди хотят жить в безопасности или в шалаше, где им будут падать кирпичи на голову? для этого и нужна смета, думал все это понимают, поэтому использовал этот пример.
Максим, ну то есть вы рассказываете какую то фигню и клиент должен сам додумать один минус что кирпич может упасть? С этой точки зрения можно ничего не рассказывать пусть сам додумывает
Любому клиенту очевидно что если строить один этаж то ничего не развалится и никакой кирпич не упадет. То есть там по прочностным характеристикам только один на миллион промахнется. Вот это клиенту очевидно, а ваш довод с кирпичом хрен догадаешься
Вы же сами видите как получается. Так работает этот рынок. Клиент готов переплатить, лишь бы узнать бюджет проекта как можно раньше. Вам придется потакать этому желанию. Клиент ведь всегда прав )).
Клиент считает, что ТЗ не так уж и важно, поэтому его и удивляет необходимость отдельно его оплачивать. Можно провести параллель с юнит тестами или документацией. Это важные и нужные вещи, но клиент не способен этого оценить, так как юнит тестами он пользоваться сам не будет, да и документацией скорее всего тоже. Не барское это дело - документацию читать. Для него это выглядит как бесполезная трата времени, за которое можно было бы напилить больше фич.
Поэтому у вас выбора особо нет:
Выставлять счёт за анализ проекта. Идеальный вариант, но не срабатывающий в реальности. Шансов больше с клиентами, с которыми вы уже работали. То есть с теми, кто уже знает вас и доверяет.
Составлять ТЗ бесплатно. Так делают все и клиенты ожидают этого от вас в том числе. Да, в конце-концов клиент может и не запустить проект, когда узнает про него более подробно. Поэтому и возникает отторжение, когда нужно заплатить за проект, который может быть даже и не будет начат. Ну и что, что вы потратили свое время. Проект-то не запущен, условия не согласованы, бюджет не выделен (он ведь неизвестен без ТЗ).
Работать без ТЗ. Как правило, с почасовой оплатой. Такой вариант отпугивает неизвестной заранее полной ценой проекта.
Проблема пункта 2 заключается в том, что на клиента бесплатно пашут несколько подрядчиков, анализируют его бизнес и тд и тп, а потом он выбирает самую вкусную цену и понятные условия, а остальные, получается, зря потратили время и получили упущенную прибыль, и, порой это несколько недель и тысяч $ в случае, если бы разраб вместо бесплатного анализа и составления ТЗ просто писал код на действующем проекте за это же время (проще говоря, время разработчика дорого стоит и работать бесплатно для составления ТЗ, которое не факт что примут и проект будет назначен именно ему - непозволительная роскошь)
а потом он выбирает самую вкусную цену и понятные условия
Именно так. Пока будут альтернативы - клиент будет выбирать. А альтернативы будут, пока разработчики соглашаются работать на таких условиях. Рыночные отношения во всей красе.
а остальные, получается, зря потратили время и получили упущенную прибыль
Не зря. Они знали на что шли и были готовы пойти на риск ради получения проекта. Проект достанется если не им, то кому-то другому.
Пока каждый разработчик в мире не начнет требовать денег за разработку ТЗ, ничего не изменится.
Можно попробовать с чуть другого ракурса:
обследование->ТЗ
обследование - платно, но его стоимость возвращается по реализации
(классика в разных ремонтах - "диагностика 500р, при ремонте у нас - бесплатно")
заодно это возбудит в клиентах сенсоры "о, скидка")
Тут выше было подобное сравнение - "вы же когда строите дом - заказываете проект, смету, которая учитывает почву и рельеф местности, положение коммуникаций, водозабора и тд, в которой посчитаны все материалы".
Да, заказываю. И не поверите - всё бесплатно. Два частных дома мне уже так построили. Плюс множество сопутствующих работ и отделки по аналогичной схеме - сначала бесплатная смета с бесплатным выездом, потом работа с минимальной предоплатой, не более 20-30% и далее поэтапная оплата.
И обычно почти никаких косяков в процессе.
Иногда, если что-то сложное (или, наоборот, работы небольшие), выезд-замер-обследование стоит денег, но если работы по итогу делаем, то эта стоимость вычитается из конечной стоимости, то есть фактически бесплатно. При этом исключительно редко разрываешь отношения после замера-обследования - потому что перед этим замером примерная стоимость (или варианты) всё-равно уже озвучены и при обследовании просто подтверждается стоимость или выбирается конкретный вариант из озвученных ранее.
В общем, конкуренция делает свое дело - хочешь клиента - надо хоть немного потрудиться, чтобы его заполучить. А имея достаточный опыт, вполне можно быстро и достаточно точно посчитать примерную стоимость с учетом даже тех хотелок, о которых клиент еще даже не догадывается, но обязательно захочет в процессе.
Видел выход в том, что нужно убеждать клиента, мол любые консультации - это экспертиза и должна быть оплачена. Но когда я озвучиваю что-то подобное даже очень богатым клиентам - сливаются.
- одно из двух: либо вам мало лидов льется, либо клиентам не видна ценность вашей экспертизы из ваших блогов, сайтов и аккаунтов в соц. сетях.
Работайте в обоих направлениях, и они перестанут сливаться. Вернее, тех, кто не слился, будет более, чем достаточно. Платная первая консультация, потом работа в рамках почасовки.
С количеством лидов проблем нет. Но я уже просто сам боюсь брать проекты, где нет готового ТЗ и разбивки тасков.
С соцсетями не работал никогда, т.к. нет нужды в потоке клиентов.
Уровень экспертизы подтверждается отзывами на бирже.
Основная проблема в том, что в рамках одной консультации невозможно запихнуть анализ бизнеса клиента, его продукта и фич, которые он хочет в онлайне. А это нужно для того, чтобы получить полную картину и назвать адекватные стоимость и сроки (а также не зафейлить проект вообще, ведь за не сделанную фичу отвечать потом мне и никого не волнует, что клиент что-то не так объяснил в чате от 5 января, когда на дворе 5 июня, а я его тогда не так понял и пошло-поехало).
Максим, если с количеством лидов проблем нет, просто каждому лиду шлите счет на составление ТЗ первым же письмом вместо здравствуй. У вас будут заказы в итоге? Если да, тогда у вас, действительно, нет проблем с количеством лидов. Если нет, вы сами себя обманываете.
По поводу экспертизы: отзывы на бирже фриланса подтверждают только тот факт, что кто-то вас успешно попользовал и довольно дешево, а не вашу экспертизу. Экспертиза - это ваш авторский контент, которого больше нигде нет. Такой, чтобы каждый потенциальный клиент прочитав, говорил себе: блин, я готов потратить любые деньги, но только чтобы работал именно этот чувак.
Ну у меня вообще-то цены гораздо выше рыночных раза в 2-3 (из-за того, что много рисков закладываю в стоимость). Поэтому я бы не сказал, что дёшево.
На бирже у меня в аккаунте не только отзывы, но и отображены конкретные проекты, плюс в ответах на предложения поработать (сам уже давно не ищу заказы) высылаю свои топовые работы. Большинство потенциальных клиентов со мной работать хотят, но все тупят с ТЗ, вот и всё. Я уже не раз проводил эксперимент: начинаю что-то говорить про ТЗ - сливаются, видимо находят варианты "по проще". А если молчу про ТЗ, т.е. сам веду себя "проще" и тупо начинаю работать в первый же день - клиент видит результат и рад. Делаю вывод - клиенты, особенно западные, слишком заняты, чтобы тратить время на ТЗ, для них это мутная тема и им просто нужен готовый продукт, решающий их задачи. Но иногда эта простота губительна, конечно же. Речь идёт об интернет-магазинах и кастомных решениях для готовых магазинов, если что. В задачх посложней возможно и клиент более грамотный и ситуация иная.
