周末了，简短记录一个小案例。
做过系统集成的朋友不知道有没有过这种体会：就是在系统集成中，有时候用自己公司的一款产品，反而不如直接用外购的设备？
近期在张罗一款新系统，系统中要用到不少厂家的设备，其中一款设备可以用公司内部自研的，但需要做一些改进。从成本上来考虑，当然是自研的更有优势，但由于涉及跨部门、跨组别的沟通和协调，推进起来就有些问题。
具体来说，公司自研产品是A，其归属于甲产品（经理）线；系统集成要用到的是基于A的改进版B，归属于乙产品（经理）线。在这个组织框架下，乙产品（经理）线需要输出需求给甲产品（经理）线，然后甲产品（经理）线需要形成技术规格书、组织开发资源进行开发，同时维护产品A和B。
如果用图来表达，大概是这么个样子。
可能很多人觉得这不很简单吗？但实际遇到的问题并不如此。
首先第一点，乙产品线相关人员可能对产品A并不了解（大体如此），其输出的需求往往并不非常清晰。
其次，甲产品线无形中增加了工作维护量。
再有，甲产品线，其对接人员由一个产品线扩展到两个产品线，产品的认识不同。
站在乙产品经理的角度，他认为自己只是提出使用需求给对应的乙产品线开发团队，但此时甲产品线开发团队其实并没有确定的需求来源。
在这种情形下，组织一个有效的会议就显得相当重要。
其一，乙产品线开发人员是第一手资源接收方，但要评估需求的输入是否足够全面和准确，此要求只能交由乙产品线经理去负责，要定义出产品B和产品A的异同点，详细的使用场景以及改动点。
其二，乙产品线经理要和甲产品线经理直接沟通，再由甲产品线经理将之形成文档传递到甲产品线开发团队，这样能保证信息不会在传递过程中有遗漏，同时在相互的交流和碰撞中，也许会有新的产品思路产生。
第三，乙产品线是产品B的第一个客户，其有责任和义务对产品B的实用性提出及时的反馈。
写在最后
看似简单的问题，其实隐藏着隐患和缺陷。
在计划使用产品B的过程中，我回溯了两年前的做法（两年前就有类似需求），但当时就是很混乱的一种状态，由乙开发团队直接和甲开发团队直接对接，导致产品一直无法有效落地，只是凑合着能有一个版本的产品用，但产品A在升级和迭代过程中，当时对应的产品B早已面目全非。
这次再次遇到类似的场景，在协调乙产品线经理的时候，他仍然是认为：项目已经交给乙开发团队去做，为什么还需要他去协调甲产品线产品经理和开发团队？
但在一次有效的会议和思维碰撞后，我认为效果还是不错的。
首先，乙产品线对产品A及衍生出来的产品B有了更多的了解，对乙产品线来说，理解并用好产品B便有了基础。
其次，甲产品线认识到其产品A有更多的使用场景和需求，扩大了产品线的宽度，同时对比了行业最佳厂商的产品地图，也引发了一些新的思考。
最后，我认为最重要的是，无论是产品需求、规格甚至产品目标，最终有了可追溯和持续优化的途径。
联系客服
