经历了几家公司，现在入职时首先问对方的问题就是，你们的开发流程是怎样的。
先说说上家公司在我修改之前的开发流程。
一，承接需求。从市场，运营同事那边将需求接回来。（坑：老板CTO人缘极好，因为所有的需求只要找到他的都会接下来。然后安排下来之后如果有什么不能实现的，就安排下面人去驳回，可想而知困难有多大，通常会被怼你老板答应了！！！深恶痛绝，为什么不看需求清单！！！）
二、画原型，写文档。（坑：如果是标准文档，包含判断条件，异常处理，补充说明等等，通常会耗费原型的3倍时间。而这个时候开发还不知情，所以能否实现根本不知道，就涉及到后面移交以后的返工修改。此时延误的工期全算产品经理的责任）
三、移交UI、开发和测试。（坑：1、在上条中提过，没有论证过可行性。2、开发听过即可没有时间研究文档，对于工期预估不准）
四、内测。（坑：1、开发完后直接丢给测试，此时通常测试压力很大，且没有经过自测会有些低级BUG影响测试效率。2、测试开始时已经过很长时间，如果没有用例和评审则可能测试和开发测完之后你忽然发现和你的需求根本不一致！3、测试和开发经常打架，找产品评理，此时因为各执一词，产品虽然有原始需求但必然影响另一方的情绪。）
修改后：
一、承接需求，出规范的产品提出文档，将所需的项目背景，预期目标，定位人群，具体功能，责任人等一一列出，形成规范化需求书，这个过程中可以帮助需求方梳理思路，也能帮产品经理节省大量时间。
二、原型产出，与UI UE 开发组长评审原型可行性。以最快速度先产出原型，此时可以不标注异常逻辑等细节，是以最小代价验证产品的可实现性。同时如果原型通过，则移交给UI UE，在产出文档时同步产出设计稿和交互稿。
三、需求评审，需要所有项目成员到场。在完成需求文档后，提前一天发会议要请，并附上需求文档的邮件，让与会人员提前浏览，能节省大量开会讨论时间。在会议上向所有开发人员移交需求和UI稿。如果有问题，则会后更新发出，重大问题二次评审，如果没问题，定稿，开发测试人员以此为据开发，后续如果有需求变更走变更流程，此处不细说。
四、测试用例评审，在开发结束前，测试同事需要撰写出测试用例然后将开发，需求方，产品召集起来确认测试用例。以此为准，否则算需求变更。
五、开发自测，在开发完成后，必须得根据测试用例自测通过才能提交给测试。
六、内测验收，测试完成后，给到产品经理，产品经理通过后给到需求方验收。通过后上线。
以上所说是最简单的瀑布流，如果大家有什么问题可以留言讨论。
网友评论