导航↓ 相册|收藏博客|加入友情链接|给博主留言
我要啦免费统计阅读使人充实,会谈使人敏捷,写作与笔记使人精确。史鉴使人明智;诗歌使人巧慧;数学使人精细;博物使人深沉;伦理之学使人庄重;逻辑与修辞使人善辩。-培根
黑猫大队长
2018-1-15 21:46

™™™
2017-10-18 10:12
™™™
2017-10-18 10:11
™™™
2017-10-18 9:52
Z浪迹天涯
2017-10-16 1:3
sunnyrl
2017-9-13 12:2
pangdan2007
2017-7-10 19:54
  • 创建:2007/2/23
  • 文章:973
  • 评论:5127
  • 访问:954841
  •  
关键字:IT项目经理

该pdf文档为Sohu一博主整理,链接为Http://axltfytx.blog.sohu.com.

内容应该还不算很完备,但还是可以作为日常参考。特推荐下载。

 

编辑 | 阅读全文(35487) | 回复(426),人月&神话 发表于 2007-10-26 8:12
关键字:IT项目经理 敏捷
1.讨论板
类似于项目组群聊的功能,每次讨论的记录可以记录和保存。讨论板可以贴图,可以发文件,最好还有主题内容的置顶功能。由于在Web上面实现,为了避免频繁刷屏的问题需要引入Ajax等相关技术来实现。

讨论板是敏捷开发中,特别是虚拟团队最常用的功能,也是很多企业内部IM及时通讯软件说具备的常用功能。

2.任务管理
需要对项目管理软件所具备的任务管理,进度计划,资源平衡,活动依赖,成本管理等内容做较大的简化。敏捷开发中的活动是根据需求(用例),或故事场景驱动的,有此驱动的需求,设计开发等活动自然会汇聚到根据功能点的工作包中。而且根据用例或功能点的需求追踪也可以根据系统自动来进行建立。

敏捷中强调迭代,迭代是重要的里程碑点,因此在任务管理中最好能够体现各个功能点在每个迭代周期中的进展和分布。

团队中各资源的使用情况最好是以图形化的方式直观的显示出来,在任务下达过程中任务本身的工作量和要求完成的时间点是终于的属性,系统应该根据资源的最大可使用情况自动来建立一些必要的约束。

任务的完成和反馈越简单越好。对于项目成员而言可以方便的查询到自己的待处理任务,而项目Leader可以通过总体任务进展图(类似停车场图)很方便的跟踪到任务的实际完成情况和进度。对于各种异常点系统应该给出很醒目的提示。

3.文档管理
敏捷开发仍然有过程,因此在各个阶段仍然存在相关的交付物和文档。因此对于文档的创建,更新,检索是必须的功能。文档的权限管理可以弱化,但对于文档本身根据工程域或支持域进行的分类管理则很重要。

对于各种模板,规范,最佳实践等内容应该作为项目知识库最重要的内容。各种知识的收集,分类,整理,抽取就显得更加重要。知识库是项目的重要核心资产,在项目进展过程中不断发展和完善。

但任务和知识关联的时候,知识库价值进一步发挥。比如但我们创建一个编码任务的时候,任务本身有很方面的连接可以看到相关的最佳实践和编码规范的内容。

4.问……
编辑 | 阅读全文(2563) | 回复(2),人月&神话 发表于 2007-10-25 20:25
关键字:时间管理
 
http://scheduler.lenovolabs.com是一个时间/日程管理的web应用,与其他日程管理软件不同的是,还提供了一个可以自然语言输入的msn机器,帮助用户创建和查询日程信息,使用方法如下:
  

Msn用户添加scheduler@lenovolabs.com为好友后,就可以通过msn与scheduler机器人以对话的方式设置日程、提醒以及查询日程,并且能够由msn直接进入自己的web上的帐户进行操作。
  

举例来说明吧:

创建提醒:如果您今天下午2点有一个重要的会议,你可以通过msn输入“今天下午2点A202会议室XXXX会”,小机器人会提供给您一个回复“提醒创建成功,2007-08-16 14:00:00 A202会议室XXXX会”,此时,提醒已经添加到您的Scheduler中去了。
  

