软件工程只能作为手段，而不能作为目的。
下面是某个场景：
用户：我想去月球玩。
我：你不会开玩笑吧？要知道造一艘去月球的火箭和飞船可能几百上千个亿都需要，我们怎么做出来给你去玩？
用户：为什么人家阿波罗几十年前就可以，而你不可以呢？
我心里想，这用户不会是个大富豪吧？难道要投资n个亿给我们搞，这样我们就可以成为Spacex2.0了。
然后我问用户：你打算投资多少钱给我们造这个飞船啊？
用户：<1w元。
我：...(心中夹带无数恼火，这家伙是精神病院出来的吧？)。
旁边妹子说：你傻啊，一点都不懂变通，人家说是想去体验下遨游月球的的感觉，一定要上月球吗？你带他去VR不就行了？
突然醒悟，那么现在这个需求的问题，就从制造宇宙飞船转化为了寻找VR体验的门店。这对于用户和服务提供者来说，可能是当前情况下最实际的一种解决方案。
以前听过类似的一种说法：软件工程就是满足用户需求，但我不这样认为，实现自己的目的，而非满足用户需求，满足用户需求不过是自己的一个可能目的
简单解释下目的和手段的关系，列举了一个例子：某天C语言老师布置一道编程题：
斐波那契数列定义:
F(1)=1，
F(2)=1,
F(n)=F(n-1)+F(n-2)（n>=2，n∈N*））
要求:输入一个整数n，输出斐波那契数列的第n项F(n)。
我们简单分析下目的和手段
目的分析：
1、我是个好学生，完成作业。
2、期末考试抱抱佛脚就好了，做题目影响我打游戏。
3、这道题太简单，侮辱了自己的智商，我应该去挑战ACM那些大题，这道题我不做了，反正期末肯定可以过。
...
手段分析
1、我只会C语言，用自己会的语言最省事省力，所以还是准备使用C实现。
2、我特别多时间，每天都闲得蛋疼，为了能装装逼，所以决定了使用Lisp来实现。
3、我是Java语言的忠实者，绝对不会使用其他语言编程程序，所以无论如何都要用Java写。
...
实际上对于老师来说就是布置作业的一个动作，但对于不同的人来说，目的可能都会有所不同。如果老师是用户，实际上满足老师的需求，仅仅只是其中的一种目的，而非全部。而对于手段来说，可能会更加多样化，每个人都根据自己的当前资源及其优先度选择最合适的手段。
用户至上派的一句经典名言：
用户就是上帝
这句话听起来似乎非常正确，为了让用户得到最好的体验，我们会竭尽全力，做到最好。但现实中，每个"最好的体验"，背后流淌着的是各种成本的血液。正如前面的例子说的，"我想上月球"是当前用户的需求，但这个需求的实现需要花费巨大的成本，而这个巨大的成本，是服务提供方所不具备的，同时，用户体验服务的时候，也无法支付这种成本。因此我们可以把这种需求理解为"无意义需求"。这个时候能否让用户退而求其之，选择使用VR体验登月呢？对于用户来说，可能他会想：
1.我就是要体验真实的登月，这种假的我不想玩。
2.那好吧，确实登月现在技术也不允许，自己也没那么多资本去完成一次登月。
如果是对于1，那就是"无意义需求"，没必要承接了。
如果是对于2呢？也需要看用户为了实现这个需求愿意付出多大的成本，然后服务方能提供到怎样的交付结果，当然这个就是需求方面的方法论了。
用户至上派的问题在于把目的"单一性"地规定在了用户需求上，也就是需求的"教条化"，忽略了背后的成本，最后的结果可能是根本不能完成项目交付，又或者是项目交付完成了，但后期运营成本过大，导致项目入不敷出，最终也导致了项目也走向了灭亡。
而与用户至上派相反的是软件工程目的派，这类派别大多数是技术出身的人士，由于错误地把软件工程作为目的，因此会导致在实际的技术选型和技术架构的时候，容易出现为技术而技术，因为某种技术特别火，特别牛逼，特别高大上，"现在xx都用这种技术了"，所以我要用某种技术。因而忽略了这项技术和这个项目是否适配。技术本身的使用难度，维护成本，和当前人力资源技术匹配度，学习成本，容错率等(属于软件工程方法论范畴)对整个项目实际上都具有生死攸关的影响，过度设计，设计不足从而使得后期项目维护成本过高而导致项目失败的例子也不再少数。
总的来说，当把软件工程的目的和手段搞反了，软件工程变成了目的，那么则会走向软件工程目的派。当我把软件工程仅仅当成手段，但如果出现目的的"教条化"，则会走向用户至上派。前置更多的是软件技术人员容易犯的错，后者则是产品经理或者需求人员容易犯的错。而本篇文章的目的，一方面是澄清软件工程的目的和手段的关系，另一方面，是强调了对目的思考的重要性，不同的场景和背景下，目的也许都需要跟随着变化，一旦目的的"教条化"，也一样会出问题。
最后借用电影《寒战》里面的一句对白：
爱奇艺截图
爱奇艺截图
软件工程只是手段，最重要的是目的。
网友评论