当前位置:C++技术网 > 资讯 > 工作中如何做好分工协作提高工作效率

工作中如何做好分工协作提高工作效率

更新时间:2017-09-11 16:13:32浏览次数:1+次

    本文就开发工作中如何做好分工协作进行一番讨论,供大家参考。
    这是根据我部门里的分工协作的经历,经过一番思考总结而来的经验。我们部门涉及到数据库设计、接口开发、前端开发、UI界面设计、运营部、市场部。我之所以按照这样一个顺序来列,是有意义的。从数据库到市场部,我们看似没有直接关系,但是却关系紧密。从部门来看,我们可以分为开发部、运营部和市场部。而市场部对接客户或用户。从整体上来看,也就形成一个回路。对于一个回路来讲,每一个环节都是非常重要的。
    而多个部门或者多个职位之间的分工协作,也就显得尤为重要了。那么我们应该如何做好分工协作呢?
    对于市场部来讲,针对客户或用户做好足够的市场需求调查,是最基本的事情了。而这个市场需求调查,可以直接关乎产品的优良。对于一个好的受欢迎的产品,必然是经过大量的市场调查得到的,而不是通过拍脑袋想出来的。而客户或用户的各种需求,很多你想都想不到,必须去问。
    当市场部拿到最直接的需求后,运营部或叫做产品部就需要将需求转换为需求模型,然后再形成产品的业务逻辑。而这个业务逻辑的形成,需要大量的研究,调查。那么运营部如何做好业务逻辑功能的设计呢?足够的需求信息是必要的。但是因为运营部可能并不是直接接触用户或客户的,或者接触的不够,所以知道的需求以及可能的需求是不够的。这样在设计产品的时候,可能有所遗漏。那么如何改善这样的情况呢?作用就在于市场部。
    市场部并不是拿到单子就算完事了。拿到单子也就是确定了很多的需求,包括隐形的需求。这个需要市场部仔细的确认。然后将所有得到的需求都要交给运营部,并将实际情况都告诉运营部。这样,运营部虽然没有直接与客户或用户沟通,但是可以得到详尽的需求资料。这样在设计功能时,也就可以考虑的更加完整。也就是说,市场部和运营部是有直接的对接关系的。
    运营部设计出来的功能逻辑,最终要得到实现,需要开发部的支持。那么运营部如何将设计出来的功能逻辑交给开发部呢?这里就是运营部与开发部的沟通对接了。
    运营部对于开发可能不了解,对于很多功能在实现上没有概念,所以设计出来的东西可能实现起来不方便,或者本来就有一些现成的不错的方案。如果有这样的方案,在实现上也就可以更快。所以,运营部在设计功能逻辑的时候,是非常需要和开发部深度沟通的。
    当功能逻辑沟通后,开发部可以估计实现上的难度和时间。另外,避免了开发上的不便,在满足需求的同时,再用最省时省力的方案实现。如果沟通不好,就可能在功能需求和开发实现上造成很多的冲突,以至于频繁改需求,甚至是推倒重来。这样都是非常低效的。所以前期沟通是非常重要的一个环节。
    然后就是开发部内部的多职位的协调工作。我们这里列举了UI设计、前端开发、后台接口和数据库设计。UI设计中的界面,必然是需要前端直接开发出来的,所以这个关系的紧密程度就不言而喻了。而前端通过调用后台接口完成功能逻辑,这种紧密联系也不用多说。那么后台接口的实现,基本上要基于数据库。后台接口除了实现业务逻辑外,还有就是对数据库的操作。那么后台接口自然和数据库设计又紧密相连。
    那么UI的改变,会不会直接影响到数据库呢?当然可能。那么用户的需求的改变会不会影响到数据库呢?当然可能。其实,从市场部的一个环节开始,直到数据库的设计,其实有着一条看不见的联系的。如果处理这一条联系,是决定分工是否协调的关键。
    我们知道分层设计的思想。那么将分层设计的思想用在分工协作里,就非常好。我们每一个工作对上对下都是有影响的。如果我们不加以控制,将会影响到整个系统。不要以为简单改个界面,加几个数据,这个可能就要从系统的最低层到最上层的界面要全套的改变,你还敢说这是简单的改变吗?
    虽然如此,那么我们如何应对需求的变更呢?如何做好分工协作呢?
    需求是变的,分工是必须的。但是我们人类的大脑更厉害。对于需求的研究做到位,我们自然可以预见一些可能预见的改变,这样在设计的过程中就可以充分考虑到这些因素。虽然客户或用户还没有提出来,但是,我们可以预先设计进去。当他们再提出来的时候,我们只要简单的做一个调整就可以满足要求。但是这个设计,是需要我们用心去做好的,不是随便就能够满足的。这也是应对需求不断变化的唯一有效的办法。
    而我们在分工的协作中,我们要将我们自己这一层的工作对上提供保证,对下做检查。我们也就是要让问题无论如何都不要通过自己这一层肆意的泛滥下去。如果需求一旦改变,但是到了你这一层,因为你做了更多的考虑,到你这一层时,需求得到了满足或者支持。那么此时需要改变的,也就只有你的下层需要改变。举个例子来说,如果开始需求是搜集用户的信息,只需要搜集名字和年龄即可。那么我们在设计数据库的时候,还是按照详细一些的信息来设计存储。这样在后面如果需求变更了,需要搜集更多的信息的时候,数据库依然能够满足。而前端界面对数据的处理,也是动态的处理,而不是写死在程序里。这样尽管需求变了,程序依然可以正常工作。改变的最后只剩下改变配置文件了。而UI方面,则也是针对多信息的搜集方式而设计,如果信息变多了,就只需要简单扩展一下界面即可,而不是针对提出的需求做简单的量身定制。
    所以说,在做好当前需求的同时,考虑到更多的可能的需求,在设计时做更多的未来的考虑,做更全面的思考,这样做出来的东西适用性更强。此时,我们对上是可以提供可靠的支持的。
    这样的话,分工协作其实也就没有那么难了。然而要做好,确实也不是一件容易的事情。但是我们始终都考虑到全面、长远和变化,给上层提供一个可靠的支持,相信分工协作只会越来越顺利。