waders的专栏

  场景1：Lenovo在美国展开优惠活动，ThinkPad笔记本在某个时期价格被下调20~22%，著名的X300被降价超过300美元，而同时，在国内，X300低配版24999元，高配版34999元。但优惠活动仅在美国本土进行。于是一些小黑的发烧友就开始联络美国的朋友或者通过淘宝网代购的途径购买美国版的ThinkPad机器。通过朋友购买，邮寄回国内，有可能被抽查，从而要支付关税，也

周二参加了中心的部门经理会，在会上了解和Review了项目R下周一上线投产的准备情况，除了项目组的开发、修复Bug的计划和人员安排外，我们主要在风险、服务层面对项目组R和部门经理T提出一些需要考虑的问题。项目R除了我们开发服务方，还有业务监理方、业主方以及最终用户，根据合同的安排，项目的培训、部署和实施服务由监理方负责，我方定位在开发服务，所以各个方面的工作需要安排协调妥当。具体的风险、服

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

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

续《发生在眼前的故事：不做好最坏的打算，往往事情就会去到最坏的地步（四）》以下事情发生在9月23日的10:10~12:00AM比dy早5分钟到了现场，先进行分工协助，不要因为出现了故障而乱了手脚！统一思想，项目经理A、负责电话和QQ服务的同事不用分心，继续维持服务，并且还要保证服务的质量不能下降！如果我们再次提前发现出现疑似“死机”的事故征兆，继续保持目前故障公告流程，让业主以

前序：系统开发完毕后进入了关键阶段——用户培训和上线部署，本项目在期间的部分点滴已经被博主记录，见《发生在眼前的故事：做好最坏的打算，往往事情不会去到最坏的地步》系列故事，这回再谈谈在用户培训过程中发生的故事：垃圾回收不回收。 场景：用户培训需要培训环境，培训环境搭好后，由于不常更新跑的时间较长，考验系统稳定性的时候到了，很可惜稳定性这个问题与我们大家的美好愿望一直背道而驰，天天求

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

上周下午和业主方的领导H进行沟通，谈到项目管理的问题，说起项目风险、跟踪的工作如何只能由H或者我来发现，那真是管理者的悲哀，原因如下：那只是“人治”，而不是流程化的法治；无法更好起到相互监督和补位的作用；项目最坏的打算不是由双方项目经理的决定，也是不对的！譬如：项目周三还不稳定，但是周五要上线，双方项目经理都没有提及上线的Deadline风险。我们不能等到周五没有解决问题，周末也没

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

绝对没有错，库存在软件项目生产也是存在的！库存就是指部分完成的工作，广义上讲就是指已经开始但尚未给客户创造价值的全部工作。在软件项目生产，我们可以容易地指出“库存”：尚未与用户进行确认的需求或者需求变更列表是库存；尚未被开发阶段验证的设计工作是库存；没有被提交测试的代码是库存；已经“做完了”，没有通过验收的开发工作、分析设计等工作也是库存；...理论上讲，软件开发中的库

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

    今天早上给同事培训了项目部署的一些实践经验，并且邀请了上个星期进行系统部署的项目组给大家介绍案例。    经过培训，我发现来参加培训的同事其实都还没有读过或者仔细读过我的写过的关于部署的Blog，我今天的培训都围绕这两个帖子展开。我看到有不少部门经理来询问下周什么时候再培训，他们还会再安排人员来参加，其实，如果认真看过这两个Blog的同事，并且能够认真执行的话，可以避免大量的问题，所以特别

场景1：         某个项目定了下来，做一个管理系统，接到这个项目后，我们组建了项目团队，派出了需求分析人员从事需求开发工作，但客户只提供了几页纸，并且告诉我们这就是最详细的需求了，这也是项目需求开发中经常碰到的问题，于是我们就开始发挥我们的专业能力了，首先是根据这些蛛丝马迹为客户分析其业务流程，并将业务流程充分规格化，转化为系统模型，然后是Step by Step的与客户进行确认，走访

 场景1：         A项目经理是刚入职的新任项目经理，迫于项目压力，A项目经理必须在入职后的第二天就投入到项目组中去，并被要求立即开展项目工作。为了帮助A项目经理顺利开始工作，部门经理组织项目组开了个会，把新任项目经理介绍给了项目组。         A项目经理进入项目组后，面临的第一个问题，也是最严峻的一个问题就是沟通问题。这一方面是因为项目经理是新来的，对项目不熟悉，对项目

项目E上周完成了初验，项目经理G一直想将他的经验总结下来，给后续的同事进行学习，我也非常鼓励他去做这件事情，今天收到他的总结大纲。呵呵，将大纲先发为快，我非常期待听一堂他的总结课，我想从以下的大纲，您应该会讲得很有意思的:) (注：一下内容摘自同事的邮件，其中每一点都可以写成一个独立完整的小故事，期待G同事的作品) 一、项目启动1、  “变量”初始化NULL值的后果——项目的前