为什么当软体或网路服务公司面临一波离职潮后，新来的同仁总是会抱怨：没有规格文件、没有版本管理、Bug修不完、不如重新开发等耳语。又或者，为什么交付团队开发的软体，就算老板自己跳下来当QA都还是很辛苦？显然有稳定性失控的问题！

确定不是恶搞？“软体”落地就那么困难？

　　看到这一段话的人，可能有些老板想说：“对呀！为什么？我是不是被搞了？”

　　在笔者的观察，会发生此结果的原因往往是：

　　1、公司没有相应的制度（或流程） 

　　2、老板不遵守制度（或流程） 

　　3、老板对正确的软体误判  

　　关于第一点与第二点，有两个面向：一个是组织架构面，另一个是开发管理面。而关于第三点，笔者只能说，这是God’sfeeling了，不论是经验、时机、品质或维护等，其实都攸关产品的成败，这种事情就交给老天了。

　　在组织架构面，公司的产品多半是由老板发起，然后团队成员讨论，然后交由PM勾勒页面、动线后，SA进行系统分析，最后交由RD开发。但是一旦老板突然的想到某个功能很重要，此时PM可能会说：这样的话会延迟之类的，老板可能就变成直接对RD要求规格变更，常此以往规格文件便会自然的丧失作用。最后的结果就是产品无法维护或者功能需求崩溃。

　　另一个面向是开发管理面，最近坊间最流行的开发方法Scrum或者Agile，笔者认为此两种方法中最重要的部分不是每天standupmeeting，而是冲刺规划中的内容要：独立、可量化、可被测试。其中，可被测试又最为重要，换句话说，如何定义出可被测试的规格文件，便是一种以终为始得需求分析。有了可被自动测试的规格，其产出的结果一开始就决定了，稳定性相对就提高了。

　　而团队如何准时交付正确的软体，笔者建议流程如下：

　　团队应该建立一个检查清单，确保该讨论的有被讨论，被讨论的结果有被纳入规格文件中（可以是分阶段开发，但仍要标示）。

　　规格文件中有三种测试架构包含：行为测试、可接受测试（类似抽样检查，检查最重要的环节）、单元测试（配合可自动化测试平台检视）。

　　规格文件中要包含补充修正章节，确保所有的补充与修正，是书面的、是延续计有主轴中又可以被查询、理解的。

　　可参考Scrum或Agile建议的工作方法，透过事前的SprintPlanning与Stand-upmeeting随时检视、调整、修正、改善每个阶段的冲刺，确保产品（软体）的目标、品质与时间能够接近预期！透过上述的流程，让老板与团队从一开始也许是目标、预算、SEO与程式架构等，都可以事先透过有系统的规划跟讨论，不仅可以提升讨论品质，也能减少老板事后需要大幅调整或插入功能的需求。


（免责声明：此域名下的内容以及本文内容均为转载企业宣传资讯，仅代表作者个人观点，与本网无关。仅供读者参考，并请自行核实相关内容。如果您发现网站上有侵犯您的知识产权的作品，请与我们取得联系，邮箱:27652307#qq.com （把#改成@），我们会及时修改或删除。）