serge_gorshkov


Сергей Горшков - о бизнесе в сфере ИТ

о семантической интеграции, программировании, управлении...


Previous Entry Share Next Entry
Что покупает клиент - продукт или часы?
serge_gorshkov
Обсуждение предыдущего поста, «Сколько стоит час программиста», приводит к еще одному серьезному вопросу экономики заказной разработки программного обеспечения – что покупает клиент? И заказчику, и подрядчику важно понять, что является предметом сделки – работы или их результат (рабочие часы или продукт)?
Менеджер по продажам, обсуждая будущий проект с заказчиком, предлагает ему продукт. То есть, менеджер описывает инструмент, получив который, заказчик сможет улучшить свои бизнес-процессы. Именно так, по результату, и оценивает заказчик предлагаемую сделку. Затем наступает очередь проектирования, и вот тут происходит некий «фазовый переход»: менеджер проекта, обосновывая заказчику цену, говорит о том, что она зависит от часов, которые разработчики потратят на создание продукта. Причем, каждое новое пожелание заказчика оценивается в часах, и увеличивает цену проекта. У заказчика создается впечатление, что он покупает часы. Многие заказчики в этот момент начинают возмущаться и говорить примерно следующее: «вы обещали решить мои проблемы примерно за такие-то деньги, я согласился купить продукт; вот и решайте, мне без разницы, сколько трудовых усилий вы на это затратите».



Точку зрения заказчика можно понять. Но можно понять и точку зрения подрядчика. Для этого лучше всего воспользоваться аналогией со строительной сферой. У человека проблема – ему нужен дом. Он заказывает дом архитектору и строителям, описывая пожелания примерно так: «мне нужен уютный, удобный, просторный двухэтажный дом с двумя спальнями, большой гостиной, и гаражом». Архитектор проектирует, прораб составляет смету, заказчик все это утверждает, дом строится. Потом заказчик говорит: «а я хочу еще мансарду!». Архитектор с прорабом, конечно, ему отвечают, что мансарду вы не заказывали-с. Заказчик в гневе: «Я ведь просил уютный и удобный дом! А без мансарды мне неуютно и неудобно! Вы мне обещали уютный и удобный дом за N k$, вот и делайте!».
Конечно, строители не станут бесплатно достраивать мансарду. А вот программистов часто на полном серьезе пытаются заставить заниматься чем-то подобным. В свете предыдущего поста, из которого следует, что час работ для подрядчика далеко не бесплатен, понятно, что если подрядчик на это согласится – он понесет убытки, и весь проект может выйти «в минус». Поскольку подрядчик – коммерческая организация, он так делать не будет.

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

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

Возникает вопрос – как решить проблему фундаментальным образом, чтобы не попадать в такие, заведомо проигрышные, ситуации? В нашей практике встречались два варианта пути к решению проблемы.

Первый – добиться от заказчика понимания того, что, подписывая ТЗ и приложение с ценой работ, он приобретает именно тот продукт, который описан в ТЗ, и любые изменения будут стоить денег. Такой способ объяснения не требует «фазового перехода», мы остаемся в терминах продукта: заказчику интуитивно понятно, что машина с шестью подушками безопасности стоит больше, чем с двумя, и платить за дополнительные возможности продукта он согласен. Если ему не понятно и он не согласен - тогда, конечно, лучше просто не работать. Главная проблема состоит в том, чтобы убедиться, что все это действительно дошло до сознания заказчика; многие склонны соглашаться «на авось», не желая продираться сквозь дебри ТЗ (пусть там даже фактически нарисован прототип продукта, в картинках), и полагая, что в случае возникновения разногласий «как-нибудь договоримся». Главная ошибка, которую можно допустить при таком подходе – это включение в ТЗ декларации целей и задач продукта: в будущем заказчик сможет подвести под эти цели и задачи практически любые усовершенствования, которые ему вздумается сделать в продукте.
Короче говоря, чаще всего мы работаем именно так, но избавиться от рисков при таком подходе не удается, и вообще путь непростой.
Особенно печально работать таким способом с крупными компаниями, у которых внедрен процесс бюджетирования. Перед заключением договора им обязательно нужна предельная оценка стоимости проекта, которую закладывают в бюджет; как правило, выбить что-нибудь сверх этого бюджета будет потом практически нереально. При этом, чем крупнее компания, тем ленивее сотрудники, поэтому шансы того, что заказчик не будет вникать в ТЗ, а при приемке станет хотеть странного, многократно повышаются. Что же делать? Как это ни печально – умножать часы на два. А то и на три. Страхуясь, таким образом, от рисков.

