几个版本之后

发篇文章感慨一下，从去年4、5月份开始，产品线正式成立（刨去mvp时间），到现在10个多月，从0到1，经历了太多。两地跑，累计飞了8万多公里，150多个小时。经济舱你懂的，真的是坐飞机都坐吐那种…..

从0开始建立产品线团队，现在产品线大大小小五个团队：产线组、平台组、测试组、产品组、架构组以及管理团队。团队已经相对完善。

从0开始确立产品目标、产品受众、产品价值，产品版本从0.1=>0.2=>0.3=>0.3.3=>1.0=>1.1。产品的roadmap已经清晰。

当然这段过程走过来，发现了一些需要提升的地方，为了让产线更加阳光灿烂。

年前大家做了下总结，确定了一下2019年的节奏。

1. 严格按照产品roadmap进行产品的迭代。力保核心功能。
2. 产品需求定义需更加清晰和严谨，必须有功能优先级，如果遇到无法自圆其说或者技术投入和产出存在较大差距的，应根据评估情况，决定做不做（由于产品上线的客户不是很多，对于某些需求不是很确定其价值，所以确立了这条规则）。功能不是越多越好。
3. 技术选型的出口人只能是平台组负责人，平台负责人对技术选型负全责。
4. 现有技术架构的优化、技术团队的工作流程优化、文档管理等由架构组负责，负责人为业务架构师。
5. 产线组、平台组、测试组三个组合并进行重新（虚拟）划分，划分为虚拟团队的形式（业务功能小组，非功能需求小组、现场支持和研发目标承接小组）。每个组暂由Scrum Master负责日常工作管理。

领导说了团队一直在用敏捷的方式再跑，但是还不够特别敏捷，今年会邀请Scrum中文网的创建人来继续对团队进行敏捷训练。找到适合团队的小步快跑方式。

一个团队是否有活力或者是否有能力，我觉得就是看团队目标是否对齐、管理团队是否足够开放、看团队是不是能自省、是否能自驱动、是否有立规矩。

2019 会怎样谁知道呢？

特别说明

虚拟团队为了解决什么问题？

1. 运转效率提升。围绕不同的目标，把相关的各职能的人员放到一个团队，解决大家之前反馈的沟通决策链过长效率低，团队优化跨组织推动麻烦等问题。
   

2. 保障非功能需求等长期目标。按照目标拆分团队，保障纳入产线规划的技术规划，持续有人去做。
   

虚拟团队的拆分原则是什么？

根据产线规划目标，按照目标的耦合程度，把目标做拆分，由不同的小组去承接这些目标。根据各组的目标和个人发展诉求相结合，把不同的同事放在不同的小组。不同的周期，小组的组成会有适度调整

都说了虚拟团队的设立是为了提升运转效率和更加敏捷的自优化，那么哪些事情我们可以自己做决定？

一句话：不涉及约定目标定义调整、目标优先级调整、周目标是否能达成的事项，团队都可以先决定，再做向上和左右的同步。