创建日程:创建日程就需要您输入日期,或是一段具体的时间了,如:“11日哈里波特首映”或“本周日8点到12点参加同学聚会”,前者将会在本月11日添加新的待办事宜,后者则会添加一个新的日程“日程创建成功 2007-08-19 08:00:00 2007-08-19 12:00:0 参加同学聚会,届时将提前10分钟提醒你.”
  

查询日程:输入“今天?”或“明天?”等等类似的语句,小机器人就会把相应的日期内的日程和提醒全部显示出来,供您查看,并提供一个链接,可以直接进入Web帐户查看日程。
  

使用msn小机器人,让Scheduler使用起来更加简单方便。如果你还不是Scheduler用户,那么添加上述机器人作为好友后,系统会自动为您在
scheduler.lenovolabs.com上创建一个帐户,帐户用户名为……
编辑 | 阅读全文(2047) | 回复(2),人月&神话 发表于 2007-10-25 20:24
关键字:IT项目经理

技术管理就像开车。当你做得正确时,没有人注意,一旦某个环节出错,问题会接踵而来。以下是我11年来作为Interviewing Manager的Team管理体会,排名不分先后,你必须注意每一点。

1. 不要重复过去二三十年来别人犯过的错误
     

这句话来自Steve Mcconnell,IEEE软件编辑和软件开发畅销书作家。Mcconnell的作品包括经典著作“Code Complete”。Mcconnell认为,“大量阅读”是避免犯重复错误的最好方法。

2. 80%的管理就是选择正确的人选
     
Scott Adams, Dilbert漫画的作者认为一个好的项目经理必须创造一个人尽其用的环境。所有的项目经理都应该读一读Tom Demarco和Tim Lister的新书“Peopleware:Productive Projects and Teams”(2nd Edition, Dorset House, 1999)。

3. 总是试图雇用比你强的人
     
不要让你的自负成为项目的瓶颈。组织一支聪明的队伍,给他们足够的资源和解决问题的规则,让员工自己解决问题。

4. 不要浪费时间
     
Tom Bragg,Intellisys Technology Corp.的首席技术官员,认为太多的项目由于不能如期开始最后陷入麻烦。通常导致延迟的原因包括其它任务的干扰,人事变动,不准时的经理等等。

5. 最优的未必是最大的
     
Tom Bragg的另一个建议是:密切注意项目开始后发生的事情。Bragg说:“计划好你的工作然后如期进行,过分紧张的工作强度反而往往……
编辑 | 阅读全文(1875) | 回复(5),人月&神话 发表于 2007-10-25 20:23

对于软件项目,估算有很重要的地位,估算步骤最好是能够先估算规模,再根据生产率得到总体工作量,再根据总体工作量预计项目各阶段周期。类别估算,参数估算,专家法或三点法估算,功能点估算等都常在软件项目中使用。

在没有充分的历史数据积累的情况下建议参与专家法通过类别方式进行估算,有了足够的历史数据来检验和校正估算参数和可以过渡到功能点估算和专家估算。项目在进行过程中需要不断的积累和收集历史项目的实际执行数据,形成工作量比例分布,生产率等实际的估算参数基准。

1.主体任务工作量估算

在 软件生命周期中的需求,设计,编码,测试等活动是项目的主体工作任务,也是估算的重点。对于软件项目在计划阶段很难直接估算到功能点的代码行,因此一般采 用对功能点或用例点进行估算,这样就可以得到需求的规模。需求规模/需求生产率可以得到需求阶段的工作量,再根据工作量比例分布即可以得到设计,编码等阶 段的工作量估算数据。

对于软件项目历史数据足够和积累了更多的经验后,可以根据各阶段产出物的规模/生产率分别来得到各阶段的工作量.

设计工作量 = 设计规模(设计类,接口等数量)/设计生产率
编码工作量 = 代码行/代码生产率
测试工作量 = 测试用例数/测试生产率

通过以上方法基本就可以得到主体任务的规模和工作量估算数据。

