PM成长日记

原文转载处链接：http://blog.csdn.net/ronghao100/article/details/7949291

NO.1 -不要使用邮件解决问题

首先，在学习任何东西前都需要明确学习的目的，我们为什么要学习电邮沟通技巧呢？因为电邮代表了个人职业形象，好吧，我们开始。

 

第一个问题是什么情况下我们应该使用邮件。

在使用邮件前我们必须清楚邮件只是众多沟通方式之一，既然是之一，那么必然就有应用它的合适场景和不合适场景。

 

邮件沟通场景之一：知会对收件人必要的信息

这类场景包括了会议通知、事件周知、申请批准和信息分享。这类邮件几乎没有什么好说的，重要程度也不会太高。

 

邮件沟通场景之二：沟通确认结果

正如会议，沟通的功夫永远在线下，会议和邮件的目的只是确认沟通的结果。事情在发邮件之前一定是被搞定了，不要通过邮件来搞定事情。领导关注的只是结果而不是过程，好的下属一定要领导省心。这类邮件包括了会议结论、行动计划、项目总结邮件。重要程度很高。

 

邮件沟通场景之三：表扬和感谢

对跨部门项目或在项目取得阶段成果时一定要多用邮件表示感谢。感谢一定要具体，要有具体事例支撑说明，要抄送收件人领导。

 

有了应用邮件的合适场景，不合适的场景基本上就对应起来，一句话：不要妄想使用邮件解决问题。任何问题的解决都是在线下，邮件只是确认结果。知道了邮件的使用场景，那么第二个问题就是如何写好邮件。

 

第二个问题是如何写好邮件呢。

在具体写之前还是必须先想明白一件事：我们为什么要写这封邮件？我们的目的是什么，要达到这个目的邮件内容应该包含哪些信息。想明白这件事，接下来的邮件形式就非常简单了：

 

1 邮件收件人一定是具体办事或需要回复的人，抄送则为领导需要知晓邮件内容的人，一定要想明白邮件的发送范围；

2  邮件标题前使用【】，例如【Anemoi项目】、【请审阅】、【请协助】、【很重要请回复】等；

3  邮件称呼使用，Dear Michael、Dear all；

4  正文要朴实、明确、简练，周期性邮件要建立模板，例如会议模板、进度汇报模板，如果使用图形一定要图形自己表达出意思不要让一千个人眼里有一千个哈姆雷特；

5  一定要有签名；

6  出差、休假时设定邮件自动告知。

 

归根结底，写好邮件其实就是一句话：一定想清楚写邮件的目的。

 

结论：不要妄想使用邮件解决问题，邮件只是确认结果；一定要想清楚写邮件的目的。

NO.2  一定要想清楚自己要什么

标题是一定要想清楚自己要什么，内容却是士兵突击，因为从那么样一群的男人身上，总能扒拉出点自己想要的。

我周围的朋友大多讨厌成才，他们把他从钢七连的出走和演习中的放弃称为“背叛”，他们把他的自我主义称之为对许三多的“出卖”，他们说，这个人才是真正的假到了一定水平的人。

我什么都没有说。 

因为说真的，在这群华丽的男人中间只有成才略显真实，只有他才在成长过程中不断遇到挫折，哪里是挫折，那样完整的一段人生历程，比之我们大多数人，那要强上太多了。 

刚到红四连，没多久，就被发配到了草原上的五班，那个让人绝望的边缘部门。好容易到了老A，袁朗又将成才做人的根基击得支离破碎，将成才信奉了二十年的那些东西打得无影无踪，他说成才心里没有七连的“不抛弃不放弃”，可是他自己却将成才放弃了，他说不敢将全队人的生命交托在这样的人手里。 

虽然理由无可厚非，但成才毕竟万念俱灰。我有时候想，袁朗难道真的是神？他一眼就看出了成才是不会被打倒的小强吗？或者不是，那么成才的一生就从此陷入自卑的阴影再也无法自拔——谁又曾把对待许三多的执着和宽容原封不动地移到成才身上过？甚至，众目睽睽下，永远温和的班长将酒泼在成才脸上，不留情面。我常常想，如果是我，我会怎么办？

