waders的专栏

昨日部门经理会，看到了某项目已经完成的工作量已经接近86％了，今天早上特别给项目经理通了电话，“祝贺”他离工作量超出100％已经不远了。他的项目已经进场一周了，还有3个星期就要上线了！（会不会与客户为了保障奥运成功举办出台的相关IT系统保障措施有冲突呢？）在讯问项目情况后，告知他作为第一次在该客户的处女作，应该紧记以下三个教条：质量导向：前提条件，不能保证质量，其它都是假的，这是我

以下事情发生在9月20日的5:00~6:00PM上周六下午天气炎热，睡了个大觉醒来时已经五时出头，知道某项目正在紧张地部署准备本周一正式投产服务，因此和项目经理A通电话了解项目部署的情况，项目经理简要地知会了部署的情况如下：部署提前在上周四就已经开展，因为需要重新部署一台新的服务器，所以保留了旧一期的平台；部署的新机器，从操作系统，到中间件服务软件，上层的旧一期以及新一期增加的软件

某日同事G和我聊起了半年来在一线当项目管理的感受，做为他当项目经理的处女作，特别谈到了其中的各种挫折，有管理方面挑战、技术方面、团队方面和客户信任等等方面！感慨规范的重要性，提及这段时间我对其工作的指引，并且谈及如何避免未来公司的新任项目经重蹈覆辙，他最后做出的感慨是：规范很重要。再从另一个角度看，公司CMMi认证目前也正在紧锣密鼓地开展，已经去到了最关键的时刻，期间也有不少动摇，现在各种定义

昨日出外开会后回到公司，检查了同事负责的给另外一个部门提供测试服务器的工作任务。按照要求，我们需要提供一台安装有操作系统linux以及中间件服务器tomcat+oracle的测试机器，此工作原计划在周一10月13日下班提供，由于技术原因实现承诺，周二、三的期间由于有其他工作安排工作挂起，周四10月16日已经向同事承诺再投入一天在周四下班前完成。很不幸，昨日10月17日下午检查工作结果是工作

转自csdn博主leo的Blog【leo版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章原始出版、作者信息和本声明。否则将追究法律责任。本文地址： http://blog.youkuaiyun.com/jobchanceleo/archive/2008/10/15/3078182.aspx】专业与职业的区别  最近看了网上一篇文章，里面有句话给我很深的印象“所谓的职业，就是你靠这个能够生活。

序：昨日吃饭，路上遇到了同事L，谈起他以及他所在项目小组工作，L告诉我他的一个真实的、新鲜出炉的故事，虽然L以前也听过我有关于部署实施的培训课，但是他说在工作中真正在吃了亏之后，才能更好地体会到其中的问题。场景：故事实际发生在上周四周五。计划的事情如下：同事L的项目组服务于业主Z，业主Z计划在周四晚上开始停机，对IT基础支持环境的Oracle数据库进行升级，计划从9i升级到10g。

场景：昨日去业主方现场去了解项目组的工作情况，了解到项目L已经着手初验工作，除了初验工作外，目前还针对本期上线实施后双方提出的变更进行开发，预计下周内完成本期变更的上线。我询问了项目组L的项目经理YS和技术经理CC，问这些变更的工作与客户是否有达成共识，客户是否对变更“买单”。得到的回答是已经和客户达成共识，在下一期的项目里补充本期的变更。我进一步询问，公司的工作量统计网站，他们当前项

在博文《发生在眼前的故事：不做好最坏的打算，往往事情就会去到最坏的地步》系列故事中，提到了cdw和我们在排查系统类似“死机”的工作中，逐步掌握了分析系统性能的方法。在完成了该系统的排查任务后的一天，刚好另外一个项目组M也在为系统S上线做准备，该项目组也知道我们前面在系统优化工作的成果，向我们提出协助的请求，我推荐了cdw去项目M现场对上线前性能优化压力测试的工作进行协助。cdw在项目M现场

某系统周一上线了，周二早上收到了同事P的上线监控报告，截至目前情况该系统由于业主周一才正式发文通知各地市使用，因此还未有很大的压力挑战。同事P在总结中也指出了此问题，并且说明了Weblogic运行情况正常，从3个时间点抽样来看，健康状态都是OK；另外指出ETL部分目前是以增量方式进行数据抽取，也还未经受挑战。另外在邮件中付上了两个附件。 看完了附件，我的回复如下：正文和附件

序：近日管理中心的同事C询问关于软件版本号管理的事情，定义公司软件版本号的规则，写入CMMi执行的条例中。C同事定义的软件版本号的三段规则，记为major.minor.(revision)，第一段主版本号major表达主要的软件版本，第二段是次版本号minor表达软件的升级补丁，第三段是可选段，用修订号revision用于表达软件的紧急修复。对于C定义的软件版本号，我赞成，也赞成不要把buil

我认为，对于脱离了作坊式生产的软件公司，用保姆盯小孩的方式来进行人员的引导和培养应该是行不通的。公司的管理层（不包括项目经理），都不能同时应付那么多的“小孩”，也不应该那样去对待“小孩”。估计那样会有点吃力而且没有收到良好的效果。 对于目前以项目组为单位的形式下，要把握好人员培养这一关，项目经理起着一个很重要的组织者的角色。但是部分的项目经理的首要任务是完成项目任务，而且主观上在安排分配工作上