Второй вариант – пересказать заказчику содержание двух моих постов, и убедить его в том, что он покупает, в конечном счете, рабочие часы. Далеко не со всеми заказчиками этот номер проходит, но наиболее «продвинутых» уговорить можно. Тогда можно проявить более гибкий подход в разработке (практически скрам!). То есть, не пытаться заранее написать точное ТЗ на продукт, а наметить себе цель и идти к ней, выбирая наиболее подходящие средства по ходу процесса. Самый неприятный момент наступает в конце месяца, когда заказчику презентуется очередная расшифровка выполненных работ, и цена. Тут начинается торговля… я не видел еще ни одного заказчика, который не начал бы торговаться над такой ведомостью. Аргументы могут быть самыми разнообразными: «почему мы должны оплачивать вот эту работу, если потом мы все равно переписали этот кусок по-другому?»; «почему ваш программист занимался такой ерундой восемь часов?»; «похожая функция уже была в позапрошлом модуле, почему я должен второй раз платить за то же самое?» И так далее, до бесконечности.
В результате, и здесь возникает соблазн не надеяться на адекватность заказчика и собственную способность торговаться, а заложить в часы некий запас – а затем со спокойной душой сделать скидку.

Все это, согласитесь, как-то неправильно. Хочется придумать такой способ, при котором подрядчик не будет нести рисков и получит справедливую прибыль, а заказчик не переплатит лишнего, но будет четко понимать, сколько и за что он заплатил.
Можно рассчитывать на идеального заказчика, который поймет ТЗ, и не будет потом требовать бесплатных доработок. Можно надеяться на другого идеального заказчика, который проникнут идеологией scrum’а, и не будет торговаться над почасовыми перечнями работ, выполненными по его пожеланиям. На самом деле, и то, и другое – сферический конь в вакууме, такого не бывает.
Единственный реальный выход состоит в том, чтобы убедить заказчика, что:
  • ТЗ – аналог сметы в строительстве. Это обязывающий документ и для заказчика (который тем самым подтверждает, что ему нужен именно такой результат, воплощенный в продукте), и для подрядчика (который берется достичь этого результата за указанное время и цену).
  • Любые дополнительные «хотелки» - дополнительны, то есть, будут оцениваться в часах отдельно.Мы не обманываем заказчика с рабочими часами, и все сотрудники действительно выполняют поставленные задачи в минимально возможные сроки (это на самом деле так, других не держим).
С бОльшей частью клиентов такой подход срабатывает, хотя нужна определенная «воспитательная работа». В результате, процесс внедрения информационной системы разбивается на две составляющие: реализация крупных функциональных блоков по заранее написанным ТЗ (разработка), и их дальнейшее совершенствование по пожеланиям заказчика (поддержка). В разработке стоимость определяется до начала выполнения работ, в соответствии с оценкой трудоемкости ТЗ, в поддержке – по факту выполнения работ. Соотношение между разработкой и поддержкой может быть самым разным: иногда бОльшая часть кода системы создается именно в рамках поддержки.

В работе с теми заказчиками, с которыми удалось достичь такой гармонии – мы просто счастливы :). Я убежден, что такой подход (в наших условиях, разумеется) в наибольшей степени отвечает интересам и заказчика, и подрядчика.




  • 1
Одна проблемы: мы - в целом и так это понимаем. А вот как донести эти мысли до Заказчика? Я бы, на месте Заказчика, эту статью читать не стал. Надо как-то это популяризировать.

В виде эксперимента дал одному заказчику ссылку на прошлый пост. Ничего - прочитал :)
Вопросы по стоимости часа после этого были сняты.
Как можно широковещательно популяризировать такие мысли, кроме как через ЖЖ и интернет в целом, даже не знаю.