PM又何尝不是这样，一段时间，我经常陷入到做事还是做过程的迷茫中。是的，团队开始迭代了，开发计划很少延期了，团队氛围活跃了、团队规则确立了，然后呢？团队方向是产品经理在负责，产品技术是技术leader在负责，PM呢，只是一个做过程的，每天就是制定计划、追踪计划还有那大大小小的会议。PM的价值究竟在什么地方，PM未来的发展到底是什么？每当这个时候，我就会想起五班上的草原，一望无际，看不清方向。

直到飞跃培训，听廖凯讲他的故事，讲他的坚守，我才明白，唔，之所以迷茫，是因为我根本没有想清楚自己想要什么啊！

谁说我们在做过程？我们本来就是在做事。团队计划总是延期，这是不是问题，是的，是问题，我们建立起有规律的开发节奏，在开发和产品之间建立起清晰的规则，保证了开发的效率和进度，这算不算是做事呢，是的，是做事；团队属于技术支持部门，尽管非常努力但用户满意度不高，这是不是问题，是的，是问题，我们对需求排定优先级将团队的开发向外可视化获得更多的理解，这算不算是做事呢，是的，是做事；中心有多个开发小组，一个面向用户的交付往往要跨越多个小组，交付时间长，这是不是问题，是的，是问题，我们协调各个小组的开发计划建立项目集的视图在整体上达成一致，这算不算是做事呢，是的，是做事；部门发展很快，一个产品的开发人员由最初十几人发展到几十人，协调越来越困难，这是不是问题，是的，是问题，我们将开发团队按照特性和产品架构进行拆分，将沟通尽量限定在一个组内，减少沟通的范围和成本，每个小组都能独立交付特性，这算不算是做事呢，是的，是做事；部门产品线上总是出事，这是不是问题，是的，是问题，我们建立起发布流程和自动化的打包发布机制，产品发布前必须经过自动化的集成测试，这算不算是做事呢，是的，是做事。

所以，PM是什么？PM是解决实际问题的人。在一个一个问题的解决过程中，PM就成长了，因为问题总是类似，对研发部门来说，需求、开发、测试、运维就是这些事，对沟通协调来说，小组、中心、部门、跨部门沟通就是这些事，对产品形态来说，客户端、前端、后端、搜索、广告、app就是这些事。当碰到一个棘手的问题时，应该对自己说，嗯，成长的机会又来了，并且，越是让自己痛苦的问题，事后一定是收获最大的问题。当有一天，你来到一个新部门，所有的问题都是那么的类似，自己都曾经解决过或知道解决方法，那么，恭喜，你就成长了。

我自己想要什么？我想要的正是解决问题的思路，在一个一个实际解决问题中积累的经验和思考，当对大多数问题你都能游刃有余的时候，这时缺少的就只是一个机会了。

回到士兵突击。

这一切，成才都熬过来了，一个人，从最初就有自己坚定的目标，知道自己想要什么，并且为着自己无论如何都要做到的事情不断地舍弃和放开，这才有可能成功。我讨厌成功这个词，我更愿意用成才最后享受到的一句话：“你的路，比许三多还长。” 

NO.3  PM成长日记第三话-那些年我们一起做过的项目

第三话按照原计划是要写写平常心的，因为飞跃计划要交作业，所以就改为写自己对项目管理的一些经验总结，刚好前一段时间那些年我们一起追过的女孩很是流行，这一话的名字就叫做那些年我们一起做过的项目。

我的第一个项目是在2005年，那是一家市场占有率前三的本地化翻译公司，公司的信息部门只有两个人：老大和我，我们一起开发公司内部的协同办公系统。要解决的问题很简单：由于公司发展迅速，以前单纯依靠纸质单据和邮件分派和追踪任务已经越来越让项目经理和财务不堪重负，迫切需要将这些工作给自动化。系统的技术架构也很简单： jsp+javabean+mysql。没有专门的开发计划，基本开发流程是这样的：每周一我们访谈一个业务部门经理，了解他的需求，周中开发，开发中有任何问题都可以直接找业务经理，周五的时候系统上测试环境，再和业务经理坐到一起看一下是否满足了他的需求。系统就一直这样不紧不慢的开发着，老板办公室就在我们身后，一有时间老板就会和我们一起使用该系统。整个开发过程只有一个细节让我印象深刻，就是对任务估算工作量时，不管我估算多少，老大都会给我乘以3，一次要给业务表单增加一个字段，老大问我需要多长时间，我说不就是增加数据库字段吗10分钟，结果老大给了我半天时间，老大说，增加字段确实只需要几分钟，但打开编辑器需要时间吧，集中注意力需要时间吧，改完了启动系统测试需要时间吧，测试完了和业务经理确认需求需要时间吧，我们估算的是完成整个事情的时间而不仅仅是编码的时间。

