waders-CSDN博客

转载转发同事的总结：做好准备

E项目是一个省建项目，一期建设已经完成，二期的建设重点是在部分地市做省市一体化的实施，现在已经基本完成S市的实施试点项目E1，准备着手第二批的地市实施，为此我们先做了一次Z公司的摸底交流工作，以下是E1项目经理对此次交流的总结。大家好，今天我们去了Z公司进行对E项目的交流，印象较为深的是需要我们做好准备，做好准备，做好准备。

2009-07-15 21:46:00 878

原创 "没事，我来扛"

今天早上,QA在茶水间遇到S项目的项目组员F，QA询问了他昨天工作的开展情况，他说因为项目组另外一位成员请假了，所以昨天的某项工作没能得到开展。QA重新查看了该项目的日报，发现项目经理没有把这件事情记录在日报，所有的任务情况全部都正常。QA找了该项目的项目经理了解这件事情，项目经理告诉QA他没有把这件事情写入日报的原因是日报也会发送给客户（客户要求的），担心客户会看到，项目昨天的任务都不是

2009-07-09 11:30:00 1014

转载转发同事的总结：需要资源吗？

YH是公司项目S的负责人，该项目目前还未结束，正在集成调试阶段。以下内容摘自同事YH今天抄送给我的总结邮件。大家好：项目管理，关注三大块：进度、质量和资源。三大块相互制衡，当进度要求过高，又要保证质量，就得增加资源。资源包括项目团队成员、公司其他部门、上级领导，客户也可以成为我们的资源。什么地方都得用到资源，协调资源就成为项目管理最平常的活动。协调资

2009-06-18 22:38:00 1073

原创监控报告风波之阳光—后续还要做些什么？

上回《监控报告风波之雨来—管理者的反思》说到这次的风波带了管理者的深度反思，大家纷纷就这件事情进行了批评和自我批评，表明了自己的观点，并给出了后续的行动计划。现在项目组发出的监控报告已经较之前有了很大的进步，高层经理也已经组织人员对监控报告的内容进行沉淀，预备加入到项目经理的工作指引中。这件事情，对我们、对高层经理、对项目经理、项目组成员起到的教育作用和带来冲击应该比任何内部同事苦口婆心的

2009-06-05 16:18:00 1387

原创监控报告风波之雨来—管理者的反思

上回《监控报告风波之雷鸣—来自客户的教育》中提到客户对我们提出了质疑，引发了我们怎么样的思考和反应呢？请看下文。事情发展到这里，所有的压力都直奔项目组而去，那么是不是全部的责任都在项目组呢？如果到此时，管理者还没有意识到自己的问题，还只是冷眼旁观的话，那么，这将是一件很可怕的事情。每个管理者都应该积极的去反思。首先是来自项目经理Z的反思：/********************

2009-06-05 16:02:00 846

原创监控报告风波之雷鸣—来自客户的教育

（接上回《监控报告风波之电闪—监控报告中的数据说明了什么？》）在我们发出这封邮件之后的第二天早上，收到了来自业主方的部门经理HJ的邮件，管理者的想法和思路经常是相似的，对问题也经常会提出相同的意见，HJ邮件的内容如下：/*****************************************************************/这些数据统计仅为上线情况统计的

2009-06-05 15:57:00 1306

原创监控报告风波之电闪—监控报告中的数据说明了什么？

（接上回《监控报告风波之云涌—监控报告到底是给谁看的？》）我们的邮件收到了一些成效，在项目组发出的第四日的监控报告中，修正了表格的格式、统计了每个分公司的登录人数，在第五日的监控报告中，增加了图表。可以看出，项目组已经开始在改进。我们需要给他们以鼓励。俗话说“趁热打铁”，教育及时才能收到更好的效果，同时改进的工作还任重而道远，我们必须利用这次机会引领他们向正确的方向发展，于是写下了

2009-06-05 14:48:00 845

原创监控报告风波之云涌—监控报告到底是给谁看的？

上回《监控报告风波之风起—监控报告这些写可以吗？》说到项目H上线了，项目组发出了监控报告，接着发生了什么样的故事呢？请看。后一日，项目组发送了上线后的第二份监控报告，具体邮件内如如下。/************************************************************************/大家好：我们对xxxx年xx月x

2009-06-04 17:28:00 1224

原创监控报告风波之风起—监控报告这些写可以吗？

