浅谈团队项目管理

我的工作经验其实算不上长，但呆过的团队其实挺多了的了。在我看来一个团队是否有战斗力，或者说是否能够做事情，领导者很关键。一般互联网公司，以项目来划分的话，这个所谓的领导者，也就是pm，当然我指的是Project Manager,而不是产品经理。

确实，如何将不同岗位不同性格的人撮合在一起，让他们一起去做一件事情来创造这个团队该创造的价值是件听上去很简单但做起来还是很麻烦的事。接下来就谈谈我作为一个团队主要成员这几年所看到的以及一些想法，有些地方可能纯属yy ，仅供参考。

好多PM 都是技术出身，技术出身的有很多情况下就会都有一个通病，就是疯狂的专注于技术，对业务了解程度也还算深，但很多时候在业务逻辑，或者页面逻辑上就会更多的从技术程度去考虑，性能方面考虑，而对一些产品逻辑问题置若罔闻。之前有次跟朋友闲聊，他跟我说他们pm 就是这种，平时工作就是哪里不会帮哪里，哪里出bug 了修哪里。从技术角度来说，这是个全才，但我觉得从团队本身来说，这有很大问题。团队之所以为团队，区别于个人，因为他有各方面专业得人存在。leader不应该是帮成员擦屁股的存在，而是需要更好的去规划统筹。在我看来，pm 应该更关注于产品本身，一个团队存在的根本意义就在于做出来的产品，一本书里是这样定义的，产品是能够提供给市场，供用户使用或消费，同时为企业带来盈利商业价值的东西。如果一个产品做得不好，首先背锅的肯定是pm。所以在我看来写代码的pm做得远远不够。

时间，这个在互联网行业中很关键的东西。互联网行业日新月异，谁能够在更短的时间里把自己的idea 落实做出来，谁就有可能在市场上占据先机。产品是允许犯错的，但是怎么样在最短的时间内把尝试的错误修改回来，就是一个问题了。我喜欢时间观念强的人，说了什么时候上线就什么时候上线，但我又不喜欢让我自己来根据需求评估时间。在我看来，人都是有惰性的，自己评估时间肯定会给自己留有比较大的余地。这里我就很喜欢之前leader 的做法，在一个迭代周期开始之前，他会根据需求优先级的排列，罗列出团队里各个成员在这个迭代期要完成哪些东西。这里其实就需要pm 再各个方向上的专业技能了，排太紧会造成团队负面情绪爆炸，排太送不利于项目本身。而且我个人建议是先紧后松的状态，pm先把迭代需求排得紧一些，看看团队得战斗力，然后再进行适度的调整，经过一段时间的磨合调整，肯定是效率不断提升的过程。

团队之间的配合也是很重要的，1加1不一定等于2，人多了沟通成本也就上去了。对于一个正常的开发迭代来说，工作其实是阶梯式的下去的。产品提出需求，需要设计就交给设计去画图，然后交给研发，研发完成了交给测试提测以及产品ui 走查。这中间就会出现一个问题，就比如测试资源就会出现在一个迭代周期里先松后紧的状态。前面几天工作就像天堂，后面几天工作如同地狱，这样子的节奏绝对是不利于团队和谐的。所以怎么样让研发小而灵活的提测也是pm 要考虑的问题之一，至于产品和设计在我看来是另一个迭代，跟研发周期措开，不同的节奏能确保所有人的节奏都能保持平稳，也不会出现资源浪费的现象。

当然，成员间坦诚相待是有必要的。就跟恋人一样，我一直觉得两个人之间相处，如果出现问题，就直接说清楚，否则藏着掖着反而会使矛盾激化，越来越严重。团队之间也是一样的，适当的开迭代总结会，大家说出迭代得问题，有什么不爽的地方都心平气和的说出来，然后提出大家都认可的解决方案，不仅能让团队成员之间更和谐，而且会更有战斗力。到也要注意开这个会的频率，多了也可能造成负面影响，过犹不及莫。

阿里文化里总是谈到这么一个词，补位，也就是说你不光自己的事做完了就可以了，也要去关心帮助别人的事。其实在我看来这只是中国传统美德罢了，互帮互助。leader可以去在团队里形成这么一种文化，精神食粮还是必须的嘛！在产品这块上，这一点尤其明显，当然这样子也会造成一种情况，就是每个人都有自己的看法，经常会出现僵持不下各有各自看法的情况，这个时候leader要做的就是做一个拍板人，做决定。

最后来谈谈人，人的性格很关键。有句话是这么说的，决定一个人是否能够取得成功智商不是关键，情商才是关键。人总是喜欢跟情商高的人来往，因为谦让礼貌，很舒服。所以我觉得招聘的时候专业技能并不是关键，是否跟团队里的人适合并且处得来尤其关键。当然，如果有个逗比那就锦上添花了，无论是工作还是生活，总是需要这类人给我们带来快乐的。

总的来说，我认为一个好的pm所要做的就是明确权责，建立团队间的沟通渠道，建立工作基准个目标，制定可行，余地的工作计划，并对计划进行沟通，检查，反馈，分析，对风险点进行沟通，评估，调整，并对一些突发情况进行解决等。

一个狼性的团队，首领很关键。深夜yy一波，发表些想法，希望以前的领导看到了不会打我，哈哈。