软件项目管理原则(转)

原创 2004年08月18日 11:16:00

汤姆.迪马可的《最后期限》是本好书。书中主人公汤普金斯先生在管理生活中不断地进行总结记录,共积累了111条关于软件项目管理的原则。现将其摘录出来与大家分享。
1、 优质管理的四大要素:
  1) 选择正确的人
  2) 为他们分配正确的工作
  3) 保持他们的积极性
  4) 帮助团队凝聚起来并保持团队的凝聚力
   (其它一切都只是“文案”)
2、 安全和变化
  1) 除非感到安全,否则人们就不能去迎接变化
  2) 在所有成功的工作中(以及在绝大多数其它有价值的工作中),变化都是基本的要素之一
  3) 安全感的缺乏会让人们反对变化
  4) 逃避风险是致命的,因为这会让你也得不到与风险同在的利益
  5) 人们可能会因为来自客观世界的直接的恐吓而觉得没有安全感,但是如果察觉到管理者可能滥用权力来惩罚自己,他们也会觉得没有安全感
3、 负面效应
  1) 威胁不是提高业绩最好的方法
  2) 如果分配的时间一开始就不够,不管威胁有多么吓人,工作也无法完成
  3) 更糟糕的是,如果目标没有实现,你就必须兑现你的威胁
4、 管理者必需的身体部位
  1) 管理涉及到心、肠胃、灵魂和鼻子
  2) 因此……
    用心来领导
    相信你的肠胃(相信你的预感)
    构筑团队的灵魂
    训练一个能嗅出谎言的鼻子
5、 用指挥战争作为管理的一个比喻
  1) 在战役开始的时候,管理者真正的工作已经完成了
6、 面试和招聘
  1) 招聘涉及到所有与管理相关的身体部位:心、灵魂、鼻子和肠胃(但主要是肠胃)
  2) 不要试图单独去招聘----两副肠胃远比一副肠胃的两倍要好
  3) 对于新的雇员,让他们承担与以前曾经成功过的同样的难度的项目,把有挑战性的目标推迟到下一次
  4) 征求提示:你最希望雇的那个人可能还知道其它很好的人选
  5) 多听,少说
  6) 如果先把材料准备好,那么所有的事情都会进行得更好
7、 生产力的提高
  1) 没有“短期生产力提高”这样的东西
  2) 生产力的提高是来自长期投资的
  3) 任何承诺立刻见效的东西都可能是江湖游医所卖的万灵油
8、 风险控制
  1) 通过控制风险来管理项目
  2) 为每个项目创建并维护风险统计表
  3) 跟踪根源性的风险,而不只是最后的那讨厌的结果。
  4) 评估每种风险具体化的概率和可能造成的开销
  5) 对于每种风险,预测标志其具体化的早期征兆
  6) 任命一个风险控制官,这个人不应该维护组织内部“我能行”的态度
  7) 建立简单的(可能是匿名的)通道,让坏消息能传递到高层
9、 防止失败
  1) 壮士断腕
  2) 控制住失败比优化成功更能提高你的全面成绩
  3) 要有闯劲,尽早取消失败的工作
  4) 除非必要,否则就不要自己去凝聚一个团队:出去找一个已经成型的团队来用
  5) 保持好的团队在一起(只要他们自己愿意),以帮助你的继任者避免团队凝聚得慢或者不能凝聚的问题
  6) 把凝聚在一起的团队----准备充分、并且也愿意接受新的工作----作为项目的收获之一
  7) 项目开始时浪费的一天和最后阶段浪费的一天对项目造成的伤害是同等的
  8) 有无数种方法可以浪费一天的时间……但是没有任何一种方法可以拿回一天的时间
10、 开发过程的建模和模拟
  1) 将你关于完成工作过程的直觉建模
  2) 在同事的交流中使用这些模型,以便交流、提炼关于项目运转的思想
  3) 用模型来模拟项目的结果
  4) 根据实际的结果来调整模型
11、 “病态的政治”
  1) 第一天,都必须准备拿自己的工作去打赌……
  2) ……但是这也不能保证“病态的政治”不会影响你
  3) “病态的政治”可能在任何地方出现,哪怕是在最健康的组织里面
  4) “病态的政治”的特征:对个人权势的渴望超过了组织本身的目标
  5) 即使这种不合理的目标与组织的目标背道而驰,它也可能出现
  6) “病态的政治”最恶劣的副作用:它使精简项目变得危险
  7) 别想根治一个病态的人
  8) 不要浪费时间,也不要因为尝试治疗上司的病态而使自己受到威胁
  9) 有时候,你惟一的选择就是等待,等问题自己解决,或者等一个让你继续前进的机会
  10) 奇迹是有可能发生的(但是千百万别去指望它)
