转pm好学吗_有甲方PM参与咋地了？

参见《又能咋地？》，这篇是续《咋地了？》

现在这另外的三个月也完了，在这半年的项目中，我下面说的这几个事可以看看。

第一、如果有甲方的PM参与，你应该了解一下他的技术水平、情绪控制能力和人品。

别以为“就是做个项目嘛，用得着使谈恋爱的招么”，不想给自己找麻烦的话最好了解一下他。

技术水平：强势PM的技术水平就是团队技术水平的天花板，一般来说PM都比TL能说，团队发现每次争论PM都胜利的话，谁把TL的话当真？久而久之，PM的技术水平自然就是天花板了。如果PM技术水平不咋地，你的天花板挨着地板也不奇怪了。

面对这式儿的PM咋弄？以前从不担心，怀着一个说相声的心，有着半个说相声的嘴，啥搞不定？这次在资本主义国家？说相声的心还有，说相声的嘴就没了，我还真的发愁了两天。实际来看，心更重要，配合心的是细致的观察。比如当知道PM的技术实力以后，尽量用她听的懂的话说，大姐懂数据库，还知道Select是关键词，我所有的谈话都比喻成从数据库Select，这样大姐都能听懂，就更容易产生同理心。

情绪控制力：这又是啥？有强大的情绪控制力的客户挺不好对付的，喜怒不形于色，你不知道怎么讨好、怎么激怒他。而情绪控制力不好的客户也不好对付，稍微发生点儿什么，就崩溃了。在我所有的说中国话的项目中，这两类客户都遇到过（当然大多数客户是正常的，介于中间的），还是那句话：怀着一个说相声的心，有着半个说相声的嘴，啥搞不定？

大姐属于控制力弱的，我甚至看到大姐为了工作的事，打电话和人嚷，然后自己在会议室哭了！对于有着敏感、细腻情绪的一个人，分享琐事是建立同理心的敲门转。我从“没事跟大姐打听一下附近有什么好吃”的开始，到“现在的年轻人太TM没有上进心了”，最后到“60年前，勤劳勇敢的我们还穿不上颜色鲜艳的衣服，但是腐化堕落的你们已经住house了”。。。

人品：大姐的人品挺好，那个架构师大哥也不赖，尽管大哥总是想着用“Javascript写业务逻辑，再用Java调用Javascript”的可怕架构，但两个人都不阴险，这点我很知足。我遇到过当面一套背后一套的客户，如果你不幸遇到了，也不是没有办法，就是累点儿而已：屁大的事就用邮件确认，外加一双慧眼，足够了。

第二、尽早建立信誉

信誉这事和嘴会说没关系，是真的要做出来。这个项目上，这么几个事帮我建立了信誉：

1、仅1个月，在只知道一句话作为需求的情况下，作出了一个可运行的平台，大姐说这是他们从来没有的；

2、在得知需求变化时候，没跟甲方争论，而是快速转换方向，在第二次showcase的时候已经找准方向，大姐特别喜欢；

3、使用“一切可视化”的方法，让一切清晰可见。在TW学到的墙面装修的手艺全能用上。大姐在随后的几个月不断的带人参观项目组办公室，俨然把这儿当样板间了；

上面的三点其实没啥神奇，都是敏捷实践的标准动作，关键的是要做出来。一旦信誉建立，嗯，就可以为所欲为了。比如，请个大假什么的。。。

第三、说几个具体问题的解决方案吧

1、为什么要有“Ready To Dev”这一栏

第一个Showcase不久，项目组进入疲惫状态，意料之中。每个人看似很多事情在Dev Doing，但是不出活，站会的时候也都有的说，由于每个人至少2个事情doing，所以站会的时间还特别长。以前在国内团队，我必须在站会上刺激一下：

比如：“你。。你能不能行？我还能活到你做完这些个卡不？”

比如：“你。。你这就狗揽8垉屎吧你，放这么多在Doing，你能今儿Doing的完么你？”

这次主要是不会翻译“狗揽8垉屎”和“你能不能行”，有点儿糟心，就翻看“最佳实践”，才发现“Ready To Dev”的奥秘，“ready to dev”就是防止“doing里面有很多卡”，立马创建这栏儿，把不Doing的卡挪过去，颁布了一个规则：每个人只能有一个卡在Doing里面。

于是眼看着开始出活了。神奇吧？这主要是因为：

A、原来是虱子多了不咬，“反正我有3个事情”，现在是秃子头上的虱子，“昨天站会就说的这个，今天还说这个，太过意不去了”；

B、站会时间短了，我就有很多的时间问：why 和 when 了，你就一个事，你能解释不了为什么干了两天还没完么？

C、大姐每次盯着Doing看的时候，只要发现Doing里没谁，立马安排事情，在经历了几次被大姐安排以后，每个开发都开始力图保证自己的头像在Doing里面，加上B保证了每个卡他又不好意思放太长时间。结果只能是，Ready To Dev的卡被主动捡走；

2、为什么要尽早激化矛盾

架构师大哥和PM大姐一起工作了近30年了，爱恨情仇的。大姐想找到一个一了百了的方案，大哥关注可行性，这当中就发生了很多矛盾。比如，大姐的梦想是做一个save，可以把任意一个表单保存在最终用户数据库里面；而大哥觉得在表单提交的内容，得经过处理甚至人工审核才能最终放在数据库里面，因为每个数据库的业务逻辑不一样，怎么校验提交的数据合法（合业务的法），这事大了，我们不能自己给自己刨坑。

我举双手双脚赞成大哥啊，但是又不能举一个手指头不赞成大姐。我明确的知道，如果这个问题不解决，根本没办法搭架构，更别说写代码了。

于是，

一有机会，我就挑事，每次大哥大姐都会当着我面（团队面）争论的面红耳赤，我适时的再给大哥帮两句腔。尽管每次的结果都是不了了之，但是蚂蚁啃大堤吧，大姐一定会幡然悔悟的，不管怎样也比团队瞎忙乎干活，然后重新推倒强啊。“自私”点儿说，作为乙方的PM/TL，如果推倒重来次数多了，不但客户不买你的人情，团队也会觉得你傻叉。而没有比团队觉得你傻这事更严重的了。

3、为什么Story要写预估时间

这是配合Ready To Dev实施的，尽管一开始大家脸皮儿薄，努力完成任务，但是只要有一个不要脸就纷纷不要脸，Doing里面的事一干就3天。我深知啊：比下线这事永无止境啊。在Retro以后，立马决定每卡必须有预估时间。白纸黑字你自己写的周三完，都周五了，还要不要点儿脸？

目前来看，这个下限还行，还没有超期两天还腆着脸跟我这儿要延期的。对了忘了说了，我给每个人一次修改的机会，就一次。

4、为什么要建立企业文化

在ThoughtWorks的时候不怎么觉得，一旦出来，真的深刻体会到企业文化的重要性。在这个“联合国”一样的项目组，PM又不怎么管，开发只要没事，就互相聊家常，跟街口大妈似的。鉴于我这英语水平，根本也插不上嘴说“别聊这没用的”，更别说引导谈话了。

不过这不是我的团队，我也没义务让他们变得好学，上进。对于我来说，把活完成了就行了。愿意多学点儿的，咱就多聊聊，多给点儿机会；愿意聊闲篇儿的，活该，死去～～

项目结束了，总想说点儿啥，就这些吧。