2.评审任务工作量估算

项目究竟应该安排哪些评审,在哪个阶段安排,评审的覆盖率要达到多少等都应该根据项目质量计划和质量策略来确定。评审是预防和保证质量,投入适量的评审可以大大的减少缺陷的泄漏和返工。

评审工作量的安排并不是越多越好,项目总周期和工作量是一定的,评审安排太多则后期主体任务和返工工作量则会被压缩。评审的关键是发现可能导致项目重大工作量偏差的缺陷泄漏,而不是要100%防止任何缺陷的泄漏。

对于评审的工作量 = 评审人数*产出物的规模/评审速率

对于不同……
编辑 | 阅读全文(2418) | 回复(1),人月&神话 发表于 2007-10-24 21:52

拟制项目管理计划是项目经理的重要核心任务,计划拟制完成并通过评审基线后,后续的项目所有活动都必须按照计划进行。InfoSys公司提供的项目计划模板主要包括项目概要,项目计划,项目跟踪,项目团队四方面的内容,具体如下。

1.项目概要

1.1项目综述
    1.1.1 项目的目标和项目范围
    1.1.2 项目的类型,平台,周期,状态,估计成本等信息
    1.1.3 项目对客户的增值
1.2项目假设,依赖,约束和承诺
1.3项目各阶段的产出物和项目验收标准

2.项目计划

2.1项目过程
    2.1.1 项目生命周期模型选择
    2.1.2 项目过程裁剪说明
    2.1.3 需求变更管理过程
    2.1.4 需求状态跟踪
2.2项目估算
    2.2.1 项目范围的WBS分解
    2.2.2 项目估算参考的基准数据和生产率
    2.2.3 项目规模估计(用例或功能点或代码行)
    2.2.4 项目工作量估计
    2.2.5 项目按阶段或迭代过程的工作量估计
2.3项目进度计划
    2.3.1 项目进度计划(Project)
    2.3.2 项目基线和里程碑
2.4项目人员
    2.4.1 项目人员需求计划
    2.4.2 项目按角色人员分配……
编辑 | 阅读全文(3991) | 回复(8),人月&神话 发表于 2007-10-17 23:26


质量计划需要回答的是如果通过各种质量相关活动来保证项目达到预期的质量目标。质量计划中的重要输入是质量目标,而质量目标来源于用户需求和商业目标,项目质量计划根据质量目标制定,包括质量保证计划和质量跟踪控制计划。
 
质量属性包括了正确、可用等功能性属性,也包括了性能,安全,易用,可维护等非功能性属性。各质量属性间本身也存 在正负相互作用力,提高某个质量属性会导致其它质量属性受影响,也会使项目进度成本等其它要素受到影响。项目进度成本有限,不可能满足所有的质量要求,因 此必须系统的确定各质量属性满足的优先级,满足的度。这里面有QFD系统的方法,也可以参考KANO模型真正找到我们投入不多的时间和成本就能大幅增加客户满足度的易用性需求。
 
因此质量目标应该包含两方面的内容,一方面是功能性的质量目标,主要以产品的无故障运行时间和产品的现场故障密度 来定义。另一方面则是非功能性的质量目标,应该根据非功能性需求中对应的质量属性来定义。只有明确的定义了质量目标才能够去计划和安排质量相关的活动。质 量成本分为COQ好质量成本和COPQ坏质量成本,质量是设计出来的而不是检验出来的,有了质量成本指标可以很好的衡量项目总体的生产率和效率,衡量项目进行中的质量水平。
 
为了提高和保证软件质量,在项目执行过程中会采取一系列的质量活动,比如评审,培训,测试,代码走查等。这些活动的安排时间点和安排工作量应该和项目质量目标一致。当为了预防质量问题投入的好质量成本小于返工等引起的坏质量成本的时候,都是值得安排的质量活动,质量活动的价值就在于提前发现质量问题,或者通过前期的培训减少质量问题的发生。因此对各活动安排的参考意见为:
 
