聊聊自驱团队的构建（二）
曾经有一位大佬分享他组建技术团队的心得，当时我问了他一个问题：请问你组建的团队是项目型组织，还是职能型组织。但是大佬似乎对于这个问题没有特别直接的回答，所以在这篇博客中，我想跟大家讨论一下这个问题。
一）职能型组织和项目型组织
职能型组织和项目型组织确实容易混为一谈，虽然二者都是为实现某种目标而由相互协作的个体组成的群体，但项目型组织则侧重于短期任务的实现，而职能型组织却长期存续。
在职能型组织中，团队以固定的组织架构形式，共同承担一个或多个项目。团队成员是一个相对稳定的组织单元，可以充分发挥职能组织的资源集中优势，也容易依托组织中的专家资源，实现资源共享和知识体系的传承，不仅能确保项目的快速推进，也能有利于公司的长期发展。当然，职能型组织也容易形成内部小团队，当需要跨组织共同完成任务时，由于权力和利益分割的问题，容易陷入各自为政的局面。
而项目型组织则是一切工作都是围绕项目进行、通过项目来创造价值。项目组织是一个专门型组织，他的存在的唯一价值就是完成项目。它的优点是目标明确，任务单一，能够基于现有资源实现对需求的最大化响应。它的缺点是成本低效（由于项目存在的唯一价值就是不择手段完成项目，有时可能会造成项目成本和资源的浪费），项目间缺乏知识信息交流，因为知识的积累需要花不少时间，这可能会对项目的进度造成不利影响。
在项目型组织中，根据项目经理对项目资源的控制能力，又有强矩阵，弱矩阵，均衡矩阵的说法。但虽然强矩阵是对项目经理来说最为舒服的一种管理形式，同样也算最有可能造成资源浪费的形式。
这两种架构各有优缺点，例如职能型组织内部实现对资源的复用和知识的共享，如果能够加上项目型组织优秀的执行能力，显然是一剂良方。
二）软件开发模型对团队造成对影响
众所周知，软件开发模型有三种，瀑布型，迭代性，增量型。虽然这只是三种软件开发模型，看似不会影响研发技术团队的沟通形式，但实际上已经无形中已经深入人心，如康威定律一般，默默的改变了一个小团队自身运行的系统架构。
例如，在瀑布型项目团队中，团队之间倾向于通过文档交流，遇到问题首先想到的是优化文档或流程，似乎是一种组织间低效沟通的标志。而敏捷型项目则有助于打破项目组内部对于文档的依赖，单从这一点上看，就能给团队带来不错的生态体系。
当然，无论哪种模式都并非一定正确，例如精密宇航技术都研发，如果用敏捷，估计得玩完，但互联网项目的开发实践，用瀑布模型，似乎用响应太慢了。
虽然将团队管理和项目管理混为一谈是技术管理者很容易陷入的误区，但也得承认，在某些常规软件开发过程中，灵活的运用从敏捷项目管理过程中带来的一些方法，确实也能够有效的推进团队之间关系的进一步融洽，从而构建更加自驱的项目团队。
三） 敏捷项目管理提供对框架
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，
我们更重视左项的价值。
而敏捷宣言所提倡的这几点，都是有利于推动团队构建的实践手段。
1、站会
在敏捷项目管理过程中，站会是一种最基础的实践，团队成员每天早上围着白板站成一个圈，然后再依次回答三个问题：
1、我完成了什么。
2、遇到了什么问题。
3、今天计划完成什么。
站会的主要特点是改变了传统项目管理中由项目经理控制整体项目的模式，改成由团队成员共同参与，在这种情境下，每个人都独立的承担其一部分职责，虽然有Scrum Master或产品负责人组织，但实际上团队成员并未向任何人汇报。
2、敏捷卡牌
传统项目管理模式中，工作量的估算一般都是由主要开发者拍脑袋、或项目经理拍脑袋，而采用了敏捷卡牌，则使工作量的估算多了许多群体决策。
在敏捷卡牌实战中，大家采取这样的实践手段：
1、首先使用某个比较易于评判的功能，作为评估标准.
2、用该标准去评估其他功能的工作量。
3、通过团队群体决策，判断其他任务的工作量，如果多个人评估的结果相差较大，则说明需求未澄清，则澄清需求点，继续评估。
这种实践有助于打破团队间信息障碍，使得功能点的执行更加易于开展。
3、反思回顾会
在项目过程中最难的大概就是经验知识的传承。而在敏捷项目迭代完成后举行的反思回顾会，也恰好是这样一种有利的手段。在反思回顾会上，大家讨论我们上一迭代有哪些事情做得好，希望继续保持，哪些事情做得不好，希望改善，有何改进计划。
对程序员来说，普遍不善于交流，而反思会则给了大家“吐槽”的机会。当然，在实际召开过程中，项目组织者可以尽量减少发言，尽量让团队成员多发言的方式，让团队成员能够自发的提出问题和对应的改进建议，而不是成为个体的一言堂。
四、结语
对于团队而言，最重要的莫过于打破沟通障碍，让团队的成员都能获得尽可能多的表现机会，而依托敏捷项目管理提供的许多框架，则可以成为这样的利器，为构建团队带来便利。
