实战心得：敏捷团队背后的秘密

2016-12-12 14:19:00

原则：如果争执不断，给最专业的人做决定。

何为敏捷？

这场经历过后，我和团队的结论是：在此时此刻、最合适团队高效完成目标的方法就是敏捷。每个团队都有自己演变出来的敏捷方法。

一、敏捷的核心是什么？

敏捷的核心是相互信任与认可。这是我在公司成员面前分享经验的时候的心得。太多团队的失败正是来源于这一点，因为不信任队友，不愿意放手，导致整个团队分崩离析。

在海贼王中，路飞有一句话我常记在心里：“我的确不会什么剑术，我不懂航海术，也不会做菜，也不会骗人，我相信没有别人的帮助我就活不下去！ ”

是的，在一家公司当中，在团队当中，我就是这样和团队一起活下来的。我并非一个全能型人才，在我的团队里配备了后端、前端、测试、UI、项目经理。我负责给出靠谱的产品方法、不断给产品拉资源、给团队打鸡血。

如何建立相互信任的文化？

1、原则：如果争执不断，给最专业的人做决定；

2、相互包容、尊重；讲个例子，UI作为一个每个人都说得上话的东西，产品狗在这块当然也会经常撕逼，但其实这一块门槛很高，UI是个技术活。我之前跟UI在视觉设计上争执不下的时候，如果尚有空余时间，我们两个采取的方法做用户性测试；如果没有太多时间，我在保证让他理解用户在这里的使用场景后，我最常跟他说的一句话是，由你决定。产品上线后，如果出现问题，我们再逐步迭代完善。我们相信对方是最专业的，如果犯错，一起承担、一起解决。每个人都有成长过程，UI也不可能每次都能保证自己做得是对的，允许双方都可能犯错，最后会形成最和谐的合作方式。我们的产品从0到1的过程当中，在菜单上做过一次大的整体改版。在一开始，我们pc端的产品视觉做得很好看，菜单都是logo，没有文字。但后面发现增加新功能后，用户点击量很少，与我们之前做的功能验证得到的市场反馈数据截然不同。后来我们将logo更换成比较普通的文字后，发现新功能的使用人数暴涨，从而发现自己针对的这群30岁左右的用户，他们对互联网产品真的一点也不懂。这是在产品设计上，我们曾走过的弯路，但这种错误是有价值的，这让我们对以用户为中心的产品设计的感受更加深刻。团队在这个过程当中没有一个人抱怨过，我们为改变后的优秀数据欢呼。

3、围绕用户展开团队建设。在这个过程当中，我借鉴了《参与感》一书，参与感的方法也来源于我对技术同事的理解。有一部分产品经理经常会把自己跟团队隔离开，很多时候会在不同场合说这是“你”的责任，“你”不了解产品，“你”不了解用户。尽管这部分产品人员最终可能完成了自己的KPI，但他会失去一个真诚的团队，我认为这不是一名合格的产品人员。“你”这个字是团队当中最刺耳的词。领导力并非来自于“你、你、你”的指派，而来自于“我们”“我们一起”。我在大学的经历当中做过开发，带过开发团队，到了公司，我也经常跟技术同事吃饭扯谈，也一起吐槽过某某产品做得垃圾。是的，我非常理解程序员想把产品狗碾死的心。产品是一个团队的结晶，而不是一个产品经理成就。所以，从产品内测开始，我把整个团队拉到了种子用户群里。在做线上运营的时候，大家一起在群里玩，和用户一起玩。每个人都能够了解用户，对产品的功能理解得就越深刻，这样得到的一个结果就是，但用户在群里说出现bug，产品经理还没提交bug的时候，技术已经改完了。然后团队成员在自己的沟通群里给技术点赞发花。让我印象最深的一件事是，某天我的用户给我发红包，感谢我的付出。

4、以数据为驱动，做好内部宣传和外部宣传团队内部的沟通要保持透明，每周提供产品的关键数据和分析让团队成员知晓目前的产品情况。产品数据表现不佳的时候，产品人员要给出问题的原因和解决方案；数据不错的时候要赞赏团队，让用户知道我们在做正确的事情。我每一次迭代重要功能的时候，都会给出手头的数据支撑，我们的产品节奏很健康，每一次迭代功能后的效果都基本满足我之前基于数据的假设，团队也大受鼓舞，对于产品人员的信任程度也大大提升。数据驱动的另外一个好处是，帮助团队和产品向公司层面获取更多的资源支持。擅于做汇报，给自己的团队带来好处是产品人员的责任，但现实是，某些公司的一些产品人员做的PPT都是为了自己，真是哔了狗了。

5、共同的目标与团队KPI目标涉及到KPI的考核，做一个从无到有的产品的时候，将KPI捆绑在团队整体表现上是关键的一点。没有共同的目标和外在KPI束缚，强有力的团队很难孕育。成年人家里都需要奶粉钱，这是最现实的因素。当团队成员并非每个人都是主观能动性超强的人的时候，KPI也能够有所引导，是有好处的。当然，对于那种团队中每个人都是主观能动性非常强的人，就可以不需要KPI了。