В предыдущих постах я писал о том, что делать, если Заказчик постоянно генерирует новые «хотелки» по ходу проекта (клац), и что делать, если он просит эти работы сделать бесплатно (клац).

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

Вводные:

Вы находитесь в проекте, у вас есть ограниченный объем работ, бюджет и срок. Заказчик приходит и озвучивает какую-то хотелку. Вы собираете требования, описываете их (ТЗ, ФТ, ТР, что угодно), согласовываете их с Заказчкиом и считаете стоимость этих работ. Но в ответ получаете возражение «а чего так дорого, там же программист за день сделает». Ещё в конце может добавить любимое: «Вы же эксперты».

То есть в этом посте речь пойдет не про техники продаж. Мы не рассматриваем вариант, когда нужно именно что-то с нуля продать Заказчику. Там работают совсем другие инструменты, о них рассказывают совсем другие люди, да и надо это не проектной команде, а сейлам.

Поэтому этот пост будет полезен тем, кто может столкнуться с такой ситуацией в проекте. А это любой сотрудник, взаимодействующих с Заказчиком. Обычно это менеджер проекта, реже архитектор, еще реже бизнес-аналитик.

Мои рекомендации основываются на собственном опыте в больших и сложных IT-проектах с внешними корпоративными Заказчиками. На фрилансе, в госах, на небольших проектах и в другой сфере могут быть свои нюансы, тут у меня опыта немного.

И последнее: речь идёт о том, что вы для Заказчика – безальтернативный Исполнитель. Если новые работы будут вынесены на ЧЕСТНЫЙ открытый конкурс, где выбирать будут ТОЛЬКО по цене, то абсолютное большинство пунктов ниже будет неприменимо.

 

Варианты работы с возражением:

Сначала пытаемся договориться на полную стоимость:

1.       Сравните с аналогичными работами. Приведите пример, известный и понятный Заказчику, в котором работы аналогичного объёма/сложности вы сделали за такую же стоимость.

2.       Обоснуйте сложность задачи. В 90% случаев Заказчик не понимает, почему простая, на первый взгляд, задача стоит так дорого. Нужно это понимание у Заказчика сформировать. Насколько подробно это надо обосновывать зависит от Заказчика – кому-то достаточно объяснения на бизнес уровне, а кому-то нужны будут все технические детали.

3.       Покажите трудозатраты на выполнение. Стоимость работ сама по себе ничего не говорит Заказчику о трудозатратах, которые вы потратите на эти работы. Можно продать 5 человеко-дней за 100.000 рублей, а можно за 1.000.000 руб. Поэтому иногда Заказчику можно сделать бюджетную оценку, в которой будет подробно расписан перечень работ и трудозатрат с разбивкой по специалистам. Например, задача №3 «Реализация кастомной формы на веб-портале», трудозатраты менеджера – 1 чд, архитектора – 5 чд, разработчика – 10 чд, аналитика – 1 чд, тестироващика – 3 чд. Из такой разбивки уже становится понятно, что на самом деле там не неделя работы разработчика, а целых две, так ещё и кроме разработчика 10 чд уходит на другие роли в проекте.

С демонстрацией трудозатрат Заказчику надо быть очень аккуратными. Такое всегда нужно согласовывать со своим руководством, потому что не всегда это применимо. И если вы на это пойдете, будьте готовы к тому, что Заказчик узнает ставки ваших специалистов, и будьте готовы к вопросам «а почему у вас разработчик стоит 50.000 рублей в день?».

4.       Продолжение предыдущего пункта – объясните Заказчику, что вы не просто продаёте какую-то фичу, вы продаёте консалтинг. Это значит, что вы собрали требования, оценили текущую ситуацию, продумали техническое решение, описали, согласовали, поставили задачу разработчику, проконтролировали выполнение, протестировали, показали и тд.

Обычно Заказчик не видит и не понимает все эти работы. Он всегда думает в парадигме «Да там разработчику на неделю работы, почему так дорого?»

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

6.       Предложите не фиксированную стоимость, а оплату по Time&Material. Это когда Заказчик платит не заранее согласованную стоимость за фиксированный объем (Fix Price), а платит по фактически потраченным трудозатратам по оговоренным ставкам. Работа по T&M выгодна исполнителю, так как снимает с него риски, что на какие-то работы будет потрачено трудозатрат больше, чем планировалось. А вот Заказчик наоборот, может потратить денег больше, чем по Fix Price, если какие-то работы пойдут не по плану. Да и генерировать замечания и хотелки Заказчику уже так просто не получится – за них придётся платить.

