技术领导力实战笔记_158_大咖对话_|_袁店明：如何将打造自组织团队落诸实践
你好，本周做客大咖，对话的是jail EMC敏捷与经益创意咨询师袁殿明曾任职于百度、阿尔卡特朗讯辅导过多个产品线转型，包括商业产品、无线变现，以及多个移动互联网产品的团队转型和组织转型。
目前，着重于项目管理团队转型、组织转型、精益创业、欣赏式探寻以及专业引导phacification的实践和应用。
今天，我们共同探讨了自驱动自组织团队的相关话题，即刻时间慢，很多公司都希望打造自驱动的团队。
那如何落出实践，打造真正自驱动的团队呢？袁殿明回答我认为，自驱动的关键在于个人的motivation动机，同时离不开组织管理。
对个人的影响，包括团队项目管理的透明性、团队的规则、透明的考评机制，团队中权利与职责的分布等等。
个人的motivation并不单单是指薪资福利。
其实一个人在拿到公司的offer时，他的薪资待遇、职业通道就已经确定了。
因为每年加薪的范畴是固定的，是你能够想象到的。
除此之外，根据公司制定的晋升机制，你的升职路径也是能想象到的。
所以，升职加薪不是给个人带来motivation的主要因素。
我认为其主要因素有三点，第一点是尊重与认可。
因为人具有社会属性，每个人都希望得到认可，感受到荣誉感与归属感。
第二点是个人能力的成长。
而个人成长只靠自我驱动是不够的，还需要依靠团队的帮助，比如团队成员间的相互促进和知识的传递分享等。
第三点是职业发展通道与个人兴趣的匹配度，也就是个人职业生涯是否符合他的个人兴趣，兴趣可以激发动力。
这一点不难理解，不知道你有没有发现获得motivation的这三点因素，其前后顺序是有关联的，先是获得认可，其次是个人能力的提升，在获得成长之后，才会更多的考虑个人职业生涯与个人兴趣的匹合度。
其实相比自驱动，我更建议用自组织来说，这个话题内容可以更丰富。
那如何打造自组织的团队呢？我认为有两个关键点，一、分散权力，比如screm中有三个角色，分别是PO产品负责人、scram、 master和team开发团队。
我觉得应该再加入一个重要角色，即people manager这四个角色相互制约、相互促进。
具体有哪些措施呢？首先，people manager不应该参与团队的日常运作，如果团队要更好的实现此组织people manager所做的事情非常多，比如招聘、培训、考核、一对一面谈等等。
如果是一个几十人组织中的people manager,这些事情就已经够他忙的了。
其次，screen master需要提醒团队成员，每个人的职责所在和权利范围不要越界，同时需要引导团队如何更好的呈现项目进度。
在这方面，screm master需要做两件事儿，即对外透明和对内透明。
先说对外透明。
比如screm master需要提醒产品负责人，不要干涉开发团队的进度。
但产品负责人一定是会很关心项目进度的。
这时，screen master就需要引导团队及时向外部所有关系人输出信息，比如利用大白板公开工作任务以及任务进度、用户故事的进度等，使产品负责人能够直观的看到项目迭代进度。
所以，作为screm master,需要引导团队准确的对外输出信息并及时更新。
这样一来，外部关系人才不会越权，干涉内部团队的项目进度。
再说，对内透明screm master需要保证项目管理的透明性和真实性。
只有项目管理真实、透明，才能在此基础上建立团队内部的信任。
打造自组织团队。
刚才讲到的对外的信息输出是透明拟的需求，也就是公开用户固值的状态。
而对内透明是为了保证任务的真实性和时效性。
这里的真实性是任务要真实，时效性是指业务状态要及时更新。
二、设定个人与团队的成长目标。
一个自组织团队必须要让团队不断的达成自己的成长目标，同时帮助团队成员成长。
在这方面，就需要scremaster去做许多工作。
比如，对于个人就需要screen master.在回顾会议上，组织每个人展望自己下个季度的目标，并以此制定自己的学习目标和成长目标。
而对于团队，也需要screen master,根据团队所面临挑战的不同，制定不同的项目计划与业务计划。
总的来说，设定团队和个人的成长目标是squremaster非常重要的一项职责。
为什么又谈个人成长又替团队成长呢？因为团队由个人组成，每一个人都应该对团队有所贡献，在自己获得成长的同时，帮助其他人学习与提升。
当然，这个团队绝对不是共产主义，只是在小团队中拥有互相帮助，共同成长的环境。
能够促使团队成员的个人能力得到快速提升，而这样才能够激发自组织团队的motivation,从而使团队越来越优秀。
即刻时间问，敏捷原则中提到，最好的架构需求和设计出自于自组织的团队。
您怎么理解这句话呢？袁天明回答这句话中，架构和设计出自于自组织团队，这两点不难理解。
那为什么会说最好的需求是来自于团队，而不是来自于客户呢？主要原因在于，客户其实并不知道自己想要什么是产品经理，将客户需求描述出来的那这么说，最好的需求难道来自于产品经理吗？也不是产品经理，只是把客户的痛点收集起来。
至于如何用产品解决用户的问题，应该是实现需求的人最了解，也就是团队团队需要写代码去实践产品，还要考虑到各种用户情况。
因此，可以说，最好的需求来自于自组织团队。
正因如此，作为一名最了解需求的技术人，就需要具备一定的产品思维，主要包括两点，一是了解用户细分人群，二是了解用户的行为和交互逻辑。
首先来看为什么要了解用户细分人群呢？极限编程中有个概念叫用户故事。
User story是从用户的角度来描述用户渴望得到的功能。
而我们有很多用户，用户需求也各不相同。
因此，就需要我们去了解用户的细分人群，清楚我们的用户是什么人、有什么特征等，这样才能写出更好的用户故事。
举个例子，有次我带团队做的是一款管理工作流的产品，就需要去了解这类产品的用户人群，了解这类人群的特征。
团队中有一位产品经理非常聪明，想到从link in上收集信息，他搜索相关岗位就能看到对应的人有什么特点和属性。
比如工作职责、教育程度、能力方向等，是一个提取用户信息的好方法。
再来看第二个产品思维及了解用户的行为和交互逻辑，最熟悉产品的人应该是技术人员。
因此，技术人需要熟悉所有用户和产品的交互逻辑，比如用户先输入什么，再输入什么，以及每一个数据的边界值，各种测试情况，各种交互路径的细节等等。
你作为技术人，需要对此都非常了解。
当然，技术团队既包括开发，又包括测试，其实测试应该要比开发更了解用户行为。
至于为什么有的技术人没能具备产品思维呢？有多方面的原因，在我看来主要有两点，第一个原因是产品经理与开发人员之间的矛盾矛盾冲突加深后，可能会让开发人员为了完成产品经理的紧急需求而选择只求交差、放弃思考的做法，甚至于产品后续会出现什么样的问题，技术人员也不会去深入思考了。
所以，产品与技术人之间的矛盾是产生问题的首要因素。
第二个原因是技术人没有参与用户故事内容的描述，一个好的用户故事应该遵循invest的原则。
这六个字母代表六个特性，其中的第二个字母n是意思，是一个用户，故事的内容是要可以协商的。
很多人就忽略了协商因素，我在辅导团队时，通常会用电子工具来管理用户故事，从中能够看到用户故事的版本记录。
如果一个用户故事从初稿到终稿，都是由产品负责人拍板，中间没有其他任何人做改动，那这个用户故事一定是有问题的。
合理的做法应该是在产品负责人写完初稿后开发和测试，再将用户故事细化，最终经过协商后确定终稿。
我认为每个用户故事都应该加入技术人的产品思维。
因为产品经理虽然从用户端了解到了他们的需求，但对于实现需求的产品逻辑与细节，技术团队才是最清楚的。
所以，产品负责人应该与开发团队共同协商，形成最终解决方案。