12、 度量
  1) 度量每个产品的规模
  2) 不要执著于单位----在等待客观度量的时候,先用你自己的主观单位
  3) 从所有能得到的原始数据(可计算的软件特征)自己构造度量单位
  4) 从已经完成的项目中收集原始数据,以推导出生产力趋向
  5) 不断完善你的度量方程式,直到它的计算结果与原始数据库中的项目工作量有最好的对应关系
  6) 借助数据库画一条趋势线,把预期工作量作为人造度量单位值的函数显示出来
  7) 现在,针对每个要评估的项目,计算出人造度量的单位值,并根据度量值在趋势线上找到预期工作量值
  8) 用生产力趋势周围的干扰水平作为映射的公差指示
13、 过程和过程改进
  1) 好的过程和持续的过程改进是绝好的目标
  2) 它们也是非常自然的目标:优秀的技术工作者一定会关注它们,不管你是否告诉他们
  3) 正式的过程改进程序需要花钱、花时间;特定的过程改进工作还会延缓项目进度。尽管最终会体现出生产力上的收获,它们也不可能抵消花在过程改进上的时间
  4) 但是,项目有希望从单个的、正确选择的方法改进中得到足够的收益,并赢回为这次改变付出的时间和金钱
  5) 在项目进行的过程中,不要希望在超过一个方法的范围内实施改进。多种技术的改进程序(比如说提高整整一个CMM等级)很可能让项目比不实施这些程序完成得更晚
  6) 标准过程的危险就在于人们可能失去重要的走捷径的机会
  7) 特别是对于人员超编的项目,标准过程看上去会很严谨,因为它们制造出了足够的工作(有用的和无用的),让所有人都忙碌不停
14、 改变完成工作的方式
  1) 如果不大幅度减少调试的时间,就没办法让项目大幅度提前完成
  2) 高速完成的项目用在调试上的时间也成比例地少得多
  3) 高速完成的项目用在设计上的时间也成比例的多得多
  4) 如果你不关心别人,不照顾别人,就别想让他们为你做一些不同寻常的事情。如果要让他们改变,就必须去了解(并赞赏)他们的过去
15、 压力的效果
  1) 压力之下的人无法更快地思考
  2) 增加加班时间只会降低生产力
  3) 短期的压力乃至于加班可能是有用的策略,因为它们能使员工集中精力,并且让他们感到工作的重要性。但是长时间的压力肯定是错误的
  4) 经理之所以会施加那么多的压力,也许是因为他们不知道该做什么,或者因为其它办法的困难而感到气馁
  5) 最坏的猜测:使用压力和加班的真正原因是为在项目失败的时候让所有人看上去能好一点
16、 愤怒的经理
  1) 管理中的愤怒和羞辱是会传递的。如果高级管理者喜欢骂人,低级管理者也会有样学样(就像经常被骂的小孩很容易变成骂人的父母)
  2) 管理中的辱骂被认为是一种刺激,可以让员工提高效率。在“胡萝卜加大棒”的管理策略中,辱骂是最常见的“大棒”。但是,哪有人被辱骂之后还能做得更好呢?
  3) 如果经理使用辱骂的方法来刺激员工,这就表现出经理的无能,而不是员工的无能
17、 含糊的规格文档
  1) 规格文档中的含糊标志着不同的系统参与者之间存在着未解决的冲突
  2) 如果一份规格文档不包含完整的输入输出列表,那么它就是毫无希望的:它根本就还没开始说明任何东西
  3) 没有人会告诉你一份规格文档是不是糟糕。人们往往倾向于责备自己,而不是责备文档
18、 冲突
  1) 只要在开发过程中有多个参与者,就一定会有冲突存在
  2) 创建、安装系统的业务中特别容易出现冲突
  3) 绝大多数系统开发团队都缺乏解决冲突的能力
  4) 冲突应当引起重视。冲突并不是缺乏职业道德的行为
  5) 应当提前声明:所有人的‘赢’都是受重视的。确保每个级别的人都能赢。
  6) 谈判困难;调解容易
  7) 如果两个人的利益是完成或者部分相斥的,预先做好安排,准备好请双方通过调解来解决冲突
  8) 记住:我们都站在同一边;跟我们对立的,是我们要解决的问题
19、 催化剂的角色
  1) 有这样一种催化剂式的人格。这样的人会帮助团队成型并凝聚,保持团队的健康和生产力,从而对项目作出贡献。就算“催化剂”别的什么事情都不干(其实,通常他们还会干很多别的事),这种催化剂的角色也是重要和有价值的
  2) 调解是“催化剂”的一项特殊工作。调解是可以学的,而且只需要很小的投资就能学会
  3) 调解应该从一个小小仪式开始。“我能帮你们调解一下吗?”在解决冲突的时候,这是必要的第一个步骤
20、 人类的错误
  1) 将你置于死地的,不是你不知道的东西……而正是你“知道”他不会置你于死地的东西