需求和总体设计类文档一般要求评审,防止前期的缺陷泄露。另外一个重要的原则就是你认为当前任务执行人无法很好的保证产出物的质量的时候都需要进行……
编辑 | 阅读全文(2766) | 回复(3),人月&神话 发表于 2007-10-17 23:24
关键字:IT项目经理 进度

WBS确定后项目详细范围基本确定,在PMBOK的时间管理里面有详细的进度计 划制定步骤。活动定义->活动排序->估算资源->估算历时->制定进度表,同时也提及到了估算方法,关键路径,PERT网络, 关键链,资源平衡等重要内容。但在整个过程中有太多的假设,假设创建出来的是理想化的进度表,而我们需要的是可行的进度表。


1.进度计划不要去追求理论最优,而应该考虑可行性和对目标的满足。
2.在活动定义和排序估算中都可能会发现WBS分解层次,粒度,遗漏等问题
3.PMBOK中制定进度各步骤并没有严格的先后关系,IT项目强调关键点是WBS,估算有后即可制定进度。

项目进度安排的首要目标:在满足质量和成本要求的情况下,满足项目预期的进度要 求。因此从这个目标出发需要优先考虑两个问题,一个就是软件生命周期和方法论的选择,一个就是团队组建,人员的搭配和角色安排。而这两个问题都是基于一个 目的,或者说是基于TOC约束理论的思路,不要在项目执行过程中因为瓶颈存在使过多的人员闲置和等待,而是要达到人力资源最佳配置和最有效的利用。

4.制定进度前往往就已经想好了开发方法论选择和人员角色搭配安排。
5.瓶颈造成资源利用不均和等待,进度安排中资源利用最大化是TOC一个重要体现。
6.在生产管理中一般在瓶颈资源前预留缓冲,而在关键链中是要考虑在路径汇聚点(最大风险处)前预留缓冲。
7.小型敏捷团队,整个计划中如果出现前期资源不饱和和空闲是要命的事情。

瀑布,迭代还是敏捷开发?关键需要解决的还是最大化的降低后续工序资源的等待时 间。对于中小型短周期的项目一般适合采用迭代或敏捷的开发方法。但敏捷不是跳过程,敏捷或迭代最好是基于前期整个开发模式和功能框架都已经确定后再进行, 这里指的并行是多个需求功能点的并行,对有严格依赖关系的,对同一个功能点的需求,设计,编码……
编辑 | 阅读全文(6252) | 回复(8),人月&神话 发表于 2007-10-13 11:42

2004年版PMBOK指南对WBS的解释: Work Breakdown Structure(WBS)工作分解结构:对应当由项目团队执行以便实现项目目标,并创造必要的可交付成果工作,按可交付成果所做的层次分解。WBS将 项目的整个范围组织在一起并加以明确。每向下分解一个层次,就意味着项目工作的定义深入了一步。WBS最终分解为工作细目。WBS的层次结构以可交付成果 为对象,包括内部和外部可交付成果。


WBS和WBS字典是项目范围的核心,通过WBS分解真正使项目目标和范围和项目进度中具体的工作任务有效的衔接起来。WBS分解的难点不在是否有WBS 模板,不在于WBS分解的方法和层次,分解的粒度等内容,更多的困难点在项目管理组要对整个项目目标范围相当熟悉,要对特定业务领域的业务运作和管理相当 熟悉。比如对于IT项目如果对软件项目管理方法论,软件过程改进,软件工程和生命周期不熟悉,或者没有积累如果经验很难分解出有效的WBS。


分解WBS,确定活动任务,已经活动排序依赖这些都不是孤立和严格先后关系的过程。在这个过程中不断的存在着反复和调整,调整重要目的仍然是保证制定出有 效的进度计划,保证后期的质量和成本控制有基准。WBS的最底层是工作包,工作包必须是严格的输出物并且可验证。对于小型项目个人认为工作包可以直接作为 任务下达。

WBS是项目范围的全集,但不要忽视了WBS字典,WBS字典是对WBS每个分解项要求的详细描述。简单讲,项目 进展过程中的任何产出物,任何活动都应该在WBS中有体现。项目执行中应该只做应该做的事情,不能遗漏也不能镀金。WBS分解的越清晰,完善,说明项目管 理组对整个项目全景的把握越好,越心中有数。

