那些注定要没什麽用的专案开发法

（终於可以讲这个了.......吗？）

如果能够不用「是否有成功通过验收并结案」来判段专案是否成功，那这个标题其实很好懂。

像：是否有留下成功的工程经验方便下一次专案进行得更顺利？
像：是否有留下成功的设计模式方便下一次专案进行得更顺利？
像：是否有建立成功的商业模式方便下一次专案进行得更顺利？

即便是「无法验收的专案」也有可能在这些问题上得到「是」的答案。

但偏偏很多专案团队在业务上总是抱着一种「客户喜欢垃圾就给他垃圾」的心态，请问花了大把工作天去完成的专案，最後团队成员学到的尽是「如何产生垃圾去给那些没品味、短视、仗着自家有集团规模优势裙带关系可以挥霍的客户在专案验收会议上得意的签字买单」，那团队大概一辈子都只能跟「产生垃圾」的勾当为伍。

对很多专案团队管理人来说，这是很划算的，因为他的个人职涯看重的是团队的「营业额」，只要这次的团队结案了、钱进来了，他在跳槽下一份工作时用的履历上就会有一笔更漂亮的数字。

但对其他人来说可能就不是那麽回事了。

工程师是否有机会验证自己的专案架构？设计师是否有机会实现自己的美学认知？（忽然忘了这到底是什麽东西？）产品企划是否有机会建立自己的商业概念？......不！大家得到的只是「另一件垃圾」而已。

这跟标题有什麽关系？

我的主张是「专案会死掉，除了专案团队本身的管理沟通技巧与工程设计能力以外，其实很多都是政治（权力）考量长期介入扭曲了一个团队运作的最终结果。」

像（之前有提过）「为什麽要大量导入第三方OpenSource的元件」？——因为「决策者以为这个世界上真的有那麽轻松容易就降低成本又快速满足客户需求的方法」。（最後专案可能就会因为在技术上使用了缺乏验证的元件，管理者又拒绝花费更多时间成本去进行修正，最後导致验收失败......这是其中一种可能。）

像最近很火红的「敏捷式开发法」，——用我的说法，其实敏捷式开发法要真能充分运作，每阶段任务在规划时就要考虑到「需求还没有提到的地方」。
像本来用在A环境下的X功能，忽然会被迁移到B环境，如果两个环境无法提供相同的初始化条件，那X功能就会无法搬移，当收到搬移的需求时，要重新大规模修正元件？要重新大规模测试元件？还是要重新大规模修正环境？要重新大规模测试环境？......通常专案团队会怎麽选择，答案有点明显，问题是「避免这种事情发生」也是「敏捷式开发」的目标与功能之一，真发生这种事情时怎麽选则就不是那麽有营养的一件事。
但先不论「敏捷式开发」的「敏捷不等於快」，为了让开发过程富有弹性、能够应付修求更动，需要建立的团队规模与运作模式，这些也都需要成本（金钱/时间），但这种成本通常.....所以敏捷式开发的命运经常......

故，那些注定要没什麽用的专案开发法。