具有主人翁精神，作业之前都考虑几步，后期就能为自己减少返工率。
为什么需求一改再改，为什么排期每天一变，导致设计与技术工作停滞或重复做工，抽出想杀死产品的刀，怨气冲天。最后项目上线延迟，BOSS怪罪，技术说因为设计稿没到不能开工，设计说因为原型没确定不能开工，产品一脸苦笑，摊开双手说业务方一会需求这样一会那样什么都没定下来，业务方犹豫半天道出老板你不是说要新加XXX？这就是互联网公司项目流程普遍规律，如果说能做到零返工率，就如技术说零bug一般扯谈。
避免理想化的产品流程
项目流程中，BOSS/业务部门为需求方，产品部为中转站（协调方），设计/技术为执行方。
案例：某咨询平台与一家权威机构合作，对方免费提供测试题目，如需生成测试报告则需付费；专家可通过该测试报告作为了解用户情况的参考依据。如用户在其他渠道进行该测试，则需要缴纳费用，boss的意思是在APP端加入测试入口，通过免费测试引入用户流量，为咨询业务带来获益。
市场部整理需求如下：
套餐分类根据咨询时长决定不同价格体系。
通过运营部协作，为该测试版块拉入一部分咨询专家，咨询方式为“见面”与“电话”。用户可在线发送报告至专家，也可打印报告线下咨询时提供，市场部提供套餐详细信息，用户可进行多次测试或多次预约专家，该测试套餐一旦购买则不能退款。
需求目的：一定要达到XX%营收，关系到所有部门绩效考核。
产品部收到需求，并进行分析，绘制流程图。
流程与需求方确认之后完成产品原型绘制完成，再次与需求方确定最终原型方案，通过之后产品部召开第一次技术评审会，并无技术难度。没问题先给设计排期，设计作业并行时间中，开发需半天左右根据原型初步评估工时，涉及到前端后台还有测试，设计完稿日期之后+1天，上午召开第二次技术评审会，下午根据设计稿评估精确工时，整个项目貌似有条不紊的进行中。
从测试到预约专家咨询流程，确实毫无问题，但是在这个流程中，我们每个环节思考的点都是理想状态，从用户的层面上考虑，我为何要一步步都跟着你的流程走呢？
并不是所有用户都知道该测试的权威性与在其他渠道必须收费，有免费的何必要付费呢。
这份测试题是全国通用的咨询前必填的，具有参考依据的权威性，如用户晓得，可在我方平台测试，提取报告找平台以外专家咨询。
互联网时代最不缺的是各种测试，用户如抱着测试玩玩的心理，几乎不会付费预约专家。
并不是所有用户都熟悉专家的专业性，即使通过免费测试得出报告想预约专家，也无从选择。
如两种咨询方式费用相同，用户更趋向于见面咨询，与专家见面可以交谈的更深入，或抱着侥幸心理购买低时长套餐线下要求专家拉长时长。
如用户可无线次数测试，极有可能为了检测报告差异性测试性的胡乱答题，造成我们成本流失。
这几点问题，是在设计结束进入开发期间财务部和市场部再次细细看原型补充出来的，从我们理想化的流程中，成本流失率比获益转换率高。解决方案如下：
抑制生成报告测试：可免费测试生成报告一次（前端不做提示），如第二次测试需预约专家才可生成报告
专家选择的顺畅性：测试详情页推荐热门专家（用户通过了解测试产生咨询需求）；也可从专家详情页购买测试套餐（用户通过了解专家产生测试需求）
于是，在设计抓狂的怨气中，整个原型又要修改，重新走一边始点，之前的所有排期都不作数。
避免职责划分的清晰性
如果产品部与技术部合为一个部门，那产品部的职责就像指挥官，同个时间段，需要往哪个方向打战，怎么布兵，什么时辰出兵，产品部门需做判断，怎样使出兵出的值。出现需求变更，有很大一部分责任在于产品部把自身职责拎的太清，把自己当作执行方，只需要依据业务部门的业务流程画出相对应的流程图。如产品部不能更为熟悉业务，找到用户的痛点爽点，一而再而三的跑一遍流程，描述用户使用场景，每个环节的用户心理变化，则产品就如一个空有架构的虚无品，不能达到业务目的。
一个完整的项目流程是：需求方输出需求——产品审核需求并做出判断获益性和实现性——设计接收原型并审核产品考虑不周之处——技术评估或执行时审核原型或设计的无理性——测试在评估原型时期编写测试样例，找出原型缺少状态。
如在这个流程线上各部门职责划分太过于清楚，则产品的成功与否，仅绑定在源头需求方，人无完人，一个人走不远，一个团队才能走的远。具有主人翁精神，作业之前都考虑几步，后期就能为自己减少返工率。