对于软件项目,我们最终需要提交的是软件产品,因此WBS的核心应该是结合了软件开发生命周期模型的产品分解结构 (PBS)。PBS再结合项目管理过程,配置变更等支持过程……
编辑 | 阅读全文(3055) | 回复(0),人月&神话 发表于 2007-10-13 11:41

有了初步的项目范围,并委任了项目经理后可以进入到项目计划阶段,做项目计划过程仍然是目标驱动,树立系统观和关注各要素的平衡。因此首先需要确定项目的目标和项目的范围。

1.项目目标的来源和包含的内容

项目的目标不是无源之水,项目目标必须来源于组织的商业目标,而组织的商业目标就是在某个时间期限中获取最大的效益和利润。因此,有了商业目标驱动,项目目标应该包含进度,质量,成本三方面的目标,具体三方面的目标如何平衡即是通过组织期望获取价值和创造利益的过程是一个短期行为还是一个长期行为。

进度,质量,成本三方面的目标都会有一个最低限的目标,当发生最低限目标都无法满足的情况最有效的方式就是削减项目范围,如果范围也不能变动则必须提高项目团队的生产率。

项目目标根据商业目标确定,而项目目标确定后又驱动项目计划的具体制定过程,项目计划中关于进度,人力,资源,成本,质量等目标的安排都应该围绕项目目标进行。

2.项目目标的确定过程

首先必须搞清楚用户真正的需求和组织的商业目标,然后根据商业目标确定项目四要素中关键要素和约束(不能变动或变动范围很小的要素)。

对于其它可变要素间本来就会存在影响和相互制约,比如多投入项目成本可以获取到更好的产品质量。因此需要对各可变要素进行多种组合分析,分析在哪种组合下对于企业在某个时间期获取到最大收益是最有利的。

一个好的项目目标必须和企业商业目标一致,最终体现到项目创造的产品和服务能够为企业创造最大的价值和收益(包括潜在的无形收益)。

3.项目的范围

项目范围和产品范围不同,产品范围关注的是产品各阶段产出物本身以及整个包括了项目完成后维护的产品生命周期。而项目范围来源于产品范围,来源于产品需求和用户需求。通过对产品需求和用户需求的分析,根据选择的产品生命周期模型制作相关的WBS分解结构,前期需求文档或SOW工作说明书,加上WBS工作结构分解共同构成了项目的范围,也可以简单理解项目范围就……
编辑 | 阅读全文(3951) | 回复(5),人月&神话 发表于 2007-10-8 18:29
关键字:进度管理 关键链

原文:http://www.focusedperformance.com/ccfaq.html

01-什么是关键链

关键链是基于约束理论思维过程,为了解决项目交付的速度和可靠性难题而开发出的针对项目管理的一套过程和实践集合。关键链管理知识体系包括针对单独项目的关键链进度和缓冲管理,针对大型组合项目的跨项目资源协调。(关键链的一些基本概念和具体内容可以参考高德拉特博士的《关键链》一书)

决定关键链的依赖有两种,一种是任务本身的逻辑依赖关系,一种是资源依赖关系(一个任务的开始必须等待另外一个任务释放资源).关键链的确认使用了任务网络,而任务网络本身是基于积极进取但又可以达成的估算安排,这种估算安排首先就需要考虑资源的约束,而不是类似关键路径在后期进行资源平衡。如果使用传统的项目管理语言,关键链的结构类似于考虑了资源约束的关键路径。

02-为何要使用关键链,它能够带给项目团队什么

基于关键链项目管理最大的不同在于关键链对偏差影响的重视,以及对人员行为分析的应对,而这些正有利于提高项目按时完成和可靠性能力。虽然我们已经建立了对于项目管理偏差的思考方法,例如计划评审技术PERT和蒙特卡洛模拟,但是这些技术结果的过多应用使得帕金森定律在多数项目中长期存在。关键链的一个独一无二的特征,关于如何应对偏差的影响,是通过预留缓冲。这些缓冲的作用是保护关键链不受非关键链上任务的影响,特别是有助于保证关键链真正关键。