状况经常都不相同，但是本质却常常类似，我们有可能穷举不尽所有的情况，但是我们却能清楚地表明我们的立场和原则。我们曾经在《关于IT服务：系统上线第一周》一文中讲述过关于系统上线后的维护服务工作。今天我们再来讲一个关于维护的故事，希望通过这个故事，让大家能体会到故事背后我们想想表述的立场。那么，对于维护这类服务性质的工作，我们的立场是什么呢？读者朋友们希望你们在看了下面的故事后，能够

2009-06-04 17:03:00 1220

转载同事项目总结之工作量的“和谐论”

转自同事H的项目总结中关于工作量的自身经历和思考，并且提出自己的建议，供读者思考。————————————————————————————————————————————场景：这里讨论的不是项目立项前的工作量，而是项目立项完毕、总体工作量既定情况下，变更工作量可能会遇到的问题。项目经理H，经历了项目A这个有关工作量变更的项目。按照原有需求，功能完成后系统已经投入正常使用。但无论是界面还

2009-03-31 21:32:00 1210

原创软件版本号执行背后的故事

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

2009-03-29 21:14:00 694

原创从“知识管理无用论”看国内顾问咨询公司现状——出路篇

转载自同事L的原创文章，续《从“知识管理无用论”看国内顾问咨询公司现状——问题篇》——————————————————————————————————————————1、咨询顾问走下神台首先我们不否定咨询顾问在知识管理服务中的价值，至少我们所在公司现在也提供咨询服务给客户，在导入一些先进概念或者成熟的实施模式方面，还是需要有人来总结和整理这方面的信息的。但是我们的立场是更多地把咨询工作

2009-03-29 19:12:00 1550

原创同事回应《记离职同事给我们的建议之一：关于人员培养方面的思考》

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

2009-03-27 13:03:00 1002

原创顾问需求方H说：“我们写的需求可能要求很高，到时候不能落地吃亏的还是你们......”

场景：业主的项目E由多方合作来进展，目前已经开展了近一个月的时间，我方负责实施落地，另一方H负责项目的顾问需求分析。周一与QA对项目E的工作情况进行监控，了解在多方的合作中，存在具体工作与合同约定不一致的地方。而我方的项目组员在这一分工立场上，原则站位还不够清晰。在几方项目经理都在场的项目周会中，当顾问需求合作方H对我方的同事说：“我们写的需求可能要求很高的，到时候不能落地吃亏的还是你们，

2009-03-25 22:34:00 1528

原创你的项目工作量预算是不是象扁嫂的人头账号？

场景：近日某一项目本周和业主进入商务的工作量确认阶段，据项目经理P反馈，双方在讨论工作量时谈得很痛苦。业主方在Review我方的工作量评价明细时，由于我方对工作任务项的细化分解比较细致，因而业主方要求我方提供从人员投入和时间纬度来检查工作量。双方在谈论资源投入的工作量时，对资源投入的分歧较大，讨论了一个下午，僵持不下。分析：业主和我们进行工作量的讨论，不是在买菜讨价还价。我告诉项目经理

2009-03-18 23:05:00 813

原创从“知识管理无用论”看国内顾问咨询公司现状——问题篇

转载自同事L的原创文章，续《从“知识管理无用论”看国内顾问咨询公司现状——引子篇》—————————————————————————————————————————— 我写上面故事，主要的诱因是在目前售前和顾问的工作过程中，遇到不少了这样的客户，他们认为“知识管理并没有象厂商和顾问公司宣传的那样有用”。一部分是本身深受其害，给顾问公司折腾得不行，最后发现付出和回报不成比例；一部分是对同

2009-03-16 22:19:00 1340

原创从“知识管理无用论”看国内顾问咨询公司现状——引子篇

转载自同事L的原创文章，由于篇幅原因，分两次发布，此篇为引子篇，为L同事的《麦肯锡养羊笑话升级版》———————————————————————————————————————————————— 又一次不请自来话说当年和麦肯锡公司顾问互相涮了一把的放羊老农，看到有得的养羊户的营生做得风生水起，不禁心里羡慕。当然老农也知道自己文化不高，能放上几百头羊已经是几年辛苦的结果，能否把自己的

2009-03-15 18:16:00 907

原创记离职同事给我们的建议之一：关于人员培养方面的思考

昨日同事H已经确定离职，我找他谈话，聊到给我们的建议，两点中的其中之一是关于人员培养方面的考虑。同事H告诉我们，他认为要更加关心人员的培养，而培养人这个工作只是某个人、某个部门去关注去执行是不够的。现将他的思路点滴记录整理下来，供我们自检：项目的目标如果只是项目，对于项目的人员成长相当不利；项目组之间的交流对于提升项目组成员的能力非常重要，一年一度的公司开放日给各个项目组有了展示和交流

