Я работаю менеджером по реализации проектов в компании по разработке программного обеспечения. Часто перед началом проекта давний и лояльный клиент связывается со мной напрямую, чтобы запросить «оценку» некоторых работ, которые должны быть выполнены в их системе.
Часто эти запросы идут с описаниями очень высокого уровня. Следует отметить, что на тот момент они еще не запрашивают котировки. Они (человек, часто мой коллега в компании-клиенте или член его команды) фактически просят меня сделать их домашнюю работу по составлению высокоуровневых оценок для их отчетов или совещаний.
Чтобы дать более полную картину, моя компания некоторое время обслуживала клиента. Дольше, чем некоторые из менеджеров и инженеров заказчика, работают там. У нас нет общего контракта, который бы покрывал такие внеконтрактные запросы, как этот. Таким образом, строго на договорной основе мы не обязаны рассматривать такие запросы. Но владелец моей компании советует мне, тем не менее, рассматривать такие запросы, потому что это способствует хорошим отношениям с клиентом и, по крайней мере, ставит нас впереди игры, когда или если проект будет участвовать в открытых торгах. И, честно говоря, я с ней согласен.
Проблема здесь в том, что когда я даю оценки в таких числах, как стоимость в долларах, потребности в человеко-днях или временные рамки. Это число часто всплывает на каком-то бюджетном собрании или в уставе какого-то проекта. Люди внутри берут на себя обязательства, основанные на этом. И когда приходит время подавать официальные котировки, моя компания часто возражает против этих цифр. Зачастую объем работ несколько вырос.
У меня такой вопрос: как лучше донести до клиентов, что смета ни в коем случае не является обязательной. Это «продолжающееся обсуждение». Любые цифры, возникающие из этого, будь то долларовые затраты или временные рамки, не являются обязательствами ни меня, ни моей компании.
Небольшая проблема с рамками: подумайте о том, чтобы предоставлять свои оценки как широкий конец конуса неопределенности, а не как дискретное число.
«Мне нужна [неопределенная вещь], сколько времени это займет?»
«Хорошо, я обсудил это со своей командой, и мы думаем, что это займет от 2 до 7 недель».
«Мне нужна точная оценка».
«Тогда нам потребуются точные данные. По нашим оценкам, для деталей, которые вы предоставили, от 2 до 7 недель».
«Хорошо, а как насчет [менее расплывчатой вещи]?»
«О, это будет от 3 до 5 недель».
Предоставление ваших оценок в виде диапазона запекает вашу неопределенность в самой оценке, так что тогда нет необходимости в отдельном шаге «но мы не полностью привержены этой оценке».
Чтобы добавить правильный ответ nvogel .
Помимо предоставления детализированных результатов, вам необходимо добавить стандартные функции, которые забыты, пропущены, но необходимы и требуют очень много времени + ресурсов, поэтому они влияют как на сроки, так и на бюджет.
Такие функции, как дизайн, функциональная спецификация, графический дизайн и подписание, интеграция (исправление ошибок в результате интеграции — необходимо дать имя, чтобы скрыть «ошибки»), контроль качества (с несколькими раундами исправления ошибок), бета-тестирование/автономное тестирование, процедуры ввода в эксплуатацию, чтобы привести несколько примеров.
Вы можете считать это само собой разумеющимся, но, как вы сказали, ваш «черновой проект» становится рабочим документом, и поэтому вы хотите предотвратить неправильное ценообразование (и возможную неудачу конкурентного анализа) на основе частичного плана проекта.
Прикрепляйте каждую оценку к детализированному результату , а не к названному объему работ, чтобы было меньше места для сомнений относительно того, что было оценено. Используйте относительную оценку (в баллах) на уровне элемента, а затем агрегируйте значения в баллах и при необходимости преобразуйте в абсолютное время и стоимость. Наилучшие оценки обычно создаются и принадлежат команде разработчиков, а не менеджеру по доставке.
Ваша проблема требует двух вещей, которые на 100% принадлежат ВАШЕЙ компании, и только эти две вещи: 1) вам нужно вставить юридический язык, который сопровождает вашу оценку того, что это оценка высокого уровня, грубая оценка порядка величины, основанная на том, что было известно в то время, что подлежит изменению, когда требования станут более известными и твердыми; и 2) ВАША компания должна стоять твердо и дать отпор, если вы испытываете давление, чтобы придерживаться этого ПЗУ. Число 2 имеет решающее значение, потому что без него число 1 бессмысленно.
Просто посмотрите на другие отрасли, такие как строительство. Если вы обратились к подрядчику, чтобы он построил вам дом с какими-то грубыми, высокоуровневыми желаниями, а затем попытаетесь удержать их от этой ценности — если они даже ее предоставят — они будут смеяться, когда уйдут от вас.
Для тех из нас, кто занимается SW или другой работой, связанной с умственными способностями, мы, похоже, испытываем трудности с этим. Но на самом деле не требуется никакого другого вмешательства, кроме как сказать: «Нет!» Продавцы программного обеспечения и других знаний занимают равные места за столом.
Общение должно быть максимально четким, если вы хотите избежать неправильного толкования, это не невежливо, а просто профессионально. Как насчет выдающейся заметки
This is a rough estimate based on incomplete requirements.
It is intended to support your decision process, but it's not binding
and should not be used in budget or schedule planning.
в вашем ответном письме? Напишите CC своему боссу, чтобы был четкий след, что вы не установили окончательный диапазон времени или бюджета.
Один из способов ответить на этот вопрос — сосредоточиться на рисках, присущих последующей работе. В общем, для очень рискованного проекта я бы вообще никогда не давал никакой оценки, вместо этого я бы предложил предварительное исследование.
Типичные факторы риска для оценки и могут быть выделены в ответе. Каждому утверждению можно присвоить число, скажем, от 1 до 5, где 5 означает высокий риск — слишком большая сумма -> предложить предварительное исследование.
Крис Х
Мазура