本人所在是一家零售电商综合平台，集团为了更极致的用户体验，提高自身物流配送能力，于年前公司收购一家同行快递公司。在此背景下，IT信息部为了业务能够顺利整合双方资源，业务能按照计划进行融合，故提前进行系统融合规划设计，保证公司收购后的平滑过渡。

本人作为项目组的核心成员，亲自从需求调研至项目上线运维的全流程进行了参与。目前项目已顺利结项，下面来从3个方面进行总结，特别是本人犯过的错，踩过的坑。本人第一次投稿，针对不合理之处，还请各位大侠指正。

需求调研：深刻理解业务，细致搜集资料

每一个产品经理都明白对业务理解的重要性，但并不是每个产品经理都能明白除了自己要深入理解之外，还必须要让项目组的开发、测试也要进行理解。回顾整个项目，对需求调研过程中需要注意的地方总结如下：

需求调研过程中，一定要对业务现场的每个操作场景要做图片、视频资料采集，保证后续可反复查看理解；本人在业务现场进行需求调研的过程中，自认为自己对业务的理解就可以了，所以没有认真对业务现场进行图片和视频的资料采集，只是简单图片拍照。待需求整理完，与开发测试进行沟通的时候，发现他们不能理解真实的操作场景，仅凭照片不能完全还原全部细节，导致本人对业务现场进行二次调研搜集资料，浪费了不少精力。待二次调研搜集资料后，发现后续在项目过程中还是会反复用到视频资料来理解业务。

需求调研过程中，除了需要对业务流程进行梳理之外，还必须关注业务量、用户角色分工、用户素质、使用场合（如网络环境）等细节；本项目中，由于涉及两个公司业务流程的融合，初期只是针对业务流程进行梳理融合，并未关注流程中的用户角色分工，导致初版设计模型中的部分产品功能不能满足业务需要，只能进行二次设计。

举例：分拨现场进行装车环节，业务流程在双方流程中其实都一致：需装车开始—-扫描包裹—-装车完成—-发车确认。

由于公司目前业务量比较少，业务现场整个操作流程都是一个人单独完成，故现有功能设计是将整个流程整合在一个功能页面负责完成的。

本项目中，业务梳理结束后，针对该模块进行设计时，也自然的按照现有功能设计方案，将整个装车流程功能设计整合一个功能页面负责完成。

待初版模型交付业务沟通后，发现设计中忽略了用户角色分工的考量，不能满足业务需要。新公司的业务量大，业务现场的用户角色分工细致，并不是一个人完成全流程，而是多角色配合完成。所以对该流程进行二次设计，将针对每个用户角色功能进行区分设计。

产品设计：千万要关注细节

1.不要着急进行产品功能设计，需在此之前，在业务流程梳理明确的基础上，定义好系统框架。

2.产品设计过程中，特别是需求文档编写时，一定要对细节性进行明确定义。产品上线后一般主流程都没有大问题，往往出问题最多的都是一些小细节的问题，所以在需求定义阶段，在文档中需要对细节问题进行明确定义，比如null和空的问题、字段长度、小数点、枚举值定义等小问题，往往小细节会导致大问题。针对接口交互，一定要考虑好异常数据接收处理、数据接收先后顺序、接口并发、接口回执等问题。

本人在此项目中，负责设计的接口曾出现过因为接口并发过大导致生产问题产生。虽然系统逻辑上设计了校验规则，但是在上游系统在毫秒级的短时间内下发多条数据的情况下，下游接收系统同时按照规则校验时失效，导致接收方数据处理产生异常。后来经过接收系统在接口处理中加入了排队处理机制才解决此问题。

3.产品设计初期，不能只考虑功能设计，还需要提前考虑性能设计。虽然产品性能多是开发需要考虑的问题，但是在产品设计过程中，产品一定要对自己的功能的业务量进行预估，并与开发提前沟通产品设计方案。否则待到上线后发现性能存在瓶颈，这个时候再来调整方案很可能就是伤筋动骨了。

项目管理：要有主人翁精神

在项目管理过程中，产品一定要有主人翁精神。产品上线后遇到的任何问题，不管是开发原因还是测试原因导致问题产品，产品都必须负有责任，开发交付后除了测试人员测试产品之外，产品也必须主动全方位验证自己产品，全面发现问题。这样也能更好发现自己功能上的雷区，更好理解产品实现逻辑，未来出现问题也能更快的定位原因。

本人在项目过程中，要求产品团队每周定期汇报自己发现的产品问题以及解决方法，并将此类问题解决后要求与测试团队共享并回归测试。分析此类问题，发现很多问题都是测试团队未发现的问题。通过此方法，可以让产品与测试更为深入的了解产品对应的用户场景以及功能逻辑设计。

沟通非常重要，产品要协调开发，测试，业务，PMO，UED多个部门和人员，所以产品要善于沟通，遇到问题要勇于承担责任。开发，测试有资格甩锅，但产品永远不能甩锅。

每次总结后，总会发出这样的感慨“我X，这么简单的错误我竟然没注意”。是的，人往往容易忽略简单的小细节，但成功的产品往往就是优秀在细节。作为一个产品经理，一定要多总结，不要忽略细节，把产品做到精致。