基础
软件项目失败的常见原因（学院派）
对客户需求理解不足造成的风险。主要包括需求变更风险，涉及风险，过程风险，安装及维护风险。
由于管理人员能力不够，经验不足，沟通不畅，任务或其分配不合理造成的各种风险，主要包括进度风险，预算风险，管理能力风险，信息安全风险。
由于技术力量不足，开发环境工具不足造成的风险。主要包括技术风险，质量风险，软件设计工具风险，软件开发工具风险，员工技能风险。
由于公司或项目组内外部环境变化所导致的风险，主要包括人力资源风险，政策风险，市场风险，营销风险。
软件项目中的风险不能消除，只能避免、减轻、和接受。
软件项目常见的失败原因（实践派）
市场窗口关闭。这个没什么好办法，及时止损，项目停止得越早损失越小。
勾心斗角。 每个阶段都输出对应文档，作为合作依据。
团队成员太多或太少。招聘人员、培训都需要时间，所以界定项目范围时，要考虑人力约束。
选择了不合适、超前或过时的技术。不合适的技术会增加成本，降低质量。超前技术大幅增加不确定性。过时技术降低质量。
核心功能变更。让营销人员、销售人员大部分工作化为乌有。
没有设置好优先级。好钢要用到刀刃上。
糟糕的架构设计。增加合格的软件架构师。
急于求成。欲速则不达。
不切实际的期限。往往是客户或管理层太乐观引起的。
我失败的项目
2003年业余时间做网站
几个月就到了2000IP，当时的主流观点是“2000IP是盈利点”，但我不知道如何盈利，也不知道如何去分析盈利模式。几年没有盈利模式，IP也降到1000IP，于是就把网站关了。
10年后总结：
a,IP能够快速到2000，是因为我自己写了一个半自动发帖的工具，所以有推广优势。等商业化的发帖工具出来后，我的优势成为劣势后，就没有回天之力了。当时将半自动发帖改进成全自动化，卖产品就发了。
b,当时没有将精力转到寻找盈利模式上，失败！
c,2000IP确实可以盈利，我之前上班的公司，5000IP养活30多人。
德安进销存
2010年创业期间，花了一个月做了一款进销存，不知道卖给谁，也不知道如何找买家，于是放弃！
7年后的总结：产品的难度远大于项目，项目演化成产品比较安全。
专职网上上课
2010年前，业余时间在网上上过一两年课。2010专职网上上课一段时间，有两个学生报名。在和潜在“学生”沟通的过程中，发现大一大二学生并不热衷于课外学习，我预料等他们快找工作会主动找我。后来预言成真了，但我的精力被游戏开发牵扯，无法抽身。
7年后的总结：4次创业中，唯一一个市场方面勉强合格的项目。
智勇三国
2010年9月到2014年2月 我开发并运营了一款微型端游。
收入一年比一年高，但最后一年的收入也只有我打工的一半到3分之一。有个同行，软件质量比我差（多次数据大面积损坏），但收入比我高。于是，我决定再打工一个合同期，去思考这个问题。
事后总结：
1，开发技术有很多改进之处，这点让我考过了“软件架构师”。
2，类库需要积累，到2017年10月，类库基本成型。
3，摸清玩家的心很难。我喜欢玩游戏，且玩了10年，实践操作的时候发现我并不懂玩家的心。摸清玩家的心需要痴迷，喜欢是不够的。
4，一个微型游戏搞了3年多，行内的惯例是半年，到后来历史负担越来越重。比较好的方法是：3个月做3个不同的demo，重点发展用户反响最好的。每一年或半年花一个月弄一个新demo，如果新demo反响好，则以新demo为主。
5，虽然经常和玩家沟通（平均一天1小时多），但拒绝了绝大部分意见，因为核心认知不同。核心认知不同主要有两个原因：a,我的游戏不适合玩家。b,玩家不适合我的游戏。无论是哪种情况，都需要解决。
四次创业的总结
1，适量的资金储备，否则，生存压力让你无法静下心来思考。
2，创业前我知道需求分析的重要性，但没有切身体会。这几次创业加深了我的体会。
3，认识到可行性分析的重要性。
4,遇到困难不要回避，要分析看如何解决：学习？外包？绕道？ 历史表明：技术问题，我会解决；市场问题，我容易回避。
牛牛
上面的总结是2018年完成的，2018年还有另外一个项目，棋牌游戏“牛牛”。报酬5万，定金8千，到了交货日期，功能完成但有缺陷，用户要求退款，我们同意了。项目虽然失败，但我们还是有收获的。我和魏家瑜第一次合作编码，我后端，他前端。我们使用了新技术WebServer，并封装成类库。我后来在智造家完成的“打印大师”就是直接使用此类库。2020年完成智勇三国二，也是此方式。
软件各开发阶段
问题定义：确定目标及可行性。
需求分析：系统分析员确定业务级功能、业务级质量、业务级约束、用户级功能、用户级约束、开发级需求。架构师确定用户级质量。
设计：架构设计确定开发级质量、开发级约束，并确保所有功能、质量、约束都转化成开发级需求或可执行策略。概要设计使分工编码变得可行。详细设计指导编码。
编码：输出可在计算机上执行的软件。
软件测试：在用户之前发现问题。
IBM估算模型：（总比重10）
软件计划：1
需求分析：1.5
设计：3.0
编码：1.0
测试：3.5
注意：
大项目的维护工作量是开发的2倍，项目越大，维护的工作量占比越大。产品越差，维护的工作量越大。所以可维护性很重要。
分工与工种
为什么要分工
分工可大幅提高劳动生产效率，原因如下：
因为分工可以让一个特定环节的人员技能提升，熟练度提升，判断力提升。
减少了在不同类型工作中间来回切换的时间。
熟练又使人员创造出更多更好用的工具，从而提升劳动效率。
亚当.斯密在《国富论》中描述了别针的生产过程：“……别针的主要过程将被分为18个不同的工序”。斯密指出，如果这些工人单独工作，他们每天生产的别针不会超过20个，而这样的分工使他们每人每天生产48000个别针。
软件分工
项目经理：领导项目团队准时、优质完成项目。
产品人员：需求分析师、系统分析师。收集、整理需求、分析系统。
开发人员：架构师确定质量目标，设计师指导编码，软件开发工程师编码。
测试人员：测试产品。
配置管理人员：版本控制。
运维人员：管理服务器和数据库。
延期的项目追加人员延期得更厉害
蟠桃园的桃树，6000年开花，6000年结果。1颗桃树如此，1200棵桃树也如此。延期的项目追加人员延期得更厉害的原因：
学习成本高，新人需要熟悉多个模块，其他人只需要熟悉自己负责的模块。
学会后，缺少实践，效率低，产出可以忽略。引入的缺陷还会拖累其他人。
新加入员往往需要项目中已有人员引导、带领，会降低项目中已有人员的工作效率。除非有专门的培训人员。
人员越多，沟通成本越大。沟通成本正比于人员的平方。
软件能力成熟度模型（CMM）
分为5级：初始级、可重复级、已定义级、已管理级、优化级。可重复级：有纪律；已定义级：标准一致；已管理级：能预见；优化级：不断改进。对于中小公司而言，可重复级已经很厉害了，本文只讲可重复级(CMM2)。CMM2由6个关键过程域（KPA）组成：需求管理（RM）、软件项目计划（SPP）、软件项目跟踪与监控（SPTO）、软件子合同管理（SSM）、软件质量保证（SQA）、软件配置管理（SCM）。
需求管理包括：一，需求收集、需求整理、需求分析。二，需求评审。三，建立基线。四，需求变更，需求变更后要重写评审，建立新的基线。五，需求回溯。基线是项目储存库中每个工件版本在特定时期的一个“快照”。 基线的作用：一，回滚。常见场景，用户要求还是使用几个月前的方案。二，分支。常见场景，用户要求在一年前的版本上修改。三，沟通。开发与测试常常因为缺陷是否修改而发生争执，原因就是版本不一致。实施人员和客户也常有类似争执。