03-什么是缓冲

缓冲是安排在项目进度表中的一系列时间和规模片断以保护对项目成功而言最重要的资源或任务。项目缓冲有助于保护关键链上的任务不出现偏差。预留缓冲有利于保护关键链上任务类似于接力赛的运行能力,这些缓冲一方面是安排在了非关键链任务分支的末端,或者是和关键链缓冲合并。

当预留了合适大小的缓冲后,对于需要依赖非关键链上任务的关键链任务就可以尽早开始,只要所有的前导任务都提前完成了。

能力缓冲是应用……
编辑 | 阅读全文(3172) | 回复(5),人月&神话 发表于 2007-10-8 18:28
根据许江林老师的IT项目管理最佳历程培训大纲,对我Blog上关于IT项目管理的相关文章进行分类汇总如下:
 
[一]组织中的项目管理
 
1. 组织中项目管理职能如何设置(PMO,组合项目管理)
2. 项目管理办公室的职能介绍(PMO,组合项目管理)
3. 项目经理技能要求

 
项目经理技能评估初稿
项目管理知识体系结构

[二]定义阶段

 
1.项目论证过程概述
IT项目管理-启动-项目立项
 
2.项目目标包含哪些方面
3.如何才是一个合格的项目目标
4.项目目标确定的过程
5.项目章程发布和项目经理的任命
 
[三]计划阶段
 
IT项目管理过程-计划阶段
IT项目管理过程-项目计划思维导图
IT项目管理中的假设约束依赖和承诺
项目管理的艺术-平衡(读书笔记1)
 
1. 组建初始项目团队编制项目管理计划
2. 项目生命周期模型的选择和使用
IT项目管理过程-方法,工具和技术
谈软件生命周期模型和选择
软件开发生命周期各阶段活动和依赖
 
3. 结构化的项目范围说明书
4. 项目工作分解结构图和分解技术
5. 项目网络图和项目进度计划编制
受资源约束的进度计划调整
再看关键链进度计划
培养做项目进度计划的系统观
软件项目计划-估算杂谈
 
6. 项目人力资源计划编制OBS和WBS的对照
7. 项目预算分析和项目S曲线编制
8. 案例分析:STAR项目范围计划/进度计划/成本计划编制和分析
9. 项目关系人分析和项目沟通计划编制
IT项目管理-启动-干系人分析
 
10.项目风险识别/风险分析和风险应对计划编制
管理软件开发项目关键风险
IT项目管理中组合风险量化分析
PMBOK风险管理知识总结
 
11.项目管理计划(PMP)的整合、评审和发布
 
[四]执行阶段
 
1.项目团队管理
IT项目管理过程-以人为本
项目管理过程中的团队建设
再谈IT……
编辑 | 阅读全文(2379) | 回复(2),人月&神话 发表于 2007-10-8 18:26
关键字:IT项目经理

基础参考:http://blog.sina.com.cn/s/blog_493a8455010008v4.html

关键链是什么?关键链是考虑了缓冲和资源约束而找寻到的项目关键路径。因此谈关键链则重点始终脱离不了缓冲和资源约束两个重点。

1.缓冲和风险意识

考虑缓冲正是具有强烈的风险意识的体现。为何要考虑接驳缓冲?因为都知道在路径汇聚处具有最大的风险,任何一个路径的延误都将导致整个项目的延误。同理,为何要考虑关键路径上的项目缓冲?因为关键路径上的任何一点延误都将导致项目延误。

任何一个任务,及时前期的估算再准确,也存在着是否能够按时完成的风险。预留缓冲正是为了缓解和应对这种风险。

预留缓冲很重要,而且缓冲必须要留在任务链和分支路径的末尾。这里比较重要的是缓冲是如何预留出来的?一种方法是压缩任务本身的工时,另外一种方法是让不 受依赖和资源约束的任务尽可能早的开始。在这里并不推荐过多使用第一种方法,如果第一种方法有效往往说明我们的估算太粗,或者估算留的余地太大,在这种情 况下应该去改进估算。在估算准确的情况下还过多采用压缩工时的方法往往是造成赶工无法保证真正的产出物质量。

