Как уйти от Fixed Price?

Чем хорош Fixed PriceНедавно проводил корпоративный тренинг (привет Минской компании iTransition :)) и один из вопросов звучал так: «Как убедить Заказчика перейти с модели fixed price на Time&Material или Dedicated team?». Конечно же, этот вопрос волнует многих коллег, которые работают на такой модели, поэтому я попытался провести детальный анализ плюсов и минусов в Fixed Price модели  и как это можно использовать при работе с Заказчиками (убеждать их переходить или нет  – это ваш выбор).

Сначала я отвечу на свой любимый вопрос: «Какую проблему Заказчика решает модель fixed price? Почему так много Заказчиков пытается работать именно по этой модели?». И вот пришел к следующим аргументам:

  • Легко управлять бюджетом и cash-flow, можно выделить большую сумму (или чаще всего частями) и точно знать, когда ее заплатишь.
  • Заказчик не берет на себя риски проекта, все риски отданы команде.
  • Заказчик не попадает на «крючок» команды, которая пытается затянуть проект в своих интересах.
  • По мнению Заказчика, дедлайны и ответственность будут стимулировать команду. Они БУДУТ напрягаться, так как отвечают за результат (в том числе финансово).

Да и примеряя к себе (как к Заказчику) модель фиксированной цены, можно сказать, что модель  вас очень даже устраивает. Ведь когда вы вызываете такси, то хотели бы знать цену заранее чтобы быть уверенным, что таксист вас не обманет. Точно также точная цена является залогом любой сделки по покупке других простых услуг. Но почему же тогда модель фиксированной цены не нравится исполнителям в ИТ аутсорсинге? Почему другие отрасли научились жить с фиксированной ценой, а мы нет?

На самом деле ответ очень прост – большая степень неопределенности трудозатрат. Или перефразируя: множество разных рисков. И именно не желание отвечать за риски, то есть оплачивать оные, и является ключевым камнем преткновения в модели взаимодействия Fixed price. Разработчики не хотят отвечать за риски (они редко их учитывают, да и не видно их в самом начале проекта, когда надо подписать контракт), а Заказчик (наслышанный о том, что ИТ-проекты жгут бюджет, круче чем пионеры костер :)) не хочет «ввязываться» в то, что непонятно. В итоге, при разрешении этого конфликта обе стороны проигрывают…

Заказчик проигрывает:

  • Команда не будет делать «правильно», а будет делать по принципу: «лишь бы Заказчик принял». Они не заинтересованы в том, чтобы что-то было сделано хорошо. Ведь в их интересах сделать все проще, чтобы оставить время (читай деньги) на риски, которые они упустили.
  • По силу первой причины, дальнейший саппорт продукта будет намного сложнее. О производительности, надежности и стабильности говорит не стоит. Это не в списке интересов команды. То есть стоимость владения продуктом возрастает. Лирическое отступление: Именно проекты, сделанные по модели фиксированной цены, чаще всего вызывают дрожь у команд поддержки. Никто не пишет комментарии, структура и изящество кода лежит за рамками must have. Естественно, первое желание команды поддержки – это спросить: «Какие, хм… таланты, разрабатывали этот продукт? Его же НЕВОЗМОЖНО поддерживать!».
  • Команда НЕ будет решать проблему, а будет стараться работать «по спецификации». Зачем уточнять требования и сделать продукт лучше, если это уменьшит прибыль?
  • В интересах команды умолчать о потенциальных проблемах в продукте. Если это не очевидно и есть шанс, что сдача проекта пройдет, то Заказчик не узнает об этом. Психология избегания провала тут сильнее, чем желание сделать продукт хорошо :)
  • В случае проблем на проекте будет потрачено огромное количество времени на тщательный анализ переписки, обещаний, документации. Все это время могло бы быть потрачено на улучшение продукта. Иногда даже время на переговоры превышают время на доработку системы.

Команда проигрывает:

  • Если по вине команды (или отдельного человека) на этапе планирования что-то было пропущено, то компания-исполнитель может понести серьезные финансовые потери (вплоть до банкротства). Каждый проект – риск для команды и компании.
  • Когда человек вынужден идти на компромиссы с внутренним пониманием качества, то резко снижается мотивация выполнять этот продукт. А значит чем беднее качество, тем хуже и хуже начинаем писать код.
  • Как только прибыль от проекта выходит на 0 (или приближается к 0) команда начинаем «замазывать дыры», а не лечить проблемы (баги), что еще «быстрее» ухудшает качество продукта