Нет, текст-то очень хороший. Но для специалистов. Как СНиП. Кто ж из Заказчиков СНиПы читает?
Предложите в ФинДир или Финансовую газету - очень даже может быть, что прокатит. А нам всем - польза :).

Курить гугл "requirements engineering iso 9000". Там есть формы, по которым делается ТЗ, плюс к тому есть много рекомендаций. ТЗ должно быть написано таким образом, что бы всякая возможность двоякого понимания исключалась.
То есть - "дом включает такие то комнаты, такого то размера, стены под покраску такой то краской, наличие дополнительных ХХ в проекте не предусмотрено". Внизу список хх.
Есть масса литературы, которая учит эстимейтингу, плюс реквайрментс-инжинерингу. Включая так же и психологические аспекты. Опять же, есть готовые формы.
С самого начала клинету должно быть показано, сколько стоит продукт, а сколько - чейндж реквест. И что является дефектом, недоделкой или CR.
Так же полезно примерно показать стоимость внесения новых фичь в зависимость от стадии проекта.
В общем, нужно курить книги, и не пользоваться только своим опытом.

Покурю с удовольствием :)

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

И попробуйте объяснить заказчику этого самого дома, что такое iso. максимум что он вспомнит - это так называется одна из функций в фотоаппарате.

А всякие "эстимейтинги" "реквайрментс-инжинеринги" несмотря на всю их полезность во многих проектах в русском транслите звучат чудовищно.

К сожалению, мне известны единицы домов, построенные компаниями, в которых по настоящему работает ISO 900X.

ну да, все буржуи дураки, а авто Лада куда круче, нежели Порше и БМВ, правда?
Там материалов, в этом стандарте - на небольшую методичку. А методические пособия с формами можно перевести на русский и использовать как шаблоны.
Кстати, а почему стандартизация не нужна? Может быть, будем каждый свои гайки-болты точить, своих размеров?
Есть очень скромных размеров стандарт, есть разжеванная - очень до состояния положить в в беззубый рот - методология, есть базовые принципы, на которых необходимо строить коммуникацию заказчик-исполнитель.
Эстимейтинг - это то, чем уважаемый господин Горшков пытается заниматся - и видно, что он пытается исходить из своего опыта, в основном. А есть - опять же стандартные приемы.
Мне все равно, как писать. Потому что для меня это вообще будет не "requirements engineering", а вовсе "Anforderungsmanagement". А как написано - всем по барабану. Понятно? Ну и славненько.
По поводу скрама и его использования - есть такая вещь, как "Ralph Stacey's Agreement & Certainty Matrix". С ее помощью можно визуально оценить, подходит ли скрам к вашему проекту или нет. Так вот, чем меньше заказчик представляет свои требования, тем больше проекту подходит скрам.

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

Про стандартизацию. У нас есть тест, который мы даем заполнить программистам перед собеседованием. Там в основном технические вопросы, но есть и блок "ценностные установки". В нем есть вопрос о стандартах - что с ними следует делать? Дано несколько вариантов, в том числе - "слепо им следовать" или "игнорировать как далекие от жизни". А правильный ответ, который мы хотим услышать от будущих сотрудников, сформулирован как-то так: "игнорировать пустой формализм, и использовать все здравое, что в них заложено".
В стандартах иногда закладываются совершенно бредовые и холиварные вещи. Чудесный пример - война вокруг оператора goto, который несколько лет считался корнем всего мирового зла, и был исключен из языка PHP, а потом здравый смысл все-таки возобладал, и его вернули. С другой стороны, стандарт - это сумма опыта, и бОльшую часть этого опыта можно и нужно использовать.
Ну а лучший опыт, конечно же - свой собственный! :)

Что касается проектов высокой сложности - тут с вами соглашусь. Но у нас, все-таки, проекты попроще. Больше 10 человеко-месяцев за раз не встречалось.

Навеяло... "клиент покупает не сверло, а дырку в стене".

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


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


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

Узнал о журнале через два-три репоста, заинтересовало. Почитаю на досуге. Не удивляйтесь, если вдруг получите комментарий к записи полугодичной давности )

p.s. у меня в блоге вы вряд ли найдете профессиональные посты - там скорее отдушина от работы.

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

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

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

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

  • 1
?

Log in

No account? Create an account