后台|后台设计漫谈——电销系统设计思路( 三 )

对稿之后就是把修改的点列出来，然后逐一修改。
这一步其实不复杂，重点是沟通得细一点。
以我的经验来说，对稿的时候可能会需要做比较多的修改：一是因为大家的理解未必一样；二是因为电销员的想法会发生改变，所以会需要根据他们的想法做调整；三是有可能在第一次沟通的时候有些东西没有讲出来，所以需要做二次补充。
以上几种情况都是有可能的，而且可能是同时会遇到。
四、开发与验收后台系统其实一般来说不如前端受重视，这是常态。对于很多小公司来说后台系统甚至是敷衍的。
所以在测试环节一定要让电销部门也同时介入验收，一个是能促使技术部门尽可能地按照你的方案进行实现，二是能合理管控电销员的预期。
我遇到过很多次，后台长得还不如我的原型稿好看，这你上哪里说理去。这个时候就需要管理预期了，让电销部门提前介入就是管理预期的一种方式。
技术的同事经验越少的对于后台的易用性通常重视程度越不足，同时很多公司都是业务驱动的，一味强调快，自然而然就放松了标准，这样一来对于实现程度来说也有非常大的影响。
所以一定要注意管理预期，不要因为你无法干预的因素而影响对你工作的评价。
我知道有些朋友甚至领导是反对让业务部门直接介入研发环节的。
一部分是出于岗位认知的原因，认为这个事情就应该产品和业务对接好，技术部门就不能和业务部门进行对接。
我个人的见解是这个认知大错特错，对于一个业务线来说，业务、产品和技术应该尽可能融合，技术接触业务就能更好的理解业务需求，这样就在实现的时候会更好。
一部分是出于部门认知的原因，认为业务部门和研发部门是两个不同的部门，产品经理应该站在研发部门的角度而不是业务部门的角度，这种情况通常是在大公司待久了，产品又放在研发中心下面，所以研发的负责人就会这么来判断。
这种情况当然不是全部，但是我遇到过，研发中心的负责人CTO直接就当面指责我不应该把业务拉进来，导致技术和业务部门有摩擦。我当时没说啥，但是很快就找了新工作。一个公司的高层，居然主动搞部门墙，格局就不是很高了，不值得跟随。
五、最后今天说的东西其实并不具体，都是个人的心得和体会，但也还是有点东西的，希望对大家有个启发。
本文由 @产品人玄青原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议