项目百态 深入理解软件项目行为模式--精选摘要

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接: https://blog.csdn.net/weixin_35933684/article/details/101012332

1、接受超出团队处理范围的工作是管理层怯懦的表现。为了避免个人遭受指责,却亲手把团队置于不可能成功的境地之中。最终,团队会饱受超负荷工作之苦,在组织里面受到的尊重度下降,就因为你没有勇气在第一时间说“不”。怎么做才能逆转这种恶性循环呢?给工作任务排定优先级,只做你最大能力范围之内的事情。把低价值的工作放在一边,先完成高价值的工作。

承担超出最大能力范围的工作是变得迟缓的罪魁祸首。

模式 39 巨神阿特拉斯

如果项目团队leader事无巨细,看似项目如火如荼,健康积极,实则leader的离职会对团队造成致命打击。

2、关键是团队在项目的整个过程中应用广度与深度研究技巧的能力。研究的广度范围识别出可能会对项目产生影响的人、组织、硬件和软件系统。在广度上知晓得越多,就越能识别出高风险与高收益的领域,以及如果辅以进一步的深度研究可能大有裨益的领域。

3、刻意隐瞒坏消息可能使得可解决的问题变成无法解决的问题

4、指出问题,却又不立刻提出改进措施——这会被认为是在发牢骚。而在很多组织里面,发牢骚者的职业生涯是有限的。

5、把自己的问题隐藏在其他人的问题之后,这种人有时被称为“进度胆小鬼”(Schedule Chicken)。

6、在一些组织里面,任何批评都被认为是针对个人的,因而视作是禁忌。批评变得委婉,变成各种含蓄的说辞,比如述评或者评估。任何缺少“做得漂亮,哈尔”之类的述评会让房间里的每个人都觉得不快。这种滥用礼貌的结果就是严重的平庸。工作无法得到真正的改善,

7、往已经延误的软件项目中添加人手,会使项目更加延误。” 添加人手,既消耗了项目的日程时间,又消耗了项目上成员的精力。在项目活动的后期添加人手对按时交付很少有帮助。如果一定要说它会给项目带来什么,或许就是延误吧。

8、一起吃饭并不能保证你的团队就会成功,就像不在一起吃饭也无法得出项目必然失败的结论一样。然而,我们观察到很多成功的团队喜欢一同准备和食用食物,他们恰恰利用了这一过程中丰富的互动机会。

未完待续。。。

猜你喜欢

转载自blog.csdn.net/weixin_35933684/article/details/101012332