今天中午,技术部开了个会.虽然我不是参与实际编码及策划的人员,但我还是很认真地听了他们团队之间的各种问题反映.在这些问题里,最突出的就是如何与一个方案策划人员很好地沟通并尽量减少双方因为领域及认知的不同而导致的不协调.
一位刚毕业不久的程序员,负责的某个模块被策划及运营部门普遍地反映为进度比较缓慢,返工修改率也高,不能很好地领悟方案的具体细节部分.虽然那位同事平时工作并不算很松懈,甚至在整个技术部也算是表现比较好的职员了.但就是因为平时与策划人员沟通方案的过程中,有了先入为主的思想,以自己程序开发的思想去寻求策划人员对于方案的原始构思解释.结果导致的是策划人员又以自己的思想(他并不一定懂得任何一种的程序开发,而且很有可能他原来的工作单位的部分已经适应他的思维的程序员可能很快捷地理解他的意图)去试图解释某些具体的流程或逻辑.然后,程序员在未完全互通思想的情况下,开始了开发编码工作,结果呢,要修改的,不符合方案原意的部分为数不少,导致了整体进度的缓慢,事倍功半得到了良好的体现.

在我看来,首先这位同事必须先根据方案设计构思自己基于程序开发思想的流程及逻辑走向,最好有条件画出结构图,然后映射好结构与现实功能间的关系,然后与策划人员就这个结构进行互通,这样既能使自己明了策划人员对于某些部分的实现思想是如何的,而又有利于策划人员发现自己的思想是否有偏离方案.何处需要更正,最后达成共识.如果能做到这样,那么接下来的编码工作时间估计能大大缩短几个周期,例如返工修改,实现功能逻辑测试等等.如果你对这个方案哪怕有任何细微的疑惑,都必须由这个问题的根源开始与方案策划人员沟通彼此思想,只有统一了思想后,才是动手的时候.

  • 分类: 学习心得