随着对企业业务和人员及流程的进一步理解，我自然而然想到下一步要将部门分成不同的组织。
为什么要分成不同的组织呢？是因为这样可以进一步提高专业化程度。提高效率，提高专业化的重要手段就是相同专业的人员的聚集。
我先想到的是三个部门，一个是产品部，然后是研发部，最后是运营部。
这企业内部运行的系统，包括资源和采购，它的选型以及立项都是由产品部来负责。
系统在公司内部的开发以及二次开发都是由研发部同事来完成。
系统上线之后，数据分析系统运维等都是由运营部来完成。
想到这面我就想到了一些场景，例如在公司内部推行自动化，但是自动化不仅仅是创建项目，更多的是对已有项目的局部优化，这就需要运营同学首先分析业务的数据得出绩效较低的部分，然后再由产品的同学去和客户沟通，如何提升效率的解决方案，尤其是通过技术来提升效率的方案。最后是研发部同学将通过自动化技术提高效率的方法研发并交付。当然上线时候仍然由运营同学进行前后效果对比。
通过这么一个局部优化的事情，可以看出来，需要三个部门人员协同。但是让我感觉到，如果不能区分，那么跨部门之间的协同将会是一个灾难。
根据以往的经验，部门之间分工如何明确将会是一个浩大的工程。同时各部门之间的扯皮，也会消耗内部绝大部分的精力，这就会使最初提高效率的目标，通过实际的扯皮消磨掉。
如果不采取专业化分工，还有种方案，就是根据整体的效果进行效果。也就是分别建立a组和B组，每个在这种方案下，组员不再会对具体的任务进行区分。
在这种模式下，组内的成员共同的目标，为齐心协力完成这个共同目标。而我的期望是人位员不要在固定岗的固定技能上锁死，具有一个专长和其他场景的通用能力的并且愿意和其他的同事合作，体现整体的最大化。
但是这样虽然会让组内所有的人员协同。但是跨度之间仍然存在着较大的沟通问题。
目前团队比较小，大家遇到问题的情况下，都愿意去了解去学习，都会承担产品，运营研发的相应职责，虽然不够专业。
如何保持小团队的活力？同时能够。兼顾企业专业化的提升，也许可以参考一下中台模式？
通过后台统一介绍大平台，前段的应用分别由不同的小组完成产品，研发和运行。但是公共服务全部提炼的公共服务组当中。这个时候需要一个二把手去承担公共服务的整体规划，从而解决底层技术的复杂和服务的要求。同时这种模式也避免了不同项目之间技术不打通的烟囱模式。
网友评论