2019-03-161. 如果希望软件做得又快、有低成本，得到的软件应该是质量差、功能可能不全的软件
2. 如果希望软件免费，又得快速交付，那么得到的软件应该是质量没有保障，功能大概率不全的软件
3. 快速、便宜、质量好的软件是不存在的
4. 之前的工作中，好像没有一个项目可以达到质量和时间、成本之间良好的平衡，最后的结果都是为了保障质量和时间，然后增加人力成本（加班），如果加班也搞不定就对时间做出妥协（延期），范围这个指标倒是比较容易调整的一个指标。
5. 读完这篇文章的收获：（1）软件项目管理本质上就是在成本、范围、时间三个要素中做出合适的妥协的过程，质量是软件项目的目标，不能妥协；（2）管理金三角有助于在软件管理中进行良好有效的沟通，将精力花在事情上，而不是花在PK上，PK不是目标；（3）对于个人成长，也有同样的指导意义，我们的目标是取得个人的成功（名或利），影响这个目标的要素有时间、成本、范围，个人管理的过程也是在这三个要素中做妥协和平衡，例如，我现在积极参加这些知识付费的课程，就是希望用成本来提高自己的学习效率，这样可以在时间和范围上获得一些机会；我如果现在去健身，也会花钱请私教，同样是用成本来提高自己的健身效率，做出这样的选择的原因是我自己感觉相对于这些课程的价格来说，我的时间更加宝贵；但是有些时候，如果价格超出了我的承受能力，那我就不得不做出选择——自己花时间去搞定事情；有时候，成本我也不在乎，但是我的时间还是有限的，那我就只能做减法（少做一些事情）展开作者回复: 赞，你这个感悟很深刻，不只是项目中，都已经应用到日常生活中了👍
1 18
2019-03-12对金三角有了进一步的认识和理解，以前只认为它是个三角形而已，还不会用，谢谢老师作者回复: 是呀，这个真的非常实用的，软件项目中很多现象都可以从它身上找到解释，很多问题都可以通过它找到合适的方案。
10
2019-03-12金三角的确很有说服性，理论级的支撑。
1 用户体验很差的软件。性能低，学习成本高，缺陷多。
2 开发成本很高。但是投入产出比会有一个边界，无限的砸钱也不可能等比提高效率与质量。
3 开发周期长。开发周期长，比较容易出现需求变动，错失良机等问题。
4 不存在。
5 没什么能稳定使用的功能，会牺牲用户体验（比如加广告），性能低，安全容易出纰漏。
6 需求面很窄，小而美的那类软件，个人情怀很到位，开发时间很长。
7 也不存在。展开作者回复: 💯
我也认同4，7不存在 5
2019-06-28我认为文中关于三要素的说法是错的。专栏里，提到这个三角的时候又总是同时提到质量，时间成本范围又同时影响着质量，对质量的要求又影响了时间成本范围，那么质量应该是要素之一。
有些文章说三要素是时间成本质量，这也是错的，范围没有了。
PMP提到了，三要素是成本质量范围，时间属成本。
花费了成本，换了别的东西，成本沉没了，再也回不来了。时间也是，花了时间和其它成本，换了别的东西，时间沉没了，再也回不来了。作者回复: 时间可以算作成本，但是三要素不代表就必须要将成本和时间合并。
对于一个软件项目来说，时间和成本都是很重要的纬度，有无限的钱和最牛的人，不代表就可以用很短的时间做出来产品。
对于项目各种因素的约束，本身就存在各种不同的解读，我不认为一定就只有一种正确答案，你选择自己认为正确的就好。 4- 2019-03-13留言中讲的买工具，提供培训，提供公共组件服务，以及搭建CICD平台和自动化测试平台，也可以理解为增加成本。但对于我们企业来说，这笔成本就不算在具体的某个开发项目里了，所以我把它归结为提高效率，实际上也可以理解为TTM （Time To Marketing）指标。
作者回复: 谢谢补充🤝
4 
2019-03-15从这篇文章，我至少学会了不要怼产品。而是要从成本，时间，范围，三原则中寻找妥协。作者回复: 💯
对，重点不是怼，而是协商 3
2019-03-14老师请教一下，敏捷开发中是怎样做成本估算的？按您所说，开发过程中每个Ticket由开发团队集体估算，但在项目开始前即立项阶段，只有初步的大概的需求，具体的Ticket还没有制定出来或者不完备，如何准确确定项目的合同金额或预算？瀑布模型开发又是如何预估成本的呢？都是采用专家估算或领导拍脑袋估算成本和工期吗？软件工程书籍中介绍的估算模型如COCOMO或其他算法模型在实践中有人用吗？功能点、用例点等软件规模的估算方法实践中还有人用吗？这些方法是不是过时了？您觉得CMM或CMMI中对开发过程中的很多方面进行量化度量的做法在当今时代的软件开发中还实用吗？一口气问了这么多问题，先谢啦😊作者回复: 首先，软件项目的成本，主要是人力成本、采购的软硬件成本以及其他办公运营等成本。
其中人力成本的估算其实就是：人员工资x时间
无论是瀑布模型还是敏捷开发，要估算人力成本，就是要算出来要多少人月
在原始需求出来后，要对需求进行分解，越细致越好，然后对于分解后的细项再凭经验估算。
基于细分的需求：
瀑布模型的话，要把阶段分出来，各个阶段预计的时间和人员投入估算出来。然后就能大致算出成本。
敏捷开发的话，要估算需要多少个Sprint，多少人参与这个项目。也能大致算出成本。
你说的“软件工程书籍中介绍的估算模型如COCOMO或其他算法模型”我不知道你指的哪本书，我也确实不太清楚这部分知识，也不知道是不是过时了。
> CMM或CMMI中对开发过程中的很多方面进行量化度量的做法在当今时代的软件开发中还实用吗？
还是看项目场景吧，如果是应用CMMI模型的软件项目，肯定是适用的。我觉得现在软件开发整体上还是在往“敏捷”上发展的。 3- 2019-03-13老师，其实，我想表达的是，传统的大企业（不是指BAT这类大企业），比如我们企业，IT项目牵涉到三个部门，一个是业务需求部门，一个是IT部门，一个是财务预算审批部门，采取的形式一般都是采用外包方式，而且往往是固定合同，也就是合同价格是确定的，需求范围也是确定的，这样的话，金三角的两条边就定下来了，剩下来的就是时间和质量的关系问题了。
按照金三角的理论，我们就可以知道前面所述的场景下项目组该重点抓什么了：作为甲方项目经理，重点抓的就是质量和时间了。如何通过提高效率，使单位时间的产出比原来的多（相当于增加了时间），来提高项目的交付质量，是我们甲方IT项目经理最关心的事。所以这时候，我们的方法是建立统一软件框架、提供公共服务组件、制定代码和测试规范、培训乙方团队、搭建CICD平台和自动化测试平台、sonarqube自动代码检测平台等，使原来几周一次测试变成一周几次测试，使原来低质量的代码快速变成高质量的代码... 反正是采用各种方法，提高工作效率，用于抵消业务部门不时提出的变更导致的项目进度的风险。当然在开发模式上，也会衡量敏捷的开发模式（特别是scrum的管理模式）和传统瀑布及衍生模式哪种模式更高效。
当然，理解了金三角，对于前期申请项目预算也是有帮助的，比如，可以和预算部门谈判，如果要砍预算，在时间一定的情况下，就只能减少项目范围，这是我们业务需求部门所不能接受的。这样，就可以使IT项目经理名正言顺地把预算部门和IT部门的矛盾转嫁到预算部门和业务需求部门去。
当然，最合理的做法应该是向BAT公司看齐，IT部门转变为利润中心，自己管预算、自己有开发团队，那么金三角的三条边就都可以进行调优了。展开作者回复: 谢谢补充👍
非常有价值的分享！ 3 
2019-03-12备注：理论上快，好，便宜是不存在的，但实际能否存在呢，可以只能加进一个新的维度“少”
所以围绕多，快，好，省（对应少，慢，差，贵）来确定1-7会是什么样的软件
1.快 + 便宜 = 质量很差并且多数伴随功能少
2.快 + 好 = 费用成本高多半是早期软件，功能少只实现核心功能但体验不错
3.好 + 便宜 = 开发周期长，但开发时间长费用成本不见得少，所以多半也伴随功能少
4. 快 + 便宜 + 好 = 如备注所说，这会是一个体验不错但功能少的软件，比如微信早期版本只能语音
5.免费 + 快 = 这样的软件也很多，质量基本没谱了可能还有安全风险
6.免费 + 好 = 这样的软件也很多，比如某零杀毒软件，当年就是以免费出道，但成本就很高开发周期一般也比较长
7.免费 + 好 + 快 = 单点功能的软件，比如微信里像抽奖助手的小程序，一个功能好用简单，还有像一些优秀的开源软件插件啥的
但通常免费多数是赚的流量费，广告插入到处是展开作者回复: 7的话可能还是有点争议，整体总结的非常好👍
3
2019-03-18很多的游戏公司这三个角都想要，就导致抄袭很严重！作者回复: 抄袭我觉得就相当于节约了需求分析的时间和成本
2- 2019-03-15谢谢宝玉老师教的砍需求大法，而且还有理论支撑，以后PK再也不虚了🙊
作者回复: 只要是为了“质量”，就没什么好虚的👍
另外沟通的时候，还是以协商为主，毕竟大家目标是一样的，是为了保障质量的前提一起协商做一些调整，并不是要PK个输赢 ：） 2 
2019-06-30如果时间、成本、范围等比例缩小，三边围成的面积也缩小了，是否意味着软件的质量也是缩小了？但现实中一般认为质量并没有缩小。作者回复: 金三角反应的更多是各个因素之间的关系和约束，并不是严格的比例限定，否则2个孕妇能5个月生孩子了
1
2019-03-21这篇把零散的知识点形成体系，强化了时间、成本、范围、质量的关系，更能联系实践！
能够提高与产品经理打太极的水准！作者回复: 大家目标都是为了项目质量，至于如何平衡还是要多沟通多协商，互相妥协 ：）
1
2019-03-13通过金三角这个概念一分析，明白了瀑布型和敏捷的你中有我，我中有你。
按照时间切片，切完片之后再来一个微型瀑布。作者回复: 敏捷的Sprint严格来说不是一个微型瀑布，迭代模型才是。
请参考“05|敏捷开发到底想要解决什么样的问题”，里面有对这个进行对比和解释。 1
2019-03-13金三角模式很实用，不过对于每个sprint是否可以按照需求来划分呢，因为如果是一个成熟的产品可能规定的时间内都不会有迭代的需求，而是按照产品经理某一天提出来的story进行迭代的。作者回复: 敏捷开发的Sprint，如果按照需求来划分，而不是按照固定时间，那么最终发布的时间就很难确定，这个Sprint就会变回小瀑布的，就很难敏捷起来。
增量模型是按功能划分的。 1
2019-03-13最怕的就是时间和范围固定，要求加成本的情况。因为在国内这个加成本往往就是加班，而且还没有加班费。作者回复: 加班就是加时间🤦♂️
1
2019-03-12受益匪浅，利用项目管理金三角理论，使我在项目中遇到到一些问题豁然开朗。作者回复: 👍赞，能把学的东西用上，是最开心的了！
1
2019-03-12“多、快、好、省”，软件工程的四难选择问题。由于质量是软件工程压倒一切的要素，因此“好”必须留在“盘子”里。剩下的要素都是可以根据具体情况权衡取舍的。四难选择变成了三难选择。于是，工程师在实践中面对不确定时，也能够有底气做到“不抵触，讲条件”了。
延长时间的另一面是提高效率。借助工具、优化流程、节约资源等方法，可以在一定程度上“冲销掉”延长的时间。
非常欣赏MVP模型，既可以快速见效，又降低了大量返工的可能。在瀑布模型中，通过会有过度设计的现象。一开始想了很多，结果发现恨不能80%都是瞎想。先拿出核心功能，再根据用户使用的情况，有指向性的完善，步步迭代演进，十分靠谱。唯一令人担忧的是，在外包模式中，如果没有明确的需求，就难以估算出较为准确、合理的预算，进而无法立项、采购。如果先做一版需求申请下来预算再说，再用MVP模型步步试探。那么最后做出来的东西可能与需求文档严重不一致，存在较大的审计、内控风险。也许企业大了、规矩多了，做起事来确实别扭。展开作者回复: 总结的非常棒👍
迭代模型和MVP是非常好的组合，因为迭代的时候，会优先选取最重要的功能，慢慢的那些不重要的功能甚至永远不会被加入迭代中，就因为不需要浪费时间在上面了 1
2019-03-12估时我觉得还和人之间的关系有关，有的人习惯估时长，领导习惯了也不压，有的人做的快，估时短，如果某次估时长，老板还会说，，，， 金三角以后我也要用这种方案试一下了作者回复: 是的，金三角是帮助你提供理论支持的，还需要根据环境灵活运用。
1
2019-03-12终于找到一套可以说服老板的说辞了作者回复: 不要想着说服老板，而是给他更多选择😂
1