这个项目完成时获得了公司上下的一致好评，从公司老板到业务经理，每个人都非常满意，而让我感到唯一遗憾的却是身为IT人员竟然从来都没有加过班。

回想起来，这个项目之所以成功固然是因为技术简单和系统不复杂（我们甚至都不需要 SVN，完全依靠脚本同步代码），但最重要的还是持续交付和持续的用户反馈，老板和业务经理每周都能看到新功能的上线，这增强了他们的信心，同时反馈几乎每天都在进行，并且他们很快都能看到这是否是他们想要的。

第二个项目在2006年，这一年我换工作了，因为当时我认为不加班的程序员不是好程序员。新公司在上地，是一家做协同办公业务平台的公司，最开始去的是项目部，一开始很为业务平台这个概念着迷，因为当写程序时最先不是写代码而是用代码生成器生成代码，并且生成完的代码马上可以运行！第一个项目是丰田公司的销售管理系统，我们创新的使用了当时最热的Ajax技术，我们完全是用技术热情加上周末时间完成对原有功能的 Ajax增强，这个项目获得了用户极高的评价，因为当大多数web系统还在使用点击 /刷新的方式进行交互时，我们却可以直接拖拽完成操作了。如果在当时，我会认为是技术的创新让项目获得了成功，但是现在，我会用渐进式增强这个词，即只有在完成用户所需要的核心功能（什么叫核心功能，即缺少这个功能系统不能工作）后才开始对系统用户体验、性能进行渐进式优化。

第三个项目是在公司的平台部，这里部门经理正准备对原有的业务平台进行重写，原先业务平台的技术框架是：jsp+struts+ojb+sqlserver，新的技术框架定义为： ajax+freemarker+webwork+spring+hibernate。这让我兴奋，因为新的技术框架几乎是当时最流行的技术。加部门经理共有三个开发人员（所以沟通一直不是问题），老大使用project来管理项目，每个人负责一个模块，估算以周为单位，最初计划是 5个月交付，功能直接就是老平台的翻版换的只是技术实现，但是 5个月后进行测试和项目试用时却发现了大量缺陷，最后几乎用了半年时间才将缺陷收敛，产品发布计划延期半年。回顾这个项目，需求没有进行详细的分解和评审导致实现与需求不一致 似乎是项目延期最重要的问题，然而更深的思考却是我们需不需因为技术原因开始新产品的开发，在不影响用户使用的情况下对原业务平台进行渐进式增强是否更加合适。即我们在启动项目时更多关注的应该是用户价值（只有有用户价值用户才会买单公司才有收益）。

第四个项目是我负责的，这个项目几乎是上一个项目的翻版，重写公司的工作流产品：支持更多的工作流模式，更易集成的api和管理界面，唯一不同的是这个项目采用了很多敏捷里的实践：持续集成、单元测试、站会、迭代，但这些实践均不影响这个项目最终的失败。同样是该不该重写这个项目的问题，在公司资金链紧张、时间要求紧、新产品相比竞品没有突出特性的情况下，这个项目从一开始就决定了失败。如果没有特别充足的理由就不要重写产品，这几乎成为我目前最重要的一条原则，尤其要从公司全局的角度看待产品不能局限在技术。现在，只要谁一说到要重写产品，而给出的仅仅是技术原因，我就会两股加紧，冷汗直流。在对项目完全负责的情况下，我另一点深刻感受就是人的重要性，对团队中的每个人员，作为leader 你都需要知道他的需求是什么，没有人愿意做机器人，在一次对某一技术方案简单粗暴拍板后，一个核心技术人员流失了，这成了压垮这个项目的最后一根稻草。

