会议室拍板的需求说改就改？软件工程开发从来不是写代码这么简单
上周跟南京河西那边的老同事吃鸭血粉丝，他啃着鸭锁骨拍桌子吐槽，说上个月赶的一个项目，上线前三天老板临时拍板，要把原本第三方跳转的支付流程改成小程序原生，整个团队熬了三个大夜赶出来，上线第一天还是出了bug，十几个用户支付成功没出订单，客服电话被打爆，项目奖金全扣，连团建经费都砍了一半。
这事听得我太熟悉了。干了快十年开发，十次项目翻车，有八次不是开发写代码写错了，是从根上的软件工程管理就歪了。
互联网团队需求变更手写记录表实拍
我之前待过一个小创业团队，五个人，老板拉了一帮同学就开干，产品老板自己兼，想到啥说啥，今天说要加个分享朋友圈的功能，开发写了一半，明天老板说不对，分享到微信群更重要，推翻重写。三个月下来，代码改得连原来写的人都看不懂，项目连雏形都没出来，投资人撤资，直接散伙。
说穿了，没软件工程这层框框兜着，再厉害的开发，也架不住瞎折腾。
软件工程用户需求拆解手绘思维导图
不过话说回来，也不是所有需求都能一开始就拆得清清楚楚。创业项目做新功能，本来就是摸索着来，不可能一开始就把所有东西定死。那怎么办？软件工程早就想过这个问题了，不要求你一下子定死，你先做最小可用版本，把核心功能拿出来给用户用，不对再改，总比你闷头做半年，出来一个没人要的东西强。
我之前做过一个电商类的小功能，一开始产品想做整套的会员积分体系，光需求文档就写了三十页，后来我们砍成了先做“积分抵现”这一个核心功能，上线试了一个月，发现用户根本不用积分，直接就把整个项目砍了，省了好几个月的开发时间，这就是把模糊变清晰的好处。
别迷信完美流程，软件工程开发是折衷的艺术
现在网上到处都在讲这个方法论那个框架，敏捷、DevOps、CMMI，一大堆名词，很多人学了之后就奉为圣经，不管什么项目都往上套，结果就是走火入魔。
我之前待过一个公司，老板听了咨询公司的忽悠，非要上全套的规范流程，改一行代码要走七个审批，要写三份文档，要三个负责人签字，本来一个小时能改完的bug，走流程走了三天，开发效率低到发指，本来三个月能上线的项目，拖了一年，市场都被对手占了，最后咨询费花了几百万，项目黄了。
这不是纯纯有病吗？
软件工程从来没有放之四海而皆准的完美流程，它本身就是折衷的艺术。两三个人的小项目，需求明明白白，你安安稳稳按瀑布模型做，写完测试上线，比你每天开半小时站会折腾强多了。需求天天变的创业项目，你就小步快跑，每两周出一个可运行的版本，及时调整，总比你写一百页需求文档，半年之后再上线强。
很多人有个误区，觉得软件工程开发就是追求零bug，追求完美，不对。哪有零bug的软件？你用的国民级APP，不还是偶尔出点小问题？关键是你要分清楚轻重缓急，支付流程出bug，那肯定连夜改，但是个人中心头像圆角多了一个像素，这种完全可以放到下个版本更新，急什么？很多团队就是本末倒置，天天纠结这种无关紧要的细节，核心功能一堆问题没人管，最后项目能做好才怪。
还有一点很多人没搞清楚，软件工程不是万能的。它只能帮你把正确的事情做对，不能帮你把错误的事情做对。老板方向选错了，要做一个已经被巨头打得没活路的产品，你软件工程再牛，流程再规范，也救不了这个项目。别把锅全甩给开发，说开发能力不行做不出来，很多时候从根上需求就错了。
说回到开头我那南京老同事的事，后来他们复盘，问题出在哪？其实一开始就没把需求锁清楚，老板说“先做着看，感觉不对再改”，听起来灵活，其实是把所有风险都扔给了开发团队。你要是一开始就拉上产品、运营、老板，把核心流程说死，就算改，也要排优先级，挪项目时间，加资源，哪来的上线前三天临时改需求的破事？
软件工程开发说穿了，就是帮你把坑提前挖出来，把变数提前摆到台面上，别等到最后踩坑了才慌。它不是什么高大上的玄学，也不是一堆没用的流程名词，就是一堆前人踩坑踩出来的经验罢了。少点拍脑袋，多点清晰，多点变通，少翻车，就已经赢了大半了。
大多数人对软件工程开发的误解，从一开始就错了
很多外行人，甚至不少刚入行的开发，都觉得软件工程开发不就是找几个会写代码的，排好工期堆功能，写完测试一下上线完事。不就是写代码吗？能有什么复杂的。 真不对。软件工程从诞生那天起，就不是为了解决“怎么写代码”的问题，它解决的是怎么管不确定性。 你想做一个软件，需求会不会变？会。开发中途会不会有人离职？会。用的第三方服务会不会突然改接口？会。测试的时候会不会测出之前完全没想到的问题？当然会。所有环节全是变数，你不靠一套方法把这些变数理顺，那不就是等着翻车吗？互联网团队需求变更手写记录表实拍
我之前待过一个小创业团队，五个人，老板拉了一帮同学就开干，产品老板自己兼，想到啥说啥，今天说要加个分享朋友圈的功能，开发写了一半，明天老板说不对，分享到微信群更重要，推翻重写。三个月下来，代码改得连原来写的人都看不懂，项目连雏形都没出来，投资人撤资，直接散伙。
说穿了，没软件工程这层框框兜着，再厉害的开发，也架不住瞎折腾。
软件工程开发最核心的一步：把模糊的东西变清晰
说实话，我见过最多的坑，就是从模糊需求开始的。 产品经理跟你说“我们要做一个让用户觉得舒服的首页”，老板说“这个功能要做得更有记忆点”，听起来都对，请问什么叫舒服？什么叫有记忆点？能测吗？能验证吗？说不清楚就开工，最后肯定是你做出来的东西，和他想要的完全不是一回事，改来改去，时间全浪费了。 软件工程里最基础的一步，就是把所有模糊的描述，拆成可落地、可验证的具体条目。就说刚才那个“舒服的首页”，拆完是什么样？ 首页完全加载不超过1.5秒，常用的五个按钮放在首屏可视区，广告位不超过首屏的五分之一，夜间模式自动跟随系统切换，点返回按钮直接退回到上一次的位置，不会刷新重进。 你看，这么一拆，谁都知道要做什么，做完了也能测对不对，不会扯半天“我感觉不对”，却讲不出哪里不对。软件工程用户需求拆解手绘思维导图
不过话说回来，也不是所有需求都能一开始就拆得清清楚楚。创业项目做新功能，本来就是摸索着来，不可能一开始就把所有东西定死。那怎么办？软件工程早就想过这个问题了，不要求你一下子定死，你先做最小可用版本，把核心功能拿出来给用户用，不对再改，总比你闷头做半年，出来一个没人要的东西强。
我之前做过一个电商类的小功能，一开始产品想做整套的会员积分体系，光需求文档就写了三十页，后来我们砍成了先做“积分抵现”这一个核心功能，上线试了一个月，发现用户根本不用积分，直接就把整个项目砍了，省了好几个月的开发时间，这就是把模糊变清晰的好处。
别迷信完美流程，软件工程开发是折衷的艺术
别迷信完美流程，软件工程开发是折衷的艺术
现在网上到处都在讲这个方法论那个框架，敏捷、DevOps、CMMI，一大堆名词，很多人学了之后就奉为圣经，不管什么项目都往上套，结果就是走火入魔。
我之前待过一个公司，老板听了咨询公司的忽悠，非要上全套的规范流程，改一行代码要走七个审批，要写三份文档，要三个负责人签字，本来一个小时能改完的bug，走流程走了三天，开发效率低到发指，本来三个月能上线的项目，拖了一年，市场都被对手占了，最后咨询费花了几百万，项目黄了。
这不是纯纯有病吗？
软件工程从来没有放之四海而皆准的完美流程，它本身就是折衷的艺术。两三个人的小项目，需求明明白白，你安安稳稳按瀑布模型做，写完测试上线，比你每天开半小时站会折腾强多了。需求天天变的创业项目，你就小步快跑，每两周出一个可运行的版本，及时调整，总比你写一百页需求文档，半年之后再上线强。
很多人有个误区，觉得软件工程开发就是追求零bug，追求完美，不对。哪有零bug的软件？你用的国民级APP，不还是偶尔出点小问题？关键是你要分清楚轻重缓急，支付流程出bug，那肯定连夜改，但是个人中心头像圆角多了一个像素，这种完全可以放到下个版本更新，急什么？很多团队就是本末倒置，天天纠结这种无关紧要的细节，核心功能一堆问题没人管，最后项目能做好才怪。
还有一点很多人没搞清楚，软件工程不是万能的。它只能帮你把正确的事情做对，不能帮你把错误的事情做对。老板方向选错了，要做一个已经被巨头打得没活路的产品，你软件工程再牛，流程再规范，也救不了这个项目。别把锅全甩给开发，说开发能力不行做不出来，很多时候从根上需求就错了。
说回到开头我那南京老同事的事，后来他们复盘，问题出在哪？其实一开始就没把需求锁清楚，老板说“先做着看，感觉不对再改”，听起来灵活，其实是把所有风险都扔给了开发团队。你要是一开始就拉上产品、运营、老板，把核心流程说死，就算改，也要排优先级，挪项目时间，加资源，哪来的上线前三天临时改需求的破事？
软件工程开发说穿了，就是帮你把坑提前挖出来，把变数提前摆到台面上，别等到最后踩坑了才慌。它不是什么高大上的玄学，也不是一堆没用的流程名词，就是一堆前人踩坑踩出来的经验罢了。少点拍脑袋，多点清晰，多点变通，少翻车，就已经赢了大半了。