极客时间已完结课程限时免费阅读

09 | 为什么软件工程项目普遍不重视可行性分析?

09 | 为什么软件工程项目普遍不重视可行性分析?-极客时间

09 | 为什么软件工程项目普遍不重视可行性分析?

讲述:宝玉

时长13:40大小12.53M

你好,我是宝玉,我今天分享的主题是:可行性研究, 一个从一开始就注定失败的跨平台项目。借此来与你一起讨论,为什么软件工程项目普遍不重视可行性分析。
如果你随手拿起本软件工程教材翻翻,第一章一般都是讲“可行性研究”的,呈现顺序仅次于“绪论”,可见其重要性。
“可行性研究”通常讲的是如何科学地论证项目的可行性,以及这个项目是不是值得做。这个知识点比较简单,落实到期末考试的题目上,一般只是一道像这样的选择题或填空题:
“可行性研究主要从哪几个方面进行?”
这个题目要回答的话也不难,记住答案即可。
对于软件项目的可行性研究,主要从以下几个方面入手:
经济可行性;
技术可行性;
社会可行性。
看上去这么简单的知识点,到底重要在哪里呢?我们先来看一个真实的案例。
2015 年的时候,Facebook 推出了一个跨平台的移动端解决方案 React Native,只要用 JavaScript 一门语言就可以将写好的代码运行于 iOS、Android 移动平台。
所以在 2016 年的时候,某著名大型互联网公司的移动部门负责人非常看好这个技术,专门成立了项目组,用了不少人力,花了大半年时间将移动端 iOS、Android 产品迁移到 React Native 技术框架上。
就在项目快要上线的时候,法务部门却发现 React Native 的开源许可协议是“BSD+ 专利”。那这个“BSD+ 专利”的许可协议是什么呢?
BSD 的许可协议本身是开放的、没有限制的,但 Facebook 在此基础增加了一个“专利”协议。也就是说,如果对 Facebook 及其子公司提出专利诉讼,不管诉讼的项目是否与该协议有关,用户的所有专利权利也都会自动终止。
也就是说,如果未来该公司因为专利问题与 Facebook 产生纠纷,那么该公司将会无条件输了官司。
而目前该公司和 Facebook 是有竞争关系的,所以法务部门为了避免未来可能的纠纷,不得不叫停这个项目。而此时,他们在这个项目上投入的大量人力财力,相当于全打水漂了。
即使后来 2018 年的时候,Facebook 把 React Native 的开源协议修改为友好的 MIT 协议,也为时晚矣。
你看,如果在立项之前,就让法务部门帮助评估一下社会可行性(具体到这里,也就是法律方面的可行性),该公司就可以避免很大一笔损失。
类似的案例其实不在少数。许多公司老板或者部门负责人不是很懂技术,天马行空想到一个点子,或者看到某个热门技术(比如说团购、共享经济、人工智能、区块链),不做可行性研究就直接立项去做,耗费了不少人力、物力和时间成本不说,最后项目也不得不以失败告终。

为什么软件项目很少做可行性研究?

