虚拟团队的管理思路

11月17日下午的虚拟团队和实体团队问题，刚好以前的经验里，基本上90%的项目都是虚拟团队组成的，所以列一下之前的管理方式，供参考。

虚拟团队有多种组织方式，包括：
1. 虚拟团队组成实体项目组；
2. 虚拟的业务、技术团队，作为长期的业务/技术决策委员会，或者短期的问题虚拟团队，只为了开拓或者寻找后续项目的思路和业务的突破点
以下描述的是针对第一种有实体项目组的虚拟团队。

虚拟团队人员管理，当有新起的项目时，项目会从几个部门抽调人员，包括：产品中心（业务顾问，产品开发），实施中心（项目经理，实施开发，运维），QA（质量管理人员、测试人员），由于是有长期的虚拟团队管理方式，我们在选择虚拟团队项目人员的时候有以下原则：
1. 镀金型人员，目的：在能力上或者技术上有很好的认可，为了将来能包装或者作为更上层的备份，我们会拍到一些重大、重要的项目里去担任比较重要的位置；
2. 一次性人员，其中，又分为：
a. 短期性，为了解决某个项目的技术，业务难题的短期支持，特别表现在业务顾问，架构师，高级产品；
b. 消耗性，处于某种目的，直接排到项目组内；
3. 长期性人员，针对这种人员，类似于管培生的管理方式，参与各种项目，为将来分公司，分部门储备人员；

对于1和2.a，都会在任务完成后，回到原团队，对于2.b,视业务情况和项目情况，灵活决定去留，对于3，长期在各种项目

人员的绩效管理：
1. 工作量的评估和归口，由于不管是销售、业务、产品、研发，都会填写日志，通过日志对工作所属项目和范围进行统计；
2. 季度绩效的评定，分为交叉季度和非交叉季度，原则是按照投入的比例（通过第一步统计）进行考核；
3. 有一个核心点：派出人员部门的收益，是受派出人员做的项目的收益决定或者影响，因此，派出人员部门本身已经对项目有足够的重视度。

人员项目结束后的问题，如何保证熟悉部门，以及如果是部分投入，如何保障多边的工作：
1. 组织行为，不管是产品、业务，在过程中，通过流程、存档，确保过程的可追溯和快速熟悉，包括：
a. 部门内部事务：公告，文档记录；
b. 部门流程变更：OA系统流程、定期的制度重宣导；
c. 业务流程的变更：业务文档变更记录，定期的业务宣导和交流；
d. 研发：所有版本的记录、过程文档，手册；
2. 部门管理行为，识别需要熟悉、了解的事项，定期同步，包括管理人员的沟通，交流，与项目负责人的同步等；

与现有公司遇到的虚拟团队的差别：
1. 这种虚拟团队的工作方式，由于已经是一种惯例，派出部门人员本身已经有冗余和储备，因此对于原部门工作并不是有太大影响；
2. 派出团队的交叉并不会有太多，最多3个部门；
项目可以根据客户、金额区分优先级以及重要程度，这个共识是管理层共识，因此在派出人员的选择上已经有参照基准，并且当前项目多为内部成本项目

---pending，当前的管理方式基于之前问题的优化