您的位置:首页 > 其它

最后期限——项目管理108

2006-03-30 13:37 134 查看
优质管理的四大要素:
选择正确的人。
为他们分配正确的工作。
保持他们的积极性。
帮助团队凝聚起来并保持团队的凝聚力。(其它一切都只是“文案”。)

安全和变化
除非感到安全,否则人们就不能去迎接变化。
在所有成功的工程中(以及在绝大多数其他有价值的工作中),变化都是基本的要素之一。
安全感的缺乏会让人们反对变化。
逃避风险是致命的,因为这会让你也得不到与风险同在的利益。
人们可能会因为来自客观世界的直接的恐吓而觉得没有安全感,但是如果察觉到管理者可能滥用权力来惩罚自己,他们也会觉得没有安全感。
负面效应
威胁不是提高业绩最好的方法。
如果分配的时间一开始就不够,不管威胁有多么吓人,工作也无法按时完成。
更糟糕的是,如果目标没有实现,你就必须兑现你的威胁。

管理者必需的身体部位
管理涉及到心、肠胃、灵魂和鼻子。
因此……用心来领导,相信你的肠胃(相信你的预感),构筑团队的灵魂,训练一个能嗅出谎言的鼻子。
用指挥战争来作为管理的一个比喻;在战役开始的时候,管理者真正的工作已经完成了。
面试和招聘;
招聘涉及到所有与管理相关的身体部位:心、灵魂、鼻子和肠胃(但是主要是肠胃)。
不要试图单独去招聘——两副肠胃远比一副肠胃的两倍要好。
对于新的雇员,让他们承担与以前曾经成功过的同样难度的项目,把有挑战性的目标推迟到下一次。
征求提示; 你最希望雇的那个人可能还知道其他很好的人选。
多听,少说。
如果先把材料整理好,那么所有的事情都会进行得更好。
生产力的提高
没有“短期生产力提高”这样的东西。
生产力的提高是来自长期投资的。
任何承诺立刻见效的东西都很可能是江湖游医所卖的万灵油。

风险控制
通过控制风险来管理项目。
为每个项目创建并维护风险统计表。
跟踪根源性的风险,而不只是最后那讨厌的结果。
评估每种风险具体化的概率和可能造成的开销。
对于每种风险,预测标志其具体化的早期征兆。
任命一个风险控制官,这个人不应该维护组织内部“我能行”的态度。
建立简单的(可能是匿名的)通道,让坏消息能传递到高层。

防止失败
壮士断腕。
控制住失败比优化成功更能提高你全面的成绩。
要有闯劲,尽早取消失败的工作。
除非必要,否则就不要自己去凝聚一个团队:出去找一个已经成型的团队来用。
保持好的团队在一起(只要他们自己愿意),以帮助你的继任者避免团队凝聚得慢或者不能凝聚的问题。
把凝聚在一起的团队——准备好、并且也愿意接受新的工作——作为项目的收获之一。
项目开始时浪费的一天和最后阶段浪费的一天对项目造成的伤害是同等的。
有无数种方法可以浪费一天的时间……但是没有任何一种方法可以拿回一天的时间。

开发过程的建模和模拟
将你关于完成工作过程的直觉建模。
在同事的交流中使用这些模型,以便交流、提炼关于项目运转的思想。
用模型来模拟项目的结果。
根据实际的结果来调整模型。

度量
度量每个产品的规模
不要执著于单位——在等待客观度量的时候,先用你自己的主观单位
从所能得到的所有原始数据(可计算的软件特性)自己构造度量单位
从已经完成项目中收集原始数据,以推导出生产力
借助数据库画出一条趋势线,把预期工作量作为人造度量值的函数显示出来
现在,针对每个评估项目,计算出人造度量单位值,并根据这个值在趋势线上找大预期工作量值
用生产力趋势周围的干扰水平作为影射的标示

