下午在读《潘正磊谈微软研发团队管理之道》和《潘正磊：做最好、做美的你》，有颇多感触，感谢潘正磊，感谢InfoQ。匆匆写博望与您共同思考。前者不是新文，相信不少朋友已经早已看过。
注：潘正磊，一位出色的微软女性经理，执掌中美两个研发团队。2010年11月应旨在帮助并支持技术型女性员工不断进步的英特尔女性员工网络（Women at Intel Networks, WIN）邀请，她与英特尔亚太研发公司近100位上海员工畅谈了18年微软职业生涯中几个故事及其个人感悟。
在微软，每次的年度总结不仅要回顾你写了多少行代码，更重要的是归纳出自己的哪些技能有所提高，明年需要改进哪些方面。因此，每年都应该选定一两个目标，而且一定是那种“需要踮起脚尖”才可以够到的目标。过去18年，我就是这样提高我的能力和积累经验的。
与此有异曲同工之妙的，是这一条微博：
@黄乐LELE：【Cisco Mid-Year Career Discussion】5个问题，很好的帮助自己清晰职业生涯的近期和远期规划。1. What motivates me? 2. What are my long-term career aspirations? 3. What progress have I made? 4. My development goals still relevant to long-term career aspirations? 5. Resources needed.
我不知道有多少公司或团队甚至个人在做这件事，但我确定这是很有意义而必要的事。
成长过程中，人们经常会问“我需要提高哪一点”？无意间就踏入了一个误区：看到别人的长处总想要去学习，而不考虑自己是否需要。
每个团队有一两个这样的专才就可以了，一个好的团队每个人应该各有所长。所以，你应该想想自己在团队里发挥什么样的作用，跟别人的差异化优势是什么。当然，某些基本技能一直不掌握会成为个人发展的瓶颈，就绝对不能马虎。
最近我也正在陷入这样的局面，希望自己成为一个既深又广的全才相反让自己疲劳追寻一无所得，我刚刚还在看于丹的《庄子心得》，虽然书写得并不是特别妙，不过刚看到的一段印象比较深，讲的是一个富人家的怀表掉到了木匠屋被满地的木屑刨花所遮掩，一群人累得筋疲力尽到天黑无功而返，有一男孩晚上一个人呆在漆黑的小屋居然是找到了，富人很惊讶，问其原因，男孩说“因为很安静，所以怀表的嘀哒声好明显，我顺着声音抹开了木屑就找着了”，虽然场景有些牵强，不过于丹用这个故事来表达：疲劳追寻是没有意义的，人需要静下心来才能听得到找得到。结合这个故事，再看这段，想来也是感触不已。
我觉得每个人的长处是不太一样的，我觉得我自己的长处，第一是技术方面还不错，因为一开始在做工程师，如果你技术上面做不好，是不可能往上走的。另一方面，我觉得我对资源整合这一方面是比较强的，我的一个强项是我很快就能看出我下面的员工他们最适合什么，他们不太适合什么，那把他们放在最适合于他们的工作岗位上。这样第一能够是最大的调动他们的积极性，第二整个团队可以成一个非常高效的团队。
关于“每个团队有一两个这样的专才就可以了”以及“资源整合”，我现在真是感同身受，也认为是现如今团队可以改善的一个方向，我相信没有几个大牛是全才，在04年就有听过一句话“我们团队不希望出现个人英雄，我们希望人人都是必要的都是英雄”，这表示全才能有一个已经足够甚至可以不需要，因为在一个健康的团队中，每人都应该有自己的专长及专注点 - 不止一个两个，这样一个团队应该才是健康与完整的，因为，这样每个人就能找到自己的位置，每个人在与自己专长相关的讨论中能发挥更积极的主导作用，能给出更多建议，并能在这过程中得到的个人满足感更强烈，但他首先应该知道他在这方面adept了，如此一来，队员互相需求、认同、分享以及帮助的。比如A君是MVC专家，B君对MCF有丰富经验、C君曾在当前项目中多次使用过某技术。这是外包的一个优势，大家所处的项目不同，用到的技术、架构，都不同，如果能互相分享告知，则能很容易在需要找到资源时，迅速定位，马上获取handy的resource。
你看，我这个考虑思路跟你完全不一样，我不会觉得我团队里面有谁对我是有所威胁的，我的出发点就是我希望能够培养一批人才，如果有一天我能够不用去上班了，而且我的团队还可以执行得非常好，这才是我的目标，所以我是希望有人能够来代替我。如果我这个工作做完了，如果我下面培养出一批人才，能够取代于我的话，那还有更加具有挑战性的工作在等着我去做。
很坦白的说，我也曾经有过“害怕自己被取代”的想法。lili有次一句话让我很醍醐，“作为TL和PM，让别人成功就是自己的成功”。现在，我接纳更多更优秀的员工共事，享受没有芥蒂的交流沟通，接纳批评，完全认同这种共同发展，甚至看到对方跑得比我快也会“笑纳”，再加把劲的追上去，这是一种成长一种绝佳动力。
从另一方面来讲，能早日培养出合格的back-up是必要的，这意味着，你可以抽身做更多有挑战性的工作。
在这样一种环境（微软）中，你怎么样能够跟大家交流，怎么样可以说服大家同意你的观点，怎么样听取别人的反馈，自信心实际上是一个非常基本的素质。如果你没有这个素质，就是作为一般的开发工程师也不会走的太远的。
在一年以前，我从来不觉得我有懂过“自信”这两个字，从小到大，几乎所有的人都会用这句话来“鼓励”我 - “要对自己有信心！要相信自己一定可以做到！”可每每听到，却是越发的胆怯、害怕、无力、无穷压力，我甚至非常憎恨有人对我说这些，我觉得这是对我的莫大伤害。在这一年中，我所感受到的对“自信”的理解，却与那时截然不同 -
自信并非是茫然无措的给自己握拳头说加油然后全身发抖的站在最前方，而是在当下，你所有需要做的，只不过就是全心投入。绝对也永远不可轻言放弃，不对自己说“不可能”，只需要心无旁骛，做好当下你所有能做的，你就成功了，结果并没有那么重要，如果你可以很安然的告诉自己，我尽力了，没有人可以对我说 - 你本来还能做得更好，那你就是成功了。2年前，有一句话撼动我至深 - “这个世界上，只有三件事，你的事、别人的事、老天的事”。
至于另一个相近的词 - “信任”，也是说来容易实际实施起来，却需要更多尊重和由此思彼。相信队友，相信他们的交付能力，相信他们处理问题的能力，在内心深处给予他们失败和总结改正的机会，再多信任几次，再耐心一些，再多看一下。如果你觉得你眼光并没有错，那么，何不为了更好的获得付出些许代价呢？懂得帮人承担，出问题尽量帮助解决。我庆幸在这方面，我有一个很优秀的lead，他让我看到更多、想得更多。
潘正磊对项目经理、产品经理、产品总监、总经理的区别给出她的理解：
作为一个开发工程师来说，你最主要的是要把你的代码写得越快越多越好。你的代码行写得多，那这个功能才增加得多，你写的代码行是最难的那部分，那才说明你对这个产品最主要的核心部分有贡献，这是作为开发工程师。（注：还应该加上质量好才对）
作为一个开发主管来说，就是我们叫Development Lead，第一方面，作为管理者，你对这个团队的价值，不仅仅是说你自己写了多少行代码，这相对来说是比较少的，最主要是你这个团队对整个产品的贡献是什么，那还是基于你这个开发的功能有多少，然后你这个功能是不是做得好，你架构是不是做得好，但是你的核心价值是把你这些资源都组合起来，然后能够帮助你团队的员工扫平障碍，让他们非常顺利地开发。如果要整个团队都能够非常顺利高效，你就要想“我怎么样让这十个人互相之间能够（协调好）”，就是很多程序是有顺序的问题，把顺序问题安排好，有些东西可能要需要一些决定，尽早的把决定做好，下面的架构可以做好，跟其他团队的关系要搞好，因为他们可能有些东西要拿来，他们先做完之后我们才能做，所以有很多东西Dependency Management，这些东西全部都要管理好，就像造房子，管理一个项目一样。这样管理好你这十个人才能都是马不停蹄、非常高效地把这个东西做好。
等你做开发经理的时候，开发经理因为不是一个第一线的管理者，而是第二线的管理者，这个时候最最有挑战性可能是，你很多东西要通过你第一线的开发主管传达到下面去，如果你开发主管对你说的话不认可，那你的观念、决定不一定真正能够传达到最下面的开发人员。而且你下面的开发主管可能每个人都还要管一摊不同的东西，你怎么样让他们之间能够互相配合、互相合作，从一个大局上面来看你整个这个开发团队缺什么，有的时候他们开发主管在那里面做，他不一定会知道说。
从开发经理来说，我在美国喜欢说三个P，你要管理产品（Product），你要管理人员（People），你还要管理流程（Process），这三样东西都要抓起来，你才能作为一个合格的开发经理，然后让整个团队都能高效地运行。从开发经理来说，他还只是主要是管开发团队的。开发团队总的来说只是占了可能是1/3。
总经理跟产品经理是两个不同的概念，产品经理是说你管一个产品，那总经理你是管多种产品，像我刚才所说的，实际上我现在这个组里面有三种不同的产品。怎么样管理这一套产品线，而且跟我们的市场部，跟我们的营销部，跟我们的DPE（开发工具及平台事业部），那些合作都是在这个层面上面是完全不同的。看你每一个产品到底里面放多少的资源进去，为什么这个产品放这么多资源，而且要看你成功的定义是什么。
而做一个产品的开发经理，这么多资源实际上已经分配给你的，你在这个资源的基础上面把它做到最大最好，所以这还是不同的概念。
我一直是一个开发工程师，而且未必是算上得合格的，读清需求、写好代码、按时按质完成交付、上传下达、必要沟通等，上述这段我几乎是大量的coy过来，是因为整条线路相当清晰，给出一个部门organization up-to-down从大局到细节部分的一个总览，是极为完美的开发职场规划路线之一。我看到的是，管理产品意味着有敏锐的市场调研，是懂经济，管理人员意味着有敏锐的将最适合人员分配到最适合岗位，是懂人，管理流程意味着自律、严格（当然不仅仅是），是懂做事。管理多个产品，则是分配资源，对市场对定位的研究，我说的这几句可能不完全正确和全面，但就我目前所能悟的这些，已是足够我思考和自省的了。
我本人是比较愿意去试验新的方法，我会让一个feature crew (功能小组)去试验这个方法。然后给他一段时间，他来给我反馈，这个不管是方法还是新的工具，他有什么优点，他有什么缺点，因为很多时候你想是想不出来，你还一定要去试，试了之后才知道它到底是好用还是不好用，它什么地方好，什么地方不好，就跟车一样，你得要去试开一下。然后在这之后，根据他的好处跟坏处，你还再可以跟现有的方法再看，再评估一下，你是把它全盘拿过来呢，还是把它改动之后再引用，或者有没有什么办法把它好的地方能够结合到现有的方法之中，不好的地方把它抛开不用。
工作方法不是我来改进的，是我的团队来改进的。因为他在日常工作（开发、测试）中发现了问题，发现什么是更好的解决方案，他要有这种主观能动性，他要明白我想解决的问题是什么，他才能够主动帮我来想更好的解决方法。那想出解决方法之后，我们大家再分享，一般都是这样。
这个问题我早就知道了，但是我现在决定不解决，因为可能有其他的方方面面的原因，所以我不解决；或者说这个想法非常好，我给你资源，你去给我做一个试验原型出来，然后我们再来看一下，这是非常常见的。
开发工作中，团队成员如果有这种主观能力性去研究新东西，并时常愿意给你新的IDEA，你给他机会让他尝试，会激励他下次继续努力。而身为执行者的开发人员，我也应该多多将我自己认为好的建议提出来，可能遭到反驳，可能会被伤害（我做得辛苦你只需要说说大话之类的心态，我想在西方企业文化中是不存在的）。鼓励新思维新技术，open to all suggestions。我现在对这些西方企业文化的兴趣更加浓了，希望能多多通过这种文章了解和学习他们。比如，我一直希望能提上日程的周四培训计划，一直在拖延，而且，本身我的完美主义倾向就有很严重的问题，如果凡事连让自己犯错的机会都不给，让自己被责骂都会觉得不如不说之类的，那就真的是自己先与这种文化格格不入了。
你怎么样能够调动员工最大的积极性，而且我觉得有的时候中国的员工不够主动，你让他做他会做得非常好，但是你不跟他说的事情，他也许就不做。这个我看得比较多，不管在美国和中国的华人员工里面都是比较常见的一个问题。作为一个管理者，你怎么样能够让他能够非常主动把问题告诉你，而且把解决方案也告诉你，这个是从微软文化上面来说是非常重要的一件事情。
这是非常有趣的一段话，有意思的是，我前几天看了下我05年的博客，上面有段话，我现在看来很有意思，里面批评了我当时的lead，认为他很不合格，我在里面对lead表达了这种一种要求 - （我原封不动的将这段拿上来）
一个没有CMM标准的软件开发公司开发过程过份幼稚，没有前期的项目文档，只有简单的所谓UI。对一个coder来说，绝对不是一个良好的经历。不规范的编程风格，小作坊式的开发模式，落后的开发工具，原始的测试手段。
规则..... 对我来说，是一种具争议的概念。我不是流水线工人，你也不是监工，我能大大提前既定时间完成同样时间别人完成不了的任务，我需要这种意义上的“激情"吗? 我没有任务，全都是我的错吗? 汇报进度是我的责任,而你作为一位PM,留意和跟进项目和人员的进度，从大局来规划任务及进度是你的事,而且不过是5个人的小team,在你PM的眼皮下,我没任务难道是我的错吗? 难道你能说我没有工作激情吗？难道能说我不能胜任工作吗？
还有你们口中所谓"团队性格",我需要为了完成一份工作而刻意逢迎我需要和你们装得很熟吗? 我需要刚来4天就夸夸其谈以表我没有交流障碍吗?我需要中午和一堆我甚至名字都叫不全的人在一起吃饭还要装得我和你们前世注定相见恨晚吗?我中午去哪吃饭还需要跟整个team汇报行踪最好就象隔壁市场部高声谈笑以示我具有团队性格吗?非常抱歉，I really feel sooorry! 我不是一个刚刚毕业的coder，还可以让你们象挰泥人一样把我挰得颇具你所倡导的团队性格,我也不需要把自己整天装在套子里装腔做势，我只是一个和你们合作的对象,如此而已.
清华XX，一个不适合IT人呆的地方，一个不适合coder呆的地方，工资低，技术落后，制度死板，程序繁杂，PM浮噪，5天对我来说已然足够(项目经理居然连版本控件都不使用...后面经我们提示，才知道世界上有一种工具叫做vss,并且可以做版本控制呢。)，一个人经历各种不同的人和事也属自然
是否很有意思呢？我们每个人在初期可能都有这种极端化的抱怨，如果一旦矛盾激化，结果就有可能是这样，这段话，是否能让现在的我，好好仔细认真的思考一番呢？让成员认同文化（而不是被迫认可团队性格）、认同他自身在团队的价值并受到激励（而不只是合作对象），标准化让他觉得值得点头称赞的合理的流程、宽松的开发环境、尽量简化人事流程和束缚等等。总之，是一种先让所有团队成员认可与相互信任的过程。继续看看下面这段潘正磊的，
那你是不是真的培养员工，真正是让员工在你团队里的重要性充分的发挥了出来，只有在这个时候员工才认可你的管理的方式，才能认可他是这个团队的一员，才能想到怎么样在这个团队里面发挥最大的重要的作用，那这也是我觉得开发管理者应该多思考的问题，和多做的事情。
真是如醍醐灌顶般畅快啊！最后这一段，也是颇有意思。
我觉得有一些可能文化上面的东西，可能会限制这些员工的发展。我看到比较多的是，有的时候员工他们碰到一个问题，我觉得可能是考试考太多了，他们看到一个问题，他们不太会去跟旁边的人，一起跟周围的团队里面的人，或者跟美国团队人一起交流，一起想最好的解决方案，能够把大家不同的观点整合起来。很多的时候看到他们自己在非常辛苦地在干。那苦干之后真的是做出来成果就说，你有没有考虑到一二三四五六，那你有没有跟这个人这个人去谈过，好像这方面做得相对来说比较差一点。因为我觉得我们考试的模式就说你不能问别人，你都要自己解决。
就在前几天，我无意间看到很多年前一个文本，里面记录了当时觉得有趣的一段在CSDN上的争论，于是我顺手又将它转到微博上，这句话是：
中国人说话很谨慎,只说正确的,不正确的基本上都缩回去了.外国人鼓厉你说出来,哪怕是错的.他们在表达观点上甚至很粗暴,像吵架一样.外国人说,就算十个人的观点都是错误的,可是,说出来,大家在十个观点的基础上思考,也可能得出一个正确的结论. 争论是正常的.但请勿互相攻击.
这些都能看出中国与西方文化间的差异，这种差异是一件很有意思的事。我最初了解到美国那种圆桌上讨论是在看《爱在哈佛》，教授出一道课程，班上成员自行组织协作团队，4~7人的样子，大家在一起讨论debate、brainstorm最后交一份答卷，是共同努力的成果（不要做任何与中国现在的大学开发“培训班”有关的联想）。中国学子都是闷头干闷头做，互相排斥，巴不得把对方挤下来，人人都与人争，就如印度片《3 idiots》中的校长入学仪式上说的“噪鹃从来不自己筑巢，他只在别人的巢里下蛋，要孵蛋的时候他们会怎样？他们会把其他的诞从巢里挤出去，竞争结束了，他们的生命从谋杀开始，这就是大自然——要么竞争，要么死……”，这能看出，我们不互相协作，闷头干自己的事，是与这种教育制度以及被鼓吹的风气有关。
我一直很向往西方团队模式，2年前关注UED时，就留意到腾讯、淘宝支付宝等UED团队都有这样的西方团队模式，非常敞开，非常棒！不知道我是不是也能有这样的机会，在这样的团队里和一帮可爱的团队成员共事呢？不知道是否能获得大家的共同认可呢？
我一直以为有这个名字和这种职场经历的女人，必然是锋芒必露甚至略感强势，原来却是一位非常外柔内刚的女性，看来我对女性IT管理的观念需要refresh了。
延续阅读：