7.       Цена – не единственный критерий выбора. Возможно, Заказчик понимает, что другие Исполнители могут сделать эти работы дешевле. Вы должны продемонстрировать Заказчику свой профессионализм и объяснить, что у вас есть куча других преимуществ. В конце концов, вы делаете основной проект и лучше знаете, как и что работает.

Более того, подсветите Заказчику, что привлечение другого Исполнителя – это огромное количество проблем: кто будет согласовывать техническую реализацию того, что новый исполнитель будет делать? Потребуется арх.надзор с вашей стороны, чтобы они не сломали то, что уже вами сделано? А кто будет за это платить? А кто будет отвечать, если что-то сломается? Всегда можно будет показать пальцем друг на друга и сказать, что это из-за них всё сломалось. А как одновременно несколько разработчиков из разной компании будут на одной среде вести разработку? А тестировать? В общем привлечение другого Исполнителя под какие-то атомарные задачи на вашем проекте – это всегда плохо, надо объяснить это Заказчику, если он рассматривает такой вариант.

8.       Оптом дешевле. Предложите сделать ещё какие-то работы. Да, общая стоимость работ вырастет, но цена конкретной доработки, которую вы обсуждаете, может быть снижена.

9.       Хватит тратить время на торги. Тоже скорее из серии манипуляций. Подсветите Заказчику, что чем больше времени вы тратите на торги, тем больше вы тратите на это трудозатрат, которые вообще-то должны быть оплачены (да, пресейл не бесплатный, но аккуратнее с донесением этой информации Заказчику, не все это адекватно могут воспринять). И ещё подсветите, что «время – деньги» и вместо того, чтобы уже выполнять эти работы, вы тратите время на обсуждение.

10.   Предложите скидку в следующих работах. Сейчас работаете по полной стоимости, но обещаете, что на будущие работы предложите скидку. Особенно хорошо сработает, если Заказчик давит на то, что он с вами нацелен на долгосрочное сотрудничество и обещает еще кучу проектов в будущем.

11.   Объясните Заказчику, что вы – коммерческая организация, и работать в минус вам невыгодно. Если вы сделаете скидку, то эти работы будут вам убыточны. Поэтому вам их проще вообще не делать, чем делать со скидкой.

12.   Перейдите на личности. Если Заказчик – человек эмпатичный, то можно обосновать ему, что ваш руководитель не похвалит вас за то, что вы сделаете скидку и вообще придёте к нему с такими вопросами. На вас будут ругаться и могут лишить премии, поэтому предложите Заказчику договориться как-то по-другому. Если никто вас премии за такое не лишит, то это будет манипуляцией чистой воды, поэтому вариант очень редко применимый.

 

Если договориться на полную стоимость не получилось, и скидку все-таки необходимо предоставить, то возможны следующие шаги:

13.   Предложите альтернативные варианты реализации. Часто бывает так, что решить одну задачу можно разными способами. Поэтому заранее продумайте, какие способы реализации есть, и, дайте Заказчику выбор. Может оказаться так, что Заказчик выберет самый «костыльный» вариант, лишь бы работало.

14.   Выкиньте «дорогие» требования. Часто бывает так, что какое-то требование очень сильно увеличивает сложность и стоимость работ. И может оказаться так, что Заказчику это требование не особо надо. Он может не понимать сложность этой работы, или озвучить требование, не до конца понимая, как оно будет работать и нужно ли оно вообще. Вы, как эксперты, должны понимать, какие работы можно выкинуть или изменить, чтобы это не повлияло на решение изначальной задачи, но позволило бы снизить стоимость.

15.   Предложите варианты с ограничениями. Если все 100% объема работ стоят 1000 руб, то предлагаем варианты: 1. 90% делаем за 900 руб, 2. 80% делаем за 800 руб, 3. 70% делаем за 700 руб и тд. Можно ещё объяснить заказчику, что доделать когда-то потом 10-20-30% будет стоить не 100-200-300 рублей, а как минимум 110-220-330 рублей, потому что сделать сразу дешевле.

Важно эти «выкинутые» 10-20-30% объема работ явно прописать в ограничениях, чтобы потом у Заказчика не было соблазна предъявить вам претензию, почему вы это не сделали.

От части это похоже на п.14. Но там мы говорим о том, что мы с Заказчиком договариваемся, какие требования можно выкинуть, чтобы получить меньшую стоимость работ. А в п.15 мы сами продумываем ограничения, и предлагаем Заказчику сразу несколько вариантов. Пусть выбирает, какие ограничения для него менее принципиальные.

