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


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