1.1 基础
1.1.1 软件项目失败的常见原因(学院派)
对客户需求理解不足造成的风险。主要包括需求变更风险,涉及风险,过程风险,安装及维护风险。
由于管理人员能力不够,经验不足,沟通不畅,任务或其分配不合理造成的各种风险,主要包括进度风险,预算风险,管理能力风险,信息安全风险。
由于技术力量不足,开发环境工具不足造成的风险。主要包括技术风险,质量风险,软件设计工具风险,软件开发工具风险,员工技能风险。
由于公司或项目组内外部环境变化所导致的风险,主要包括人力资源风险,政策风险,市场风险,营销风险。
软件项目中的风险不能消除,只能避免、减轻、和接受。
1.1.2 软件项目常见的失败原因(实践派)
市场窗口关闭。这个没什么好办法,及时止损,项目停止得越早损失越小。
勾心斗角。 每个阶段都输出对应文档,作为合作依据。
团队成员太多或太少。招聘人员、培训都需要时间,所以界定项目范围时,要考虑人力约束。
选择了不合适、超前或过时的技术。不合适的技术会增加成本,降低质量。超前技术大幅增加不确定性。过时技术降低质量。
核心功能变更。让营销人员、销售人员大部分工作化为乌有。
没有设置好优先级。好钢要用到刀刃上。
糟糕的架构设计。增加合格的软件架构师。
急于求成。欲速则不达。
不切实际的期限。往往是客户或管理层太乐观引起的。
1.1.3 我失败的项目
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年完成智勇三国二,也是此方式。
1.1.4 软件各开发阶段
问题定义:确定目标及可行性。
需求分析:系统分析员确定业务级功能、业务级质量、业务级约束、用户级功能、用户级约束、开发级需求。架构师确定用户级质量。
设计:架构设计确定开发级质量、开发级约束,并确保所有功能、质量、约束都转化成开发级需求或可执行策略。概要设计使分工编码变得可行。详细设计指导编码。
编码:输出可在计算机上执行的软件。
软件测试:在用户之前发现问题。
IBM估算模型:(总比重10)
软件计划:1
需求分析:1.5
设计:3.0
编码:1.0
测试:3.5
注意:
大项目的维护工作量是开发的2倍,项目越大,维护的工作量占比越大。产品越差,维护的工作量越大。所以可维护性很重要。
1.1.5 分工与工种
为什么要分工
分工可大幅提高劳动生产效率,原因如下:
- 因为分工可以让一个特定环节的人员技能提升,熟练度提升,判断力提升。
- 减少了在不同类型工作中间来回切换的时间。
- 熟练又使人员创造出更多更好用的工具,从而提升劳动效率。
亚当.斯密在《国富论》中描述了别针的生产过程:“……别针的主要过程将被分为18个不同的工序”。斯密指出,如果这些工人单独工作,他们每天生产的别针不会超过20个,而这样的分工使他们每人每天生产48000个别针。
软件分工
项目经理:领导项目团队准时、优质完成项目。
产品人员:需求分析师、系统分析师。收集、整理需求、分析系统。
开发人员:架构师确定质量目标,设计师指导编码,软件开发工程师编码。
测试人员:测试产品。
配置管理人员:版本控制。
运维人员:管理服务器和数据库。
1.1.6 延期的项目追加人员延期得更厉害
蟠桃园的桃树,6000年开花,6000年结果。1颗桃树如此,1200棵桃树也如此。延期的项目追加人员延期得更厉害的原因:
- 学习成本高,新人需要熟悉多个模块,其他人只需要熟悉自己负责的模块。
- 学会后,缺少实践,效率低,产出可以忽略。引入的缺陷还会拖累其他人。
- 新加入员往往需要项目中已有人员引导、带领,会降低项目中已有人员的工作效率。除非有专门的培训人员。
- 人员越多,沟通成本越大。沟通成本正比于人员的平方。
1.1.7 软件能力成熟度模型(CMM)
分为5级:初始级、可重复级、已定义级、已管理级、优化级。可重复级:有纪律;已定义级:标准一致;已管理级:能预见;优化级:不断改进。对于中小公司而言,可重复级已经很厉害了,本文只讲可重复级(CMM2)。CMM2由6个关键过程域(KPA)组成:需求管理(RM)、软件项目计划(SPP)、软件项目跟踪与监控(SPTO)、软件子合同管理(SSM)、软件质量保证(SQA)、软件配置管理(SCM)。
需求管理包括:一,需求收集、需求整理、需求分析。二,需求评审。三,建立基线。四,需求变更,需求变更后要重写评审,建立新的基线。五,需求回溯。基线是项目储存库中每个工件版本在特定时期的一个“快照”。 基线的作用:一,回滚。常见场景,用户要求还是使用几个月前的方案。二,分支。常见场景,用户要求在一年前的版本上修改。三,沟通。开发与测试常常因为缺陷是否修改而发生争执,原因就是版本不一致。实施人员和客户也常有类似争执。