16.   Разбейте задачу на несколько. Следствие предыдущего пункта. Но вы не просто часть работ переносите в ограничения, а сразу договариваетесь, что 70% работ делаете сейчас, а оставшиеся 30% работ оцениваете отдельно и закладываете в бюджет на следующий отчетный период. Тут для вас плюс в том, что, если вы понимаете, что с высокой долей вероятности, вы эти работы всё-таки будете делать, вы можете сразу при реализации 70% работ это учесть, чтобы потом было проще реализовать оставшиеся 30%.

17.   Обоснуйте Заказчику риски. Тут нужно быть очень аккуратными, потому что мы не можем сказать, что «мы здесь накинули 10%, потому что фиг его знает, сколько разработчик будет делать эту задачу – то ли 8 дней, то ли 12. А тут мы накинули 10%, потому что боимся, что вы выскажите кучу замечаний по результатам выполненных работ». Нужно найти те риски, которые можно озвучить Заказчику. Возможно, Заказчик часть из этих рисков сможет снять и тогда оценка будет меньше.

18.   Сделайте задачу «в лоб». Договоритесь с Заказчиком, что вы с ним согласовываете реализацию, делаете задачу так, как согласовали, и всё - не принимаете никакие замечания, не проводите ПСИ. Честно скажу, сами так ещё ни разу не пробовали. Но такой вариант применим, если Заказчик уверен, что требование однозначно трактуется, всем всё понятно и считает, что там нечего делать. Вы таким образом можете немного снизить стоимость, убрав заложенные риски на доработку по результатам демонстрации/ОПЭ. Пункт опасен тем, что Заказчик сможет потом переобуться и сказать, что это вообще не то, что он хотел, надо всё переделывать. И попробуйте доказать, что вы не закладывали доработку в стоимость.

19.   Сделайте скидку сейчас, но в будущие работы добавьте размер этой скидки. Пункт для нас менее комфортный, чем п. 10, но может быть применим для Заказчиков, с которыми есть история взаимоотношений и есть понимание, что будут ещё контракты в будущем.

20.   Попросите что-нибудь взамен. Если вы делаете скидку, пусть Заказчик упростит вам требование где-то в другом месте, в каком-то спорном вопросе примет вашу сторону или снимет какие-то ограничения. Это нормально, когда и вы уступаете, и Заказчик

 

Общие рекомендации:

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

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

23.   Если вы все-таки согласились уменьшить стоимость работ:

·         Имейте ввиду, что теперь Заказчик всегда будет просить скидку, так как будет знать, что из вас её можно «выбить».

·         Обязательно где-то зафиксируйте, что стоимость работ такая именно за счет того, что была предложена скидка (можно прям в КП это отобразить). 

·         Используйте это, как аргумент в следующей спорной ситуации: «ну вот мы вам в прошлый раз пошли на встречу, давайте вот здесь вы пойдете нам на встречу».

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

24.   Попробуйте узнать, почему Заказчик говорит, что дорого. Им кто-то пообещал дешевле? Или правда денег нет? Или у кого-то просто kpi на то, чтобы сбить цену от первоначального предложения Исполнителя (у нас были такие примеры). А может человек просто любит торговаться, такие тоже бывают. Если удастся получить такую информацию, вам будет легче подобрать аргументы.

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

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

