|
在上周的时候就听说杭州思步科技要组织项目管理类的沙龙，我得到消息后就报名参加了，参加的目的有两个：1、学到知识和方法，回去用工作上，以道御术干事业；2、交到圈子里面的朋友，方便以后大家一起交流，有了第一面的认识了以后，许多事情就方便了。 全天的沙龙有两个课题，可以看这里：《2011焦点追击：项目管理-敏捷-CMMI沙龙活动【杭州站】》。 一天下来，收获颇丰，尤其上午。课程很充实，也需要有很强的基础，毕竟是将几天的课程进行压缩了以后放到半天来讲的，所以讲师也只能在很多地方都点到为止。上午的题目是《集成产品开发(IPD)与研发项目管理应用》。针对这个题目，我做了很多的笔记，现整理到博客上来，一是方便自己随时查阅，以防笔记丢失；二是希望其他同行也能从中受益，最主要的还是整理自己的思路。 在讲到项目成功的因素时，我印象最深的是以下几点： - 项目的目标、范围是否明确
- 是否建立了有序的、有效的、良好的沟通渠道
- 是否建立了良好的、积极的、团队合的工作氛围
当然，附近以上几点之外，还有一些有关组织是否健全和稳定、领导是否积极支持、是否具有有效的全面的项目管理和严格的变更控制等这些内容，我倒是认为是其次的。 在谈到项目失败的主要因素时，以下几点讲的也非常好： - 跨部门协作不得力
- 责、权、利不清
- 资源配备、供给欠佳
- 缺乏有交的沟通
- 计划和控制不力
项目能够成功的原因很多，但是项目失败，跑不出讲义里面提到的这些原因，而以上我例举的的几点，是从我的角度来看，破坏力相比其它点会更加猛烈些。在IPD整理框架下，要有效的利用现有的平台，并且把员工的日常工作模式化。这两点，无论是不是IPD，我感觉都非常重要。如果利用现有的、原来的基础框架、组件以及平台，是每个公司都要去解决的问题，这里面的核心其实就是复用和重用，但层次不同，这里面要求的是平台级别的重用，而一般的程序人员都是代码级别的copy，只是方法或者函数级别的复用，距离平台级别相去甚远。把员工的日常工作模式化、固化，这个不用再解释了，因为一个人总是做各种各样的事情效率一定比一直做同一件事情低很多。 在新的项目组成立，或者启动了新的研发项目时，除了明确项目目标、明确沟通方式、明确项目团队成员职责等之外，就是要进行认命，通过任命书的方式，将责任落实到项目组的各组员头上。 项目启动了之后，就要做项目计划。做计划最重要的几个方面是：有明确的目标和范围，加强计划意识，项目成员要充分参与制定，提出建设性意见，由上往下制订与由下往上修改相结合，加强工期/工作量估计的经验积累，做好与其它相关部门计划的衔接等。那判断一个项目的目标是否明确的标准是： - 明确性：最终目标是否明确了应该做出=到哪一步以及何时完成
- 可度量性：能在多大程度上测量最终目标的完成情况
- 可完成性：在规定的时间内，最终目标是否合理，能否实现
- 相关性：最终目标是否很重要、很有价值、是否值得进行下去
- 可跟踪性：能够对整个项目的时间进程进行跟踪检查吗
一个完整的计划包括：任务名称及层次、资源、成本、时间进度、完成标志、上层任务的约束、下层任务的配合、阶段里程碑，其中阶段里程碑被称之为项目的心跳，既然叫心跳，就不能心率失常。那么正常的心率也就是正常的里程碑点，比如需求、设计、开发、测试等在整个项目周期所占的比重，在国际上或者国内都有专门的机构在进行统计，国外的是ISBSG，国内的是CSBSG，又叫做：中国软件过程基准用户组，只不过里面的数据是要收费的。 在制定计划时，要考虑制定计划的要素，包括： - 是否包含了版本及所有特性的计划
- 是否全流程的计划（硬件、软件、测试、市场技术、生产率）
- 是否产品卖得出去的计划（资料、宣传、操作指南等）
- 是否根据产品的特点进行了分层
- 每项活动是否分解到个人，且时间不超过一周
- 各层次之间配合关系是否明确
- 特性是否相关
- 计划的过渡是否符合市场需求
- 技术难度及解决情况是否支撑
- 资源需求是否合理
- 资源需求是否可保证
- 各阶段、步骤、任务的时间安排是否合理
- 关键物料的货期是否符合计划
- 是否符合流程
- 是否设置了关键路径和里程碑
- 每个活动是否有结束的标志
在计划制定好之后，就到了WBS：工作任务分解。WBS的原理是：将任务逐级分解直至个人，在矩阵中体现为：先确定横向有多少个结点，再将每一个结点任务逐渐细化直到个人，工作分解图实际上就是就一个复杂的开发系统分层逐步细化为一个个独立的我们能够预测、计划、和控制的单元，这样可以使我们将复杂、庞大的、不知如何下手的大系统划分成为了一个个独立的我们能预测、计划和控制的单元，从而也就达到了对整个系统进行控制的目的。WBS的分配原则是：将主体目标逐步细化分解，最底层的任务活动可直接分派到个人去完成，通俗点讲就是分解到可估算的程度就好了。WBS分解的方法：自上而下与自下而上的充分沟通、一对一个别交流、小组讨论。WBS的分解标准：分解后的活动结构清晰＼逻辑上形成一个大的活动＼集成了所有的关键因素＼包含临时的里程碑和监控点＼所有活动全部定义清楚。 在估算这一节中，我学习到了快速功能点估计法：Fp=ILF*35+EIF*15。举个例子：要做一个OA系统中的领导日程安排模块，首先是要找到内部逻辑文件（ILF），有：使用用户（领导、管理员等）、日周月日与用户权限三个，3*35=105；外部逻辑文件（ELF）主要是日程的短信提醒，１×１５，这样加进来的话就是105+15=120，那么再乘个系数3.95人/工作时，最终就得出120*3.95=474人/工作时，如果每天按8个小时计算，即需要59人/天，如果每月20000元费用，那么开发费用约为59/22*20000=53636元。这样的话，领导日程安排这个功能就估计出来了，至于为什么系数是3.95，我还要去问问讲师。 有一句话我是感受深刻，并完全赞同。要加速项目的进度，就要：向关键路径（工作）要时间，向非关键路径（工作）要资源。 计划做好了，任务也分解掉了，接下来就是计划控制了，那计划不是一个人做出来的，应该是集体讨论的成果，这样在分解任务到人的时候，不至于任务接受人有很大的抵触。项目的计划分为三级：一级是里程碑计划；二级是阶段计划；三级是日计划和周计划。在计划控制的时候，顺序也是一级二级三级这样。需要关注重点，关注心跳。毕竟到了三级这种日计划，一定会有偏差的。控制计划的手段主要有：项目报告和项目会议。报告一般都是常见的本周做了什么，下周要做什么，遇到了什么问题，怎么解决的，诸如此类。今天讲师讲到了摩托罗拉是用六张图来进行监控：进度偏差图、质量数据图等反映一些趋势的，而不是反映状态的。会议就比较常见了，包括各种例会、说明会、评审会等等，会议的目的是为了控制计划，而不能为了会议而开会。除此之外呢，还要与员工保持充分的信息沟通，做好风险评估和应对措施，及早发现问题、解决问题，加强问题与风险的经验教训总结。员工时间汇报项目问题发生状态是跟踪计划的比较好的手段。 当计划出现了偏差，就要有变更，这个变更也要控制，不能随意。变更的控制要从计划抓起，计划做好之后，就要相关责任人签字，并讲明各种情况的处理方式。处理偏差也分两种，正规和非正规。正规的是申请加班、申请资源。非正规的就是看项目经理或者负责人各显神通了。 项目控制的五个步骤： - 及时掌握最新情况和项目进展
- 分析计划进度和质量产生偏差的原因
- 处理偏差
- 公布修改方案及滚动的计划
- 周知管理部门
项目还要采用一些自动化的构建、测试、集成的工具，如TFS等。 记的就这些，也不知道自己真正掌握了多少，还是要用到实处才行！写句诗勉励下自己吧：纸上得来终觉浅 绝知此事要躬行
上一篇：【思步沙龙-杭州站】资料分享之二：软件企业能力实践与方法应用（CMMI与Agile））
下一篇：首届“思步讲坛”即将开讲 | 
[复制链接]
service@step365.com
0571-87357690
狗仔卡
发表于 2011-4-29 11:35:17
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
转播
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
发表于 2011-4-29 13:30:53
发表于 2012-3-20 15:41:56
真受益！
