Tony Bai

昨天是周五，按照工作计划，上午和组内同事做个人阶段性目标沟通。在与一位曾经在国外公司里做过项目的同事沟通时，他给我讲了这么一个故事：某一年的圣诞节前夕(圣诞节在西方人眼里是地位最高的节日了吧)他所在的那家公司的经理预感到圣诞节那天他们公司的网站的访问量激增的可能性会很大，为了保证网站在那圣诞节那天能"挺住"，他要求手下的人对网站进行一次压力测试，并决定让手下用jmeter来做这件事情。手下人没有异议，由于没有用过jmeter，遂大家都忙碌起来，预研的、准备测试环境的等等。一切就绪后，正准备开始测试了，这时那位经理突然召集手下人说jmeter不能满足他们的压力测试要求，大家都惊愕之，并马上提出了反驳，因为jmeter工具是这位领导提出要使用的，现在又不用了，圣诞节已经迫在眉睫，更换压力测试工具肯定不能完成这个任务了。这位经理无奈妥协，结果是：通过jmeter压力测试后优化的网站顺利了通过了”圣诞节的考验“，不过大家都觉得这个过程很别扭。

上面的那位经理显然是犯错误了，我看到的起码有二：第一，没有经过对jmeter细致的评估，就断言要使用jmeter做为压力测试工具；第二，其领导意志的不坚定，险些使任务失败，并最终造成了公司成员的不满情绪，影响了整个团队，得不偿失。

这个故事也让我触动很大。记得在上一个项目的准备布局阶段，我当时很想在项目组内推行自动化页面测试，提高开发人员和测试人员的测试效率，到目前为止我也觉得当初我的想法是没有错的，但是问题就在于执行过程出了问题。我对web页面开发是外行，WEB页面开发过程会遇到哪些问题，我基本没有太多概念。当时部门内部正巧有一个服务于外国公司的项目使用了Watir-一款用Ruby实现的轻量级开源Web 自动化测试框架，很袖珍，上手简单。我就安排了一位同事专门花时间去研究了一下如何使用这个工具，并在组内做了一个Share。大家对这个工具提出了一些自己的意见和建议，并基本上认同了它。由于是试点，所以先安排放到测试组做自动化页面回归测试，由专门的测试人员负责编写测试脚本。就这样完成两轮测试后，收到一份文档-关于Watir在自动化回归测试过程的问题报告，里面列出了诸多问题，比如：自动测试过程中如遇到弹出对话框的情况，自动化过程被中断，需人为干预；测试对数据依赖很大，当数据量很大，需要多页显示时，没有找到很好的办法；页面元素变动较为频繁，用例脚本需不断更新，工作量较大；Watir只支持IE，对其他浏览器支持不好；Watir录制功能不甚完善等等。这些问题是我始料未及的，恰逢那个时候，我又发现了一个更为强大的页面自动化测试工具-Selenium，我个人也就渐渐的对Watir失去了早先的热情，Watir在我的不坚定的意志下没有收获很好的结果。现在看来，如果当时我持续关注、持续推进Watir的使用，积极解决发现的问题，也许Watir就会成为大家日常不可缺少的一个工具而存活下来，显然我没有这么做，我想和上面的故事一样，或多或少这也给组内的同事带来了一些负面的影响。

与此类似的是部门曾经多次考虑过使用C++来重新设计和实现我们的产品，众所周知C++开发效率高，性能也不逊于C，如果真的改成了C++，我们的思维也可以和这个世界接轨了(很多人认为：太多的新思想似乎和古老的C搭不上边)，大家认可，关键是领导也认可并鼓励一些有能力的开发人员抽时间研究学习C++，但是每每总是不了了之，领导始终没有坚定的意志做这次变革，开发人员也逐渐消磨的热情，回归到了C的世界。

打破既有规则，拥抱新事物，似乎一直就是一件很困难的事，而领导意志在一个组织内部目前来看还是起着决定性的作用的，否则再好的东西也会变成局部的个人兴趣，没有用武之地。如果一个领导坚定的推行大家都不认同的新事物(很可能是领导的个人喜好或者上级的命令)，那么这样带来的后果将更加严重。

所以作为领导的，确需三思而后行啊，用此文自勉共勉吧。

国内，也包括国外大多数项目经理/技术经理都是技术出身，工作了若干年，羽翼丰满后，被赋予了带领一个项目的责任。从技术到管理的过程多数人都需要一段时间去转换和适应。什么时候算是合格了或者说是入道了呢？没有标准。但是从我的体会而言，是否开始主动思考项目是至关重要的一点，一个重要的转折点。

刚刚从技术转为管理的人一般都不能很好适应角色的变化。技术人员最拿手的、最擅长的就是技术了，编码是他们发挥才能的舞台所在，也是获取成就感的源泉所在。以前一个技术人员可能只需要完成自己那摊子事情即可，但是转换为项目经理角色后，他要关心的事情就比较多、比较繁琐了。时间、质量和人，无一不要涉及到。更有甚者对于国内很多开发行业软件的项目经理而言，应对行业客户也可能是份内的职责，焦头烂额也许是刚刚步入项目经理角色的人最真实的写照。刚开始做的不好，遭遇挫折和抱怨其实不是项目经理的错，他们曾经是技术人员，没有经历过系统学习和培训，转换角色后都是摸着石头过河，起初势必没有头绪，或者是照猫画虎，把以前自己的顶头上司的那套照搬过来，执行之，也不管到底适合否。项目在这样的状态下运行的磕磕绊绊，但在这样的一个过程中，多数项目经理会发现问题，开始调整、学习、咨询、参加各种培训，试图破解自己遇到的诸多问题。