Как результат, мы получаем, что Fixed price – это всегда компромисс денег и качества. Цель Заказчика – экономить, на что команда может ответить только одним – минимально приемлемым качеством продукта.

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

  1. Если создается продукт, который необходимо будет поддерживать и развивать в будущем, то фиксированная цена сделает эту поддержку максимально дорогой.
  2. Короткие релизы продукта «потенциально готового к поставке» (привет Скраму), могут четко показывать прогресс и оперативно подстраивать продукт.
  3. Оплата по результатам коротких релизов (некий специфический Time&Matertial) убирают риск того, что Заказчик садится «на крючок». Исходный код  и программа сразу же находится в полном доступе Заказчика.
  4. Дедлайны могут стимулировать команду, но тайм-боксы в Скраме  или короткие релизы выступают даже более лучшими мотиваторами.
  5. У команды нет предпосылок скрывать информацию о возможных проблемах продукта. Они даже с радостью это будут делать. А Заказчик сможет принимать взвешенные решения по поводу того, нужны ли эти улучшения или нет.

Вывод: Я не знаю, достаточны ли аргументы для перехода с модели Fixed Price на другие, но все выводы говорят о том, что можно найти разумный компромисс. Главным аргументом должно выступать то, что Заказчик не хочет “shoot himself in a leg” («прострелить себе ногу») и выпустить на рынок продукт не самого лучшего качества. Команде же со своей стороны придется ДОКАЗАТЬ, что все деньги, которые инвестирует Заказчик идут ТОЛЬКО на то, чтобы сделать проект лучше и быстрее. Только тогда возможен переход на другую модель.

P.S. Вот дописал пост и понял, что Fixed Price – отражение высшей степени недоверия со стороны Клиента (опять моя любимая матрица «Прозрачность-Доверие» в деле).

P.S.S. Идеи по поводу топика очень приветствуется. Есть же в мире еще много людей, которые пишут по модели с фиксированной ценой? :)

