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