21、 人员安排
  1) 在早期,人员超编会迫使项目跨过关键的设计阶段(这是为了让所有的人都有事可做)
  2) 如果在设计完成之前,工作先被分给许多人,那么人与人之间、工作组之间的接口就会很复杂
  3) 这会使团队内部耦合度提高,会议时间、重复劳动和无效工作都会增加
  4) 理想的人员安排是这样:在项目的大部分时间里由小型核心团队来做设计工作,在开发的最后阶段(时间安排的最后1/6)加入大量的人手
  5) 可怕的猜想:时间安排紧迫的项目,与时间安排比较合理的项目比起来,完成的时间反而会更长
22、 项目社会学
  1) 让不必与会的人可以放心的离开,从而保持会议的精简。有一份公开的议程,并严格的执行,这是最简单的办法
  2) 项目需要仪式
  3) 用小小的仪式来使人们注意项目的目标和理想状态:小规模会议、零缺陷工作等等
  4) 采取行动,防止人们随便发怒
  5) 记住:愤怒=恐惧。随便对下级发怒的人经理一定是因为恐惧才会这样做的
  6) 意见:如果所有人都懂得“愤怒=恐惧”这个道理,就能明显地看出发怒的人是在害怕。由于无法再隐瞒自己的恐惧,他也就不会再生气了。(这不是能解决这些生气的人的问题,但是肯定可以让其他人好受一些。)
23、 精兵简政
  1) 精兵简政是失败的公司使用的办法,它让员工负担失败的责任
  2) 公司的目标应该正好相反:兴旺而人性化
  3) 当你听到“精兵简政”这个词的时候,请记住它的弦外之音:失败和恐吓
24、 基本常识
  1) 项目既需要目标,也需要计划
  2) 而且这两者应该不同

在软件开发中应用80:20原则

本文来源于我在InfoQ中文站原创的文章,原文地址是:http://www.infoq.com/cn/news/2013/11/80-20-rules-software-devJim Bird是一位经...
  • ricohzhanglong
  • ricohzhanglong
  • 2013年11月19日 23:53
  • 3156

项目管理 软件版本号的命名格式和规则

最近公司发布测试版,涉及软件的版本号管理,发现不同公司的版本号管理的方法都不一样,各有千秋。在这里展示个人认为还不 错的版本号管理的方法。 【1】版本命名规范 软件版本号有四部分...
  • aoshilang2249
  • aoshilang2249
  • 2014年11月03日 19:54
  • 2571

详解软件项目管理流程的每一步

一、项目启动(项目开工会) 了解项目干系人及其利害关系。 所有项目组成员是否到位,如到位则拿到项目开发人员的简历,详细了解每个开发人员的情况(可能会组织到客户方面试)。 根据项目需求...
  • u012576527
  • u012576527
  • 2016年08月28日 08:03
  • 3536

鲜为人知的软件项目管理原则

转自:http://home.cnblogs.com/group/topic/5049.html   软件开发的残酷的现实告诉我们:没有规则的软件开发过程带来的只可能是无法预料的结果。我们中的大多数项...
  • w5q7c3
  • w5q7c3
  • 2011年01月05日 10:01
  • 1177

鲜为人知的软件项目管理原则(转载)

软件开发的残酷的现实告诉我们:没有规则的软件开发过程带来的只可能是无法预料的结果。我们中的大多数项目管理人员在其个人简历中纷纷写到:"拥有多年的丰富的项目管理经验",但在实际开发中,"丰富的"管理经验...
  • SmartDevice
  • SmartDevice
  • 2011年02月21日 11:05
  • 400

软件项目管理的成功原则

在我们讨论软件项目为什么会失败时可以列出了很多的原因,答案有很多,如管理问题、技术问题、人员问题等等,但是有一个根本的思想问题是最容易忽视的,也是软件系统的用户、软件开发商、销售代理商最不想正视的,那...
  • bingyu9875
  • bingyu9875
  • 2015年11月16日 15:11
  • 418

管理理念:软件项目管理原则谈

软件项目管理原则谈      软件开发的残酷的现实告诉我们:没有规则的软件开发过程带来的只可能是无法预料的结果。我们中的大多数项目管理人员在其个人简历中纷纷写到:“拥有多年的丰富的项目管理经验”,但在...
  • lanyd
  • lanyd
  • 2011年06月28日 09:50
  • 1543

鲜为人知的软件项目管理原则

  • 2012年02月25日 08:50
  • 36KB
  • 下载

了解编程的心理 谈谈软件项目管理的重要性 (转)

关键词: 了解编程的心理    谈谈软件项目管理的重要性    (转)                                           了解编程的心理 原著...
  • ljafl9988
  • ljafl9988
  • 2012年06月03日 22:32
  • 3242

【转】从软件项目管理角度读——Steve Jobs

“不是杰作,就是狗屎!” 本人一向不喜欢阅读比砖头厚的书。但是,这几周每天早上在班车上或晚上回家吃过晚饭,都迫不及待的拿起《Steve Jobs》这本比转头还厚的书。刚开始看的时候,觉得不过就是...
  • view1221
  • view1221
  • 2012年10月14日 13:20
  • 336
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:软件项目管理原则(转)
举报原因:
原因补充:

(最多只允许输入30个字)