在周一公司内部和部门经理一起进行的项目周会上，项目经理基本上会按照以下的议程给管理者汇报：上周工作计划的完成情况以获得的成果或者产出；上周实际执行情况与上周预计的计划进行差异分析，提出改进；本周的工作计划以及对项目目前风险的分析；呵呵，听报告其实是个苦活，如何从听汇报中了解项目工作的细节，找到可能项目经理忽略的问题或者风险，分析问题的关键点，并且给出意见，是项目经理们给管理者的考验！从前端时间对项

公司正在进行CMMi实施，从前一周CMMi顾问在预评审阶段前给到我们的差距分析报告来看，可以毫不客气地说，现在公司正在进行地项目，CMMi实施项目是风险最高的项目了。从报告中看到的差距，那些在我们工作中抽查发现“本末倒置”的做法，可以看到不仅需要我们在工作中扎实付出改进、严格执行，更可以看到，需要我们项目经理的领导在意识上、管理理念上进行升级换代。随着管理中心近期对CMMi的加大投入，我想

场景一：前周某QA同事A去抽检项目周会，认为有不少可以改进的地方，A在会后和项目经理沟通了这些情况。但是管理中心等了3天，才收到A的邮件书面报告，书面报告中，A没有将该邮件发送给项目经理。思考一：QA目的不是为了刁难谁、让谁难堪，也不是向领导打小报告，目的是帮助项目经理发现自身没注意的问题，收集作得好的案例，同时向公司管理层反映项目真实情况，为管理活动收集依据和反馈。A也不能保

前日下午过了下班时间，看同事A还没有回去。问A为什么还不回？A说正在整理下午的内部设计评审的内容。接着又询问了下午他们内部设计评审，总有多少人参加并且提出了多少个问题（其实想通过这个问题了解到提出问题的效率以及能力）。从回答的数据上来看，我觉得对于项目的第一次技术评审，该数据还有很大提升的空间。简单看了一下他们项目组的模型设计，我给A几点建议：美观上去改进，给人看起来舒服，特别不要

周五和某项目经理C了解该项目的情况，由于该项目属于生产管理系统，而且每个月都有新的功能特性需要上线。由于是生产管理系统，所以每次上线的时间只能选择在系统较为沉寂的晚上进行部署上线。但是，最近几次项目组几次上线都要接近通宵到凌晨5点，接近10个小事的工作量。思维花絮：和C谈的时候，思维回到了从前...记得我刚入行的98年，每一次演示前，我们都要准备环境到凌晨4点，当时觉得是个“习惯”！

场景：在周会上，项目经理汇报上周某系统上线的培训，由于出现了前一天部署更新系统导致环境的问题，影响了培训效果，我们培训的当天中午解决了问题，下午终于可以开展完毕。业主觉得我们在系统上线前的培训工作，重视不够，除了项目经理，只派了一个开发人员参加，向负责该业务方向的高级项目经理施加压力，要求高级项目经理应该参加以后的培训。另外，还表达对我们项目经理的能力的怀疑，说项目经理的表达能力还不够，而

 连续几个帖子都出现了管理者面对客户的投诉，甚至是会上对项目经理进行尖锐的批评和指责，做为管理者，我们应该也需要进行及时的善后工作处理。 针对前面的案例：业主说我们项目经理上线很随意，“爱发就发”！服务，服务，服务的价值！不善后，结果如何？业主希望看到我们的改进，不善后处理，会让他觉得无奈；无奈多了，业主会完全失去信心，等到那个时候，才去做工作，已经晚了，现在投

这两天早上进行如何进行会议纪要的培训，最后一个环节交流会议纪要的编写经验，有同事询问：“如何提高项目组成员的会议纪要的记录能力？”，参加会议的各个项目经理纷纷出主意，现将思路整理如下：给项目组的同事在会前准备工作中，提供会议纪要的模板，让同事们看以往会议纪要的案例，让记录者了解会议纪要的各个要素和每点内容的要素；在进行会议纪要前，必须对记录者进行业务背景的介绍，让他对业务知识有所认识，

场景：（续原文《历史为鉴：稳定高于一切》）某项目组的系统在培训的时候出现：40个左右的最终用户在操作我们的培训系统时，系统没有了响应，最终用户操作的浏览器一片“空白”，后台服务器类似“挂起”，需要重新启动后台的中间件服务器。刚开始，项目经理和技术经理对此现象的风险意识不够，在多方教育下，逐步认识到目前发现并且解决问题才是最佳处理事机，等待上了生产系统，由于更多人员使用，会有太多干涉要素会加

某项目组周一上线，某地最终用户A在QQ群中询问：“XXX功能什么时候可以批量导入啊，急啊”，QQ群负责服务的同事对于A提出的这个问题没有及时响应。经询问了解，项目组的同事都知道用户提出的这个功能，而且也知道这个功能对于一线用户的作用，只是这个功能在需求调研时并没有提出，直到两个月前的第一次功能测试时，一线用户才提出，由于业主对上线时间要求得很紧，因此这个功能以需求变更的方式会在后期功能开发实现。经

在该项目中，需求调研人员花费一个半月时间开了8次需求交流会发出十几封需求讨论邮件向业主方调研需求，期间产出了3个版本的需求规格说明书（均在60页以上）。系统部分功能开发完成后给业主方展示。看了之后业主方惊呼不是自己想要的，指责我方不按照需求开发， 我方拿出需求规格说明书后，业主方更加激动当即认为我方“篡改需求”。后经项目经理通过从业务的角度向业主方说明为什么这样实现，以及按照业主方的想法实