Комментарии (46)


  1. Wesha
    26.06.2024 20:45
    +4

    Как в IT-проектах работать с возражением Заказчика «Почему так дорого?»

    "Делаем: быстро, дёшево, хорошо*
    (*) выберите любые 2"


    1. ilyagot Автор
      26.06.2024 20:45

      Звучит смешно, но в жизни не сработает)

      Если Заказчик хочет скидку, то делая долго и плохо, непонятно за счёт чего должно получиться дешевле)


      1. ITask
        26.06.2024 20:45

        Может и сработает, если хорошо управлять настроением заказчика


    1. amkartashov
      26.06.2024 20:45

      вообще-то "выберите любое одно". Если быстро, то дорого и плохо. Если дёшево, то долго и плохо. Если хорошо, до долго и дорого.


  1. newintellimouse
    26.06.2024 20:45
    +4

    «а чего так дорого, там же программист за день сделает»

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


    1. ilyagot Автор
      26.06.2024 20:45

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

      Не всегда Заказчик что-то говорит из "вредности", или манипулирует, или торгуется. Бывают случаи (и их не мало), что действительно не понимают.


      1. newintellimouse
        26.06.2024 20:45

        Вы предлагаете доказывать Заказчику, что если он достаточно заплатит, то вы достаточно поработаете?


  1. codecity
    26.06.2024 20:45

    Все самые умелые PM-ы, которых встречал, умели предложить наиболее дешевую цену, но потом плавно и как бы в добровольно-принудительном порядке повысить ее в несколько раз, когда отступать заказчику было уже некуда. Ключевое - все было как бы по согласию, т.е. без скандалов и судебных угроз. При этом проект то уже получен и что там говорили другие - не важно, может быть они были более правы в оценке, но это уже история.


    1. Wesha
      26.06.2024 20:45

      предложить наиболее дешевую цену, но потом плавно и как бы в добровольно-принудительном порядке повысить ее в несколько раз,

      Этот способ мошенничества называется Bait-and-switch.


      1. codecity
        26.06.2024 20:45

        Этот способ мошенничества называется Bait-and-switch.

        Вы же не товар покупаете - а сложное техническое решение, которое не возможно на 100% спрогнозировать и не возможно все предусмотреть.

        Конечно же потом получаете обоснование почему это должно стоить дороже, почему изначально не было учтено в требованиях и т.д.

        Главное что заказчик как бы переходит на сторону менеджера, понимает - нет ни скандала ни суда.

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

        Ценность такого высококлассного менеджера - не только в способности обоснованно поднять цену в n раз, но еще и определить заранее есть ли у заказчика деньги или он вообще выберет закрыть проект за неимением оных. Т.е. заранее поймет с кем можно иметь дело а с кем лучше не связываться.

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


        1. IvanPetrof
          26.06.2024 20:45
          +1

          По-русски это называется "развод лоха на деньги".


          1. codecity
            26.06.2024 20:45

            По-русски это называется "развод лоха на деньги".

            Вы посмотрите даже гос. проекты - практически всегда приходится увеличивать планируемый бюджет.

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

            Альтернатива - сидеть без проектов или долбить разработчиков, чтобы пахали как можно больше и дешевле.


            1. IvanPetrof
              26.06.2024 20:45

              Что интересно, вы меня процитировали, но не стали опровергать, а лишь аппелировали к распространённости явления))


              1. codecity
                26.06.2024 20:45

                а лишь аппелировали к распространённости явления))

                Есть вещи похожие. Вот, вы вложили в МММ и потеряли - мошенничество. А вложили в фирму и она обанкротилась, точно так потеряли - это не мошенничество. Хотя для вас итог один - и там и там потеряли деньги.

                Юридически и нравственно есть разница и опытный PM должен эту разницу обеспечить - не только юридически, но и нравственно.

                С другой стороны заказчик сам скупердяй и в конечном итоге ведь все равно не переплатит. Гораздо хуже когда проект потом не доведут до завершения и деньги будут просто выкинуты.


                1. Wesha
                  26.06.2024 20:45

                  Разница в намерениях. Преступление требует умысла. Если фирма придумала продукт, изо всех сил честно старалась-старалась продать, но не шмогла — это не мошенничество. А если даже и не пыталась, и вообще реального продукта не имела, аки то самоё МММ — это мошенничество. И часто юридические баталии идут как раз вокруг того "понимали ли хозяева, что они творят, или нет?"


                  1. codecity
                    26.06.2024 20:45

                    Разница в намерениях. Преступление требует умысла.

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


                    1. Wesha
                      26.06.2024 20:45

                      Ну вот у кого адвокаты убедительнее — те и выиграют!


                      1. codecity
                        26.06.2024 20:45

                        Ну если PM довел до суда - это уже проигрышь, не зависимо от решения суда.


        1. izuru_hitachi
          26.06.2024 20:45

          Не согласен. Если заключается договор на определённый результат за определённую сумму - эта сумма НИКАК не может поменяться, даже в меньшую сторону. Единственное исключение - дополнение к договору.

          Лично я считаю это мошенничеством, и тут можно привести простую аналогию: вы приехали на сезонную замену резины на зимнюю (вполне можно назвать технической задачей), говорите что вам нужно поменять резину. Спустя час выясняется, что они там посмотрели, резина не подходит по диаметру к диску, потому купили новый диск. Но к диск теперь уже не влезает, так как не хватает размера колёсной арки, меняют подвеску на более высокую, но и тут возникла проблема...

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

          Можно даже проще сформулировать - заказчик захотел вот такой проект, Вы с ним сторговались до устраивающей обоих суммы, согласовали работы и сроки. Всё, что и как Вы будете делать, и какие у Вас будут проблемы, заказчика не волнует в совершенной степени, так как всё согласовано и заключён договор. Единственное исключение - форсмажоры, в виде торнадо над головой.

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

          В третьих, если будут требовать оплаты в любом случае, вызову полицию (привлеку юристов), так как это явное нарушение законов РФ.


          1. codecity
            26.06.2024 20:45

            Если заключается договор на определённый результат за определённую сумму - эта сумма НИКАК не может поменяться, даже в меньшую сторону. Единственное исключение - дополнение к договору.

            Договор всегда гибкий, конечно и дополнения к договору или переход на почасовую оплату команды для упрощения.

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

            Лично я считаю это мошенничеством

            Нет, опытный менеджер так же и юридически должен сделать так, чтобы никаких претензий не возникло.

            вы приехали на сезонную замену резины на зимнюю 

            Простые однотипные действия - да, легко рассчитать. Сложные же технические решения - каждое уникально и всех нюансов не учесть. Здесь разработка и есть исследование.

            Даже банальный пример - ремонт квартиры. Редко кто вложится в ту сумму, которую сам же рассчитал для себя.


          1. JYE
            26.06.2024 20:45
            +1

            Скорее так:

            • Это автосервис? можете поменять колеса?

            • Да приезжайте, стоимость 1000 руб

            Начали домкратить машину, развалился пополам кузов.

            Далее по тексту


          1. losse_narmo
            26.06.2024 20:45
            +1

            Учитывая мой опыт скорее будет вот так:

            ТЗ: поменять зимнюю резину на летнюю, резину и автомобиль предоставляет Заказчик

            Просишь заказчика показать автомобиль и резину до заключения договора - "да там всё стандартно, что вы, автомобилей не видели? И вообще без NDA ничего не покажем!"

            Подписались, приезжает... фура у которой не 4 колеса, а 8.

            Резины на замену при этом 4 колеса (3 16-дюймых и одно 18-дюймовое)

            На любые замечания - вы уже подписались, никаких корректировок суммы и сроков не предусмотрено, а то пожалуемся куда следует и вы вообще не сможете в госконтрактах участвовать!


            1. Wesha
              26.06.2024 20:45

              Ну в данном случае шиномонтаж однозначно виноват — не прописал явно в контракте, что "выполняемые работы: поменять четыре 16-дюймовых колеса, на стандартной резине, машина модели Такой-То, расположение опорных площадок домкратов согласно ISO 12345, сухой массой не более X тонн и т.д и т.п." Именно для этого юристы и нужны — чтобы всё заранее предусмотреть.


              1. JYE
                26.06.2024 20:45

                Шиномонтаж - аналогия, причем сильно упрощенная. В ит зачастую приходится решать нестандартные задачи, когда , если брать аналогию шиномонтажа, заказчик даже не может сказать сколько колес у него и какое транспортное средство


                1. Wesha
                  26.06.2024 20:45

                  В таком случае "определить, что это вообще за хрень" — это предварительный этап работ!


                  1. JYE
                    26.06.2024 20:45

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


    1. ilyagot Автор
      26.06.2024 20:45
      +1

      Спорный способ.

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

      С чего бы вдруг Заказчик должен согласиться заплатить в N раз больше, чем у него выделен бюджет? Он сначала будет до победного ругаться, что вы должны сделать всё, что планировалось в проекте, и это ваша проблема, что вы не так посчитали и вылезли какие-то неожиданные риски. Ну а дальше Заказчику будет проще Закрыть проект и начать новый, чем соглашаться на "кабальные" условия Исполнителя, который в его глазах некомпетентен.


      1. codecity
        26.06.2024 20:45

        С чего бы вдруг Заказчик должен согласиться заплатить в N раз больше, чем у него выделен бюджет?

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

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


  1. Yukr
    26.06.2024 20:45
    +2

    ну, не знаю...

    Аппеляция к эмоциям заказчика - имхо последнее дело. Максимум, что допустимо в переговорах: вежливо спросить заказчика, какой марки у него машина ( а почему не "Ока"?) и не чёрно-белый ли он смотрит телевизор. Или почему его продукция не стоит 1 рубль за единицу. Мне помогало. Если заказчик после этого начинает орать - ну его нафиг, дальше будет хуже.

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


    1. ilyagot Автор
      26.06.2024 20:45

      Если под эмоциями вы имеете ввиду пункт 12, то соглашусь, что его можно использовать далеко не всегда.

      Но вообще во многих ситуациях - это рабочий способ. Смысл в том, что мы хоть и воспринимаем друг друга, как "Исполнителя" и "Заказчика", или как представителя фирмы, но по факту все мы люди (отставить шутки про КО). И если опуститься на уровень общения с человеком (а не разговаривать с ним, как с представителем фирмы Заказчика), то договориться о чем-то будет легче.


      1. Yukr
        26.06.2024 20:45

        Тем сложнее будет в случае просьб сделать что-то сделать задёшево, "по дружески."


  1. ozzyBLR
    26.06.2024 20:45

    Спасибо, большинству пунктов одобрительно киваю.


  1. Hivemaster
    26.06.2024 20:45

    Раньше на фрилансе можно было просто подождать, пока заказчик сэкономит через заказ студенту, а потом вернётся платить в два раза больше за переписывание навороченного. Как говорится, скупой платит дважды, дурак трижды, а лох всегда.


    1. ilyagot Автор
      26.06.2024 20:45
      +1

      А у нас и не на фрилансе есть такие кейсы)

      Заказчик ушёл к тому, у кого дешевле. А через год вернулся, "наевшись" дешёвого результата =)


  1. Batalmv
    26.06.2024 20:45
    +1

    По опыту, все равно у Заказчика есть бюджет, из которого он может очень редко выпрыгнуть. И если вы в него не попали, то вас так или иначе "отожмут", или просто найдут другого

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

    ---------------

    В целом выглядит как просто "дапм" памяти всей кейсов, которые автору удалось вспомнить, чем целостная статья с попыткой порефлексировать на тему :)


    1. ilyagot Автор
      26.06.2024 20:45

       все равно у Заказчика есть бюджет, из которого он может очень редко выпрыгнуть

      Ситуаций бывает масса. Это лишь одна из. Да, самая распространенная, но это не значит, что в такой ситуации надо ставить крест и ничего не делать.

      Вписываться можно либо снижая маржу, либо где-то уменьшая работы

      Способы рабочие, но не единственные.

      Пост написан для того, чтобы как раз и продемонстрировать все возможные варианты. Чем больше шаблонов, есть у менеджера, который пытается договориться, тем больше вероятность успеха. Я же не говорю, что все 25 пунктов надо использовать в каждом кейсе.


      1. Batalmv
        26.06.2024 20:45
        +1

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

        Но все таки "статья" должна претендовать на обобщения и выводы, а не просто "дамп" накопленных кейсов :)

        Да, самая распространенная, но это не значит, что в такой ситуации надо ставить крест и ничего не делать.

        В проектах, где его нет либо он минимален - ну интересно послушать кейс, как бы обошли ограничения бюджета?

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

        Остальное работает, когда вы в бюджете. Тогда можно прикинуться "птицей говоруном" и выходить на сумму

        -----------------------------------

        Есть еще случай - проект с откатом. Тогда все живет по своим правилам, если отказ важнее проекта


  1. IvanSTV
    26.06.2024 20:45

    Участвовал в процессах как со стороны заказчика, так и исполнителем. Огромная часть претензий заказчика по цене - это совершенно очевидные попытки поднять необоснованные деньги. Случаи из жизни:
    - требовали 50 тыр за операцию, которая по факту у разработчика заняла 5 минут (архитектор просто лично залез в код и поменял две строчки). Сколько б там ни получал архитектор, но 50 тыр явно завышенная цена

    - оценили пул доработок в 150 часов. Потому что шина, предоставленная исполнителем как коробочное готовое решение просто некорректно работала на типовом обмене по так и не объясненной заказчику причине. На вопрос - почему требуется доработка функционала, за который уже оплачено в виде покупки коробочного продукта, просто сказали, что "ну он же у вас не работает, вам надо чтобы работал"

    - фактически дублировали доработки одного продукта разным отделам заказчика, узнали случайно, перепутав документы на сетевом диске и открыв документ чужого отдела.

    - продавали как доработку штатную настройку продукта, просто при составлении требований никто не прочухал, что функционал возможно просто настроить

    - продали доработку документа, мотивировав сумму тем, что его надо проводить через все регистры. По факту из шести перечисленных регистров документ проводился только через один.

    - сравнение доработок показало, что время разработки ставилось от балды - одна и та же кнопка на вызов одной и той же формы из разных по содержанию, но типовых окон была оценена в разное количество часов, на вопрос почему сказали, что процессы разные. Был вызван собственный разработчик, который наглядно и вживую показал процесс добавление кнопок и ссылок и разъяснил, что в типовых процессах ничего разного нет, после чего пошел пересмотр вообще всего на предмет аналогичных кейсов. Хорошо, что выяснилось на согласовании доработок. 300 часов отмели только за счет этого.

    -взяли как доработку за полную цену фичу, которая уже есть в готовом виде и сделана для другого клиента, проговорился один из инженеров исполнителя. Юридически все чисто, а фактически заказчик испытал ощущение, что его и в других местах поимели.

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

    Так вот если мы хотим решить проблему - то может быть, исполнитель будет как-то аккуратно, обоснованно, честно и без попыток взять заказчика "на хапок" работать? Чтобы вопрос "почему так дорого" и не возникал. Для исполнителя так работать вообще-то проще, игра в открытую, постоянный фидбэк по статусам, и вот уже на вопрос о том, чтобы пересмотреть стоимость, потому что возникли какие-то затруднения и подводные камни со стороны заказчика нет вообще никаких возражений.

    Хотя не, это фантастика.
    Хотя не, это фантастика.


    1. newintellimouse
      26.06.2024 20:45

      - требовали 50 тыр за операцию, которая по факту у разработчика заняла 5 минут (архитектор просто лично залез в код и поменял две строчки). Сколько б там ни получал архитектор, но 50 тыр явно завышенная цена

      Анекдот про удар молотком

      - оценили пул доработок в 150 часов. Потому что шина, предоставленная исполнителем как коробочное готовое решение просто некорректно работала на типовом обмене по так и не объясненной заказчику причине. На вопрос - почему требуется доработка функционала, за который уже оплачено в виде покупки коробочного продукта, просто сказали, что "ну он же у вас не работает, вам надо чтобы работал"

      Предмет для досудебной претензии и возврата денег, если это возможно подтвердить

      - фактически дублировали доработки одного продукта разным отделам заказчика, узнали случайно, перепутав документы на сетевом диске и открыв документ чужого отдела.

      - продали доработку документа, мотивировав сумму тем, что его надо проводить через все регистры. По факту из шести перечисленных регистров документ проводился только через один.

      Кажется, что это тоже предмет для досудебной претензии и возврата денег за доработки в полном объёме, причём по факту — юротдел может крепко взять разработчика за разные интересные места и выкрутить их в пользу Заказчика на куда большую сумму

      - сравнение доработок показало, что время разработки ставилось от балды...

      Ленивый, трусливый и тупой ПМ Исполнителя. Работать с таким сплошное удовольствие для некоторых бизнес-акул — даже без юротдела можно взять себе в рабство Исполнителя и прогнуть его на кучу бесплатной работы. Для всех остальных — сигнал сменить Исполнителя. Если у них ПМ ленивый, трусливый и тупой, то что там в производстве творится — бог весть.

      -взяли как доработку за полную цену фичу, которая уже есть в готовом виде и сделана для другого клиента

      Проблем нет. Доработку можно не делать за эту цену. Но эта функциональность в дополнении к базовой стоит именно столько для всех.


      1. IvanSTV
        26.06.2024 20:45

        Анекдот про удар молотком

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

        Предмет для досудебной претензии и возврата денег, если это возможно подтвердить

        долго бодались, но продавили исправление проблемы за счет исполнителя. Исполнитель попытался в других местах на голом месте поповышать. Где-то это удалось, где-то нет.

        Ленивый, трусливый и тупой ПМ Исполнителя.

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

        Проблем нет. Доработку можно не делать за эту цену. Но эта функциональность в дополнении к базовой стоит именно столько для всех.

        нет. Цена доработки с нуля- это продаваемое время разработчика. Цена готового продукта, за разработку которого уже заплачено и прибыль получена - это чисто положить деньги в карман. Копипаст фактически бесплатная для производителя операция.


        1. newintellimouse
          26.06.2024 20:45

          Фактически там свелось к тому, чтобы вместо запятой поставить точку в двух местах и преобразовать тип.

          А заказ был оформлен именно так? В таком случае я на вашей стороне. Потому, что это вы (как компания) знали, куда стукнуть молотком.

          Копипаст фактически бесплатная для производителя операция.

          На этом стоит наша цифровая экономика. Ну то есть серьёзно — я понимаю вендора 1С, он разработал программный код для решения специфической проблемы одного клиента, видит эту проблему у других клиентов и понимает этого кода ценность. Не удивлюсь, если он понимает, что серьёзно недооценил коммерческий потенциал этой доработки в первый раз.

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


          1. IvanSTV
            26.06.2024 20:45

            и понимает этого кода ценность.

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

            В этом и проблема рыночной экономики - ей рулит жадный и недальновидный класс, которому причем совершенно неинтересен натуральный продукт, и который считает все показатели только в стоимостном, то есть, превращенном выражении. Потому и получается, что, например, Акселот (это про нее была история с продажей как новой разработки уже готового модуля), которая имеет пакет уже готового функционала, специально не включает его в коробочные решения, обрезает коробку до самого что ни на есть минимума, и тем самым объективно тормозит прогресс информационных систем. Ну, достало уже - в третьей подряд компании, где я работаю одна и та же история - берется WMS и пилятся напильником функции, которые общие практически для всех складов, и которые экономно и достаточно один раз запилить в коробочной версии (я уже не говорю про то, что зоопарк WMS на 1Сной платформе есть в принципе ненормальная вещь для разумно организованной экономики). Жадность предпринимателя потому что. Он ради того, чтобы стричь купоны, будет этот зоопарк, бардак и куцый функционал беречь, лелеять и взращивать. А зачем? чтобы купить себе какой-нибудь "бугагатти" или что там они покупают, чтобы попонтоваться перед такими же примитивными особями...


            1. newintellimouse
              26.06.2024 20:45

              Да. И это общий способ ведения дел в этой нашей экономике, начиная с громких случаев типа John Deere и Мартина Шкрели и заканчивая мелкими сервисными компаниями в глухой российской провинции. Если у него есть конкуренты, готовые предложить тоже самое за меньшие деньги и на более прозрачных условиях — заказчик уйдёт к ним, рано или поздно. И уходит.

              А всё остальное — вы не переломите. Потому что это законно, морально, не порицается и на каждое возражение заказчика, что «так дела не делаются» можно найти примеров обратного уже из его практики, какой бы она ни была.

              Особенно если заказчик — строитель, например.


  1. santjagocorkez
    26.06.2024 20:45

    -взяли как доработку за полную цену фичу, которая уже есть в готовом виде и сделана для другого клиента, проговорился один из инженеров исполнителя. Юридически все чисто, а фактически заказчик испытал ощущение, что его и в других местах поимели.

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


    1. IvanSTV
      26.06.2024 20:45

      еще раз для непонятливых. Чем отличается разработка под заказ от разработки на рынок?
      Разработка под заказ. Компания А заплатила за фичу. Полностью. Компания-исполнитель Б полностью взяла все деньги, продукт ПОЛНОСТЬЮ оплачен. Расходы окуплены, прибыль получена, фича передана, вопрос закрыт.

      Разработка на рынок. Компания Б разработала фичу и прикинула, что за полную стоимость ее мало кто сможет купить (оплатить полную стоимость разработки винды под силам только нескольким сотням компаний мира), соответственно, продажная цена разбивается на гипотетическое количество копий, которые твердо можно продать, и получается и небольшая сумма от каждого, и большое количество покупателей.


      Так вот, хитрозадые компании пытаются как разработку под заказ подсунуть разработку фактически на рынок по цене разработки под заказ. Это и легально, и нормальная практика, но но с точки зрения заказчика его хотят на...ть, потому он после такого финта доверять остальным ценам не будет тоже.
      Вот у меня когда активно брал заказы на всякое макрописание, накопился пул типичных модулей и программ, которые раз написанные, уже могли вставляться заказчику в продукт. Так вот цену я выставлял с учетом, что я этот код возьму чисто с диска, это честно перед заказчиком в целом (и, к вопросу, может быть им проверено, потому что и я такого рода код иногда выкладывал в открытый доступ, дописав до уровня универсального, либо заказчики были между собой знакомы) и давало возможность озвучить эти модули как бесплатные бонусы, а потому некоторые раз по 7 заказывали что-то, хотя я, бывало, сроки и динамил. Но в данном случае претензия именно в том, что если ты хочешь, чтобы заказчик у тебя остался (а для многих разработок поддержка и постоянные доработки важней и даже дороже разовой разработки пусть даже крупной), то так вести не комильфо. Адепты синицы в руках ценой неприятных ощущений в попе клиента имеют право на существование, но отзывы о них отвратительные. Мне такие адепты после года моего увольнения с одной из работ звонили как-то и просили поговорить с бывшими начальниками, порекомендовать их на новый проект, потому что они на старом залетели с таким вот жульничеством, и их поперли со всех проектов и поддержки.


      1. santjagocorkez
        26.06.2024 20:45

        А что делать с разработкой на рынок под заказ?

        Компания А заплатила за фичу. Полностью.

        Вот прям полностью? У заказчика есть прямой фид из системы учета расходов исполнителя? Заказчик скалькулировал поминутно ФОТ каждого сотрудника, вовлеченного в проект (даже если это вовлечение — результат слишком широкого To: в электронном письме от заказчика, которое разработчик был вынужден прочитать, чтобы понять, что его не касается), не забыл в этот ФОТ включить налоговые и неналоговые сопутствующие платежи, амортизацию используемого оборудования, арендные платежи пропорционально и так далее, не забыл накинуть коммерческий интерес (интеллектуальная собственность на решение), сверил со счетом, и точно с полным основанием имеет право утверждать: счет к оплате покрывал всё это?

        Я могу подсказать, как заказчику защититься от перепродажи решения, которое пишется по его заказу за полную цену:

        • исключительная и эксклюзивная лицензия на решение с правом получения выписки из отчетов аудиторов по данному решению

        • либо же передача исключительных прав на решение заказчику по условиям договора

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