可行性研究不是软件项目的专利,在很多其他工程领域,项目正式启动前,都会有可行性研究这一环节,而且一般都会请一家甚至多家专业的评估机构帮助做可行性分析,并出具可行性研究报告,然后项目方来决定是不是立项。
拿建筑工程来说,你要在某条街上盖房子,却不做可行性研究,那么如果这条街两年后要拆迁,那就意味着你的房子也会面临被拆掉的命运,那损失就大了。
为什么在软件工程领域,可行性研究就不是很灵了?如果你也经历过或者听说过一些失败的软件项目,不知道你有没有想过,为什么这些软件项目很少有做可行性研究的?如果你有机会就这个问题去做一下调查,很可能会得到下面这些答案。
1. “因为我们是软件项目,所以我们很特殊。”
“我们很特殊”,这句话听着有没有很熟悉?软件项目确实有和其他工程项目不一样的地方。
比如说软件项目很抽象,以至于在立项之前对于问题的描述(需求)和解决方案(技术方案)通常都是模糊不清的,只有随着项目的推进,才能逐步搞清楚需求。
而可行性研究是基于问题和解决方案来分析的,因此这有点像“先有鸡还是先有蛋”的问题:你得先立项才能慢慢搞明白需求是什么,然后才能有解决方案;而你只有搞明白需求是什么,以及解决方案是什么,才能去做可行性研究。
但“我们很特殊”,不能成为不做可行性分析的借口,可能项目需求最开始是模糊不清的,还不具备可行性研究的条件,那么等到项目有了一定的进展,需求逐步明确后,要继续对可行性做研究。
如果发现方案不具备可行性,也应及时调整方案或停止项目以止损。
2.“老板拍板的项目,明知道不可行也得硬着头皮干呀!”
这个问题要分类讨论,有两种情况。
第一种情况,多半是由于老板或者项目负责人控制决策权,且对于不同意见容忍度较低。底下人不敢提不同意见,明知道不对也只能执行。
如果你是项目执行人员,不能参与决策,但觉得项目明显不可行,我仍然建议你尽可能站在专业的角度给出科学的分析,通过合理的方式反馈意见。毕竟,项目如果失败了,你也一样可能遭受损失。
如果你就是老板或者项目负责人,则应该建立可行性研究的意识,并理性听取不同意见,科学客观地进行可行性分析,以便有效降低项目失败概率。
第二种情况,老板或者项目负责人能接触到的信息更多、更全面,同时还有战略上的一些考虑,所以下面执行的人觉得不靠谱,并不代表真的不靠谱。
举个例子,2009 年阿里巴巴决定做阿里云的时候,公司反对者占绝大多数,只有马云和王坚等少数人觉得这个项目可行,而且必须做。最后,事实证明他们是对的。
所以有时候,也不要着急下结论,可以换个角度思考下,也许是你因为条件限制还没想清楚。
3.“软件项目是鼓励创新、鼓励试错的,可行性研究会阻碍创新!”
这也是一种很典型的错误观点,认为创新就可以不做可行性研究,否则会阻碍创新。实际上可行性研究和创新从来就不是矛盾的,它反而可以帮助你提前过滤掉那些不靠谱的创新想法,提前发现可能的风险。
想一想文章开头关于 React Native 开源协议冲突的案例,虽然是一个创新性的项目,却未绕过开源协议引起的法律纠纷。如果当初有法律方面的可行性研究,完全可以改用开源协议更友好的同类开源技术,避免项目的失败。

如何做好可行性研究?

前面,我们讲了可行性研究在软件工程中的重要性,也帮你厘清了几个常见的困惑,接下来我们来看看“如何做”的问题。
其实,当你决定要做可行性研究,你就已经成功一半了,怎么做反而是相对简单的部分!
软件工程的教材里面,通常会讲如何写可行性研究报告,很繁琐,要撰写诸如引言、背景、定义等内容。在这里,我们关注的重点是,软件工程中是如何去做可行性研究的。如文章开头所说的,通常从三个方面着手做:
经济可行性。从成本和收益角度分析,看投入产出比。不仅要分析短期利益,还要分析长期利益,看是不是值得做。
技术可行性。软件项目最终是需要人通过技术来实现的,所以要分析技术上是不是可行,如果有技术上解决不了的问题又能否规避。
社会可行性。社会可行性涉及法律、道德、社会影响等社会因素。比如,触犯国家法律的事情肯定不能做;产品如若不符合道德标准,可能带来较大的社会负面影响,那么也要慎重考虑。
仍然以文章开头提到的 React Native 项目为例,我们从这三个方面出发,来做一个简单的可行性研究。
先来看看经济可行性。按照投入成本和收益估算,我们在此仅做一些简单假设:
这个项目要投入 10 个人,每个人的人力成本预计是 10000 元 / 月,预计要花半年时间上线;
每个人在项目实施过程中,所需要的硬件和软件成本预计在 1000 元 / 月;
每年该部门预计完成 10 个项目,每个项目收益预计 1000000 元;
该项目导致 2 个项目延期半年;
该项目预计可以节约项目成本,所以每个项目收益可以提高 50000 元;
该项目可以让部门每年完成的项目提升到 12 个。
预计投入 1660000 元 / 半年,投入使用后每年可以产生约 2600000 元的收益,不到一年可以收回成本。
以前我写程序的时候并没有多少成本意识,觉得就改改代码而已,后来发现真要把工资和用的时间算一下,其实成本还是不低的。
就像上面这样一个 10 个人的项目,半年下来就要花一百多万。当然如果项目成功的话,不到一年就可以收回成本,而且后面还会持续创造价值。所以从经济可行性分析,还是可行的。
然后再来看看技术可行性。
从技术本身来说,经过一年多的发展,技术已经成熟稳定,并且已经有了几个成功案例。
从人员储备来说,部门已经有 5 名成员有 React Native 项目经验,其他人员可以通过 3 个月左右的培训上手。
从风险角度看,部分老的安卓机型无法支持,但是这部分机型占有率非常低,可以不予考虑。另外,部分视频组件需要自己实现,技术上可行,需要把这部分的开发任务放入项目计划中。
技术可行不可行,关键还是在人。就算技术成熟,如果短时间内找不到人来做,也是有很大风险的。同时也要评估可能存在的技术风险,像本例中的设备兼容问题,如果不兼容设备很多,那技术就不可行了。
像这个项目,已经有一定的人才储备,不会成为技术上的瓶颈,另外不支持的设备只占极少数,可以忽略不计,所以总体上技术还是可行的。
最后再来看看社会可行性。
道德可行性是没有问题的,不会有任何不良道德行为。
社会影响方面,也没有负面影响。
法律可行性上,项目本身不违反国家法律法规。版权上,React Native 采用 BSD+ 专利开源协议,存在法律风险!
至此,我们可以得出结论,这个项目从经济可行性和技术可行性上来说,都没问题,但是社会可行性方面存在很大风险。于是,接下来我们和公司法务部门进一步沟通,确认并达成一致,最好的结果是暂时冻结该项目。
就这样,我们通过项目启动前的可行性研究,及时冻结项目,为公司避免了人力、物力和时间上的浪费。而且,这样一来,我们还有了及时寻找其他解决方案的时间和机会。

