Балансировка треугольника объема, времени и затрат для мотивации команды и удовлетворения клиента

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

В проектах, в которых участвовали члены нашей команды, преобладали следующие факторы:

  • высокий размах,
  • меньше времени &
  • меньше ресурсов (всегда один разработчик).

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

Как сбалансировать треугольник эффективно, хотя бы в приличной степени, чтобы и член моей команды, и клиент остались довольны? :)

Какова твоя роль? Вы PM, разработчик или кто-то еще? Перспектива имеет значение.
@CodeGnome: PM, менеджер проекта связывает разработчика и клиента один раз после запуска проекта.

Ответы (5)

Не зря его называют «железным треугольником». Как сказал другой, он часто выпрямляется, но если все углы исправлены, то часто жертвуют качеством или отсутствием.

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

введите описание изображения здесь

Ключевые моменты agile, которые помогут вам сбалансировать — увеличить общение (ежедневно) — сократить ваши функции/объем в работе только до того, что вы можете сделать за 1-2 недели (Scrum) — расставить приоритеты в своем объеме — получить представление о том, как быстро вы завершение вашей области (на самом деле) - демонстрация / обзор с вашим клиентом завершенной области каждые 1-2 недели - настройте себя на то, чтобы приветствовать изменение области (потому что в стартапе .... вы должны!)

В Интернете есть множество ресурсов о том, как заниматься бережливой и/или гибкой разработкой.

Удачи!

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

Менеджеру проекта может понадобиться помощь с оценками и разбивкой работ, что является нормальным явлением. Однако после того, как это было сделано и до того, как оно было отправлено клиенту, the estimation should be reviewed from scope, time and cost perspectives. Кроме того, руководитель проекта должен иметь веские обоснования оценки времени и стоимости согласованного объема работ.

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

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

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

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

Треугольник уравновешивается естественным образом. Вы можете самостоятельно фиксировать или манипулировать одной или двумя сторонами, но третья зависима и будет подстраиваться под баланс. Но это не ваша проблема.

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

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

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

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

Кажется, это вопрос сотрудничества, общения в коллективе и оценки работы.

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

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

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