2009-03-14 23:31:00 1063 1

原创售前评估的工作量和项目经理评估的有出入，怎么办？

场景：昨天同事H和我沟通，谈到了项目在开展时存在的问题，聊到公司的工作量评估和考核办法。目前工作量在售前的时候，由售前人员评估后经过部门经理的审阅，和业主客户进行共识确认。可是等到项目经理进入的时候，就会发现，售前评估的工作量少了，工作量有增加，该怎么办呢？而且公司对项目的考核机制也包括工作量的考核，考核工作量的基准应该是那个呢？分析：同事H反映的问题应该有一定的共性，从H的描述中，我

2009-03-14 10:36:00 3346

原创同事对评审的常见误区

前段时间参加了一些项目评审会议，发现同事对评审工作的存在一些常见的误区，现将这些问题罗列出来，抛砖引玉，以便管理中心的CMMi推进小组跟进。一个是对评审的方式的理解存在误区，评审不是一定邀请大批同事参加一个评审会，这样的工作方式很多时候会变成效率低下浪费资源的方式。评审其实可以分正式评审与非正式评审两种形式，而且往往在正式评审之前，多采用非正式评审的方式进行预先评审。非正式评审会的处理形

2009-03-02 09:05:00 1088

原创你说你最美丽、最艳丽，而且还是唯一的正确选择！我该怎么办？

场景：某业务系统X的技术要求提供业主最终用户的自定义数据模型的扩展需求，读者，我所了解到此需求确实是必要需求，不是项目组凭空想出来玩的。设计评审的时候，针对此需求，同事Y在讲解了设计成果。允许业主最终用户定义的数据模型，系统表达为逻辑虚拟表，通过虚拟表操作组件来完成，我简要地将设计者的设计结果表达如下：虚拟表操作组件的接口提供逻辑虚拟表的增/删/改/查的功能；操作提供了接口数据

2009-02-20 00:49:00 1456 1

原创给同事建议，如何能够真正学习成为Oracle高手？

