![第二期
Apr.2012
[ 季刊 ]
专业源于实践
PMBar
中国IT项目管理第一实践社区
实践 - 健康 - 创新 - 家园
www.pmbar.net](https://image.slidesharecdn.com/pmbar2012-120412003442-phpapp02/85/pmbar2012-1-320.jpg)
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to 《PMBAR》二期2012
Similar to 《PMBAR》二期2012 (20)
Recently uploaded
Recently uploaded (14)
《PMBAR》二期2012
- 1. 第二期 Apr.2012 [ 季刊 ] 专业源于实践 PMBar 中国IT项目管理第一实践社区 实践 - 健康 - 创新 - 家园 www.pmbar.net
- 2. 卷首语 群思荟萃 有一种胜利叫撤退 微观点 项目案例 项目管理中遇到的最大的挑战是什么? 重大需求变更该谁审批？ 项目收尾中的需求管理 题外话：如何准备应聘企业信息主管? PM 成长 我的PMO十年 我的PM成长之路 管理体系 如何用Enterprise_Architect进行 需求管理和追踪变更 PMBar动态 PMBar牵手ITIL先锋论坛 PMBar出版物《项目管理那些事儿》 PMBar PM 人物 专业源于实 践 轻松一刻 中国IT项目 管理第一实 践社区
- 3. 很多人，特别是女人，都不难有这样的时候： 本来要去超市买盒牛奶的，结果溜达一圈出来，手上绝对是不止一件。 去宜家的更甚，报道说没有低于三件出来的，即使最初的想法只是：进去逛逛。 逛衣服店、商场，更是不在话下了。 那么不爱逛的男生们又会好到哪里去吗？ Maybe, but not. 许好原本只想三十岁开个A4的，结果买A4的钱还未攒够忽地想要A8；房子90方也嫌小…… 关注焦点不同而已，终离不开人善变的本性。 买东西尚且如此，做事情，尤其是做系统的事情，牵一发而动全身的软件开发，需求更是举足轻重。 “需求，”这是一个让人蠢蠢欲动的词，一个让商家绞尽脑汁的词，对于PM们，这个词用“敬畏三尺”、“既爱且恨”毫不为过。 搞清楚这个词都难，何谈管理，管也不住，拉扯周旋，还有他法吗？ 书上教的，要签好合同，要明确边界，要访谈、调研、建模、原型，要深入现场，要深度挖掘，要透悉未来，我们都做了，但客户 都是人，人是多变的，最不讲道理的，何况他还作甲方，他又不自己干活，他只消一动口，你便…… 而，这也是很有趣的。因为围绕需求，便会有很多故事每天上演：你方不断提要求，我方不断求良方。 换个角度想想，则别有洞天。 你方不断有需求，我才不断有市场。有需求，说明产品有升级换代的空间，有更新的机会。 没有需求，我们要诱导需求产生，给一点，留一点，再给一点……留些想像空间，再多一点机会——捉迷藏的游戏。 需求有层次，客户的面向对象分层考虑，是基本设计原则。 哪些人来做？需求工程师？不上规模的团队，难有。Husthxd一抛 出2012年研发管理新思路，让测试的人做需求，立马评论激增；小布 ，在面对客户不讲道理的新增需求时，很有勇气地Say No；对不肯负责任，不讲道理，胡搅蛮缠的客户，糖衣炮弹加威逼利诱，统 一战线又适度坚持原则，周旋拿捏；让客户多参考，把他们拉进来，透明化过程管理，让数据来说话；规范化、确认签名，增加责 任感……招式各一，视客户的层次，大打八卦太极，无不是为了实现项目管理的三角平衡。 平衡，是一门考人的学问，在需求的领域里，尤是。 欲知更多，且看后续章节分解…… PMBar - 需求 3
- 4. We are PMBar team 致谢！ 我十分惭愧，愧自己的疏于沟通、放任进度；愧于自己才学疏浅，还不知道推托，勇敢来篇开场白； 十分欣喜，有那么多热心人，恺墨大哥、老张、马总、记忆、老谷、Richard…… 推荐专家：吴浩刚，徐锋，在接到电话后，响应迅速，还有新加入的Frank，雅静，艳春…… 都是十分给力的好伙伴。 编辑团队在这一期起，试行分组稿、编辑、美编组，欢迎更多伙伴加入， 以你我的热爱，将PMBar E刊进行到底。 PMBar，有你有我！ 镜子 Apr.2012 PMBar - 需求 4
- 5. PMBar IT项目管理公益实践社区 网站：www.pmbar.net 微博：@pmbar PMBar IT项目管理公益实践社区www.pmbar.net，由一群专注于项目管理、研发管理、IT服务管理、团队管理等IT管理领域的业内专家自发 组成，目前已有全国各地千余名IT领域的项目经理、项目总监、CTO及CEO。PMBAR定期的开展线上线下交流，线上"项目管理MSN群"每周二 中午13:00-14:00进行项目管理专题讨论，并在新浪微博 @pmbar 同步，目前已经进行近110期。 PMBar社区使命： 使项目管理在IT领域普遍成功，建立适合中国特色的IT项目经理选拔与培养方法论。 PMBar社区愿景： 打造国际国内公认的首屈一指的学习型IT项目管实践公益社区，为IT人提供全方位的创新性项目 管理服务。 PMBar社区宗旨： 营造一分享、交流、互动的IT文化平台，学习研究和普及项目管理相关体系知识，分享项目管理 成功经验，启迪项目管理中种种困窘的解决之道，推动项目管理的创新。 PMBar社区口号： 让IT项目管理在中国普遍成功 PMBar 社 训： 实践，健康，创新，家园
- 6. 发EMAIL提交个人认证信息，加入PMBar社区官方QQ群 为了方便PMBar社区成员之间的深入交流，同时作为MSN群的备份，PMBar启动官方QQ群：190375042（本群是封闭群， email提交详细信息后审批，谢谢理解）。 EMAIL主题：ID-职称-地区（微薄ID，如有），申请加入PMBar QQ群。 邮件内容格式： 热 点 请申请加入PMBar官方QQ群的朋友将个人基本简历、专长和期望交流或资源对接的方向等请发邮件至pmbar@pmbar.net。 1、工作经历： 2012年1月至今 在某某公司 担任项目经理。主要负责。。。 2、专长 在 行业做了4年多的项目管理 3、期望交流 对项目管理方面、政府/企业信息化建设等相关内容比较熟悉 本群只进行专业交流，不推荐灌水。谢谢！ PMBar IT项目管理公益社区 2012年1月
- 7. 群英荟萃 有一种胜利叫撤退 微观点 Micro-Points
- 8. 项目场景 1.这是一家大型的创新型业务公司，市场销售尽管在初期探索阶段，销售部门认为急迫需要 开发一套销售管理系统，通过IT的方式将业务销售管理起来,否则在信息化管理的今天跟不上 时代潮流; 2.这个基本功能包括销售渠道管理、经纪人管理，薪金管理，佣金管理。由于销售模式的不 断变化，使得该项目的需求变化显得特别突出。 群英 项目问题 1、该系统一期按照计划本来已经结项，但开发依然遥遥无期， 荟萃 2、项目延期、乙方大多开发人员撤离。 3、甲方依然不断的新需求提出、此时甲方业务人员提出开发该系统二期的功能 新接任的项目经理小Z原来认为只需解决一些开发计划的协调跟踪即可解决问题，随着项目 了解的深入，发现远没有那么简单。。。 有一种胜利叫撤退 马兆林 2012/3/26 PMBar - 需求 8
- 9. 经过一段时间的了解，小Z发现: 1、甲方业务人员与业务模式都在发生变化 销售模式在尝试，由于新兴业务拓展不顺利,销售基本法在时刻变化调整,渠道人员管理模式都 处在不稳定的状态中,同时,由于业绩的压力,使得该系统的需求人员和系统使用人员在流动，往 往使需求提出人员和验收时不同的人,对销售基本法有不同的认识和执行,甚至主管销售的总经 理也在变化. 2、原来甲方项目经理非常不负责 需求整理、审定、开发计划基本全部依赖乙方团队，甚至一些不合理的小概率事件的功能需求 没有进行时审查（如：“培训人员”的管理功能），使得乙方开发人员觉得没有合理需求，就 不向下开发，而甲方项目放任之，往往业务人员认为已经进入开发计划，但系统也迟迟没有交 付，造成该项目满意度相当差； 群英 3、乙方项目经理和开发团队撤离 由于该项目开发后迟迟没有验收，乙方大部分人员撤离，只保留一人进行需求整理和对接工作 这种情景使小Z陷入了两难的处境，一方面甲方需求人员非常不满意目前的进度，而乙方开发 荟萃 人员已经基本离场了，这个项目将时刻成为烂尾工程，渣子工程。 多年的项目管理历练使得小Z立刻提示自己要冷静下来，好好的进行一个分析: 1、站在立项的角度，这个项目的开发存在着相当的风险，业务部门为了系统而系统，没有成 熟固化的流程，业务发展模式和规章时刻在变，使得功能需求、开发付出的代价很大（无法 可依） 2、在实施过程的角度，由于前任项目经理的不负责，使得一些不合理需求纳入开发计划，使 得乙方开发成果往往效率很低，没有成就感，开发完毕没有及时验收，甲方项目管理的职责 有一种胜利叫撤退 存在了很大的缺失 马兆林 3、进行两种决策的趋势分析 2012/3/26 A、继续开发、需求在不断变化，无法控制风险，费用上会陷入无底洞，并不能解决满意度 B、中断开发，只有部分功能可以投入使用，需要做工作完成项目的验收和费用支付 PMBar - 需求 9
- 10. 决策标准，公司利益上控制风险，控制满意度的不断恶化 1、在一个时间内，需求是否清晰，并保持一定的稳定性 2、需求是都有“法”可依据，支持 3、能否看到阶段性的里程碑结果 所以没有迟疑，小Z只有选择：B 中断开发，停止项目 我们可以想象，做出决定容易，在任何一个甲方执行这一个结果还是很难的 小Z首先向IT部门领导作了汇报，取得了部门领导的支持，然后和业务部门需求主管进行了一次 群英 深入交流，共同分析了这个项目的现状和未来，这里有一个优势，他们是老乡。而且，销售部 门负责人刚离职，可以定向为后果的承担者。此时，这个需求主管也确实被这个系统搞的焦头 烂额，首尾不顾，看来只好这么处理。 乙方那边答应他们配合好一些功能验收后，可以结款项，前提是做好一些功能部署的扫尾工作 荟萃 ，当然，验收签字工作由甲方业务部门需求主管牵头完成。 这样经过一个多月的进度，完成了部分功能的上线工作，这些功能是一些可以目前固化有经常 使用的部分，而其他需求由于存在很大变数或者不合理，统统停掉了。 验收一个月后，乙方验收前收到了双方谈好的尾款。 在公司层面上，这个项目在内部继续进行需求讨论，为二期开发做准备，实际项目已经停止了。 案例解析 有一种胜利叫撤退 有一种失败叫占领,有一种胜利叫撤退 马兆林 如果没有把握赢得这场战争的时候，撤退也许是一种保全自我的很好的方式 2012/3/26 PMBar - 需求 10
- 11. 我们看到这个场景中: 小Z能够毅然的中断项目，既要冷静的判断力，还需要项目管理的实践历练，包括扫尾工作的沟 通能力，都是PM最佳实践的厚积薄发的体现。 这里面的最大难度在于说服甲方需求主管，这里小Z利用了“老乡”, “销售部门负责人离职” 等因素,四两拨千斤的化解了需求部门的坚持，我们会有人讲，这几个有利因素怎么都让小Z碰上 了，实际上在最佳实践中需要你去发掘，分析有用的细节和因子，求同存异，为我所用，这是故 事这个段落想表达的沟通技巧 。 最后讲讲这个案例中的“道、法、术”： 这个场景里的道，就是这个项目能否顺利进行的几个因素，我们看到小Z分析的过程；道路不通， 项目失败。 这个场景项目里的法：就是销售基本法，通常我们讲的需求流程，业务规则。由于市场销售模式 变化，使得销售基本法也在变，实际这个项目是无法可依，失败亦然 术：由于在本场景中，乙方的开发技术不是问题的重点，关注最少。 我们看到，通过道、法这两个方面的分析，是这个项目失败的核心问题。 群英 后续故事： 三年后该公司又启动了该系统的开发（传说中的该项目二期，不过是个新的系统和开发商）， 荟萃 小Z已经是IT部门主管级别的干部了，这时的甲方项目经理小H是个富有激情和责任感的青年人。 经过三年的发展，该公司的销售模式有了基本的固化，但也只限于少数渠道，增加了很多分公 司等的层级销售人员管理。 进入这个项目后，小H的脑海里经常浮现的几个词组就是“悲催”，“苦B”，经常有一些没干 过一线销售和管理的女孩过来和他讨论需求…… 小H发现经常对他们的需求说“可以开发”并不能带来他们的满意度和自己的成就感，因为按照 他们需求开发后，一些原来的规则破坏掉了，系统不流畅，好在公司有了相当的业务使得该系统 能够发挥一些价值…… 由于小H的态度和努力，他获得了公司年度最佳员工的奖励，相信他还在探索IT项目管理的最佳 有一种胜利叫撤退 实践之旅，和我们一样，在路上。 马兆林 祝福他吧，也祝福我们自己…… 2012/3/26 PMBar - 需求 11
- 12. Mars_Lee_Dw (鼎为通讯科技有限公司 客户项目中心 总监) 需求管理，不是拒绝或满足需求，而是如何把实实在在的优秀需求进行筛选开发，不浪费时间在 没有价值的需求上面，好刀能用在刀刃上，帮项目赚钱才是王道。 王晓明同学 （知名敏捷咨询专家，敏思特咨询首席合伙人王晓明） 什么是有价值的用户需求？ 符合以下6个条件才算： 1.本身是一个产品或服务； 2.有用户需要，并解决他们的问题； 3.有销售渠道并且价格公道； 4.用户对该产品、服务有购买意 向； 群英 5.有清晰的市场定位； 6.优于竞争对手的特点。 不是所有“需求”都make sense。开发人员应多质疑， 帮助产品和需求经理优化需求管理 高宇-胡言亂語 （二十一世纪空间技术股份公司 高级软件开发工程师） CMM只是关注需求活动的过程，而不是需求分析技术本身。要提高软件需求文档的质量，要最大 限度地减少用户需求分析活动中的遗漏、变更和误解，这样就必须不断积累需求分析的能力，提早 挖掘客户需求中的变化因素，努力成为客户领域内的专家。显然，这种积累不是一时半会可以做好的 荟萃 杰子 微观点 需求管理#做 项目最难把控的就是需求，BI项目更是如此。曾有人用“尿频,尿急,尿不净”来形容客户 Micro-Points 的需求，非常贴切。需求把控是关键，不能一味地听从客户，要提出 改进建议，帮助客户把不成熟的 想法成熟起来，而成熟需要时间的，这样就能在一定程度上不那么“尿急”！如果做得好，还能“尿 得更干净”! PMBar - 需求 12
- 13. 冯国馨PMBar（联合永道副总兼CTO pmbar项目研发管理公益社区创始人） 对于项目型企业，需求变更是一个系统的生态链。没有无缘无故的变化！ 要强调的是一定要从经营角度看变更，是客户内部矛盾演化的变更，是没 有经过有效咨询疏 导而在操作中渐进明晰演化的变更，是突发事件如政治 任务引起的，还是技术难关引起的变更等等等等。找到原因后，办法总比 困难多。 mibystander 《浅谈需求变更及其对策》 诚如IBM的广告——我们提供的是随需应变的解决方案，如果我们意识到IT服务的本质就是应对 群英 变化，其工作的核心内容不是生产而是设计，那么我们就最终理解了诸如持续改进的意义所在了。 网龙网络有限公司副总裁 唐兆希 需求没有规则只有变化，市场没有问题只有机会 用户是没有责任，也没有资格提供需求，用户只有自己的痛点或者涉众利益。 需求是开发方的来 根据涉众利益排座整理出来的。如果需求直接来之于用户，很可能需求就是假的，更糟糕的是， 后面的需求变更才是噩梦的开始 一开始不理解，现在逐步理解一点了 荟萃 Alex_wang__ 微观点 Micro-Points 需求变更的根源来自哪里？ 这和需求的级别有关 第一稳定的需求级别是用例，基本很少变化 第二 稳定的需求级别是路径 第三稳定的需求级别是步骤 第四稳定的需求级别是补充约束。 补充约束的 变更往往容易较多。 所以，解决需求变更的问题，实际上就是检查上述4个有没有遗漏的。 PMBar - 需求 13
- 14. 项目管理中遇到的最大的挑战是什么? 重大需求变更该谁审批？ 项目收尾中的需求管理 题外话：如何准备应聘企业信息主管? 需求管理，需求开发，计划赶不上变化？ 系统做好了客户不肯签验收报告？ 项目进度一拖再延不受控制？ 很大部分原因是 不确定的需求，善变的需求，无边界的需求…… 你遇到的最大难题在哪？ 管理，控制，变更，谁说了算？ 合同需求界定不明，客户胡搅蛮缠如何应对？ 最真实的现场，观点，为你奉献
- 15. 项目管理中遇到的最大的挑战是什么 这是一次非正式讲座，由Frank同学提出问题，大家一起讨论而成 Frank-项目主管-上海 says (11:58): 活跃人物 Frank-项目主管-上海、超-技术负责-深圳、seplves1-PM-北京、Heard-IT Consultant-singapore fan-sr.e-sz、max-打杂-sh、东倒西歪-供应链-BJ、mazd-Melody-PM-上海、Richard李明-项目主管 需求多变，协调困难，边界界定？ Ivy-pm/QA-shanghai、Michael-PM-厦门、龙小宝-pm-bj、Frank-项目主管-上海 以各位的经验，项目管理中遇到的最大的挑战是什么？ 超-技术负责-深圳 says (11:59): 人的因素吧！和人有关的一切。边界就和业务有关，但最终是人。 公司对这个职位的定位和主要负责的工作。 seplves1-PM-北京 says (11:57): 项目团队人力资源管理、项目沟通，项目整体的把握。 我觉得也可以说是资源，包括人力资源。看做的事和所支配的资源，剩下的就是效率。 Heard - IT Consultant - singapore says (11:58): team！我前一个team遇到的最大问题是沟通..... 人分布在三个国家。 fan-sr.e-sz says (12:00): 我觉得最难是需要完成的任务，超过了项目经理的权力范围。 如果组织本身是在震荡阶段，这里的项目经理应该是最惨的吧。 max-打杂-sh says (12:01): 东倒西歪-供应链-BJ says (12:02): 最大的挑战是项目经理自己，哈哈。 我觉得最大的挑战就是项目经理没事干 mazd-Melody-PM-上海 says (12:05): 不同的组织结构，项目经理的职责范围不一样，挑战也不一样。要看这个项目经理的level。 Richard李明-项目主管-北京 says (12:30): Ivy-pm/QA-shanghai says (13:00): 最大的挑战是对习惯的挑战。 在对外项目中，客户关系也是一块吧 Michael-PM-厦门 says (13:11): 我觉得最难的是风险管理，风险即不确定， 不确定意味着被动，无从下手。 龙小宝-pm-bj says (13:14): 风险我觉得好难操作 按照PMBOK说的，最重要的是计划、计划、计划 Frank-项目主管-上海 says (12:58): 继续刚才的问题，有几位同学的观点，我总结了一下：项目管理最大的挑战在人，团队建设、沟通管理、资源协调，无不与人密切相关。 最大的责任：项目范围边界的界定，项目进度计划的控制。 PMBar - 需求 15
- 16. blue-pm-bj说： 重大需求变更该谁审批? 活跃人物 blue-pm-bj、Hawk-PM-苏州、pinky-pm-gz 邓超-开发-上海、超-技术负责-深圳、Frank-项目主管-上海 Hawk-PM-苏州说: 重大需求变更该谁审批应该由CCB或发起人，项目管理办公室或发起人，来负责。需求变更属于范围变更的部分，有时需要发起人来同意。一般情 况下，发起人会是CCB的一份子。 我们公司也没有CCB，不过，涉及范围的变更肯定要发起人签署。我个人观点：项目经理未必是CCB成员之一，发起人肯定会是CCB成员之一。 项目经理通常是CCB成员之一，发起人未必是CCB成员之一。 PMBar点评 变更很可能是某个具体工程师提出来，而具体工程师通常不是CCB成员。 blue-pm-bj说: 我们公司没有CCB。 pinky-pm-gz说: 我们的CCB都是例行工作，或者只是参与，没有决定权的。PMO是不是也监管CCB？我以前的公司有CCB部门，他们是例行的文档管理部门，记录 变更的是配置管理部门。他们没有决定权，都是发起人来确定是否变更。基本是高层说了算，但是没有说一定指定哪些人。 邓超-开发-上海说: CCB不是部门，是每个项目定义的，在项目立项的时候根据变更的可能影响范围定义的组织。CCB的职责就是估计项目变更的影响，所以是有审批 权的，一般重要的干系人都会在CCB里面。 那么，是不是每个项目都有一个CCB？而且是不同的人？答案是肯定的，是不同的人，但是技术专家可能是共享的，或者高层经理也是共享的。说 个简单的，项目延期针对项目计划变更，如果没有客户或者高层经理的审批，这个变更做了也是白做。提前定义CCB，相当于是一个立约，所有干 系人都同意，出现问题的时候这几个人有权力如何解决问题。 我所在的项目里面，配置管理员只是负责对变更产生的变更申请、纪要、对基线的改动做归档和记录，但并不负责审批 ，审批还是CCB来。应该也 要和项目经理探讨一下，变更管理还是要慎重，尤其是范围变更和需求变更。所以CCB的定义还是蛮重要的，项目经理肯定是CCB成员之一。 我们公司没有CCB组织。这个东西有时候包括配置管理这块，除非很大的项目才要，一般小的项目没有那么细化的。很可能都是身兼多职，更多情 况下是先做出来再说，但是就理论上来讲，这些东西都要学到或者知道的。毕竟规范细化好了，才可以更好的做事。 邓超的说明非常到位！ PMBar点评 PMBar - 需求 16
- 17. blue-pm-bj说： 重大需求变更该谁审批? 活跃人物 blue-pm-bj、Hawk-PM-苏州、pinky-pm-gz 邓超-开发-上海、超-技术负责-深圳、Frank-项目主管-上海 Hawk-PM-苏州说:超-技术负责-深圳说: 我觉得关键讨论的是前期工作中加入应对变更的部门或者人员，以便变更出现时，有确定好的流程去应对。 超-技术负责-深圳说: 我们不用去纠结CCB的组成人员是否包含发起人，但是项目的发起人属于高层。从干系人管理上看，应该要包含在内，即使不包含，有些东西也 是要得到高层的支持的。 邓超-开发-上海说: 发起人可以是、也可以不是CCB成员，但是变更的过程，他是肯定会参与的。就审批权限而言，发起人可以拥有这个权限CCB成员，当然也可能 只是描述问题和影响并没有决策权（非CCB成员）。理想情况下是所有干系人来参与对需求变更的审批，但是实际中只能是在利益比较大的几个 方面选出代表。这个就是CCB。 Fenny说: 我是在電子行業做PM，有CCB，每個禮拜都會發生。CCB既然是change control board，就應該有一個人在主導。其實就不是什么leader的說 法，而是誰來做主導，讓大家去執行。 【PMBar点评】全员参与决策是一种理想状态，这与企业管理文化和成熟度息息相关，通常可执行的方法是选出有专业背景、有决策能力背景的 各方代表加入到CCB中。 项目经理通常是CCB成员之一，发起人未必是CCB成员之一。 PMBar点评 变更很可能是某个具体工程师提出来，而具体工程师通常不是CCB成员。 PMBar - 需求 17
- 18. 项目收尾中的需求管理 月亮-pm-bj 说: 我们项目中一直存在一个问题，就是项目验收的问题，好多项目做完后，迟迟得不到验收，验收通过不了，项目拿不到钱，然后市场部反映说我们项目做的不行。 客户不肯签验收单，一是担心业务系统会有问题，二是反映系统操作复杂。针对项目验收问题，前期应该做哪些准备，怎么样避免客户的顾忌？ 我感觉，我们项目中缺少一个标准。 比如，我们项目中有添加的功能，但是客户试用期间说我们还需要修改，我们就得加上了。项目验收通过不了，主要针对技 术部门讨论一下，怎样协调各个部门的关系，还有与客户的关系? PMBar点评 项目合同是否明确界定了项目需求范围以及变更控制办法？这个对限定范围不无限放大起到很关键作用。 Richard李明-项目主管-北京 说: 第一次开发期间，客户参与到项目了么？ 月亮-pm-bj 说: 合同我只看过一眼，对于内容只提到提供哪些模块，变更的话只说了通过什么途径提交需求。 对于哪些需求做，哪些不做，我自己感觉没有人管。基本上提的 都做，就算不做也只是和对方说"暂时先不做"。 有点怕得罪客户的感觉。 PMBar点评 初步判断：一方面合同签订不严谨，另一方面可能销售与客户的承诺放大有关。 seplves1-PM-北京 说: 项目实施过程中有没有文档控制啊？ Richard李明-项目主管-北京 说: 分析具体问题，才能找出具体解决办法。一方面，变更控制不好。另一方面，感觉客户不了解项目的进度安排，平常的进展也不了解，沟通出了 问题。另外，建议采取分段验收，即完成一点就让客户验收一点。 月亮-pm-bj 说: 因为是业务系统，所以必须得做完了后，给客户看整体的。 但是到后来客户会一直加需求。 itpub id 中惠李-打杂-dg 说: 可以延伸看来，是需求膨胀问题。 1、在需求调研时，没有跟客户做好确认 2、客户的需求需要加以控制 mazd-Melody-PM-上海 说: 需求没做好，客户最终看到的跟他的期望值差距太大。商务没做好，跟客户达不成共识。 做MIS系统，首先就得允许客户变，这是个前提。 PMBar点评 主动迎接需求变更是非常必要的，不能拒绝，但要在前期以及合同中合理引导需求变更处理的规矩，包括变更 控制流程、费用增加流程等等。 PMBar - 需求 18
- 19. 项目收尾中的需求管理 IT01-打杂-东北区 说: 分阶段的话就怕客户的思想老变。 河边草herbacon-pm-深圳 说: 前期规划沟通的问题。 hitbird开启尘封的记忆-无聊中-北京 说: 一个是，变更控制没做好；另外一个，项目验收估计没有确定好，是不是合同里规定的优点不够准确？ 不胜人生一场醉-打杂-海口说: 一般情况下系统验收规划的是1个月，实际上可能3~6个月，预留好时间。和客户说做个系统预验收，然后建一个跟踪现存问题、扩展问题、完善性问题之类的 让客户在上面提，不要一个个的口头或发邮件。 月亮-pm-bj 说: 我们这次又新接到一个项目，我怕到时候又像其他的项目一样。。做完了，一直在让他们试用。。需求有时候直接跟我们开发部门说。我们这也有技术支持部。 也有市场部。。是人才派遣系统。。我们这次是先画了原型，然后写了详细的需求，拿着这个需求跟客户对。。。 商务收不回来钱，就说我们做的系统不行。这 样老板找我们，客户找我们，然后商务还有理由找我们。 上次调研需求，他们公司内部有个活动，然后耽误了1周，我们说时间紧张，是不是延期一下。。他们提前都没说过。。 IT01-打杂-东北区 说: 没用。遇到强势的用户，想到哪做到哪。 客户只能引导，不能说服。 PMBar点评 客户再强势也是需要完成项目，乙方最低限时放弃项目，这个他们也很害怕的。关键是要在前期培养客户接受双方 约定的应对变更的方法和流程的意识，余下需要销售做好客户关系运营。 mazd-Melody-PM-上海 说: 没有明显需求框架，纯粹是按照客户感觉走，客户又多头管理，你们搞不定客户，肯定验收不了的。 itpub id 中惠李-打杂-dg 说: 需要跟客户确认你们的蓝图设计。 不胜人生一场醉-打杂-海口说: 一般情况下 客户也有上线时间要求和上线压力。 上不了线，他也会着急。你的问题是说服他和你站一条线， 年底不上线他没绩效，控制进度、需求也是他的责 任。 作为pm应该把这些不利于自己的证据保留下来，以便以后的谈判。 客户内部原因，设备原因，网络原因，都可以作为有效的理由。 感觉，商务渗透不够， 商务对技术配合支持不足。 PMBar - 需求 19
- 20. 项目收尾中的需求管理 seplves1-PM-北京 说: 项目干系人一般不止一个，客户之间也不是铁板一块，逐步突破。 mazd-Melody-PM-上海 说: 一开始做的一切就是为了验收，前面按阶段都完成了，验收自然就顺利， 不能只是为了验收而验收。 做事是底下人在做，签验收是头在验收。。头不看系统， 就问底下人，系统行不行。。 底下人都不敢保证行，都说现在没问题，不保证以后没问题，然后他们领导就不签验收。 客户需求多，大部门是因为他们自己也不知道想要的是什么东西。先让客户内部形成需求团队，指定接口人收集需求，然后你们接收需求，需求筛选，合理的 接受，不合理的说明原因，最终形成文档。同时，配合你们的原型系统对客户进行引导。 还有，关键要跟客户方能有拍板能力的人搞好关系，让他跟你们站在 一边。 Richard李明-项目主管-北京 说: 看来你那边是问题挺多， 控制需求不但是你，还应让商务的也来做。 客户的预算也可能有限，先把需求分优先级，次要的等二期。需求把握控制好范围，保 持在一定的限度内变动。 每次的变更你要记下来，分析一下对现在项目进度的影响，告知用户。 这样，他们再变的时候就会进行变更，那么进度方面会不会 受到很到影响， 他们必须要知道带来的后果。 做好的东西及时让用户了解，争取做好一个让用户接受一个，等到最后验收那就很容易了。 毕竟他肯定过的东东，到最后他不会否定他自己把情况及时通报。 记得变更要写成文档，然后就是变更要不要执行的问题了。 pw-PM-CD 说: 不了解具体情况，但如果让客户早一些加入到项目的开发过程中，早一些提出改进意见，或许可以减少后期变化的可能性。你们有原型设计，这个是个好的机 会让用户提出意见。 蔡晓东-技术主管-it-福州 说: 电话说过的事情，我们一般的做法，是随后再发一封邮件。 PMBar - 需求 20
- 21. Frank-项目主管-上海 says (13:13): 最近考虑应聘一家企业信息主管职位，要与公司主管副总面谈。我考虑以下几个方面谈我的理解，请大家帮提提建议： 一、公司信息科技部的合理组织架构是什么； 二、信息化建设面临的挑战和问题,以及对策； 三、信息化战略和公司发展战略如何保持一致； 四、举例项目管理中的经验和体会 Frank-项目主管-上海 says (13:26): 我个人的理解如下： 信息技术管理委员会，总裁或分管副总裁是主管。首先要考虑的是信息科技部在一个公司作用和地位，职责范围。考虑行业 特点，例如金融行业对信息化建设依赖程度高。 具体来说信息科技部职责范围如下： 1、负责公司信息系统的规划及技术创新 2、负责信息系统管理规章的制订 3、负责信息系统的开发、运行及管理 4、负责公司IT应用设备管理与维护 5、负责各营业部电脑人员的管理 6、负责信息技术团队建设 说到底，是需要了解和把握行业现状和面临的实际问题。 一是技术规划与公司业务战略拟合度不高，导致规划实施的可行性较差； 二是信息系统运行维护管理体系不健全，相关的信息技术制度未得到有效落实，缺乏制度落实的保障和检查机制； 三、是IT人员任务重，压力大，待遇低，公司领导层不够重视的问题，导致IT人员缺乏创新积极性。人才培养和引进方面存在短板。 四、信息技术人员缺乏交流和学习，一定程度上影响了信息系统的建设和管理。 我是从甲方信息技术的角度来看问题的，先提出问题，然后分析问题，提出解决办法。 Michael-PM-厦门 says (13:42): 我觉得frank说的挺好。 第一点可以请咨询公司来做。 第二点同上。 第三，第四是内部管理问题，应该建立合适的激励制度，激励人员去做相应的事情。归根结底就是一个字，钱，嘿嘿。 题外话：如何准备应聘企业信息主管?
- 22. Frank-项目主管-上海 says (13:13): 呵呵，其实我觉得，如果我作为高管，我只是想听对方的想法和看法，解决办法也大多数归为想法里面。作为传统的 国营金融机构，是不会允许有多大变动。 通过交流，来确认你对这个行业的认知程度和理解程度，以及对这个职位的胜任程度。 上面的4个问题，引出一个时下流行的概念--IT治理。 IT治理不同于IT管理，治理是规则、制度、机制、责权利的确定，管理是制度的执行。 超-技术负责-深圳 says (13:50): 因为 既然是积极 去准备的话，任何风险都要考虑在内吧，也算是风险应对~~~。审计是其中重要一环。 龙小宝-pm-bj says (13:55): 其实IT治理也简单，跟反贪局一样，或者审计局一样，就是审计一下规则、制度的执行情况而已。反正很难搞，因为 “权”的问题。我们的IT治理最终成为了政治工具，无疾而终…… Frank-项目主管-上海说: IT治理不同于IT管理，治理是规则、制度、机制、责权利的确定，管理是制度的执行。个人认为，治理针对于问题，现状和改善；而管理 则更强调的是职责、制度、规范。治理是针对管理现状的改善活动。IT治理到底能够为企业带来什么益处，其目标何在？ Frank-项目主管-上海 says (13:57): 1、引导IT战略，保证IT战略目标与公司战略目标一致 2、建立公司标准的信息基础架构，进一步提高IT建设的规范性、科学性和有效性，有力支持业务增长。 3、对公司核心IT资源做出合理的制度安排。 4、指导和控制公司的IT投资、机遇、收益及风险。 5、公司的IT建设风险透明化。 其实说白了，IT治理之所以要用，主要原因还是老板不懂IT，外行管内行，针对IT和业务部门纠缠不清，IT不透明，引导出来的概念。 控制成本也是治理中一个重要环节。 题外话：如何准备应聘企业信息主管?
- 23. Michael-PM-厦门 says (13:59): 一是技术规划与公司业务战略拟合度不高，导致规划实施的可行性较差； 分析公司业务战略，请IT专家按不同的发展阶段总结出对应的IT需求，包括设备、人员、应用系统等，在此过程中，应 注意结合IT技术、产品发展的走向，以及人员的培养。 二是信息系统运行维护管理体系不健全，相关的信息技术制度未得到有效落实，缺乏制度落实的保障和检查机制；信 息系统运维管理，应该紧密围绕业务需求展开，因为IT为业务运营服务和？做支撑，制度的落实和检查重点在于人的管 理，对于人的管理最重要的是恰当的激励和准确的绩效考核。 三、是IT人员任务重，压力大，待遇低，公司领导层不够重视的问题，导致IT人员缺乏创新积极性。人才培养和引进方 面存在短板。要在IT组织内部进行明确的分工，各小组之前必须做到协同工作，要在内部创立合作、互助、友善的氛围。 四、信息技术人员缺乏交流和学习，一定程度上影响了信息系统的建设和管理，把交流和学习纳入到绩效。 龙小宝- pm-bj says (13:57): 我以前听过老师讲的治理的PPT，他是从成本来讲的。IT治理的目标是降低企业管理费用。 企业管理费用分两部分：一部分是日常管理的正常费用，另外一部分是各部门/人员间因为利益冲突而摩擦造成的费用。 然后那个老师说，IT治理说跟检查汽车的各个环节一样，让各个渠道畅通，上点润滑油，减少管理费用。实际情况是未必减少费用。多了个 部门，多了扯皮的环节。嗯，其实治理部门后来都发展成虚职的那种，只有1~2个人是实职。 再后来，就沦为了政治斗争的工具。 IT治理，因为是揭短的工作，很容易纠缠进办公室政治里边。 我有一个经历（以前的公司），老板要做绩效考核，然后最开始做什么职位梳理、岗位定义一类的。做工程师类的岗位定义的时候挺好，到 管理岗位定义的时候，问题开始多了。后来要按照岗位定义来执行的时候，中层的管理不干了，哈哈哈，问题是：职责太明确了，不好扯皮 。过了一阵子绩效考核就不了了之了。 Frank-项目主管-上海 says (13:57): IT治理--重点在人。这也是概念提出好多年了，很多公司并没有设置这个IT治理部门的关键。尽可能简化考核模型。 题外话：如何准备应聘企业信息主管?
- 24. P M 成长 我 们一直 在关注... 我的PMO十年 我的PM成长之路
- 25. chuner_wang-PMO-北京说: 1）协助项目经理监控项目进度； 我今天的交流主题是，我的《PMO十年》，我2001年12月加入 2）向上和向外汇报项目进度； 同方，一直在PMO里担任不同的角色，从项目协调员，到进度 3）作为与用户方、咨询方或监理方的沟通接口，协调项目内外关系， 管理工程师， 再到项目管理工程师，最后到PMO主管。对PMO 处理信息的收集和反馈 。 ，我有我的热爱，也有我的期待…… 4）配置管理（CC）。 今天，本着我个人的经历，今天主要跟大家交流下我的PMO发 5）协助处理项目日常事务，如组织例会、来往公函的起草和收发、 展历程，其中有收获，也有困惑，与大 家分享。 项目费用记录、组织项目 建设活动等。 有一个一直一来的疑问：PMO是助理机构，还是管理机构？它 职责上看，以协助项目经理为主。 与EPG和QA有什么区别？ 我也一样，在不断的“惑”与“解惑”中，做过了是助理机构的 我的PMO十年 chuner_wang-PMO-北京说: PMO；也做过了是管理机构的 PMO；也做过了做过程改进的 此时，PMO共4人，PMO主任下设一名进度管理工程师、配置管理 PMO…… 其实，我更期待，PMO的下个时代，可以是决策机构... 工程师和项目助理各一名。除主任外，对其它人员项目管理系统知识 下边我就重点跟大家交流下我的PMO的前两个阶段：助理机构和 的要求不高 。 管理机构。 这期间，从管理角度最大的收获，或说项目管理比较有效的方法是： 1）项目进度日跟踪、进度上墙（一大幅RPOJECT的进度计划表，相 从助理机构到管理机构的转变 当于20多个A4那么大）营 造一种透明、相互赶超的氛围和压力。尤 其在项目的关键阶段，很有效。 chuner_wang-PMO-北京说: 2）PMO作为内外沟通的唯一接口，确保了信息的完整性、及时性和 首先说，我的PMO实现 从助理机构到管理机构的转变，我们用了3 可追溯性 。不通过PMO的所有项目信息，都视为无效，这个条款， 年多的时间。成功转变也缘于PMO成立后承建的第一个项目，它引 与众不同的被写在了SOW里，双方签署！尤其这个可追溯性（全有 入IBM作为甲方的管理咨询方。IBM负责协助、 指导甲乙方项目监 记录），到了后期产生合同纠纷时，立下了汗马功劳。 控和管理工作。与他们的合作中，我们学习和吸收了大量IBM优秀 3）签署清晰的SOW，用1个礼拜，双方封闭编写。详细约束各方职 的项目管理思想，为以后的成功转型打下了良好的基础。 责、活动和产物。这个也很有效，避免双方扯皮，也带动了客户的主 在PMO作为项目“助理型”机构时，我们以单个项目为主线，一对 动性 一跟踪、服务。重点在进度 监控和汇报上。那时候，我们事业部同 4）用ClearCase做配置管理工具，这个大家都基本清楚，其好处就 时在建的项目少，尤其初期，基本上一两年就承建一个项目 项目规 不用多说了，用过这么多配置工具，CC还是最强大。 模：周期2年 ，合同金额8千万，项目成员100左右。所以，PMO的 全体都按不同分工，扑在一个项目上。 我的PMO十年 邓超-开发-上海说: 对不起 我有个疑问： pmo里面会有客户方的人员吗？ Richard李明-PMO项目主管-北京说: 还没有太多的资源竞争吧？ 我的PMO十年 chuner_wang-PMO-北京说: 没有。 chuner_wang-PMO-北京说: 没错，所以那时候，进度监控是重点！ Richard李明-PMO-BJ说： 助理型PMO的主要职责是： SOW:Statement Of Work工作说明书 PMBar - 需求 25
- 26. chuner_wang-PMO-北京说: 工作，比如实时了解公司每个人的工作情况，包括状态、饱和度、 这是PMO作为助理机构的总结…… 胜任能力…… 在这里，没有人事上的绩效考核，是依据一些产出数据及经验评估。 邓超-开发-上海说: 此时，PMO共5人，PMO主任下设项目管理工程师2人、进度管理员 好的 谢谢 我是看到“不通过PMO的所有项目信息，都视为无效，这个 、配置管理员。原则是，分工 不分家、互为备份、各有侧重。 条款，与众不同的被写在了SOW里，双方签署！” 这个觉得有这个疑 对人员的要求比较高，其中三人，都经过专业的项目管理培训……比 问的。 如：PMP 。 chuner_wang-PMO-北京说: 这期间，从管理角度最大的收获，或者觉得比较有效的项目管理方 随后，事业部同时在建的项目越来越多，项目流程的规范、项目间的资 我的PMO十年 法是： 源共享、项目间横向比 较、决策等需求变得越来越突出，这也就要求 1）任何方法和机构设置，没有最好，只有最适用。比如，在开发阶 PMO组织对项目管理的职责要更丰富。 段，且计划变化较频繁时，优秀的360和平衡计分 法等考核办法，竟 传统来说，PMO更关注人力资源的冲突和共享……其实，真正对企业有 然比不上看上去有些老“土”的表彰与惩罚制度更有效……说白了就 价值的，是如何共享各项目的软件资源，继而抽取出来，复用。这个， 是贴小红旗。这在很大程度上刺激了项目成员的荣誉感和自尊心，任 在PMO成为管理机构后，也成了研究的重心 务执行力得到了很大改善 ，值得一提的是，小红旗可以贴在PMO， 于是，我们积累之前项目管理的经验和教训，结合IBM和同方专家顾问 也可以贴在项目的“作战室”，呵呵…… 组的优秀的管理思想， 开始编制项目管理体系，制定项目绩效考核制度 2）客观的执行数据，是监控和决策项目最重要的依据。无论多大的 ，由“服务”开始转向“管理”。 项目，最基本的数据必须 注意在过程中收集，如工作量、进度……。 只有这样，才能清楚偏差，才可以预测。 管理型的PMO 3）主动汇报，向领导，向客户，尤其是向客户……。我们有个项目， 每周与客户开例会，一 月一小报，一季度一大报，不管客户要求不 chuner_wang-PMO-北京说: 要求。事实证明，这样做的好处是，成果共享，压力均摊。客户配合 管理型的PMO，主要的职责包括： 力度明显高于汇报少的项目。 1）制定并持续改进项目管理体系，规范项目管理流程。这个与现在很 4）沟通时，能见面，就不要打电话，能打电话就不要发邮件。最终， 多人在做的CMMI也没什么大的差别，只是那时候，我们没有引进什么 不管什么形式，必须落 实到字面上。往往你会发现，某一个看了的人 标准和模型，全靠经验。但实践证明，与CMMI什么的，没有多大出入。 ，会给你反馈非常重要的信息。1+1绝对大于2。 2）收集项目执行数据并分析，考核项目。需要一提的是，除了以产出 5）要求项目经理做什么，不如先让项目经理知道，你能为他提供什 为导向的考核办法外在一段时间，我们还使用了以具体任务为案例的表 么。 “管制”项目经理不 是初衷，最重要的是为项目经理提供必要 我的PMO十年 的支持和指导，使项目最大限度的贴近成功。 我的PMO十年 彰与惩罚制度，按某一个“任务单”为考核 单位，以月为单位统计表彰 与惩罚的积分数。 6）推广项目管理体系，我觉得“小步快走”、“细水长流”更有效。 3）为项目经理提供项目管理咨询及支持。不是助手，是“技术支持” 我们从开始编制管理体系到推广，用了一年时间，让大家吸收、执行 4）编写重大项目的项目管理实施方案。 ，用了一年……让大家将执行规范流程形成一种“习惯”，用了两年！ 5）协调整体资源，确保项目投入。 以上是管理型PMO的一些职责和工作中的收获…… 这个就是刚才有人说的，处理资源冲突……项目组的人力资源，都需要 看过有的文章，说如果项目数量少，公司规模小，就可以不设置PMO PMO审核确定，包括过程中的人员调配 当然，这需要PMO做一些基础 。其实我觉得，这只是PMO 的机制设置问题，根本不是是否有必要 PMBar - 需求 26
- 27. 设置PMO的分水岭。它可以大，也可以小，可以是助理，也可以是管 nancy-咨询-北京说: 理，甚至参与决策。但是，我的经历告诉我，这个机构是项目所需， 参与项目的具体需求调研工作？ 是公司发展所需…… 也或许，它都可以不叫PMO...只要合适。 chuner_wang-PMO-北京说: 最后，我更想说的是，我的PMO已经从助理机构华丽的转为管理机构 而且，我们也必须大致清楚项目的技术架构，需要知道项目需要配 ，我期待，我的下 一个PMO，可以成为决策机构。真的与企业运营目 置什么的技术人才 。KM的问题……组织机构上，我们归总经理直接 标挂钩，不是从受理项目管理任务开始，而 是从决策是否要立项开始。 管辖，对项目客观评价……另外，授予我们权力，可以调配资源…… PMO的价值或大或小，终归离不开5大过程，9大领域。但其实现的价 值如何，却总是事在人为。 nancy-咨询-北京说: 时间有限，其中很多问题没有很细致的展开，如果可以，我们以后可 我的PMO十年 你们管项目成本吗？预算？决算？成本控制？ 以深入交流，期待大师们 的指教。 chuner_wang-PMO-北京说: Q&A 甚至，还可以考核项目经理。哈哈，搞不好，也可能因为我们的某 个评价，项目经理换人啦 ，成本这块，我们针对单个项目做，只负 责管理和监控，单个项目的预算和支出，适时预警 ，至于事业部成 Richard李明-PMO项目主管-北京说: 本运营那部分，我们不涉及 。项目的每一笔支出，包括商务费用， 在CC有什么样的制度？ 我们要盖章，记账…… nancy-咨询-北京说: 开启尘封的记忆-KM-北京说: 想问一下，你们的PMO人员对公司业务是否熟悉？就是说除了纯粹的项 那你们的PMO，会对项目和项目经理进行考核，你么你的考核，他 目管理，对项目本身的业务了解多少？我觉得这是将来具备决策只能的 们是否认可？那这种认可和制度，是如何推行下去的？ 一个关键，管理了那么多项目，对公司的项目实施能力是否已经非常清 楚？对于公司能否承担什么样的项目，公司需要什么样的资源做项目是 chuner_wang-PMO-北京说: 否已经了如指掌？ 项目策划时，要制订项目预算，并每月细化 。KM：我们的考核数据 会实时反馈给项目经理，不会等到最后汇总时他们才知道……所以， chuner_wang-PMO-北京说: 这个最难的，就是考核办法……我们试过很多中考核方案……最后， 我们有clearcase管理制度，包括日常操作的、资源出入的。基本上，都 发现，贴小红旗最有效…… 是按照clearcase的规范来…… 期间，也有争执和分歧，但一般会消除在过程中……我们的原则是， 我的PMO十年 处罚不是目的，引导正确的方向才是主旨…… 我的PMO十年 开启尘封的记忆-KM-北京 说: 说起来。PMO在你们内部是一个管理机构，那你们内部，对这种管理机 nancy-咨询-北京说: 构的定义是什么呢？和助理机构的最大差别是哪里呢？ 项目经理是否只有PMO考核？ chuner_wang-PMO-北京说: 不同的是，我们设置封闭的开发环境，只有一个人有资源出入的权力。 超-技术负责-深圳说: nancy的问题，我们PMO人员要了解业务，要参加需求调研，但我们不 你们比较关心项目经理上报的哪些信息？或者你们选择项目经理时， 一定很专业，但主体业务流程都必须熟悉 PMBar - 需求 27
- 28. 综合考虑的是哪些方面 开启尘封的记忆-KM-北京说: 应该是个质量部门吧？ chuner_wang-PMO-北京说: 不是，我们不是人事那层面的考核……我们只以项目绩效为出发点。 nancy-咨询-北京说: 至于其它的，还有一年一度的人事考核 。超：基本上，关注项目经理上 呵呵，你们总经理管得还真不少，相当重视管理啊！ 报的进度、任务完成情况、技术难题、项目问题…… 当然，数据采集是双向的。 chuner_wang-PMO-北京说: 后来，就没有了，把评审这部分归到PMO，测试单独一个部门 开启尘封的记忆-KM-北京说: 我的PMO十年 那你能不能用个比较简洁、形象的比喻来描述一下你们PMO与项目、项 一骑满尘(微博)-QAM-北京说: 目经理的关系是怎么样的呢？ 不跟项目走？ chuner_wang-PMO-北京说: chuner_wang-PMO-北京说: 我们有项目管理工具做辅助，可以看上报来的数据，也可以自己采集数据 对，算是重视……但也可能是因为外部环境驱使吧？第一个项目，有 IBM加入……第二年的项目，来个监理，第三年，又来个代建…… Richard李明-PMO项目主管-北京说: 项目管理工具？选哪种了？ 超-技术负责-深圳说: 那QA部门的相关工作如何和项目同步呢？ chuner_wang-PMO-北京说: KM: PMO是PM的助力！推动项目成功；PMO也是总管，代表公司客观 chuner_wang-PMO-北京说: 评价，综合协调项目间的资源。李明：开始用的是projectser ver，后来 哈哈，这三大角色，全部关注我们的管理……我们不重视也难啊 是漫索系统 ，上海漫索系统 蔡德辉-PMO-大连说: Richard李明-PMO项目主管-北京说: PMO管理多少个项目？ 感觉后者更好用么 ？ chuner_wang-PMO-北京说: chuner_wang-PMO-北京说: 超：我们的qa跟着项目走，我们同时在建项目少。蔡总：最多时候， 后者现在还在用……只能说是一种辅助……还需要人工处理 我的PMO十年 同时管四个。大小规模不一样 nancy-咨询-北京说: 你们除了PMO，有QA吗？QA在哪个部门？ 我的PMO十年 超-技术负责-深圳说: 有没有你觉得好的资料，可以分享一下的，就是你曾经读过的觉得 对你们工作产生过切实帮助的书籍资料，可以公开的不涉及公司商 chuner_wang-PMO-北京说: 业机密的那种。 有一个时期，除了PMO，还有一个QA部门 ，但那个部门是负责做测试、 评审这类的工作，也是独立的，总经理直接管 PMBar - 需求 28
- 29. chuner_wang-PMO-北京说: PMO会出什么报告？ 我就是觉得PMBOK挺好，哈哈。还有《IT项目哪些事儿》…… chuner_wang-PMO-北京说: 蔡德辉-PMO-大连说: 项目状态月报、季报 从整体上来说，刚开始是作为项目经理的辅助出现的 蔡德辉-PMO-大连说: chuner_wang-PMO-北京说: 你可以再大点看，揉在一起的，还叫PMO。定性的还是定量娥？ 哈哈！我读书不多。 chuner_wang-PMO-北京说: 我的PMO十年 蔡德辉-PMO-大连说: 报告内容有以定量为主……大部分是数据统计，加上一些从管理角度 后来又了几个项目了，就有了整体协调了。 的分析……领导的指示，我们基本上不下定性的结论，用事实和数据 说话 。蔡总，您说的对，也许不出两个月，质量管理部就改名PMO chuner_wang-PMO-北京说: 了，哈哈 对，是这样的 nancy-咨询-北京说: 蔡德辉-PMO-大连说: 很高明的领导 有质量部门嘛？我不指测试人员 蔡德辉-PMO-大连说: chuner_wang-PMO-北京说: 如果有几十，上百个项目，应该如何办 后来有质量部门……专门做CMMI、GJB9001B之类……对项目的过程和 工作产品实施规范性审查 chuner_wang-PMO-北京说: 4个能管，10个也一样可以管……方法一样，只是执行时稍有变通…… 蔡德辉-PMO-大连说: 和PMO什么关系？ 蔡德辉-PMO-大连说: 定量的数据，主要有哪些？ chuner_wang-PMO-北京说: 揉在一起了 chuner_wang-PMO-北京说: 如果同时管10个，是不是人手也得多些，辅助工具更好使些 蔡德辉-PMO-大连说: 我的PMO十年 哦，明白了 我的PMO十年 蔡德辉-PMO-大连说: 工具的问题，也是很多企业的问题 chuner_wang-PMO-北京说: 没有独立的PMO了……哈哈 chuner_wang-PMO-北京说: 工作量、工期偏差、进度偏差、投入产出比、生产率、缺陷密度、 蔡德辉-PMO-大连说: 用例数、类数.....甚至，文档页数 PMBar - 需求 29
- 30. 蔡德辉-PMO-大连说: nancy-咨询-北京说: 这些数据是你们自己采集，还是项目组报上来的？还是质量部门收集 神州数码以前的PMO里也是有QA，项目监理等 来的？ 蔡德辉-PMO-大连说: chuner_wang-PMO-北京说: 我觉得所有企业的难点：体系部署、数据收集、资源调配 最小业务流数 chuner_wang-PMO-北京说: 蔡德辉-PMO-大连说: 体系部署指什么？ 还是使用漫索 就能统计出来？ 我的PMO十年 蔡德辉-PMO-大连说: chuner_wang-PMO-北京说: PMO的工作呢，与质量管理不一样的地方，PMO是为了 赢而来， 大部分是自己采集。漫索只能统计工作量、工期、进度之类。其它，需 以风险管理为驱动 。质量管理体系也好，项目管理体系也好，都是 要到产出中采集 。 比较难的，涉及到人的习惯改变。 蔡德辉-PMO-大连说: chuner_wang-PMO-北京说: 谁去采集的呢？ 没错…… PMO是为赢而来，呵呵，收了这句…… chuner_wang-PMO-北京说: 超-技术负责-深圳说: 质量管理部 说到风险管理，那你们在体系里是如何运作风险管理这块呢，能否 详细说下 蔡德辉-PMO-大连说: 我们现在从集团层面来说质量管理与项目管理也是和在一起，但职责是 蔡德辉-PMO-大连说: 有不同的，这也叫因人设岗吧 。我们的PPQA都归到各个业务部门的 我想，还是要先想想，主要风险在哪里。不是指风险管理，作为流 PMO里面。 程或者管理领域本身。有的企业，主要在需求控制，有的企业主要 在人员能力。不同的情况，重点就会随之改变……所以有的PMO， chuner_wang-PMO-北京说: 会重点抓售前时候的Review，不好的项目，不妨进来，或者提前做 对，其实目标都一样，只是分工问题，适合机会行 好预防。有的PMO，重点在过程中的监控。 我的PMO十年 蔡德辉-PMO-大连说: 这样也方便大家做工作 ，难点还在用数据说话。 我的PMO十年 chuner_wang-PMO-北京说: 我们没有分那么多层……就一个PMO，跟到底。 PMBar - 需求 30
- 31. 我的PM成长之路 Richard Richard 与绝大多数项目经理成长道路类似，我也是从技术出身的项目经理。 在刚开始工作的时候，也只是一名软件开发者，随着工作经历的增加，才转变成为项目经理。 在大学选择的专业还不是计算机方面的。我对计算机方面的兴趣还是来自于在大学时候接触 的游戏“红色警戒”，那时候国内还没有互联网，有的也是校内计算中心的局域网和PC机。 学校里面教授的计算机开发语言也只有BASIC和C（^_^估计很多人都不知道BASIC 啦），另 外也会讲些数据结构和硬件方面的知识（像单片机什么的）。源于个人兴趣，我自己又在校 外学习了汇编语言，那时候接触操作系统有各种版本DOS系统和微软的window32系统。 （哈，够啰嗦了，简单些！） 毕业后凭借专业背景，我进入了一个大型国企研究所，如愿以偿的做起了软件开发，主要开发的是实时监控系统。 那时候开始接触C++，开始是跟着研究所几个牛人边学变干。从最初的与用户讨论需求，再到设计和代码实现都完整的经历过 （感谢国企的培养机制啊，现在很多公司都不重视培养员工）。 在跟着别人做的时候，也逐渐开始考虑这个任务的分解是否合理，分配给某人去完成是否合适，要是我来做的话会不会能做的更好， 怎么样保证任务能够准时得到交付。在后来我负责带着一组人马单独完成一些项目开发，从开始需求到设计，再将任务分配出去， 并在开发中指导和监督组内人员的工作，最后获得想要的结果。 那时候，世界范围内都开始关注软件出现的质量问题，因此，如何做出一个可靠的软件成为极为关注的一件事。我在书店刚好看到一本介绍软件 工程的书，讲解如何用工程化方法构建和维护有效的、实用的和高质量的软件。通过在项目开发的试用，我发现软件工程的确可以极大提高软件 产品的质量和开发效率，减少维护的困难。 PMBar - 需求 31
- 34. 如何用Enterprise Architect进行需求管理和追踪变更 张权 中科软科技 项目伊始，分析人员在需求调研阶段交出一本厚厚的需求规格说明书，之后的架构、设计、开发、发布和维护等阶段，尽管需求会有改动， 会有添加，对甲方和乙方各级管理人员而言，除了变更列表、状态报告和系统演示，开发工作常常被开发团队封闭在一个“黑箱”之中，尽 管设立了变更评审环节，由于无法对变更做完整的影响分析，很大程度上都依赖开发人员的记忆力，起初开发速度很高，慢慢地开发就慢似 蜗牛了。 开发团队需要树立正确的需求管理意识是很重要的，需求和变更之所以要被记录，变更之所以要被跟踪，是甲乙双方的沟通需要： 1 如何向用户说明变更需求代价？ 2 如何从用户的立场出发引导，阐述其不合理的变更请求？ [图一] 在软件工程中，需求工程由需求开发和需求管理组成，需求开发和需求管理的分界线是基线管理，需求管理通常是由三部分组成，即基线管 理、变更管理、需求跟踪。 [图二] 本文中，我们以Enterprise Architect为“手术刀”，谈谈如何管理需求和追踪变更。 PMBar - 需求 34
- 35. 如何用Enterprise Architect进行需求管理和追踪变更 张权 中科软科技 一、阐释变更的代价 欲阐释变更代价，就要分析变更带来的影响，就需要有方便的手段浏览对象间的关系。Enterprise Architect提供三种方式，即： .使用图（Diagram）来创建和浏览关系。在图中元素之间的关系很容易使用工具条中定义的标准关联关系来创建。 . 使用关系矩阵来创建和浏览关系。关系矩阵是一种提供了不同包间的元素创建和浏览的关系的方法，这些定义的包可以是独立的。 . 使用层次关系视图（Hierarchy View）来浏览关系。层次关系视图提供了跟踪所有选定元素关系的功能。 1.1、使用图（ Diagrams）创建关系 手工方式，直观地建立对象间关系： . 创建新图（diagram） . 从 Project View 拖到图（diagram）上，尽管元素可能分属不同的包。 [图三] 1.2、关系矩阵 关系矩阵是另一种浏览和建立需求间关系的方法，我们有两种方法创建之： 1, 通过超级链接 2, 屏幕顶端的视图菜单 ( View | Relationship Matrix…) [图四] 关系矩阵（跟踪矩阵）是CMMI认证的基础要求。 它可以应用到任何一种元素，比如图5即是表达了需求和用例图之间的关系： [图五] PMBar - 需求 35
- 36. 如何用Enterprise Architect进行需求管理和追踪变更 张权 中科软科技 1) 对于大型的软件系统，各种需求和约束常常被分别被定义在不同的包和图里。业务需求和用户需求之间，用户需求和功能需求之间，功能 需求和非功能需求之间，关系矩阵都可以用来浏览和设置这些元素间的关系。 2) 在开发阶段，需求之后的各种元素，比如用例、类等等，需要与需求保持可追朔跟踪能力。 1.3、使用层次关系窗口的可跟踪能力 层次关系视窗（ hierarchy window）可以浏览需求间的关系。它可以浏览对需求管理有用的其他UML元素。 打开层次关系窗口(View | Hierarchy 或 Ctrl+Shift+4)，选择其中一个元素，元素关系显示在层次关系窗口中。 [图六] 二、更改控制 Enterprise Architect 提供了丰富的追踪需求变更的功能，这包括审计，基线管理，以及Change（改变）和Issue（问题）。 2.1、审计（Auditing） 审计功能可以让你记录Enterprise Architect中的模型变化。它将记录谁修改了一个元素，什么时间和怎样修改的，并附有这个元素之前的 状态。这在记载需求模型历史方面极为有用。 为使用这个功能： 1. 从主菜单选择: View | Audit View，将打开下列视图: [图七] 2. 选择 Audit Settings （审计设置）button。 3. 弹出Audit Settings 窗口: [图八] PMBar - 需求 36
- 37. 如何用Enterprise Architect进行需求管理和追踪变更 张权 中科软科技 4. 在审计设置窗口，设置: Enable Auditing （启用审计）。 接下来，我们就可以设置过滤器，浏览变更历史了。 2.2、使用基线 Enterprise Architect提供了基于配置管理的模型版本差异，笔者还是比较喜欢 EAP内部的管理基线（ Baseline Management）功能，可以设置全模型的基线 ，也可以设置某一个包的基线。 [图九] 2.2.1、何时打基线 . 在需求阶段、设计阶段和开发阶段，通常是按阶段或迭代打基线，细化一块就打一条基线 . 维护阶段，通常是每周或每月搜集一次需求，可以周期性打基线，比如每周或每月 . 也可以按版本或Build打基线。 有了基线，我们就可以比较当前的模型状态和合并变化了。 2.2.2、查看区别 点“Show Differences”就可以查看区别了。 [图十] 2.3、更改外部需求的请求和问题 Enterprise Architect有两种方式记录需求变更： a) 使用 Maintenance View针对每一个元素 列出缺陷Defects，变化Changes，问题Issues和任务Tasks。 b) 使用常规元素类型“Issue” （问题）and “Change”（变化）链接到变更的外部需求。 PMBar - 需求 37
- 38. 如何用Enterprise Architect进行需求管理和追踪变更 张权 中科软科技 下面是它们使用的简略不同： 使用维护视图（ the Maintenance View） [图十一] Maintenance View 可被用来记录针对元素和包的变化。这提供了列表: o 元素缺陷Defects o 元素变化Changes o 元素问题Issues o 元素任务Tasks 这些区域用来记录“被谁？在何时？”，这些请求被产生和完成，如：状态，优先权，描述和历史。 由于Maintenance View是针对某一元素的，其他图无法引用到，所以笔者更喜欢第二种方式，在维护模型中，针对某一版本发现的缺陷， 用元素类型的“Issue” （问题）and “Change”（变化）记录变更或者导入，可以拖拽Issue和Change其他“图”以标示这一块是因什 么而变化。 [图十二] 三、结束语 其他UML工具也提供了类似的需求管理和追踪功能，笔者抛砖引玉，希望看到更多关于需求管理方面的经验分享。 PMBar - 需求 38
- 40. PMBar牵手ITIL先锋论坛 PMBar特约记者 陋室北京报道 2012年2月9日晚20:00-22:00，PMBar IT项目管理公益实践社区与ITIL先锋论坛联合举办的“ITIL握手PM”YY语音在线沙龙活动圆满结束。 IT项目管理专家、PMBAR创始人@冯国馨PMBar（谷雨霖）老师，ITSM业内知名专家杜肖辉老师联袂出席沙龙主题分享及互动。沙龙由ITIL 先锋论坛发起者之一刘杰老师主持。 沙龙就以下三个方面开展了探讨： 1、 ITSM及PM的发展前沿和未来趋势； 2、 ITIL与PM的融合； 3、 ITSM与PM的职业发展选择； 首先，杜老师从自身多年ITIL咨询、实施及培训经验出发，就ITSM的发展前沿和国内现状进行了介绍。其中，总结到：国内能够有效开展 ITSM咨询和实施的单位，多数为国企、大型企业和外资企业。这些单位有一定的管理成熟度和较大的资金实力，对客户和内部的服务质量 需求较高，有发展ITSM的动力。对大多数国内企业来说，ITSM的发展之路还很长。 接下来，PMBar社区创始人冯老师先简单介绍了PMBar社区的基本情况：PMBar IT项目管理公益实践社区www.pmbar.net，由一群专注于 项目管理、研发管理、IT服务管理、团队管理等IT管理领域的业内专家自发组成，目前已有全国各地千余名IT领域的项目经理、项目总监、 CTO及CEO。PMBar定期的开展线上线下交流，线上"IT项目管理MSN群"每周二中午13:00-14:00进行项目管理专题讨论，并在新浪微博 @pmbar 同步，目前已经进行逾110期。 接着，冯老师从项目管理国内外现状谈起。他谈到，项目管理是一个基本技能，美国从幼儿园时期即培养大家项目管理能力，项目管理理念被 广泛认同。从项目管理认证体系上看，有美国PMI的PMBOK知识体系及PMP认证，欧洲的IPMP/PRINCE2等认证，国内有工信部发起的系统 集成项目管理师等认证。在我国，项目管理刚刚被大家认知，但在实际工作和生活中还没有广泛被应用和实践。 然后，冯老师从组织级、项目级和人员级三个层面，就项目管理现状进行深入分析： 1、从组织级体系上看，项目管理被融合到ISO、CMM、IPD、敏捷等模型和方法论中。而国内IT项目管理的水平整体相对比较低，从管理成熟 度来说大多集中咋2级-3级。项目可重复成功的能力不足，10年前普遍存在的项目管理问题、10年后的今天依然很普遍。 2、从项目级上看，国内大多中小企业没有建立可以依循的项目管理体系，没有基本的配置管理、质量保证等管理手段，项目历史数据没有收集 和整理，过程管理、过程改进更无从谈起。 3、从人员级上看，国内成熟的项目经理屈指可数。大多数IT项目经理从技术人员直接提拔上来，没有得到认真的选拔和系统的培养。中国的项 目生态相对复杂，甲方管理不成熟、强势，乙方企业生存环境恶劣，IT项目经理发展面临巨大的挑战。时下流行的PMP、Prince2等认证，并不 能解决项目经理一线实践操作中面临的困惑。为此，项目经理的自我修炼和组织系统培养非常重要。PMBar社区努力从这个角度多展开一些实 践和探索！ PMBar - 需求 40
- 41. PMBar牵手ITIL先锋论坛 PMBar特约记者 陋室北京报道 ITIL专家杜老师和项目管理专家冯老师的精彩开场，把参与沙龙的社区会员积极性调动了起来，大家纷纷踊跃提问。 话题一：ITIL与PM是否有融合的点？在哪里？是否具备可操作性？ PMBar冯老师认为：任何事情都可以拆分为项目来运作，ITIL管理者更需要项目管理知识来武装。ITIL管理通常属于人员少、任务重、业务复 杂的工作，项目管理能让大家更有序。奥运会售票系统、铁道部网上购票系统等上线崩溃，很大程度上是项目管理失误。北京奥组委在总结北 京奥运会运营经验教训中，重点提出中国在项目管理人才方面培养不够，并把项目管理写进了十二五人才纲要中。 话题二：作为一名IT从业人员，是否需要同时学习掌握ITIL和PM两套知识框架？ PMBar冯老师认为：项目管理是一种通用管理技能，ITIL是专业管理技能。国内ITIL运作优秀的企业，如国资委、外企、联想神州数码等国企的 ITIL专家都要求有项目管理技能，有的企业甚至要求高级管理者需要具备工信部项目管理师、PMP等认证。 话题三：ITSM和PM哪一个更适合作为职业发展的方向？如何根据个人的条件进行选择？ PMBar冯老师认为：他们之间没有直接的可比性。职业发展规划的核心，是需要个人问清自己要什么？所谓，我想成为什么样的人？技术职业 发展通常有以下4类： 技术工程师 开发 测试 质量保证 美工 架构师、系统分析师 管理类 项目经理 产品经理 部门经理 市场类 售前工程师 售后工程师 每个需要依据自己的实际情况来确定自己的发展路线。就项目管理而言，一名合格的项目经理，从性格特质、专业技能、学习能力、决策能力、 沟通能力等方面都有一定要求。好消息是，项目经理往往是通用管理者的阶梯。 最后，PMBar创始人老谷分享了PMBar社区近期动态： 1、PMBAR第一本经典著作重磅出击《IT项目管理那些事儿》热销！ a)8月中旬上架，目前已销售5500册，第二版印刷已完成。 b)策划敏捷实践书籍，预计今年7月上架 PMBar - 需求 41
- 42. PMBar牵手ITIL先锋论坛 PMBar特约记者 陋室北京报道 c)下半年策划CMMI实践书籍，预计2013年上半年上架 2、PMBAR项目经理电子杂志试刊首期—敏捷VS传统 隆重推出！第二期 “需求管理”专辑进行中。 3、与ITIL先锋论坛合作，启动YY在线语音沙龙活动。 4、每月举办地面项目管理沙龙活动 5、建立PMBar项目管理培训体系并举办公开课 6、启动PMBar项目管理工具开发及试用 7、开展社区项目管理知识沉淀工作 此次活动取得了远远超出预期的效果，受到了来ITIL和PMBar社区成员的高度赞誉。此次活动的成功举办，标志着PMBar在IT项目管理领域的 公益实践更上了一层楼，开辟了实践社区合作的新形式，为推进“让IT项目管理在中国普遍成功”向前迈出了坚实的一步。 后继：“ITIL握手PM”活动开启了PMBar与ITIL两个实践社区之间在线语音沙龙的合作之旅。目前，已成功联合举办2期活动。 3.22 PMBar第1期暨ITIL先锋第20期歪歪语音沙龙：《项目管理和谐之旅》--恺墨 成功举行 3.29 PMBar第2期暨ITIL先锋第21期歪歪语音沙龙：《说说IT项目管理工作死角那些事》王艳春chuner 参考链接http://www.pmbar.net/read.php?tid=1432和http://www.pmbar.net/read.php?tid=1453 附录: ITIL先锋论坛论坛网址：www.itilxf.com ITIL 先锋论坛是国内最大的IT服务管理专业社区，自2010年底成立以来始终致力于 以ITIL为代表的信息技术科学方法论在国内的推广与落地， 目前已发展论坛 会员近7000人，15000多微博粉丝，6000多名QQ群友，40000多 条帖子，10000多分可供下载的管理及实践资料。ITIL先锋论坛在各位 版主及广大 网友的共同努力下，将继续为IT服务管理初学者提供入门的引领，为IT服务管理实践 者提供落地的支撑，为IT服务管理业界提供沟通交流的平台。 社区口号：ITIL先锋，你我同行。 PMBar - 需求 42
- 43. PMBar出版物：《项目管理那些事儿》 （编按/恺墨）《IT项目管理那些事儿》是PMBar IT项目管理实践社区推出的实践系列丛书第一本。为了便于大家更好地和读者交流，我们将在 本栏目陆续介绍其中各章的内容。首先，请允许我在这里介绍其中的两位作者：王保强和蔡晓东。 王保强 12年IT工作经验，曾在华为、HP、Infosys等国内外知名IT企业任职；关注领域包括证券、航空、制造、电信等。在数据库开发和优化、数据仓 库、系统架构、大中型项目管理、Web2.0方面有一定研究。《剑破冰山—Oracle开发艺术》一书合著者。 ITPUB数据仓库和MSSQL等版块版主，曾获ITPUB最佳博客和ITPUB数据库大版最佳版主。博客地址为: http://blog.csdn.net/baoqiangwang 和http://space.itpub.net/6517/。 蔡晓东 在电信行业IT企业中工作13年，担任过开发工程师、系统架构师、项目经理、产品线经理等职位，现任技术总监兼项目推进部(PMO)经理。在 长期的项目实践中，获得了丰富的技术及项目管理经验。长期关注软件过程方法研究，关注PMI项目管理方法体系（PMBOK、OPM3等）及敏 捷方法。曾作为评估组成员参加CMMI 5级评估，对CMMI方法论原理也有一定研究。致力于将项目管理方法、软件过程方法与组织级项目管理 方法等融合在一起，建立统合的IT项目管理方法论，使客户、项目经理、项目成员、组织级干系人等各方利益最大化。 正如托尔斯泰说过的：“所有幸福的家庭都一样,不幸的家庭各有个的不幸”。需求似乎是每个项目经理心中永远的痛！当然，每个人的痛也不 一样。那么，让我们来看看王老师和蔡老师在他们的项目管理中曾经分别遇到了什么困扰？他们又是怎么解决的？ 文摘第一部分： 系统需求 宁泰资讯管理平台项目于9月下旬正式进入系统需求分析阶段，一直到11月下旬提交需求规格说明书为止。 通过前期的系统规划，已经了解了各子系统业务需求情况和相互间的依赖关系，所以我们决定把该项目定位为项目群的管理方式，因为该各子 系统之间的关联性不是很强，所以可以隔离开来分别进行需求调研；又通过进一步的客户沟通，我们把子项目做了优先级排序，把客户最关心 的终端项目放在需求调研的第一位，然后把知识库放在需求调研的其次位置上，把一些后台维护管理模块暂时搁置，但其实资讯库的建设才是 该项目的重中之重。 在终端项目需求调研阶段，首先向汪经理了解终端项目会涉及到哪些部门以及各部门对终端的期许和目标，因为牵扯到的部门太多，而且各部 门之间是平行关系，随后我表达了我的担忧，担心需求会在各部门之间蔓延发散而无法聚焦，汪经理表示理解，并表示会尽力汇集、引导和控 制各业务部门的需求；接下来由汪经理召集召开了各部门参与的一个群体会议，在会议上大家可以自由发挥、群力群策，畅所欲言，我们分别 记录下来，这次会议的目标是让大家发挥头脑风暴的作用，发现一些潜在的业务需求；对需求进行梳理和分析后，然后在汪经理的支持下，分 别对每个业务部门进行专门的业务调研，这次的调研目标是有意的引导客户向总目标靠拢，同时也挖掘新的业务需求；这样经过反复几轮调研 和确认，售前人员和我一起不断完善终端的Demo，说到这里不能不说Excel是个很有用的Demo构建工具，您不需要有很深的技术背景，只需 PMBar - 需求 43
- 44. PMBar出版物：《项目管理那些事儿》 要了解客户的需求并具备一定的美工眼光，就可以实现Demo的开发，然后和汪经理的沟通就建立在这个Demo的基础上了；最后根据Demo完 成需求规格说明书的撰写，并以此作为合同的附件。 因为涉及到其他业务系统的接口，与其他第三方厂商的需求调研就没那么顺利了，因为在需求分析阶段，关于系统接口的需求很大程度上自己还 是停留在懵懵懂懂的认知阶段，当然第三方也不会去尽力配合你了，你所能做的就是等待和忍耐。 关于知识库的需求调研就没那么顺利了，因为公司无法派出合适的售前人员，一直推到10月份一个部门总监才姗姗来迟，交流时间和准备都很仓 促，只是宣讲了一下自己的解决方案，并简单听取了一下业务部门的意见，不过该总监的业务能力还是比较强的，还是赢得了对方的信任；为了 更进一步了解用户需求，需要进行第二轮的需求调研，在客户的催促和我的强烈要求下，又等了1个月，公司才派出需求调研人员，而且是两位 陌生的面孔，仍旧是原来解决方案的宣讲，并没有看到对业务部门上次提出的需求的反馈，这一次仍旧是来去匆匆；很快又过了一个月，终端已 经进入设计阶段了，而知识库的需求调研仍然没有任何进展，应甲方的不断督促，公司才派驻了一位新面孔卓项目经理来进行需求调研，而宣讲 的还是第一次的解决方案，连我都忍耐不住了，不用说业务部门更是意见很大，连续调研三次，连续三波调研人员， 连续三次都是同样的解决方 案，没有任何进展！还好这一次总算确定了项目经理，至少不用再担心换人了，关于知识库的需求调研算是正式开始了。 在系统需求阶段，我还在准备另外一件事，即系统架构的不断深化和数据同步技术的预研工作；由于我对某些业务不熟悉，因此我只能在某些子 系统的需求调研上充当主持人的角色；在系统需求分析的大部分时间里，只有我和销售江经理两人在客户现场，为了体现公司对项目的重视态度 ，我开始向公司寻求需求分析人员和资深技术人员上的支持；最终公司从母公司借调了两位女士周小姐和伍小姐派驻到现场，周小姐是做过3年 Java开发的技术人员，伍小姐则是专职的系统测试人员，我不禁有些啼笑皆非。只好安排周小姐研究一下Java的框架，安排伍小姐做文档管理员 ，并顺便作会议记录。 有效的引导和收敛需求，可视化的Demo设计，是项目经理迈向成功的坚实基础。 ------------ 本节摘自：《第一章 中小型民营IT企业项目管理手记》 ------------ 第二部分： 项目第二阶段 经过项目的第一阶段，开发人员对业务、技术比较熟悉，能够帮助陆续到岗的开发人员很快熟悉业务。第二阶段的目标是完成本省BST业务功能 开发，因此，需求成为第二阶段的首要问题。此时，需求人员也陆续到岗了。 需求工程与需求管理 无论是瀑布模型、CMMI还是敏捷方法论，都对人力资源的投入情况做了理想化的假设。但在中国的软件开发实践中，常常出现“不正常”的现 象，甚至比“正常”现象更诶常见。在BST项目中，需求人员在项目第二阶段时才进入项目，对于BST业务与呼叫中心业务也非常陌生。这种情 况下，由需求人员负责需求调研已经不现实了。 让开发人员来做需求调研吗？经过了项目第一阶段的设计与编码，开发人员对于BST业务与呼叫中心都有了基本的概念，很容易理解业务需求。 PMBar - 需求 44
- 46. P M 人物