Dec 16th, 2010
  1. Антон Кан
    Dec 16th, 2010 at 09:03 | #1

    Готов подписаться под каждым словом (только про “крючок” не совсем убедительно для заказчика).

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

    Подумаю ещё и, может быть, предложу какие-нибудь дополнения.

  2. Nadya Knysh
    Dec 16th, 2010 at 09:23 | #2

    В целом, все верно.. нюанс вот в чем:
    - если заказчик сам прочитает эту статью, он, вероятно, в это поверит (либо ужесточит приемку :)).
    - а если к нему придем мы со словами: “если работаем по fixed price, то проект будет плох, а если по T&M/DedicatedTeam, то будет тебе счастье”, он вполне может усомниться в нашей компетенции и намерениях.

    так что осталось дать заказчику ссылку на твой блог :)

  3. Dec 16th, 2010 at 11:34 | #3

    to Nadya Knysh
    100% согласен с комментариями. Обратный эффект – ужесточение приемки, но он это может делать и так, например на основании своего предудыщего опыта.

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

  4. Dec 17th, 2010 at 08:29 | #4

    Коллеги, давайте уточним – мы говорим про fixed price или fixed all? Это важно, так как при зафиксированном бюджете, но “плавающем” scope тот же Скрам как раз прекрасно работает. А вот именно в fixed all контрактах как раз справедливо все то, о чем написано в статье.

    В дополнение, fixed all контракты порождает не только недоверие, но и бюрократизм (особенно характерно для больших корпораций)

  5. Dec 17th, 2010 at 14:26 | #5

    To Dmytro L.
    Дима, в данном посте имел ввиду Fixed all.
    Есть такая ниша большая проектов, при которых заказчик подписывается на все фиксированное. Только в таком случае он готов платить.
    А вот идея с плавающим scope при фиксед прайс в общем-то хороша. Можно предлагать. ХОтя это мало чем отличается от time&material… (просто на время покупают).

  6. Dec 17th, 2010 at 14:26 | #6

    По-моему, риски – лишь одна из причин того, почему в IT так туго с fixed price/all, причем не факт что основная. Я бы сказал, что основная причина – это гибкость программных продуктов или другими словами возможность вносить в них изменения практически на любой стадии (до разумного предела, конечно). При создании материальных ценностей изменения вносить либо невозможно, либо очень сложно, поэтому примеры из “реального” мира здесь и не катят :), а вот при разработке софта – запросто. А причина изменений требований – это не только недоработка аналитика/лида, но зачастую также и непонимание клиента, что ему нужно на самом деле. Это риск, который клиент и подрядчик должны разделять между собой, и который нужно обсуждать до начала проекта и прописывать в контрактах.

    С изменениями требований и рисками можно бороться по-разному. В проектах, работающих по T&M или dedicated team схемах – это просто, все мы знаем как это делать. В fixed price проектах нужно оставлять свободный scope, как уже сказал Дима. В fixed all проекты … лучше в принципе не попадать :) А если серьезно, то единственный шанс успешно завершить подобный проект – подробно специфицировать требования в самом начале (никакого agile, сорри), постараться не обложаться с оценкой + заложить в нее риски.

    Хотя описанная альтернатива движения fixed price-итерациями тоже очень хорошо работает. Мы ее используем для некоторых клиентов, с которыми еще не построено доверие. Насчет доверия ты прав 100%.

    Да и в целом, со всем остальным соглашусь. Отлично все расписал. Перевести бы на английский и можно будет ссылку клиентам отправлять. Для самообразования :)

  7. Dec 17th, 2010 at 15:49 | #7

    @Merle никакого agile, сорри

    Да, в плане “гибкости” требований никакого аджайла, конечно, в сценарии fixed all не будет. Что не мешает применять прочие agile-практики для своевременного выявления и снижения рисков.

    Ну и еще один, по-моему, неупомянутый минус fixed-all для заказчика – в таком сценарии буферы что по бюджету, что по графику любой вменяемый вендор заложит “от души”. Исключение – тендеры, которые вообще отдельная грустная песня.

  8. Dec 17th, 2010 at 16:14 | #8

    >> Что не мешает применять прочие agile-практики для своевременного выявления и снижения рисков.

    Согласен :)

  9. Dec 17th, 2010 at 20:55 | #9

    2 Merle

    По-моему, риски – лишь одна из причин того, почему в IT так туго с fixed price/all, причем не факт что основная. Я бы сказал, что основная причина – это гибкость программных продуктов или другими словами возможность вносить в них изменения практически на любой стадии (до разумного предела, конечно).

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

  10. Dec 17th, 2010 at 21:40 | #10

    Не совсем понял. Гибкость продукта – это причина рисков? По-моему, это свойство любого приложения. На то он и софт.

    Возможное изменение требований – это риск. И вот здесь мы уже можем что-то с этим делать: проводить более детальный анализ, оценивать вероятность с точки зрения детальности требований (то, что ты сказал), ставить буферы, подписывать строгие контракты, или использовать agile и T&M, чтобы для нас этот риск вообще свелся практически к нулю.

    Но это мы уже начали спорить о терминах. В целом смысл понятен, и статья очень хорошая :)

  11. Dec 20th, 2010 at 10:56 | #11

    мой опыт говорит, что убеждать переходить не надо :) если вы хорошо выполняете проект, то потом оно само собой приходит к тому, что “блин, задолбали меня эти контракты и планы! давайте я вам буду платить раз в 2 недели. ок?”

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

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

  12. Dec 20th, 2010 at 16:10 | #12

    @Сотона “где заказчик настолько молодой __бизнесмен__”

    А вот, кстати, еще один очень интересный момент! С заказчиком-бизнесменом можно и нужно говорить о разделении рисков и фидбэке, но лично мой опыт говорит о том, что такие заказчики (вернее, прямой доступ к ним) – редкость. Гораздо чаще мы как аутсорсеры имеем дело с менеджерами среднего звена, которым, пардон, прикрыть свою задницу и получить бонус гораздо важнее, чем сделать успешный С ТОЧКИ ЗРЕНИЯ БИЗНЕСА проект.

  13. Dec 20th, 2010 at 18:03 | #13

    угу. с такими я и говорю о том, что “если ты хочешь прикрыть задницу, то и я хочу – давай договариваться…”

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

    **основное правило** – это всё надо обговаривать _до_ реализации какого-либо риска, а лучше ещё до начала кодирования, иначе выглядит не как прозорливость, а как отмазка.

  14. Dec 21st, 2010 at 19:38 | #14

    to COTOHA

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

    Полностью поддерживаю Диму!
    Я вот тоже так думал… но оказывается мир намного сложнее. Бизнессмен готов платить за сервис и риски. Но есть огромный пласт проектов, которые делают не для бизнесменов, а для обывателей. Конечно бюджеты редко бывают шестизначными, но зато таких Заказчиков очень много.

  15. Dec 21st, 2010 at 20:44 | #15

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

    а обыватели… ну не видел я в “обывательских” проектах реализации таких рисков, которые бы их делали непривлекательными для команды.

    проект до 3х-4х человекомесяцев (средне-обывательский проект в моём понимании) вполне поддаётся экспертной оценке, в которую он потом и вкладывается +-20% при адекватном подходе (ну лениться-то не надо), что абсолютно нормально.

    проект выше требует или прототипа, который позволит завоевать доверие и\или проверить адекватность заказчика = минимизировать будущие риски или не надо соглашаться – заказчиков же много :)

  16. SanSem
    Jan 24th, 2011 at 23:07 | #16

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

  17. PMP
    Feb 7th, 2011 at 13:43 | #17

    Я думаю, что проблема fixed price вовсе не в fixed price, а в кривости рук ПМа.

    Зачем идти на компромисс с качеством? Если у Вас безграмотно построен процесс, непонятно как измеряется качество, и не пишутся комменты в коде, то в проекте, скорее всего, отсутствуют ключевые стандарты, метрики – количественные показатели качества Вашей работы и работы команды (как Вы идете по графику, с каким качеством управляете проектом, насколько код стабилен и пр.), в software development plan (если он вообще есть или его аналог) нет ни слова о комментах в коде PHP, которые собирает phpDocumentor (например). Как об этом узнает разработчик, и, тем более, разберется в Вашем коде клиент? Тем более, если большинство Ваших договоренностей с командой и клиентом в устной форме (т.е. они отсутствуют).

    А модель цены здесь совершенно не причем. Да – fixed price более строгий вариант, более экстремальный, если хотите. Но ведь у клиента может быть достаточно ограниченный бюджет. Ведь никто не спорит с тем, что нужно предлагать “как лучше”, но важно посоветоваться с клиентом, – действительно ли это будет “лучше” для него. Очень часто команды тратят бюджет на всякие “улучшения”, не выполнив того, что описано в спецификации требований. Сколько в итоге потребуется средств для того, чтоб довести проект до ума (в том числе, с “улучшениями”)? Почему вдруг Вы решили, что заказчик готов бесконечно платить за Ваши бесконечные апгрейды, которые ПО-ВАШЕМУ мнению представляют ценность для проекта? Любая гибкость тоже должна иметь предел, особенно в требованиях, которые не могут быть идеальными. Клиенту важно показать, что мы готовы сделать за средства, которые находятся в рамках бюджета. И от этого уже отталкиваться – хочешь больше и лучше, плати больше. Это здорово, что больше денег придет в компанию, но однажды клиенту надоест платить за Ваши прихоти, и он откажется от Ваших услуг, а компания потеряет то, что могла получить в рамках зафиксированного Cost.
    Если это change request`ы, за которые клиент готов платить при контролируемом бюджете и сроках – это другое дело.

    IMHO хороший ПМ должен уметь работать в разных условиях, а не перекладывать собственную некомпетентность на fixed price. Тогда и качество будет приемлимым. А для начинающего ПМа fixed price – наиболее подходящая модель, в которой можно научиться ценить деньги и время. А время, как известно – деньги.

  18. Feb 7th, 2011 at 14:46 | #18

    @ PMP
    Я полностью согласен с большинством выводов. И предпосылки правильные и выводы. О том, что много ПМов не умеют правильно трекать изменения и потом это перекладывают на других.

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

    Как мне кажется в этой цепочке ПРАВИЛЬНЫХ комментариев есть только одна неправильная предпосылка, которая и смазывает всю правильность. При описанном подходе Вы исходите из предположения, что изначальная оценка (estimate) была правильной. Если это так, то вся вина за “кривой код” и неправильную торговлю с клиентом лежит на ПМе и Лидах. А вот если оценка была неправильной (а это очень реально в нашей индустрии), то все становится печально….В добавок к этому, если попадется клиент типа “кидала”, то он бесконечными реквестами вас загонит ниже плинтуса.

  19. PMP
    Feb 7th, 2011 at 15:54 | #19

    @ Сергей

    А кто, по-Вашему, отвечает за “неправильную” оценку проекта?
    Не ПМ случайно вместе с командой? :)
    Бывает, что клиент указывает допустимые рамки бюджета (еще в RFP), но не может ведь он Вас загнать в этот бюджет – если Ваши оценки превышают бюджет (в часах, или долларах – в зависимости от того, с чем Вы работаете), то надо сразу об этом заявить. Если он согласен – работаем дальше. Нет – до свидания. Или компромисс. Но пропускать этот момент нельзя. То же самое касается и сроков, хотя о них здесь речь и не идет.

    Идеальных проектов не бывает. Мы можем лишь свести возможные риски к минимуму, выбрав стратегии.

    В данном случае, для этого, например, есть ROM estimate, – достаточно грубая начальная оценка, чтоб было от чего отталкиваться. Также есть несколько методов оценки точной (three-point-estimate, parametric etc etс)- когда сформированы требования и архитектура. Я, например, оценивал одни и те же требования силами разных разработчиков (минимум трёх), а также компаниями-подрядчиками. Таким образом можно выбрать оптимальные цены, сроки. И снижается риск завышения оценки – если три оценщика говорят, что это стоит 50 часов (в среднем) их работы, а четвёртый – 120, то, видимо, четвёртый не понимает задачу, либо переоценивает, либо пытается включить в оценку какие-то другие виды работ. После этого оцениваете ключевые риски + время на проджект менеджмент (у меня обычно получалось до +40% от скоупа). Формируете WBS, чтоб ничего не упустить из виду. Как-то так.

    Что касается качества, то вот здесь максимально все зависит от грамотной постановки задачи (как и во всем остальном) Вами, а также от готовности клиента платить за это качество.

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

    Печально всё может быть только в случае очень больших отклонений. Работал и с большими проектами, и с маленькими – могу сказать, что большие отклонения возможны только в случае неучтения очень критических рисков (это факап ПМа, но если Вы опытный ПМ, то это вряд ли произойдет), либо из-за халатной оценки. Даже если Вы не поклонник fixed price, и за риски отвечать не любите (но как “продуманный” ПМ все равно ими занимаетсь :)), то с источниками рисков/рисками/стратегиями все должно быть в порядке. Если только это не тот самый cutting edge в самой новой технологии, с которой никто толком не работал до Вас. В конце концов, некоторые риски можно и нужно трансферить на клиента – я же не могу отвечать за его оборудование (ляжет сервак его в самый неподходящий момент, потребуются деньги/время на восстановление), за квалификацию персонала (админы etc) с его стороны, т.к. он вне команды. В общем, подавляющее большинство рисков можно учесть.

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

    С мотивацией для клиента я полностью согласиться не могу – мухи и котлеты здесь вместе. А вообще с Вами я согласен – безусловно, Dedicated Teams гораздо комфортнее, и в первую очередь для команды :). Но пока не все компании могут выбирать себе клиентов, приходится работать на условиях, которые приемлимы для кастомеров – не все ведь могут предложить шесть нулей в контракте.

  20. PMP
    Feb 7th, 2011 at 16:14 | #20

    Тут ещё тема рисков в fixed price упоминалась. Мне приходилось общаться с ПМами, которые хорошо понимали поведение функции в джаве, но при этом не знали ничего о рисках и не умели работать с ними, не умели работать с изменениями. Все они были уверены, что успех проекта зависит от их знаний технологии программирования (“а все остальное – туфта”). IMHO fixed price проекты – это отличная практика для них. Заодно разберутся в том, что проджект менеджмент – это отдельная область знаний.

  21. Aug 3rd, 2011 at 13:52 | #21

    Да уж, мне есть что сказать на эту тему.
    Есть на самом деле один хороший честный аргумент против фиксед-прайса. Потому что аргумент “качество будет ниже” – не аргумент. Качество должно быть всегда высоким. Иначе надо уходить с этого рынка.

    (Side note: внутри нашей компании мы все проекты, даже если они dedicated или t&m, стараемся делать как fixed price. потому что на самом деле-то этот прайс всегда фиксед. Не самим заказчиком, так рынком – заказчик, потратив слишком много денег на разработку, обанкротится, и у нас не будет больше заказчика. Fixed price дисциплинирует команду. Я соглашусь с тем, что качество теоретически может упасть, но при высоких требованиях к качеству, заложенных в бюджет, оно не упадет.)

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

    Мы обычно примерно на 3ю фазу в случае fixed price проекта говорим клиенту:
    - Дорогой клиент, поскольку твой проект fixed price, то скорее всего начать твою третью фазу мы сможем аж через 3 месяца, и не 5ю, а только 3мя девелоперами. Потому что сорри, мир идет вперед, мы получаем новые проекты, и поскольку с твоей стороны особого коммита на долговременное сотрудничество нет, то мы переводим людей туда, куда нам выгодно. И еще – скорее всего мы не сможем сохранить при fixed price на эту фазу именно тех людей, которые делали тебе 1 и 2 фазы. Конечно, мы очень постараемся, но обычно самых лучших специалистов наши клиенты оплачивают по dedicated схеме.

    При этом все сказанное должно быть, естественно, правдой.

    Такие вещи, по нашему опыту, в 80% приводят к переходу на dedicated после 6-8 месяцев работы, а в 20% случаев приводят к уходу клиента (и может быть слава богу).

    Это был взгляд Sales Manager на приведенную проблему :).

Show Hide 1 trackbacks

Leave a comment