08年底去了一家新公司，新公司采用敏捷实践。第一个项目很成功，几乎是敏捷项目的一个成功范例，需求分析、迭代、持续集成、结对、客户 showcase、持续交付，项目甚至提前半个月完成。唯一美中不足的是项目二期时新团队由于一期文档很少带来了很多困扰。突出的感受是：团队人员有了角色、有了分工也就有了流程。现在，到了一个新的部门或中心，第一件事情往往就是梳理项目开发流程，定义出每个人的角色，职责不清是互相埋怨之源。

第二个项目是咨询项目，略去不表。第三个项目是分布式团队，一部分团队在国外，一部分团队在国内，最开始一切顺利，但在上线前一个月遇到了严重的性能问题，陷入了一片混乱当中，所有人都不知道我们离上线还有多远，还有哪些工作需要完成，优先级都是什么，项目经理甚至自己都失去对整个项目的把控，她不知道项目上线究竟需要满足什么条件，于是一次次在等待国外团队优化后的测试结果，于是一次次的测试结果不满意，于是项目在一次次的下周二上线的空头承诺中成了整个公司的笑柄。这个项目回顾起来就是团队遇到挫折时放弃了计划，迭代没有了，故事墙没有了，所有人都在等待，而项目经理为了不让开发人员被公司收回还不得不想一些优先级不高的任务给团队完成装着我们很忙。教训就是，任何情况下都不能放弃计划，计划是项目之本。其他包括团队能不分布式就不要分布式，如果必须分布式那么一定要从架构开发任务上进行隔离，尽量减少两个团队之间的交互（很多项目经理进入到部门之后推进项目制，其实也是同样的原则，团队大了就要拆解，产品代码多了也要模块化，尽量减少团队之间、模块之间的交互，做到能够各自独立演进和发布）。尽早进行实际环境的测试，越早越好。测试越早进行越好，测试环境越贴近产品环境越好，这一原则什么时候强调都不过分（我们上线前的测试才发现严重的性能问题）。

第三个项目是幸运的，因为他们有钱，能够等待，在多等待了大半年后系统终于上线。而第四个项目就没有这么走运了，这个项目是一个在线 saas CRM系统的重写，而且有着强时间约束（如果半年不能交付，将错过该系统客户每年做预算的窗口期），看吧，又是重写，又是时间约束，这几乎总预示着它厄运难逃。表面上看项目是在一次中期的架构重写中崩溃了，重写耗去了团队太多的时间，而由于对未知领域知识的不正确估算（需要学习）再次令项目雪上加霜，项目目标又不能变化，要在六个月后上线，但更深层的原因还是项目开始之前没有决策正确，真的要重写产品吗？老产品确实界面很丑、一些功能没有，但这些不能渐进式增强进行吗，一定要重新开始吗？重写使用新团队，他们对该业务领域并没有经验，过去系统遇到的坑他们不清楚，他们的计划因为少考虑了一些情况是否显得过于乐观？这个项目的其他问题包括项目计划一直没有发生变化，尽管所有人都认为在规定日期到来之前不可能交付，但这个日期却没有发生变化。最后不得不说这是一个技术强大的团队，一切都做到了自动化，甚至部署产品环境也是一键完成，但是这些在项目目标失败的情况下显得黯然失色。而客户贷款做这个项目则让很多团队成员良心不安。

来到腾讯，来到soso，最重要的收获是对运维有了新的认识，以前曾经认为devops就是自动化部署，全功能团队，现在发现它关乎架构：一条搜索的badcase是否能够很快找出错误的原因？是抓取失败，是索引时丢失，还是相关性排序不好？关乎监控和报警，我们能否很快从监控中定位出原因？关乎组织结构，前台开发，后台架构，基础架构，运维测试团队都是分离的，如何协作才能使团队合作的成本最低而整体利益最大化？

回顾往事，保尔柯察金说：如何才能不虚度光阴，只有为共产主义奋斗终身；柯景腾说：唯有沈佳宜让我怀念；而我想说的是：

• 做任何项目之前一定要想清楚为什么要做这个项目，一定要想清楚这个项目的价值是对用户和公司的（尤其需要跳出站到一个比较高的层次看项目），一定要想清楚项目的约束（时间约束、人员约束）,不仅是项目开始之前要想，过程中要不断回顾；；
• 项目任何时候都必须有计划，对所有干系人透明；
• 项目一定是持续交付和持续反馈的，不允许黑盒出现；
• 测试和运维一定要尽早介入；
• 从每个团队成员的角度出发关注所有人的利益实现共赢。