Как конкурировать на скудном проекте, чтобы избежать командного марша смерти?
Я оцениваю время и стоимость полусложного программного решения, у которого нет особых требований примерно к 75% функций. Я все еще хотел бы сделать как можно более точную оценку, получая дополнительные данные от клиента. По-прежнему будут существовать части, которые могут оказаться не в состоянии развиваться, поскольку слишком много зависимостей от других продуктов / технологий и отсутствие определения. У меня также очень плотный график, чтобы произвести эту оценку.
Также будут другие претенденты на этот проект. Клиент ожидает цену + продолжительность (и, вероятно, также функции), и я знаю, что все будут выключены. Я знаю, что это невозможно, но скажи это маркетологам. Другая проблема заключается в том, что я общаюсь с посредником, а не напрямую с клиентом. Я могу обрести уверенность только с посредником, но не с решающим клиентом. Это совсем другая проблема.
Какую оговорку / информацию я могу указать в своем ценовом плане / контракте, чтобы не убивать команду с этим проектом, поэтому, когда проект начинает проскальзывать (с точки зрения стоимости / времени / возможностей), мы получаем какую-то оплату. Я, конечно, хотел бы, чтобы мне платили спринты или релизы в зависимости от времени, но я сомневаюсь, что клиент мог быть в этом убежден. Я уверен, что мы можем закончить этот продукт раньше срока, а также создать отличный продукт, но как я могу убедить клиента поверить мне?
Вопрос
Что я могу сделать, чтобы получить этот проект и избежать ситуации марша смерти одновременно?
Любое предложение приветствуется!
РЕДАКТИРОВАТЬ: Результат
В конце концов, мы (я и мой коллега) убедили клиента, что нам нужна хотя бы неделя для оценки продукта. Так мы и сделали. Мы также выдвинули (и получили) слот на несколько часов для встречи с клиентом, чтобы прояснить любые нерешенные вопросы. Так мы и сделали. Встреча была проведена после того, как мы подготовили первый проект сметы, поэтому мы были уверены, что у нас есть все вопросы, чтобы указать на особенности, которые были либо неправильно поняты, либо слишком расплывчаты для оценки. Я надеюсь, что мы получим проект, потому что это будет означать 8 месяцев работы на полную ставку для нас плюс разумная оплата. Мы узнаем примерно через полторы недели.
Конечно, я также указал, что способ, которым мы будем поставлять этот продукт, даст им именно то, что они хотят, с продуктом, который на самом деле будет тем, что они хотели. А также то, что мы берем на себя обязательства только по цене и времени, но не по функциональности, потому что они есть и будут подвержены изменениям. Я думаю, что мы произвели достаточно хорошее впечатление.
6 ответов
Добро пожаловать в мир фиксированных услуг разработки:-)
Способы выиграть этот проект и избежать ситуации марша смерти одновременно:
- Не перебивайте проект. Ставка на то, что вы думаете, что проект возьмет и добавить некоторый процент за вещи, которые могут пойти не так.
- Если вам не хватает 75% деталей, вероятность того, что проект будет значительно отличаться от ожидаемого в настоящее время. Документируйте некоторые разумные детали предположения в рамках определенной работы. Когда проект фактически начинается, а детали не соответствуют предположению, у вас есть возможность договориться о стоимости изменений. В то же время, вы также можете быть в лучшем положении, чтобы узнать, сколько у вас больше / меньше, и попытаться компенсировать эту цитату.
- Ваша цель в SOW (техническом задании) должна состоять в том, чтобы определить достаточно деталей, чтобы дать вам возможность пересмотреть стоимость изменений, когда вы узнаете больше о проекте. Запишите их как положительные, как можно больше. Обратите внимание, что маловероятно, что люди, которые действительно понимают проект, будут читать или понимать SOW... Я основываю это на том факте, что вам дается несколько деталей для цитирования. Это означает, что это не консультативная продажа, и ни одна из сторон не нацелена на создание "правильного" решения.
- Если вы можете получить контракт, как T&M (время и материалы) здорово. Я сомневаюсь, что вы это получите или не сможете получить без каких-либо ограничений, которые по сути дела противоречат цели T&M. Ваши потенциальные клиенты смотрят на это, поскольку они принимают на себя все риски, связанные с вашими способностями.
- Надеюсь, вы не первый в вашей компании, чтобы сделать это. Исторически выясните, какими были проекты и каковы типичные показатели результатов. Многие группы разработчиков программного обеспечения взимают почасовую ставку, которая значительно выше стоимости... но их котировки, как правило, ниже, а не фактические часы. Клиенты часто будут спорить о часах / днях больше, чем фактическая цитата. Предприятия, как правило, привыкли платить высокие почасовые ставки.
- Определите ожидаемую маржу вашего отдела (прибыль, которую вы должны получить от работы). Это может помочь вам понять, с каким "маршем смерти" вы можете столкнуться, когда ваш проект проваливается.
- В SOW укажите уровень детализации, который потребуется в спецификации перед началом работы. Хотя Agile и другие ориентированные на клиента процессы используют подход, ориентированный на поиск наилучшего решения, они не предназначены для того, чтобы держать расходы под контролем в среде фиксированных ставок. Вам нужно будет использовать водопадный подход к требованиям, а затем быстро и гибко строить, чтобы вы могли в процессе приспособиться. Спецификация, как и SOW, даст вам возможность выставлять счета за изменения. Хотя клиенту это не понравится, он возложит на себя бремя и риски, связанные с требованиями, а не с вашей командой.
Обратите внимание, что для успеха этих переговоров вам нужна вспомогательная команда по управлению, продажам и управлению проектами. Если у вас этого нет, вы обязательно будете на "маршах смерти". Даже если вы откажетесь от качества, обработки, тестирования и других вещей, вы обнаружите, что времени на проект никогда не хватит.
В этой экономической среде много компаний борются за небольшую работу. Кто-то обязан сделать им очень приятную ставку, которая
- Не сможет доставить,
- Убить их команду с помощью, или
- И то и другое.
Когда они не могут доставить по согласованной цене, они начнут снижать качество, чтобы доставить что-то и получить оплату.
Ваша задача состоит в том, чтобы представить этот факт на перспективу на профессиональном уровне и убедить их в том, что вы будете очень усердно работать, чтобы доставить по разумной цене, а также доставить именно то, что им нужно. Тот факт, что вы возвращаетесь для более подробной информации, и метод, которым вы подходите к проекту (гибко... но будьте уверены и объясните им деловую выгоду), помогают гарантировать, что они получат то, что им действительно нужно.
Помните, что они хотят получить необходимое программное обеспечение по минимально возможной цене.
Убедите их в том, что вы будете доставлять именно то, что им нужно, и что ваша цена будет разумной.
Несколько вещей, о которых я бы хотел подумать:
Допущения: Вы не можете добавить ни одного отказа от ответственности, но вам необходимо заполнить пробелы в требованиях разумными предположениями и документировать их. Ничего особенного или страшного, просто раздел в вашей спецификации / заявке со списком пунктов, в которых говорится о том, что вы предположили, что это правда, чего не было (например, сведения о пользователях будут извлечены с использованием LDAP, и никакие экраны администратора не будут написаны, чтобы покрыть пользователя-администратора),
Это дает вам ясность в оценке, поскольку у вас теперь есть полный набор возможностей для работы, но это также означает, что если клиент возвращается с вещами, которые сильно отличаются, у вас есть достаточные основания для того, чтобы начать говорить о повышении запросов на изменение и изменении стоимости. В качестве альтернативы они могут вернуться во время переговоров, сказав, что это предположение или что оно неверно, и у вас есть больше информации.
Вне области: конкретный случай предположений - перечислите вещи, которые вы не включаете (например, не будет никакой интеграции с системой X). Опять же, это позволяет вам иметь полный объем и разумное обоснование для потенциально меняющихся затрат на более позднем этапе.
Допущения и выход за рамки особенно применимы, когда вещи упоминаются мимоходом, но на самом деле не отслеживаются, или когда вещи, которые, как они говорят, могут подождать второй этап. Часто это то, во что верит клиент, как часть основного проекта, а команда проекта - нет.
Надеемся, что тщательность и понимание из допущений и объема, которые вы определяете, поможет вселить уверенность и в конечного клиента.
Непредвиденные обстоятельства: хитрый, но вы должны добавить непредвиденные обстоятельства двумя способами:
(1) для конкретных рисков. Что касается вещей, которые могут означать, что что-то занимает больше времени, чем вы рассчитывали, то положите сумму, покрывающую вероятность того, что это произойдет. Сложите все это, и это ваш случайный риск.
(2) Дерьмо случается непредвиденно - непредсказуемое дерьмо случается на ИТ-проектах. Добавьте от 10% до 20%, чтобы покрыть это.
Спрячете ли вы непредвиденные обстоятельства от ваших коммерческих людей и клиента или нет, зависит от ваших отношений, но если они будут устранены, они должны понять, что это значит (по сути, вы БУДЕТЕ переигрывать).
Понимать взаимосвязь между усилиями и затратами. Ваша задача как технолога состоит в том, чтобы предоставить оценку усилий на основе имеющейся у вас информации. Затем вам необходимо сообщить об этом с допущениями, уровнем непредвиденных обстоятельств и т. Д. Вашей коммерческой команде, которая может преобразовать ее в денежную стоимость. С ними нужно уяснить: если они хотят снизить стоимость, это не меняет усилий.
Существует множество веских причин для того, чтобы записать стоимость для клиента (чтобы построить отношения, потому что у вас останется материал, который вы сможете использовать позже и т. Д.), Но люди должны понимать, что, если объем не изменится, усилия останутся то же самое - сокращение прибыли из прибыли.
РЕДАКТИРОВАТЬ:
Решение проблемы посредников. Я думаю, что лучшим способом было бы представить список рисков вместе с вашей ставкой в качестве любезности клиенту. Вроде как дать им понять, каковы их ограничения проекта. Это будет стоить вам работы заранее, но я думаю, что это может помочь вам выиграть проект.
у вас есть два варианта
сделать правильное предположение и удвоить или утроить свою оценку (ваши конкуренты, вероятно, делают то же самое).
Объясните клиенту, что вы не можете предлагать такую работу, и скажите ему, что все остальные, которые дают ему фиксированную оценку, вероятно, не совсем правдивы.
В конце концов, если вы не можете зарабатывать деньги на работе, нет смысла пытаться это сделать.
Лично я предпочитаю, чтобы последнее, искреннее и честное общение с вашими клиентами унесло вас дальше, чем любые хитрости.
У меня есть статья в блоге, которая может иметь несколько советов для вас:
http://pm4web.blogspot.com/2009/06/surviving-under-resourced-project.html
один из других постеров здесь имеет хорошее значение. всегда будет кто-то, кто предложит более низкую цену, чтобы получить работу. и разработчик пострадает за это позже (т. е. от того, что ему придется много работать, чтобы удовлетворить клиента).
Некоторые клиенты должны иметь такой опыт, прежде чем он поймет, что вы не можете делать ИТ-проекты по дешевке, не платя какую-то цену.
LM
Перейти на реализм. Избегайте слишком много обещаний, а затем сделайте это.
Многие клиенты были сожжены нереальными оферентами, которые не в состоянии доставить, как обещали.
Подчеркните необходимость проведения спринта. Сосредоточьтесь на основной функциональности и стремлении к поставке, а не на бонусах. Предложите начальную фазу разработки для предоставления основной функциональности.
Сообщите всю силу и безопасность гибкого подхода. Кредитуйте клиента способностью видеть здравый смысл.
Вкратце: старайтесь выглядеть реалистично и серьезно (в большей степени, чем ваши конкуренты). В конечном итоге для любого серьезного покупателя важнее всего не цена, а уверенность в том, что товар будет доставлен вовремя и в рамках бюджета.