总结

可行性研究是项目启动前很关键的一步,可能最早帮你发现风险,甚至避免损失,千万要重视起来。就如我前面所说的:
哪怕你做的可行性研究不能改变决策,最后项目结束的时候,和当初做的可行性研究做一下对比,也都是非常宝贵的项目经验积累。
结合《工程思维:把每件事都当作一个项目来推进》一文的内容,我建议你把每件事都当作一个项目来看,因此每次决定做一件事前,不妨先做一个“可行性研究”。
比如说,你打算要做一个功能模块的性能优化,不妨先列一下成本和收益(经济可行性),看看你投入的时间精力,再看看最终带来的性能提升效果,来判断下是不是值得做。
比如说,你要换工作,那就列一下你工资提升带来的收益(经济可行性)。最好换算成时薪,看看长期是不是真的更合算,因为有时候虽然工资多了一点,但加班太多反而得不偿失。
最重要的,你要关注一下法律上的风险(社会可行性),想一想你有没有签竞业协议,新工作会不会因违反竞业协议给你带来巨额赔偿问题。
最后,我想给你一个小建议:如果可行性研究并不能给你一个很明确的结果,也可以考虑小范围试点,先实现一个最小化可行产品,等验证了可行性,再逐步加大投入。

课后思考

除了本文列出的几个,你觉得还有哪些原因导致了可行性研究形同虚设?你身边有没有关于可行性研究的案例,以及你是怎么做可行性研究的?欢迎你在留言区留言,和我分享讨论。
感谢阅读,如果你觉得这篇文章对你有一些启发,也欢迎把它分享给你的朋友。
分享给需要的人,Ta购买本课程,你将得18
生成海报并分享

赞 10

提建议

上一篇
“一问一答”第1期 | 30个软件开发常见问题解决策略
下一篇
10 | 如果你想技术转管理,先来试试管好一个项目
 写留言

