На этой странице обсуждения обсуждаются улучшения в статье о треугольнике управления проектами . Это не форум для общего обсуждения темы статьи. |
Политика статьи
|
Найти источники: Google ( книги · новости · газеты · ученый · бесплатные изображения · WP рефов ) · FENS · JSTOR · NYT · TWL |
|
Известность установлена
Я просто установил известность, добавив три ссылки. Один поиск в книгах Google показывает, что существует множество книг, в которых упоминается эта концепция. Известность здесь не проблема. Думаю, оригинальное исследование есть.
Позвольте мне прояснить одну вещь. Я не писал эту статью. Я отделил этот текст от статьи об управлении проектом и переместил его сюда, как часть серии действий по улучшению этой статьи. См. Также Обсуждение: Управление проектами
- Марсель Доу Деккер ( разговор ) 01:07, 2 декабря 2008 г. (UTC)
Предложение о слиянии
- Следующее обсуждение закрыто. Пожалуйста, не изменяйте его. Последующие комментарии следует делать в новом разделе. Краткое изложение сделанных выводов следует ниже.
- Результатом этого обсуждения стало объединение страниц .
Несмотря на утверждение в статье о треугольнике проекта , я не могу понять, чем отличаются тематика этих двух статей. Поскольку я считаю, что «треугольник управления проектами» - более распространенный термин, я рекомендую объединить очень похожую статью о «треугольнике проекта» в эту. 98.212.175.119 ( разговорное ) 00:32, 24 января 2009 (UTC)
- Статья "Треугольник управления проектами" цитируется неправильно. Хотя статья может называться более распространенным названием, цитаты следует привести в порядок. —Предыдущий неподписанный комментарий добавлен 79.97.214.91 ( обсуждение ) 18:14, 21 марта 2009 г. (UTC)
Копировать и вставить регистрацию
- В этом начальном редактировании текст скопирован / вставлен сюда из статьи по управлению проектом .
- Пн ( разговор ) 13:27, 5 ноября 2009 г. (UTC)
Качество
Во втором абзаце введения есть фраза: «сфера применения» (качество). Это ошибочно означает, что качество такое же, как и в пределах области применения. Я попытался проверить ссылку [5], но указанный сайт Microsoft Office вернул ошибку.
Обратите внимание, что время, стоимость и объем - это количественные значения, тогда как качество, конечно же, является качественным значением.
Кроме того, хотя размещение «Качество» в треугольнике «Время-Стоимость-Объем» указывает на связь между концепциями, оно ошибочно подразумевает, что уменьшение объема обязательно приведет к уменьшению количества качества (поскольку площадь треугольника будет меньше). Хотя уменьшение объема может снизить ожидаемую выгоду (если для получения выгоды требуются все продукты / элементы объема), существуют и другие возможные сценарии: (а) объем может уменьшиться, потому что продукт больше не нужен в проекте (например, он понял, что компонент уже куплен); и (b) меньший объем может означать больше времени и затрат, которые нужно потратить на оставшиеся элементы объема, что придает им более высокое качество.
Рвилкин ( разговор ) 04:55, 12 сентября 2015 (UTC)
Я разделяю мнение о том, что «качество» не связано с количеством. Требование качества может легко иметь количество, например требование скорости в автомобильном проекте. Я также думаю, что изображение, которое показывает качество в середине золотого треугольника, на самом деле должно иметь область видимости в центре и качество в одной из вершин. Объем - это то, что вам как менеджеру проекта поручено выполнить, а качество, график и стоимость - это ограничения, налагаемые на этот объем. Например, вас просят построить трехэтажный дом из гонтовой плитки с позолоченной сантехникой за 200 000 долларов в течение шести месяцев. Объем проекта - сам дом. Требования к «облицованной плиткой», «3-этажной» и «позолоченной сантехнике» - это качественные ограничения или требования, предъявляемые к строительству этого дома. (Ограничения по стоимости и графику очевидны.) Даже опытные менеджеры проектов часто не понимают разницу между качеством и объемом, но если вы думаете, что объем - это то, "что" вы доставляете, а качество - как «насколько хороша» должна быть прицел, довольно легко разделить эти две концепции. Вот пара статей, которые лучше это объясняют: http://www.theprojectmanagementblueprint.com/?p=244 и http://www.theprojectmanagementblueprint.com/?p=75 MarkHWarner ( обсуждение ) 20:17, 11 августа 2016 (UTC)
Сфера
Термин «Область действия» используется в этой статье непоследовательно. В разделе «Обзор» это определяется как «что необходимо сделать для достижения конечного результата проекта». В разделе «Модель STR» говорится: «Объем относится к сложности (что также может означать качество)». А в разделе «Темы треугольника управления проектами» это обозначено как «Требования, указанные для достижения конечного результата».
При использовании планирования на основе продуктов PRINCE2 фокусируется на продуктах при использовании термина: объем. Это более простое и менее запутанное использование термина, где объем - это количество материалов (продуктов), которые проект должен произвести.
Требования высокого уровня - это то, что необходимо для достижения искомых преимуществ, при этом основное внимание уделяется «почему». Принимая во внимание, что в центре внимания находится «что»; поэтому определение в разделе «Темы треугольника управления проектом» (определение объема как требований) кажется бесполезным.
Рвилкин ( разговор ) 05:24, 12 сентября 2015 (UTC)
Конкурирующие формы / сочетание концепций
Я думаю, что общая концепция набора проблем существует несколькими способами в этой статье и за ее пределами. Это, кажется, вносит путаницу и некоторые пробелы в общей теме.
- На верхней диаграмме показаны стоимость, объем и график; нижний показывает хорошо, быстро, дешево; еще ниже объем = время х ресурсы.
- Еще ниже находится ромб, а ниже - шестиконечная звезда.
- Я также рассматривал это как «стоимость, график и производительность» и несколько поправил, что это должны быть «затраты, график, производительность и риск», чтобы избежать предвзятости в отношении длинных планов.
Я думаю, что заголовок статьи «треугольник» является немного избирательным, и что, возможно, в разделе обзора следует обсудить, что существуют альтернативные основания для размышлений.
Это, вероятно, все еще будет сложной путаницей из-за большого количества разновидностей - вроде как есть несколько способов составления расписания и формы расписания (диаграмма Ганта, сетевая диаграмма, табличная и т. .
Маркбассетт ( разговор ) 22:58, 20 июля 2016 (UTC)
Начало перезаписи
Я только что внес первое из, возможно, нескольких правок, чтобы исправить некоторые из наиболее вопиющих проблем в этой статье. Я начал с введения. Предыдущее введение на самом деле не объясняло, что говорит проектный треугольник, и подразумевало, что это была модель успеха проекта, а не ограничений проекта. Сейчас должно быть лучше. Если у меня будет время, я продолжу исправлять статью сверху вниз. Я также добавил несколько цитат в литературу по управлению проектами. Пол Ральф (Оклендский университет) ( выступление ) 18:58, 22 июля 2017 г. (UTC)