09 为什么软件工程项目普遍不重视可行性分析？
你好，我是宝玉，我今天分享的主题是：可行性研究， 一个从一开始就注定失败的跨平台项目。借此来与你一起讨论，为什么软件工程项目普遍不重视可行性分析。
如果你随手拿起本软件工程教材翻翻，第一章一般都是讲“可行性研究”的，呈现顺序仅次于“绪论”，可见其重要性。
“可行性研究”通常讲的是如何科学地论证项目的可行性，以及这个项目是不是值得做。这个知识点比较简单，落实到期末考试的题目上，一般只是一道像这样的选择题或填空题：
“可行性研究主要从哪几个方面进行？”
这个题目要回答的话也不难，记住答案即可。
对于软件项目的可行性研究，主要从以下几个方面入手：
- 经济可行性；
- 技术可行性；
- 社会可行性。
看上去这么简单的知识点，到底重要在哪里呢？我们先来看一个真实的案例。
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+专利开源协议，存在法律风险！
至此，我们可以得出结论，这个项目从经济可行性和技术可行性上来说，都没问题，但是社会可行性方面存在很大风险。于是，接下来我们和公司法务部门进一步沟通，确认并达成一致，最好的结果是暂时冻结该项目。
就这样，我们通过项目启动前的可行性研究，及时冻结项目，为公司避免了人力、物力和时间上的浪费。而且，这样一来，我们还有了及时寻找其他解决方案的时间和机会。
总结
可行性研究是项目启动前很关键的一步，可能最早帮你发现风险，甚至避免损失，千万要重视起来。就如我前面所说的：
哪怕你做的可行性研究不能改变决策，最后项目结束的时候，和当初做的可行性研究做一下对比，也都是非常宝贵的项目经验积累。
结合《工程思维：把每件事都当作一个项目来推进》一文的内容，我建议你把每件事都当作一个项目来看，因此每次决定做一件事前，不妨先做一个“可行性研究”。
- 比如说，你打算要做一个功能模块的性能优化，不妨先列一下成本和收益（经济可行性），看看你投入的时间精力，再看看最终带来的性能提升效果，来判断下是不是值得做。
- 比如说，你要换工作，那就列一下你工资提升带来的收益（经济可行性）。最好换算成时薪，看看长期是不是真的更合算，因为有时候虽然工资多了一点，但加班太多反而得不偿失。
最重要的，你要关注一下法律上的风险（社会可行性），想一想你有没有签竞业协议，新工作会不会因违反竞业协议给你带来巨额赔偿问题。
最后，我想给你一个小建议：如果可行性研究并不能给你一个很明确的结果，也可以考虑小范围试点，先实现一个最小化可行产品，等验证了可行性，再逐步加大投入。
课后思考
除了本文列出的几个，你觉得还有哪些原因导致了可行性研究形同虚设？你身边有没有关于可行性研究的案例，以及你是怎么做可行性研究的？欢迎你在留言区留言，和我分享讨论。
感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。
- alva_xu 👍（9） 💬（3）
从三个角度分析可行性，相当全面。 我们企业在软件项目立项时，经济可行性分析和技术可行性分析是必须要有文档材料，并且进行严格审批的，社会可行性方面，倒是没有严格的审批流程。 首先讲技术可行性。我们碰到的最主要的问题是对于技术解决方案是否合理的问题。由于决策层对技术的了解程度不一样，如果是采用已经在使用的技术，那么决策起来比较容易，但如果需要引进新的技术，那么最终的技术方案的敲定会历时很长。我们一般会通过寻求专家咨询，通过分析Gartner魔力象限和成熟度曲线，已经通过POC等方式，来寻求可行的技术解决方案。当然这里也遵循一些原则，就像老师上次说过的几个架构原则，“合适原则、简单原则、演化原则”来选择技术解决方案。 再谈一下经济可行性分析。 成本分析相对来说比较好分析，难处主要在于收益分析。一个软件项目，一般的目的主要在于解放生产力，让手工操作变为电脑操作，可以提高劳动生产率。从定性的角度是比较容易说的，但是到定量就很难了。特别是经济性分析的审核部门是财务部，如果我们说可以节省多少人手，那么财务部可能真的会要求业务部门减招人员，而这个又是业务部门很不愿意做的事情。所以这个问题还是在我们这样的大企业里存在，各个部门都希望保住自己的利益，所以会有很大的冲突。 老师，你以为呢？如果像这种情况，如何更合理地做出经济性分析，又能让各个部门皆大欢喜？
2019-03-15 - 花灰 👍（6） 💬（1）
每当经理说要做一个项目，就我自己来说总是找不到不做的理由，因为我们项目一般是部门内用，基本上没有技术成本和社会成本，学了本课，了解到人力成本，以后简单的容易上手的可以放心交给低一些的工程师，复杂一些的就自己写核心，辅助组内其他人完善。
2019-08-25 - 张驰 👍（5） 💬（1）
微软雅黑，能坑垮一家公司。
2019-03-19 - 西西弗与卡夫卡 👍（5） 💬（1）
最近有个项目延期，原因之一就是用到的第三方库需要https绑定域名，测试环境因为用http所以没有发现该问题。 事先的可行性研究，目的就是消除或者平衡项目中的技术风险、能力风险、协作成本、法律、部署等风险。 总结里给出了一个可行方法，即尽早上线部署，不对外公开服务即可。像法律问题，靠及早软件部署没法解决，可以有个检查清单，每类风险都给出适当评估意见
2019-03-14 - Dream. 👍（4） 💬（1）
技术可行性这东西。。。 就是每次在搭建项目之前，会各种分析各种技术的优劣。 架构搭建好之后，除非重构，都是奉行“只有想不到，没有做不到”的思路，从此再也没有技术可行性分析，一切都是可行😂😂😂
2019-03-14 - Jack MA 👍（3） 💬（1）
可行性分析可以从更多维度进行分析，我认为可以参考模型PEST或PESTLE（Political, Economic, Sociological, Technological, Legal, Environmental）
2019-11-18 - 一路向北 👍（3） 💬（1）
用失败的案例来理解怎样做才能成功会更加容易，老师从这个角度来分析也让我容易接受。 实际的项目确实很少分析可行性，一般客户有需求就想着怎么去实现，也就是说都是分析技术可行性为主。 我们做的项目大部分都是硬件和软件结合，从经济角度分析，硬件更加容易分析清楚，软件会困难很多。
2019-03-15 - wuzz 👍（3） 💬（1）
可行性分析，在智能硬件上特别突出，考虑经济成本上经常只计算了硬件成本，选择低廉的 MCU，不考虑软件上的成本，结合上节课的黄金三角，为实现需求最终只能在时间做出妥协，成本回收周期更长，需要卖出的产品要更多。
2019-03-15 - 纯洁的憎恶 👍（3） 💬（1）
由于软件工程相对于大多传统工程，在立项前所面对的问题、实际需求与解决方案往往更加模糊、不够明确。而问题及其解决方案又是可行性研究的前提。因此软件工程的可行性研究也存在差异。在软件工程进展的过程中，持续或分阶段进行可行性评估，尽早发现风险及时应对，也许是更好的方法。 经济可行性——成本收益分析 技术可行性——技术成熟度、人员条件、缺陷容忍度 社会可行性——法律、价值观、道德、社会影响
2019-03-14 - osbeibei 👍（3） 💬（1）
都只评估技术和功能可行性
2019-03-14 - 庄小P 👍（2） 💬（1）
学生时代做项目的时候，就有一种感觉，感觉没人push，即使可行，项目进展非常难，大家都'没把心思放在上面上，导致可行性形同虚设
2019-04-14 - aya 👍（2） 💬（1）
经济可行性应该如何衡量呢，经常老板说值得做就做了，很少自己思考这个问题
2019-03-14 - williamcai 👍（2） 💬（1）
我们开发用的是业界比较成熟的技术，对于技术可行性的研究没有那么重视，其实这是有风险的，老板也知道，但是大家都默认了
2019-03-14 - 青石 👍（1） 💬（1）
我们的项目中技术可行性和成本可行性考虑的会偏多一些，社会可行性通常很少考虑。 有些时候因为技术人员技能存储问题，可能会导致很适合项目的技术，却无法使用。通过其他笨方法，虽然实现了功能，但看起来很low，回过头再想想其实也符合最简化原则。 成本可行性很多情况偏重于决策层，有些项目属于长远战略，即便短期没有收益甚至亏损，公司依然长期投入，当然也有失败的风险。 在项目上，大部分情况都是脑子里走一遍，容易思虑不周、以偏概全。跟着老师系统学习，觉得还是落成文字才行。
2019-03-18 - Charles 👍（1） 💬（0）
可行性分析形同虚设：小公司岗位职责不清晰，互相照顾面子怕得罪人，谁都怕犯错背锅，感觉谁都对，最终就导致谁是“老板”谁拍板！ 我感觉这个问题挺严重的，很影响决策正确性，只能等所谓的市场反馈。 也用类似项目成员“扑克牌”打分的方式可以解决吗？核心问题出在哪里？多谢老师，期待解答
2019-03-16