开始思考项目，我觉得这应该是一个项目经理真正融入角色的一个标志。带了这么长时间的项目，我也是从今年中期才逐渐发现自己开始有意无意的思考整个项目的。中期总结、下半年目标制定、项目过程上的一些改进和新的尝试、新员工培养计划、促进现有人员技能提升以及新技术框架的使用，这一切都是在思考之后采取的措施。

公司采用的CMMI的Heavy Development Process，从心底比较抵触。做过几个项目后，发现自己再也不愿意做重复的事情了，决定另起一条线，尝试一些Agile的Practice。一个人努力的持续推进Process的改善，挺累的。很多人不理解，不清楚为什么要这么做，我也计划着逐步通过讨论和Training向大家渗透一些Agile的观点和做法，让大家从各个方面接受之。虽然我也只是初步了解一些Agile的东西，呵呵。

目前已经开始尝试的Practice包括：
- 看板管理；
- Daily Stand-up Meeting；
- 阶段性成果演示；
- 持续集成；

从目前来看，大家似乎对持续集成不是很感冒，对于CC.rb发送的build fail的mail也置之不理，自己都无法build成功的代码也照常提交，这只能说明大家尚未了解CI的好处，也没有养成好的代码提交习惯。

看板和Daily Stand-up Meeting对于大家来说都是很新鲜的事物，大家有着很高的热情，目前感觉瓶颈在我，如何能正确的执行这两种Practice，还需要我继续学习、实践和思考。一批书籍待我去读和领悟。

阶段性成果演示收到的效果最出乎我的意料，曾经写过一篇blog专门述之。

提高执行力、提高个人和团队工作效率、合理的团队建设、减少浪费和不断的过程改进是我下半年的几个改进重点。可以说，现在的项目是我的一个试验品，要想试验成功，没有一股子韧劲儿是不成的。对自己说：坚持住。

最近一段时间正处于项目策划阶段，这个阶段势必要和部门QA打交道，咨询问题并获取支持。按照我们公司的软件开发流程，策划阶段要输出一系列文档的。这些文档都是有公司模板或者是经部门裁剪后模板作为基础的，所以现在项目前期策划基本上就是按照自己的思路填写文档，估计很多公司也都是这么做的。

好不容易花了一个星期的时间把这些文档'填全'了。提交给QA，让之帮忙审审。QA的一封邮件回来，问题多多。

当我看到这些QA提出的问题时，我的第一个念头就是"QA人员一定要有实际项目经验"或者说这些体系文档QA自己按照流程一个一个的实践一下，自己填一遍。这样就能体谅这些问题是为什么发生的了。比如说：QA建议每个项目阶段前都要有一个任务叫"策划xx阶段"，用过MS Project的人都会了解，如果分配给一个人的任务散布在整个Project甘特图的各个部分，十分不利于人员的任务分配，你要考虑到任务间的依赖关系，还要考虑到'资源工作表'中每个资源不能'变红(过载了)'。这些阶段性策划在实际项目过程中都是在一个集中的时间段完成的，大可集中放到一处。还有，对于多人参与的任务也是很难分配的，也是要考虑依赖关系和资源过载的。

部门的QA没有实际项目经验，隶属学院派的，工作很认真，并且有坚定的过程改善的信念，唯一缺乏的就是实际的项目经验。如果能到一线锻炼一下，相信她会发现更多待改善的问题，也就不用我们不断的提意见、沟通、反驳、再沟通、再达成一致了。谈到QA，我的理解是：QA一定要有坚定的信念，很好的执行力，丰富的项目经验，相信通过良好的不断改进的过程一定能让项目管理更加精确、准时。否则如果没有这份坚定，做起工作来那简直就毫无乐趣而言了。很多大公司的QA都是由一线开发人员、测试人员或者是项目管理人员转型后来做的，他们在项目里待过，知道改善的地方在哪里，同理心更强，知道开发人员为了达到某个项目管理的目标需要付出的代价。有项目经验的QA能大大减少纸上谈兵的概率，提高自己的说服力。

还有很多问题原因不在QA，而是模板的问题。填写模板时我们也希望要填写自己能控制、能想到的东西，如果在自己控制力之外的一些东西非要填，那就很头疼了。其实这也和部门角色定位有关系。部门的项目负责人与传统意义上的项目经理不甚相同，部门的项目负责人在一定意义上是偏技术类的。如果让偏技术类的负责人去填写什么"信息资产管理"、"共利益者管理"、"客户资产管理"、"项目采购计划"这类的表格显然是"门不当户不对"。

做项目也是做事，应该本着一个原则'简单'。把一些与项目目标不相关的事情也牵扯进来似乎费力费神，毫无意义。记得在上一个项目总结会上提到过一个成本目标的问题，项目初期策划时需要填写一个成本估计，然后结项时收集实际成本数据做比对，看目标是否达成。可是项目总结时根本无处获取这样一个成本数据，财务那面根本就不会给我们技术负责人出这种报表的，类似这样的'估计'估之作甚呢。

意见和建议已经提交给QA了，估计明天又会有一次激烈讨论。^_^