精选留言(25)

  • alva_xu
    2019-03-15
    从三个角度分析可行性,相当全面。 我们企业在软件项目立项时,经济可行性分析和技术可行性分析是必须要有文档材料,并且进行严格审批的,社会可行性方面,倒是没有严格的审批流程。 首先讲技术可行性。我们碰到的最主要的问题是对于技术解决方案是否合理的问题。由于决策层对技术的了解程度不一样,如果是采用已经在使用的技术,那么决策起来比较容易,但如果需要引进新的技术,那么最终的技术方案的敲定会历时很长。我们一般会通过寻求专家咨询,通过分析Gartner魔力象限和成熟度曲线,已经通过POC等方式,来寻求可行的技术解决方案。当然这里也遵循一些原则,就像老师上次说过的几个架构原则,“合适原则、简单原则、演化原则”来选择技术解决方案。 再谈一下经济可行性分析。 成本分析相对来说比较好分析,难处主要在于收益分析。一个软件项目,一般的目的主要在于解放生产力,让手工操作变为电脑操作,可以提高劳动生产率。从定性的角度是比较容易说的,但是到定量就很难了。特别是经济性分析的审核部门是财务部,如果我们说可以节省多少人手,那么财务部可能真的会要求业务部门减招人员,而这个又是业务部门很不愿意做的事情。所以这个问题还是在我们这样的大企业里存在,各个部门都希望保住自己的利益,所以会有很大的冲突。 老师,你以为呢?如果像这种情况,如何更合理地做出经济性分析,又能让各个部门皆大欢喜?
    展开

    作者回复: 你说的这个问题对我有点难度呀!🤔 我觉得经济可行性分析的结果,不能只说提高劳动生产率,更多的要谈创造的价值。当然实际上也要真的能给公司创造价值。 很多IT部门因为没有直接创造价值,所以地位反而不如销售部门,是因为从表面上看,软件项目是不直接创造价值的,只有销售出去才创造价值。 当IT部门或者说软件项目,能让人意识到能创造价值,而且能持续的创造价值,那么就不是减人的事情了,还得考虑增加人手呢。

    共 3 条评论
    9
  • 花灰
    2019-08-25
    每当经理说要做一个项目,就我自己来说总是找不到不做的理由,因为我们项目一般是部门内用,基本上没有技术成本和社会成本,学了本课,了解到人力成本,以后简单的容易上手的可以放心交给低一些的工程师,复杂一些的就自己写核心,辅助组内其他人完善。

    作者回复: 对的,人力成本是项目中很重要的一个因素。 另外,很多时候我们确实无法去对项目中的事情做决策,但并不妨碍通过学到的知识,科学的去分析和判断。 没有决策权毕竟还有建议权,好的建议总有被引起重视的时候。就算建议没采纳,也积累了一次练习的机会。 现在没有决策权不代表将来没有决策权,早做准备这样等到你有决策权的时候已经积累了大量经验了。

    6
  • 西西弗与卡夫卡
    2019-03-14
    最近有个项目延期,原因之一就是用到的第三方库需要https绑定域名,测试环境因为用http所以没有发现该问题。 事先的可行性研究,目的就是消除或者平衡项目中的技术风险、能力风险、协作成本、法律、部署等风险。 总结里给出了一个可行方法,即尽早上线部署,不对外公开服务即可。像法律问题,靠及早软件部署没法解决,可以有个检查清单,每类风险都给出适当评估意见
    展开

    作者回复: 这种问题确实不好暴露。 除了及早上线,有一点可以改进的建议就是测试环境也可以考虑把https用起来,尽可能保持一致,这样能减少一点类似问题的风险。

    5
  • Dream.
    2019-03-14
    技术可行性这东西。。。 就是每次在搭建项目之前,会各种分析各种技术的优劣。 架构搭建好之后,除非重构,都是奉行“只有想不到,没有做不到”的思路,从此再也没有技术可行性分析,一切都是可行😂😂😂
    展开

    作者回复: 哈哈,这个确实很常见。技术人员都有执念,我懂的! 另一个角度讲,可行性研究本就是架构设计时要确定的,架构如果都已经做好了,成本也很高了,除非有真绕不过去的坎。

    4
  • Jack MA
    2019-11-18
    可行性分析可以从更多维度进行分析,我认为可以参考模型PEST或PESTLE(Political, Economic, Sociological, Technological, Legal, Environmental)

    作者回复: 政治(Political)、经济(Economic)、社会(Sociological)、科技(Technological)、法律(Legal), 环境(Environmental) 👍

    3
  • 张驰
    2019-03-19
    微软雅黑,能坑垮一家公司。

    作者回复: 👍这个案例好😄

    4
  • 一路向北
    2019-03-15
    用失败的案例来理解怎样做才能成功会更加容易,老师从这个角度来分析也让我容易接受。 实际的项目确实很少分析可行性,一般客户有需求就想着怎么去实现,也就是说都是分析技术可行性为主。 我们做的项目大部分都是硬件和软件结合,从经济角度分析,硬件更加容易分析清楚,软件会困难很多。
    展开

    作者回复: 对,软件的可行性分析确实有困难,但还是应该做一下,项目完成后再对比一下当初做的分析,几个项目积累下来,会有很多收获。

    3
  • 纯洁的憎恶
    2019-03-14
    由于软件工程相对于大多传统工程,在立项前所面对的问题、实际需求与解决方案往往更加模糊、不够明确。而问题及其解决方案又是可行性研究的前提。因此软件工程的可行性研究也存在差异。在软件工程进展的过程中,持续或分阶段进行可行性评估,尽早发现风险及时应对,也许是更好的方法。 经济可行性——成本收益分析 技术可行性——技术成熟度、人员条件、缺陷容忍度 社会可行性——法律、价值观、道德、社会影响
    展开

    作者回复: 👍谢谢补充

    3
  • wuzz
    2019-03-15
    可行性分析,在智能硬件上特别突出,考虑经济成本上经常只计算了硬件成本,选择低廉的 MCU,不考虑软件上的成本,结合上节课的黄金三角,为实现需求最终只能在时间做出妥协,成本回收周期更长,需要卖出的产品要更多。

    作者回复: 👍 软件工程的很多知识是有借鉴其他工程领域的,像可行性分析、金三角都不是软件项目独有的。

    3
  • osbeibei
    2019-03-14
    都只评估技术和功能可行性

    作者回复: 有时候没评估是没意识到需要评估,如果了解了不妨从文章中提到的几个角度思考一下,也许可以避免不必要损失。

    2
  • williamcai
    2019-03-14
    我们开发用的是业界比较成熟的技术,对于技术可行性的研究没有那么重视,其实这是有风险的,老板也知道,但是大家都默认了

    作者回复: 说到风险,《14 | 风险管理:不能盲目乐观,凡事都应该有B计划》会讲到风险管理。 对于风险有一种应对策略就是“接受风险”,也就是明知道是风险,还继续做:)

    2
  • 庄小P
    2019-04-14
    学生时代做项目的时候,就有一种感觉,感觉没人push,即使可行,项目进展非常难,大家都'没把心思放在上面上,导致可行性形同虚设

    作者回复: 你说的这更像一个项目管理和项目计划的问题:) 当然也可以认为是可行性分析时就预见到了这种可能:P

    1
  • 青石
    2019-03-18
    我们的项目中技术可行性和成本可行性考虑的会偏多一些,社会可行性通常很少考虑。 有些时候因为技术人员技能存储问题,可能会导致很适合项目的技术,却无法使用。通过其他笨方法,虽然实现了功能,但看起来很low,回过头再想想其实也符合最简化原则。 成本可行性很多情况偏重于决策层,有些项目属于长远战略,即便短期没有收益甚至亏损,公司依然长期投入,当然也有失败的风险。 在项目上,大部分情况都是脑子里走一遍,容易思虑不周、以偏概全。跟着老师系统学习,觉得还是落成文字才行。
    展开

    作者回复: 👍落成文字是个帮助思考的好习惯

    1
  • Charles
    2019-03-16
    可行性分析形同虚设:小公司岗位职责不清晰,互相照顾面子怕得罪人,谁都怕犯错背锅,感觉谁都对,最终就导致谁是“老板”谁拍板! 我感觉这个问题挺严重的,很影响决策正确性,只能等所谓的市场反馈。 也用类似项目成员“扑克牌”打分的方式可以解决吗?核心问题出在哪里?多谢老师,期待解答
    展开

    作者回复: 你这个问题已经不是可行性研究的问题了! 核心问题在于没有一套合理的类似于扑克牌打分的机制和流程。 扑克牌为什么是个好机制: 1. 公平合理,每个人都有机会不受他人影响的表达 2. 不用背锅,估错了也没关系,意见不一致还可以讨论 可行性研究是不是也可以形成类似机制?有专门会议,大家提前准备,会议上一起讨论结果,不用背锅,根据讨论结果形成最终决议。项目结束后在回顾对比当初的分析,作为下一次的参考。

    1
  • 胡鹏
    2019-03-15
    我们公司小,都考虑技术可行性,感觉上这样成本会小一点,,不过不做其他技术可行性分析,缺点也特别明显,

    作者回复: 还是有必要做一下,即使最终还是要做,也可以帮助你提前发现一些潜在的风险,早点预防

    1
  • Felix
    2019-03-15
    这也是为什么公司或团队成立技术委员会的目的,就是让视野开阔的技术大牛从多角度分析方案落地的可行性,我觉得还是很有必要的;社会角度确实之前也没有考虑到,这也是日后需改进的点

    作者回复: 是的,技术可行性还是需要有几个人一起多角度分析一下更科学客观

    1
  • aya
    2019-03-14
    经济可行性应该如何衡量呢,经常老板说值得做就做了,很少自己思考这个问题

    作者回复: 就像文章里面举的例子,算算人力成本,算算软硬件成本。

    1
  • ifelse
    2022-06-22
    如果可行性研究并不能给你一个很明确的结果,也可以考虑小范围试点,先实现一个最小化可行产品,等验证了可行性,再逐步加大投入。--记下来
  • LeeYa Master
    2022-06-03
    确实是这样,之前在小公司,就我一个开发,前端+后端都是我一个人做,老板接了个私活,我去那边驻场开发完成之后,因为没有ICP证,上不了线。导致客户不把钱给我们。损失了半个多月的时间。
  • aoe
    2022-01-12
    这篇文章很社会 如果是自己投资开发一个项目,只要听过可行性分析,一般都愿意做可行性分析,因为可以避免大量损失。 但大部分情况是:需求来了、上线时间定了,开发就是搬砖的,干就完了……