2.资源约束和TOC

个人认为关键链真正的价值还是在TOC和资源约束。因为缓冲的考虑本身并不是对关键路径进度计划的否定,只是一个扩展和完善,在关键路径进度计划中,我们 也会考虑预留相关的进度储备。关键路径真正无法解决的问题还是在资源约束场景下进度计划的安排,因为在这种场景下关键路径方法本身是无效的,根据理论公式 计算出的关键路径无法真正体现项目周期。

高德拉特是关键链理论的创始人,同时也是TOC约束理论的创始人。TOC关注的是目标,资源和约束,通过这些要素来建立相关的目标,通过运筹学线性规划和组合最优化的方法来寻求最佳解和满意解。

什么时候项目网络图中存在资源约束?一种情况是……
编辑 | 阅读全文(1885) | 回复(1),人月&神话 发表于 2007-10-3 11:25
关键字:项目管理

PMThink! from Jerry Manas, Frank M, Garry B, FemPM, G McHardy and R J Goodman
Project Management Thought Leadership

Reforming Project Management from Hal Macomber
项目管理时代杂志


The Berkun Blog from Scott Berkun, author of The Art of Project Management and The Myths of Innovation
创造性,革新和人员管理。项目管理艺术一书的作者。


ProjectSteps from Stephen Seay
Tips, hints, links, and helpful information related to the discipline of Project Management.


projectified from Brian Kennemer
endlessly obsessing about Project Server so that you don't have to


Eclectic Bill from Bill Brantley
项目管理,知识管理,变更管理,学习型组织,思维模型,TOC约束理论


4PM: Project Management Tools, Techniques & Best Practices from Dick Billows
项目管理和大项目管理工具和技术,文章和视频。

Herding Cats from Glen Alle……
编辑 | 阅读全文(2919) | 回复(3),人月&神话 发表于 2007-10-2 20:56

摘录自林锐博士《软件和互联网企业研发管理问题分析和对策》相关ppt

1.组织结构和人力资源管理
 
职能型还是矩阵型,项目经理和职能经理的交叉管理和平衡。
多头领导,能干的人都搞管理去了(彼得原理)。
岗位,角色,职责不清楚,而且经常发生变动。
缺乏竞争和激励机制
营销、研发、服务没有很好衔接。(产品生命周期管理,IPD思路)

2.产品生命周期问题

不清楚“产品生命周期”和“项目生命周期”之间的关系,不清楚产品管理和项目管理的区别与联系。(项目目标也是根据商业目标和产品定义确定的,最终创造价值的是产品,项目生命周期仅仅是产品生命周期中的一个阶段)
 
缺乏“产品生命周期阶段划分和决策评审”的详细操作指导书,不能有效地开展决策评审和技术评审。
 
大型企业内部可能有一些机构在推行ISO9000, CMMI, PACE, RUP等方法,越做越复杂,难以产生广泛认同、简单有效的思想方法,难以提高管理效率。(流程,过程,规范,集成产品研发各自作用在哪里?最终都要体现到创造效益上)
不清楚“软件配置管理”、“文档管理”和“BOM表管理”的区别和联系,甚至错误地使用工具。

3.项目管理问题

3.1 立项管理问题

自主研发项目:缺乏“调研,可行性分析,立项建议,决策评审”,主要靠公司领导独断,团队只知道干活,却不了解产品的开发背景,不清楚用户期望的产品应该是什么样的。在开发过程中经常迷失方向,导致进度延误、费用超支等问题。
合同项目:需求不清晰、合同内容空洞;双方在签订合同的过程中给出了一些空头承诺(例如对进度、质量、费用的估计过于乐观),在实际执行时却难以兑现这些承……
编辑 | 阅读全文(2057) | 回复(0),人月&神话 发表于 2007-10-2 20:52
(共 973 条) 1 2 ... 7 8 9 10 11 ... 64 65 翻页至

仅列出标题