前段时间，在公司大会议室，看到同事D在阅读《Oracle高效设计》一书，鼓励D说：“你知道吗？公司的H同事就是学懂了这本书后，在Oracle技术方面有了一个大的突破。如果你学会贯通了这本书，可以说在外面10个开发Oracle的开发人员，你能够赢一半！”。过了一两天，还在公司大会议室，还是遇到同事D，问起书看得怎么样，听到D的回答是：“觉得不是很能看下去，看起来吃力，不太理解:(”。我接着问D，

2009-02-16 22:09:00 2006

原创一个关于系统建模的探讨（一）

前言写一篇系统建模领域的文章，是怀着忐忑不安的心情来写，不敢亵渎这个领域的思考者，因为特定场合下工作良好的思路/模式在另外的场合下可能会失败得很惨。如果存在普遍适用的方法/模式，软件将会只提供该种方法/模式的支持了，为什么还要让人操心呢？在谈论复杂的时间建模的案例前，我们先来看看一个简单的系统模型，不存在时间纬度的需要，看看需要考虑的问题。我在十年前在某OA产品中使用过，因为产品的思考，尽

2009-02-07 18:02:00 1145 3

原创创新的Idea，为十年前参加OO培训同事的创意喝彩！

序：十年一晃而过，当年我还不在现在的公司服务，除了进行维护开发的工作，还需要对同事进行培训工作。培训的工作，其实需要进行很多课程规划工作，有苦有乐。以下内容可以给大家参考：策划阶段：包括明确培训对象的技能要求列表、培训目标以及培训的简要内容列表；开发阶段：准备培训的自学资料，撰写培训课件，包括：资料PPT、内容案例、学员交互材料、培训前自学考察、培训后效果考试；实施阶段：计划培

2009-01-18 18:35:00 958

原创在组织间跨项目组加强推广学习优秀经验

前言：以往对项目总结的认识不够，很多时候也就是写写PPT或者开个会，很多经验没有能被辨识出来成为案例，也就不能给大家分享。特别是很多教训，人性的问题，没有被说出来，毕竟说出自己的不是不是每个人都能做到。导致教训库不能不断丰富，因此前人吃亏，后人无法继承到有效的经验。前段时间进行2008年度总结的时候，业主提出接触我们这么多项目，我们每个项目经理的风格都不一样，项目的成功与否太依赖于项目经理

2009-01-08 22:18:00 802

原创养成预计的工作习惯，并且让自己的预计趋向于准确。

序：元旦前一周，项目O和项目C整合上线，整个上线持续了近三天时间。计划从周五下班后持续到周日凌晨0时，实际持续到周日凌晨3时项目C和项目O除一小部分非紧要功能存在缺陷外，实现整合上线。项目C技术负责人的L同事周日通宵到周一下午2点，而项目O的技术负责人C同事则从周五上班持续到周日凌晨3点都没有离开业务方的办公室，期间只是在办公桌上打个盹！除了他们之外，整个项目组的同事都非常努力和辛苦。

2009-01-05 21:51:00 751 1

原创转发同事总结：一个BUG引发的血案（总结篇）

续《转发同事总结：一个BUG引发的血案（结果篇）》，原文如下：4. 总结总结以上问题，在对外方面，第一个原因是初验之前只注重了IT部门的意见，和各个业务部门沟通不足，未达成一致的验收标准。我们自己认为可作为遗留问题，但用户的观点是如果不正确就不给验收。没有提前去拆除地雷，留到最后就相继爆发了，造成更为严重的后果。第二个原因，和外围系统的接口规范不够明确，制定规范时未阐明数据内在的逻辑关系

2008-12-31 17:44:00 805

原创 “正邪”的认识就在一线之间

本月某日对同事Z进行Review，除了交流月度工作成果外，也沟通了月度工作中的理解和体会。Review的内容涉及工作的多个方面，在这里和读者共享其中的一点。Z谈到了和同事Y的接触，让Z感触很深。Y参与了项目H已经有快两年的时间了，负责项目H的开发维护服务工作，11月底从公司离职。Z在和Y刚开始接触的时候，觉得Y好像挺滑头的，一开始都挺抵触或者有戒心的，但是后来的接触中，这种感觉改观了。Z以往也

2008-12-31 16:14:00 738

转载转发同事总结：一个BUG引发的血案（结果篇）

续《转发同事总结：一个BUG引发的血案（经过篇）》，原文如下：3. 结果EVENT5：初验会的爆发 TIME：初验会初验会开始了，前期埋下的地雷到了爆炸的时候，客户再次核对后发现导入和导出数据还是不一致，于是二话没说，推迟初验。此事件开创了公司的先河，成为第一个初验不通过的初验会。SOLUTION5：未雨绸缪的重要性出来混总是要还的，这样的结果对项目组打击很大。但仔细分析过之

2008-12-30 17:20:00 921

转载转发同事总结：一个BUG引发的血案（经过篇）

序：博文《转发同事总结：一个BUG引发的血案（起因篇）》说了项目初验不成功的总结，本期刊登同事P对过程的经过分析。原文如下：2. 经过EVENT3：被逃过的测试 TIME：初验会前3个月～初验会前1周第一轮测试工作中，测试人员测出了很多问题，但是上述两个问题并未测出，这是为什么呢？首先，测试用例并未详尽到这个程度。而问题1如果不是挨个核对确实很难发现，所有表格都挨个核对工作量

2008-12-27 10:00:00 949

原创从科教片人猿的进化差异想到...

某夜回到家打开电视，正在播放美国国家地理杂志的科教片，具体的名称当时也没有在意，就是一出描述人与猿的进化的电视。越看越觉得有意思，除了以往理解的美国人用数据说明问题的科学精神外，还被美国科学家的认真、谨慎的实验精神、治学研究态度所触动！影片讨论了人猿进化差异的各个方面，我刚好看到的是关于人猿的学习差异的部分，在学习能力方面，美科学家设计了以下的实验Learning Test：两组实验群

2008-12-23 14:12:00 1208

转载转发同事在例会后对技术问题的反思和对做事方式的改进思考

序：周五是某项目组内部例行周会时间，上周同事L将他在会后自己对技术问题的思考和对做事方式的改进想法发给了项目组，抄送给我。看完文章后，感触颇深，L也是以往在我认识中也是一个很技术化的同事，通过这段时间的锻炼和挫折，已经认识到执行力的重要性，而强调执行力，更加需要人有思维上的改变。L的反思和自我改进，我看出了他的良苦用心，从正文中可以看到L的苦闷，有不被理解的呐喊，希望他的项目各位同事能够认

2008-12-23 13:59:00 798

原创抓住你的用户心理，才能打造成功的作品！

冯小刚09贺岁篇《非诚勿扰》上映了，除了“想不笑，打麻药”外，笑声之外，最大的就是对观众内心深层的“隐性”需求撞击，喜怒哀乐全在冯导的掌控。他抓住了每个花几十元进场的观众，不管是上流社会，还是草根阶层，这些“隐形”需求都可以对号入座、引起共鸣！整场电影，冯导知道除了用欢笑来安抚中国人民08年疲倦的内心，所有的一切都融入了人的感情，以人为本围绕人性的需要才是最真诚的作品。除了男女感情和爱情，在影

2008-12-21 10:32:00 605

转载转发同事总结：一个BUG引发的血案（起因篇）

序：博文《公司的一个“新记录”：项目初验不成功》记录了项目P初验不通过的事情，项目经理P在而后的一个星期顺利通过初验后，将以往的经验总结成文，在部门内部进行相互学习。应Stud_100等读者的要求，现在将同事P的总结共享如下，由于篇幅原因，分起因篇、经过篇、结果与总结，本期刊登他的起因篇。原文如下：上周五，项目P的验收因为一个我们看来小小的bug被业主C部门用户在初验会上拒绝了。

2008-12-17 23:01:00 960

原创《给初入管理的IT技术人员建议，不要将默契式管理和人性化管理划等号》一文的更正

同事C在阅读了博文《给初入管理的IT技术人员建议，不要将默契式管理和人性化管理划等号。》后，已经清楚地对号入座，知道我将他的工作内容记录为案例三，给我特别发来了他的评论如下：我认为您是在项目的大概了解的情况下做出如此的评论，对其他同事有失公正性，不够客观。我认为有必要告诉您事情的真相，毕竟每次您看到我们的那一面只是恰巧看到。呵呵，没有错，我的抽查和物理学中的测不准原理是不同的，但是可能确

2008-12-17 22:03:00 614

原创给初入管理的IT技术人员建议，不要将默契式管理和人性化管理划等号。

学而优则仕在中国还是一个挺普遍的现象，给批判得也很多！但是原话是“仕而优则学，学而优则仕”，见于《论语·子张》，其真正含义并不是我们片面理解的“学习优秀的就去做官”。同样，“仕而优则学”难道是告诉管理者：“做好了官，有余力则学习！”如果你认定等我有余力才学习吗？呵呵，那你永远也没有有余力的一天。在IT行业，不少管理者都是技术出身，从论语这句话，我们应该学习到：当走上管理岗位，更加要“边干边学”

2008-12-14 12:10:00 990 2

原创公司的一个“新记录”：项目初验不成功

场景：自公司成立以来，以往由业主方召开的项目初验会议，都未发生过项目初验上出现问题。我一直认为，中国人的从众心理一般都挺严重的，加上我们对项目质量的认识以及对项目管理的重视，就没有碰过一回结论为：初验不通过的初验会。这次，这样的事情都给我赶上了，刚听到部门经理Z讲的时候，我都觉得有点不可思议！你能理解吗？因为会议之前，同事Z告诉我他得参加项目S初验会，我还非常坚定地告诉他没有什么必要，既然

2008-12-10 22:30:00 963 3

原创 IT世界里，所有的发明都是用来被推翻的！java也好，.NET也罢，都无法逃脱这样的宿命

前几日安排了一位java方向的项目经理X参与一下公司级项目管理平台的构想测试，初步的思路是采用Microsoft Team Foundation Server（以下简称TFS）做为后台的项目管理平台，将各个技术方向上的项目纳入全过程的管理，并且有利于梳理每年近百个开发项目的资料、文档、代码、报告等资源资料。由于该项目经理以往未接触过TFS，因此安排了一个熟悉TFS的同事C给X进行了接近一个小时

2008-12-10 21:24:00 753 1

原创不管你所属的企业属于那个线条的上游、中游，还是下游，记着你们在同一条河上！

最近进入冬天的广州，天气非常舒服，如果广州的天气天天这样，绝对是适宜人居的强有力竞争者。中午的时分，和同事一起走在去饭堂的路上，也是沟通交流的好机会。场景一：某天和某项目组的同事W在午餐路上谈论起他从事的项目H，W介绍说他的项目存在难题，说起项目有多方合作，有业主方，还要需求方的公司A。目前业主方正在使用着A公司以前编写的应用系统R，本期让我们负责建设新的应用系统R来取代旧系统，业主方认为

2008-12-07 22:33:00 1156 1

原创案例：需求你先做吧，我去和客户确认！

场景：同事cdw大半年在业主方现场工作，负责开发的工作，在此之前和他有两次在现场一起进行性能优化的合作，难得在公司见到了他，和他聊了最近的工作情况。cdw和我介绍了他最近的工作情况，其中也提到本周内他已经开始带3个同事进行开发工作，和以前相比，除了自己开发工作外，已经需要进行一些管理的工作，并形象地比喻，说他自己目前需要从单核CPU改进成多核的。在聊的过程中，他询问了本周管理工作中发生的一

2008-11-23 21:43:00 877

空空如也

空空如也