过程和过程改进
好的过程和持续的过程改进是绝好的目标
他们也是非常好的目标,优秀的技术工作者一定会关注他们,不管你是否告诉他们
正式的过程改进程序常需要花钱、花时间;特定的过程改进工作拖延项目进度。尽管最终会体现生产力上的收获,它们也不可能抵消花在过程改进上的时间。
但是,项目有希望从单个的、正确选择的方法改进中得到足够的收益,并赢回这次过程改进的时间和金钱。
在项目进行的过程中,不要希望在超过一个方法的范围内实施改进。多中技术的改进程序很可能让项目不实施这些程序完成得更晚。
标准过程的饿危险就在于人们可能失去重要的走捷径的机会。
特别是对于人员超编的项目,标准过程看上去会很严谨,因为他们制造出了足够的工作,让所有人都忙碌不停。

改变完成工作的方式:
如果不大幅度减少调试的时间,就没有办法让项目大幅度提前完成。
高速完成的项目用在调试上的时间也成比例地少得多。
高速完成的项目用在设计上的时间也成比例地多得多。
提摸你你关心别人,不照顾别人,就别想让他们为你做一些不同寻常的事情。如果要让他们改变,就必须去了解并赞赏他们的过去。

压力的效果:
压力下的人无法更快地思考。
增加加班时间只会降低生产力。
短期的压力乃至于加班可能是有用的策略,因为他们能是员工集中经理,并且让他们感到工作的饿重要性,但长期的压力肯定是错误的。
经理之所以会施加那么多的压力,月许是因为他们不知道该做什么,或者因为其他办法的困难而感到气馁。
最坏的猜测是:用压力和加班的真正原因是为了在项目失败的时候让所有人看上去能好一点。

含糊的规格文档
规格文档中的含糊隐含着不同的系统参与者之间存在着未解决的冲突。
如果一份规格文档不包含完整的输入输出列表,那么它就是毫无希望的,它根本就没开始说明任何东西。
没有人会告诉你一份规格文档是不是糟糕,人民往往倾向于责备自己,而不是责备文档。

冲突
只要在开发过程中有多个参与者,就一定会有冲突存在。
创建、安装系统业务中特别容易出现冲突。
绝大多数系统开发团队都缺乏解决冲突的能力。
冲突应当引起重视。冲突并不是缺乏职业道德的行为。
应当提前申明:所有人的‘赢‘都是受重视的,确保每个级别的人都能赢。
谈判困难;调解容易。
如果两个人的利益是完全或者部分互斥的,预先最好安排,准备好请双方通过调解来解决冲突。
记住:我们都站在同一边;跟我们对立的,是我们要解决的问题。

人类的错误
将你置于死地的,不是你不知道的东西,而正是你知道绝不会置你于死地的东西。

人员安排
在早期,人员超编会迫使项目跨过关键的设计阶段(这是为了染个所有的人有事可做)。
如果在设计完成之前,工作先被分给了很多人,那么人与人之间、工作组之间的接口就回很乱套。
这会是团队内部偶合度提高,会议时间、重复劳动和无效工作都会增加。
理想的人员安排是这样:在项目的大部分时间里由小型核心团队来做设计工作,在开发的最后阶段加入大量的人手。
可怕的猜想:时间安排紧迫的项目,与时间按比较合理的项目比起来,完成的时间反而会更长。

项目的社会学
让不必与会的人可以放心离开,从而保证会议的精简。有一份公开的议程,并严格执行,这是最简单的办法。
项目需要仪式。
用小小的仪式来使人们注意项目的目标和理想状态,小规模会议、零缺陷工作等等。
采取行动,防止人们随便发怒。
记住:愤怒=恐惧。随便对下级发怒的经理一定是因为恐惧才回这样做的。
意见:如果所有人都懂得“愤怒=恐惧”这个道理,就能明显地看出发怒的人是在害怕。由于无法再隐瞒自己的恐惧,他就不会再生气了。

精兵简政
精兵简政是失败的公司使用的办法。它让员工负担失败的责任。
公司的目标应该正好相反:兴旺而人性化。
当你听到“精兵简政”这个词的时候,请记住它的弦外之音:失败和恐吓。

基本常识
项目既需要目标,也需要计划。
而且这两者不一样。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: