《最后期限》书评

当前位置:首页 > 管理 > > 最后期限

出版社:清华大学出版社
出版日期:2002-12-1
ISBN:9787302060864
作者:汤姆・迪马可
页数:314页

转载:NOTES

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

小心小说里的陷阱

这本书的主旨是不错,值5星。但要小心这本书也是小说,只是强调了人的作用,不能简单照搬到实际工作中。

屌丝程序员打怪升级的经典意淫小说

屌丝程序员打怪升级的经典意淫小说尤其是结尾部分。。。“说你答应,韦伯斯特,请答应吧。我会非常高兴的。”他停了一会儿,盯着她说:“请等一分钟。”这一次,如果得不到他想要的。他绝不再让步。他换上最严厉的表情:“告诉我。莱克莎,你给自己选择的角色是什么?”第一次,她显得不自信了。她咬着嘴唇:“我……”“告诉我。菜克莎。”她低头看着地板。“我还没想过。”她轻声说道。“好吧,那就让我来告诉你。我给你准备了一个角色,你必须接受——否则我转身就走。”她还是不看他:“你给我什么角色,韦伯斯特?”他让自己平静一下,然后说道:“元首助理和夫人。”“噢,韦伯斯特,我还以为你永远不会问呢。”“嗯?”“我同意,我愿意,我接受。”“好。”他四下看看,“那么,我们现在该去哪儿?”“王室套间。”她说逋,朝着一扇华美的门点头示意,“就在那边。”他把她抱起来,朝他们的新生活走去。

软件开发,人的管理

——书评《最后期限》Windy   记得有一段时间,我迷上了UFO,神秘文明,四维空间等等,走在路上,周围一个人也没有的时候,经常会担心:我会不会一不小心走进四维空间,然后发生很多奇怪的事,走出来的时候几十年过去了,大家都不认识我了?  虽然这样的事一次都没有发生过,后来也慢慢淡忘了,但是当我看到《最后期限》的开头汤普金斯先生的奇遇,就忍不住瞪大了眼睛:失业的时候被美女绑架,获得一份不可思议的工作,去了一个风景如画的世外桃源,在那里会发生一些什么样的故事呢,唔,想想就令人向往……  如何对软件开发团队进行管理,显然是这本书想要阐述的核心,在小说里,汤普金斯对此有着独到的见解:选择正确的人,为他们分配正确的工作,保持他们的积极性,帮助团队凝聚起来并保持他们的凝聚力。这里,最重要的是人,和团队,而不是许多冗长枯燥的管理课程中讲述的那些"文案":甘特图,波特图,状态报告,交流规范,会议计划,时间卡,进度跟踪记录,项目里程碑报告,质量管理程序……那不是管理,管理是人性的。  选择正确的人,那么人员招聘是重要的,汤普金斯开始挑选他的项目经理和管理人员,什么样的人适合当项目经理呢?是那些尊重团队,重视团队,重视团队成员的人,一个候选人为他的团队创造最好的工作环境,一个候选人高度赞扬自己的团队并保持团队的完整性,一个候选人采用半匿名的机制听取下属的意见,马可夫准将极力保持下属的积极性;而那个认为自己才是团队灵魂,成员都是步兵的"巴顿将军崇拜者",他在招聘中落选了。  项目经理是人,团队成员是人,保护你的团队,不要让他们受到外来的伤害,这也是管理的重要内容,于是汤普金斯遇到了象贝洛克部长那样的人,他不了解软件开发,不了解项目进展,也不关心项目团队,他只会说,我花在你们身上的成本是多少多少,因此你们要加班加点,发布产品的日期要提前,你们要提交项目报告,你们要进行过程改进。这是命令,不是管理。在这样的压力下,汤普金斯仍然坚持保护他的团队,把他们藏到7号楼,为他们保证良好的工作环境,不必遵循死板的过程,隔离压力。通过"先贤"的邮件,他回答了我们这个问题:  n 为什么对程序员的压力最多只能6%的生产力提升呢?  n 压力下的人不能更快地思考。  我们始终不能忘记,程序员也是人,当我们在以往的项目中遇到各种各样的问题,客户的需求频繁变动,来自领导、客户、销售人员要求尽快结束项目的压力,用一拥而上的方式增加人手,计划延迟,工期变长,漫长的维护过程,乃至长期出差驻守在外地,离开家人,这个时候,没有成就感和疲惫的感觉会让最好的程序员失去热情。在这里要提到的是,曾经有个项目工期太长,每个周一都要出差去外地,在那段时间里,我甚至得了"周日晚上失眠(恐惧)症",噢,可怜的程序员们,你们是否也有过类似的经历?好的管理还会对团队内部发生的冲突进行调解:发生冲突的时候"谈判困难,调解容易","记住,我们都站在同一边;跟我们对立的,是我们要解决的问题"。并且,当团队或成员遇到困难的时候,管理者需要解除他们的困苦,"A团队的奥斯曼忍受不了压力啦!""当我告诉他再也不必做经理的时候,你真该看看他的脸。那一刻,他就象年轻了好几岁……",把他们从无关的会议中解放出来:"我觉得他们来开这个会是没有意义的……所以,我让他们三个离开。"  在摩罗维亚的日子里,发生着一个又一个生动而又真实的小故事,汤普金斯一直在忙着为他的团队解决问题,在每天的日记里总结着他在软件开发管理中得到的经验,虽然他的A团队都失败了,但B和C团队都完成了"不可能完成的任务",不能不说,这是一种非常乐观的态度,但,是不是我们多重视一下项目中的团队,项目中的人,就会离成功近一点?如果没有方法,没有工具可以成为解决软件工程问题的"银弹",那么关键是否在于项目实施中的人?稍稍有点遗憾的是,书中没有描述团队的具体细节,例如,他们坐在哪里,工作的过程,或者,有个程序员完成了工作,他就会快乐地唱起歌来,没有看到这些。当然,对于这些细节和可具体操作的方法,在《人件》里面有更详细的介绍。  书中还有其他很多有价值的观点,例如功能点,度量,为直觉建模等等,当我躺在床上,用午睡的时间一口气读完以后,不能不说,这实在是一次心旷神怡的体验。  当我从摩罗维亚的四维空间走出来,如果你问我,软件开发中的管理是什么,我会对你说,了解他们,爱他们,爱你的团队,关心他们,帮助他们;在你要实施某个措施的时候,想一想,这样的措施是为了自己工作更方便,还是可以帮助你的团队解决问题,提高效率。   因为,团队是你的力量,"他们只会因为爱你而追随你"。(一篇老书评)

有趣的读物

很多年前读过的这本书,只能说是一本有趣的读物,对初学者了解一些软件工程的概念有帮助,但不具有实践参考意义。可以当小说看(其实就是一部小说),消磨时间之余还能了解一点软件工程的只是。

做一个不负责任的负面评论:爱思考的人不要买

这本书的风格不是我所喜欢的,它是一本根据结论虚构案例的书,好像童话,但是故事远不及任何童话精彩。爱思考的人想读这本书,只需要读者个帖子:http://blog.163.com/xingsword@126/blog/static/232081202007123103439794/说是不负责任,是因为我只在书店看了一章,十页不到的书,然后没决定买。(还好去书店转了转,在网上买了就瞎了)这本书作者的观点是精辟而激动人心的。我也是在好友的Blog上看到摘要才去翻的这本书。看到评论的时候我也曾叫好,但是也对这本书能包含这么多精辟观点感到好奇。看到这本书我发现了他的问题:根据结论虚构的案例。这些案例太过简单,只能算是对结论的一点解释说明,起不到任何补充论证的作用。所以这本书在精辟的结论之外,也就没有了更多的意义。一本好的管理书籍,他的案例应该是真实的,高度还原的,结论是提炼出来的。读者在品味作者结论的时候,可以自己推敲,能对作者的观点找到切实的支持,也能在作者有所疏漏的发觉问题。这样才是一本开放式的书。一本好的童话书籍,其中的故事应该带有趣味性,从而便于传播。同时故事也不能直接了当地直说问题,而应该带有一点思考。所以我只能说对这本书较好的人都是不求甚解的接收者。他们倾向于对接收到的信息不加思索与过滤,就简单得接受。

轻松的学习

小说的方式阐述一些项目管理的理论和技巧又是一本工作前看过的书工作5年后的现在准备在看看,挖掘一些理解

人们追随你,是因为爱你!

正在做一个项目,边实践边对照着书,感慨故事和现实何以惊人的相似。这一次是重读了,很多事情你只有经历过了,才能理解,才会印象深刻。虽然是小说,没有管理书籍常见的条条框框,但是作者还是很善意的每章的末尾作了小小的总结。讲几个自己感受最深的:“一拥而上”,企图通过早点开工和增加人手来加快速度,结果导致的问题是人人都在设计,却没有整体设计,人与人之间的交流成本变得很高。这一点《人月神话》已经说得很明白,需要一个主刀的手术师,需要概念的整合,人与人之间的交流是有成本的。“确保大家都在忙着”,老板不能容忍员工没有事情干,你总得做点事情让自己忙着,这样老板才会踏实。所以一些基层的领导就会随便抓了一些任务过来,让手下去做,也不管以后有用没用,至少他们都很忙。最后会提交一个东西上来,反正我做了,是不是你想要的,我可不管!德鲁克说过,一个卓有成效的管理者,他的工作必须让别人利用,才能体现价值。他还说,不是你想做什么,而是你应该做什么,要明白自己的任务所在。“不切实际的期限”,因为销售下个季度没有别的业务了,所以你们必须在这之前完成一个产品。还有,下个月xxx公司的高层要看演示,所有基本功能都必须完成......《最》里的贝洛克部长就是这样,一再的缩短工期,因为他觉得虽然目标也可能完不成,但是在压力之下总能把员工的精力最大的压榨出来。即便没有好处,那也没有坏处,他是这么想的。“压力会让人崩溃”,人们会选择离开,因为无法承受。而留下的,则根本不拿项目期限当回事,反正也完成不了,还不如就这么悠着。而中间换人,成本是很高的,结果工期没有缩短,反而更长了!“人与人之间的催化剂”,每个组织中,总需要这样一些人能够把大家都粘合在一起。也许,他/她什么事情都不做,但是因为他/她的存在,整个组织就会变得和谐和融洽。在工作环境,人与人之间的交流可能会很公式化,甚至还很生硬,需要有人来软化这种气氛。“匿名的管道”,组织中必须提供一个让员工发泄不满的途径,否则就会积郁成疾,一旦爆发就不可收拾。老板虽然说,自己办公室的大门永远是敞开的,但是你有勇气迈进去么?还有,在公司的实名制的论坛里,有人敢乱说话么?结果是噤若寒蝉,万马齐喑,而下面却是暗潮涌动。老板于是很纳闷,为什么看起来都没有问题,却感觉有很多问题呢?“巴顿将军”,当战斗打响的时候,他的工作已经结束。如果能够做到这样的地步,那真是最高境界了。这要求,你的战略是正确的,你选择的人是正确的。记得联想有这样的话“定战略、带班子”,这就是领导的职责。要做好一件事情,你首先要把正确的人放到正确的位置上。“人们追随你,是因为爱你!”要做到这一点,可真不容易。

最后期限,值得你读

因为有遇到估算项目进度的问题,找到了这本书。花了一天的时间把这本书给读完了,顺便还记录了一下书摘。读这本书的时候,仿佛置身于其中。里面的101条法则是值得我们学习的!书中不乏一些搞笑的片段。不知道是因为我笑点低还是怎么的,反正我在读的过程中笑了很多次。希望周围的同事不要认为我是神经病。呵呵这是一本让人爱不释手的书。最后期限,THE DEADLINE ,值得你读!

有趣的小书

没人规定谈论项目管理问题的是必须用实际案例。有时间的时候,读读这样的项目管理经验谈小说,也是寓教于乐。

项目中的人性

在我看到《最后期限》中间部分时,老婆问我看什么书,我说关于项目管理方面的小说,于是问,“有没有爱情故事?”,“没有吧!”,“那不适合我看。”,“这么俗!”,“那今晚你睡厅吧!”没想到看完到最后几行时,发现还真以爱情故事完美结局噢,那怕是讲工作类小说也需要生活、爱情去点缀的,或许这就是真实的工作,人性在工作中的体现所占的比例远远高于我们所感受到的。人作为项目的主体,以整体团队去取演绎项目的进程,最终的结果的成败,很大程度上,项目的失败并不是技术、方法上的原因,往往非常大的因素是由于人的社会因素所决定的。在《最后期限》中也有不少章节在重点刻画人的因素。管理者需要用身体,用心、肠胃、灵魂、鼻子去管理,用心去领导,相信你的肠胃(感觉)去选人,用你的鼻子去嗅出谎言,管理者需要用心去构建有信念的团结的团队,营造沟通畅快的环境,团队拥有共同的梦想,团队就是有梦想才能团结在一起,团队才有了灵魂。这些并不是技术、制度所能创造的,需要管理者用心去挖掘团队人员人性上的特质。团队的大小与在一定时间内所完成的项目进度关系并不是一个线性关系,例如10人团队一年所完成的工作量与20个人半年完成的工作量对比,它们并不相等,甚至于20人半年的工作量还不到10人一年的一半。为什么相差这么大呢?在《最后期限》的结尾也给出了答案,6个项目中,每个项目的大团队都是以失败告终,小团队在大部分的时间中人数都是大团队的六分之一左右,结果让人深思。人不是机器,增加机器很容易计算出生产率的提高量,而人的加入,会增加沟通的成本,培训的成本,团队需要磨合,团队的凝聚力也决定了生存率。前面两次提到沟通的字眼,沟通为什么在现在变得越来越重要了,因为节奏更快了,项目是需要团队成员合作去完成的,人却由于价值观、职业精神、能力等各方面的差异大,如果需要在一个层面上工作,沟通你我成为必须。《最后期限》提及到很多沟通上的实践,创建无障碍上下级沟通平台,借助工具量化生产率、功能点等,领导层之间亲密沟通,管理者与元首、代元首、评估者等的及时沟通,无不是为了互通有无,达成共识。工作中的愤怒往往是因为其对工作的胆怯,对未来不可实现任务的担忧,于是产生了压力,压力的不断加大,就会借助对下属的愤怒去发泄出来。作为更上一级的管理者,需要他去用心去感受到中层管理的痛,往往释放中层管理者的痛,将其调离工作岗位或许是对他最大的嘉奖。人的自信程度也决定了他的格局,在权威的需求文档前面,只有主角的得力助手看出了文档的问题,其他人被文档中的技术复杂度所折服了,失去了自信,理解不了文档,错觉中认为自己的能力不够,不敢质疑文档的合理性。《最后期限》的男主角,从被裁员开始,被充当小王国的人力总监女主角挟持,空降到小王国的当上了国家项目的大总管,开始了他的项目管理实验室,他及他的领导团队在实践着项目管理中的真谛,完成了这个实践,他们就可以知道项目管理中的秘密,可以真正理解项目成功的原因。有该信念,支撑着他们克服困难,不断追求改善工作的方式方法,男主角没有什么过人之处,但善于沟通、执行力强、坚持学习总结,这些貌似简单能力,确更加真实的反馈出领导力的真谛,正确简单重复,真理都是简单的,人性都是简单的,简单而正确的事情重复做,围绕着周围的一群都拥有过人之处的帮手,陪伴着他迈向成功之门。

101条项目管理法则 - 网摘

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

管理的童话

很早的时候就有了这么一本书,却不知道是怎么有的,反正它一直停留在书架上面,没有任何迹象和线索能够引导我想起这本书的来历。因此,也一直没有想法要去读它,一本不被引起注意的书通常是机缘巧合才去翻读的,而且往往会邂逅惊喜,比如这本。作者汤姆.迪马可身载Warnier计算机领域终身贡献奖,也是经典巨著《人件》的作者,也只有这样有着深厚功力的人才可以将复杂的学问举重若轻,娓娓道来,也才有了印着大师风范的童话故事。童话中巧妙的穿插着日常生活中常见的各种矛盾和冲突,当你站在一个管理者的角度,你看见的是管理中神似的情景和状况,如果你只是一个普通读者,你也未必就不能看见生活中点点滴滴的困惑和麻烦,这一切,无非都可以帮助一个人提炼人生经验,加强思维能力。很喜欢汤普金斯那个有效的习惯,他把自己一闪而过的灵光记录在每日的日记中,高度概括的观点不一定正确,却在一定程度上形成一种高效的经验,那便是不停止思考,并且用某种积累来改善思考。这是一本童话故事,的确如此,不过童话中无不投射着智慧的光影,所谓见仁见智,那是需要心灵默契和思维对等的。我喜欢这本书。

永远不要认为自己很懂管理

每读一个章节,都能够在现实的工作中找到或多或少的影子。想做好项目管理 -- 或者是更广泛意义的管理工作,都应该去翻翻这本书。

不错,挺好的一本书

不过没经历过大项目,里头一些东西找不到共鸣。我在想书里面的元首是不是指微软那个比尔,那个小国是不是指印度?呵呵。

门外汉的别有洞天

自己是做营销的,对项目管理没有很深刻的认识,通过这本书,我深刻的认识到项目管理的常见问题,拿着书和公司现状比对,原来是那么的相似。看来美国人和中国人都有同样的问题。无论怎么说,如过你是门外汉,想了解项目管理,那么这是你必须的一本书。感谢作者,汗,作者是谁了的?

给自己定一个 期限

这本书 花了2个早上看完,当时读完以后就有很多理念上的更新和收获。今天抽空来写书评,我只想 说说我的“期限”。事实上,所有的企业必须面临时间管理的问题,好企业往往在时间和运营上能够相对平衡。我想,在这里,给自己一个期限(管理企业的人,首先要学会管理自己) 在06年年底之前,能够充分将书里的知识点应用起来。 知识是拿来用的,而不仅仅是用来讨论和概念化的。

南柯一梦……

汤普金斯被解雇了,他像往常一样,坐在礼堂的最后面,接受着“新的机会”的洗脑,好让自己有动力去外面寻找新的机会,不过这一切都太无聊了,于是,汤普金斯又睡着了……这时,来了一个黑发美女,坐到汤普金斯的旁边,与他谈论了一些关于项目管理的问题,然后,美女给了他一个职位,但是去一个从来没听说过的国家……,虽然他想反抗,但最终还是被带过去了……这个国家叫摩罗维亚,由汤普金斯来负责带领完成6个项目,资源极其充沛,各种要求都能被满足,如果有什么困惑,总会有人来帮助他,所以,开始看起来相当困难的项目,随着时间的推进,一切都逐渐清晰起来,再加上自己周围那些聪明能干的部下,一切都是如此的美好……但天有不测风云,元首需要出差,由一个阴险的小人贝洛克代理元首,从此……项目日期被提前,要求员工加班,每周改为7天工作制,必须遵守软件开发规范,一定要在年底前达到CMM3级。。。各种不合理的要求,这真是让人郁闷至极,这也是最黑暗的时期……不过,对男主角来说,在困难的时期,绝望的时刻,总会有配角出来解救。汤普金斯明修栈道,暗度陈仓,自己来一套,给贝洛克展示一套。不过,黑暗过后总会有黎明,风雨之后见彩虹,黑发美女回来了,阴险的小人贝洛克就得了重病,可能要住院一年,真是大快人心。有3个项目按阴险小人的计划完成了,其它的项目也非常顺利。最终,摩罗维亚要上市了,汤普金斯即有期权,又有股权……以至于富的买下了另一个小国家,自己当了元首,而且,黑发美女最终做了自己的媳妇……真是美满的大结局。。。突然,汤普金斯被吵醒了,发现台上仍然在讲“新的机会”……///////////////////////////////////////其实吧,书中并没说这是做梦,两年前读过一点这本书,但完全是当小说看的,没有觉得有多好。两年后再读,感觉完全不一样了,这真的是本非常不错的项目管理书籍。汤普金斯的笔记,基本上就是我们要记的笔记,下面基本是简单拷贝出来的:///////////////////////////////////////让正确的人去做正确的事。这就是优秀的管理者和平庸的管理者之间的区别。寻找合适的人选。然后,不管你之后做错了什么,这个人都会拯救你。这就是管理所有的艺术。项目管理中最根本的四个要素:人员的选择、任务的分配、激励或者团队构建优质管理的四大要素:选择正确的人。为他们分配正确的工作。保持他们的积极性。帮助团队凝聚起来并保持团队的凝聚力。(其它一切都只是“方案”)安全和变化除非感到安全,否则人们就不能去迎接变化。在所有成功的工程中(以及在绝大多数其他有价值的工作中),变化都是基本的要素之一。安全感的缺乏会让人们反对变化。逃避风险是致命的,因为这会让你也得不到与风险同在的利益。人们可能会因为来自客观世界的直接的恐吓而觉得没有安全感,但是如果察觉到管理者可能滥用权力来惩罚自己,他们也会觉得没有安全感。负面效应威胁不是提高业绩最好的方法。如果分配的时间一开始就不够,不管威胁有多么吓人,工作也无法按时完成。更糟糕的是,如果目标没有实现,你就必须兑现你的威胁。如果你在管理的时候注意一下哪个器官在活动,那多半不是大脑。管理在内脏里、在心里、在灵魂里。人们不会因为你聪明或者因为你一贯正确而追随你,他们只会因为爱你而追随你。那些我们尊敬的管理者,他们都有着广阔的胸襟。在某种意义上,心是管理的根本要素。会动脑的‘领袖’可以带领别人,但是别人不会追随他。管理者的作用就是创造一种氛围,让团队成员之间有紧密的、温暖的甚至是亲密的联系。在战役开始的时候,管理者真正的工作已经完成了。如果先把材料整理好,那么所有的事情都会进行得更好。生产力的提高没有“短期生产力提高”这样的东西。生产力的提高是来自长期投资的。任何承诺立刻见效的东西都很可能是江湖游医所卖的万灵油。风险控制通过控制风险来管理项目。为每个项目创建并维护风险统计表。跟踪根源性的风险,而不只是最后那讨厌的结果。评估每种风险具体化的概率和可能造成的开销。对于每种风险,预测标志其具体化的早期征兆。任命一个风险控制官,这个人不应该维护组织内部“我能行”的态度。建立简单的(可能是匿名的)通道,让坏消息能传递到高层。防止失败壮士断腕。控制住失败比优化成功更能提高你全面的成绩。要有闯劲,尽早取消失败的工作。除非必要,否则就不要自己去凝聚一个团队:出去找一个已经成型的团队来用。保持好的团队在一起(只要他们自己愿意),以帮助你的继任者避免团队凝聚得慢或者不能凝聚的问题。把凝聚在一起的团队—— 准备好、并且也愿意接受新的工作—— 作为项目的收获之一。项目开始时浪费的一天和最后阶段浪费的一天对项目造成的伤害是同等的。有无数种方法可以浪费一天的时间...但是没有任何一种方法可以拿回一天的时间。开发过程的建模和模拟将你关于完成工作过程的直觉建模。在同事的交流中使用这些模型,以便交流、提炼关于项目运转的思想。用模型来模拟项目的结果。根据实际的结果来调整模型。团队有一个吸收率,只能以一定的速度增大。如果你试图让他们更快,结果只会适得其反。病态的政治每一天,你都必须准备拿自己的工作打赌.....但是这也不能保证“病态的政治”影响你。“病态的政治”可能在任何地方出现,哪怕是在最健康的组织里面。“病态的政治”的特征:对个人权势的渴望超过了组织本身的目标。即使这种不合理的目标与组织目标背道而驰,它也可能出现。“病态的政治”最恶劣的副作用:它精简项目变得危险。度量度量每个产品的规模不要执着于单位 – 在等待客观度量的时候,先用你自己的主观单位从所有能得到的原始数据(可计算得软件特性)自己构造度量单位从已经完成得项目中收集原始数据,以推导出生产力趋向借助数据库画一条趋势线,把预期工作量作为人造度量值的函数显示出来现在,针对每个要评估的项目,计算出人造度量单位值,并根据这个值在趋势线上找到预期工作量值用生产力趋势周围的干扰水平作为映射的标示过程和过程改进:好的过程和持续的过程改进是绝好的目标它们也是非常自然的目标:优秀的技术工作者一定会关注它们,不管你是否告诉他们。正式的过程改进程序常需要花钱、花时间;特定的过程改进工作拖延项目进度。尽管最终会体现出生产力上的收获,它们也不可能抵消花在过程改进上的时间。但是,项目有希望从单个的、正确选择的方法改进中得到足够的收益,并赢回为这次改变付出的时间和金钱。在项目进行的过程中,不要希望在超过一个方法的范围内实施改进。多种技术的改进程序(比如说提高整整一个CMM等级)很可能让项目比不实施这些程序完成得更晚。标准过程的危险就在于人们可能失去重要的走捷径的机会特别是对于人员超编的项目,标准过程看上去会很严谨,因为它们制造出了足够的工作(有用的和无用的),让所有人都忙碌不停。“人们会做我要他们做的事,是因为他们喜欢我”“不是因为他们喜欢你。是因为你喜欢他们。”“你喜欢、尊重为你工作的人.你关心他们.他们的问题就是你的问题,他们的担忧就是你的担忧。你的胸怀像天空一样宽广。在一个人真正证明自己的可信以前,你就信任他。你让我们都觉得你把我们当成一家人,这就是我们跟着你的原因。”改变完成工作的方式:如果不大幅度减少调试的时间,就没办法让项目大幅度提前完成高速完成的项目用在调试上的时间也成比例地少得多高速完成的项目用在设计上的时间也成比例地多得多如果你不关心别人,不照顾别人,就别想让他们为你做一些不同寻常的事情。如果要让他们改变,就必须去了解(并赞赏)他们的过去。压力的效果:压力之下的人无法更快地思考增加加班时间只会降低生产力短期的压力乃至于加班可能是有用的策略,因为它们能使员工集中精力,并且让他们感到工作的重要性。但是长期的压力肯定是错误的。经理之所以会施加那么多的压力,也许是因为他们不知道该做什么,或者因为其他办法的困难而感到气馁。最坏的猜测:是用压力和加班的真正原因是为了在项目失败的时候让所有人看上去能好一点。愤怒的经理:管理中的愤怒和耻辱是会传染的。如果高级管理者喜欢骂人,低级管理者也会有样学样(就像经常被骂得小孩很容易变成爱骂人的父母)。管理中的辱骂常被认为是一种刺激,可以让员工提高效率。在“胡萝卜加大棒”的管理策略中,辱骂是最常见的“大棒”。但是,哪有人被辱骂之后还能做得更好的?如果经理使用辱骂得方法来刺激员工,这就表现出经理的无能,而不是员工的无能。每个人在内心深处都觉得自己的智力比其他人要低一些,并且用更多的努力来补偿自己的‘缺陷’。含糊的规格文档:规格文档中的含糊隐含着不同的系统参与者之间存在着未解决的冲突。如果一份规格文档不包含完整的输入输出列表,那么它就是毫无希望的,它根本就还没开始说明任何东西。没有人会告诉你一份规格文档是不是糟糕。人们往往倾向于责备自己,而不是责备文档。每个人都只看到自己的目标。应该看到全局目标。绝大多数时候,冲突双方之间的谈判通常都是零和游戏。不要在冲突的时候才去调解,这就是关键。我们需要在冲突完全形成之前就去调解,这正是‘全赢’的根本。冲突:只要在开式过程中有多个参与者,就一定会有冲突存在。创建、安装系统的业务中特别容易出现冲突。绝大多数系统开发团队都缺乏解决冲突的能力。冲突应当引起重视。冲突并不是缺乏职业道德的行为。应当提前声明:所有人的‘赢’都是受重视的。确保每个级别的人都能赢。谈判困难;调解容易。如果两个人的利益是完全或者部分相斥的,预先做好安排,准备好请双方通过调解来解决冲突。记住:我们都站在同一边;跟我们对立的,是我们要解决的问题。催化剂的角色:有这样一种催化剂式的人物,这样的人能帮助团队成型并凝聚,持团队的健康和生产力,从而对项目做出贡献。就算“催化剂”别的什么事情都不干(其实,通常他们还会干很多别的事),这种催化剂的角色也是重要而有价值的。调解是“催化剂”的一项特殊工作。调解是可以学的,而且只需要很小的投资就能学会。调解应该从一个小小的仪式开始。“我能帮你们调解一下吗?”在解决冲突的时候,这是必要的第一个步骤。人类的错误:将你置于死地的,不是你不知道的的东西…而正是你“知道”绝不会置你于死地的东西。早期的超编妨碍了明智的设计人员安排:在早期,人员超编会迫使项目跨过关键的设计阶段(这是为了让所有的人有事可做)。如果在设计完成之前,工作先被分给了很多人,那么人与人之间、工作组之间的接口就会很乱套。这会使团队内部耦合度提高,会议时间、重复劳动和无效工作都会增加。理想的人员安排是这样:在项目的的大部分时间里由小型核心团队来做设计工作,在开发的最后阶段(时间安排的最后1/6)加入大量的人手。可怕的猜想:时间安排紧迫的项目,与时间安排比较合理的项目比起来,完成的时间发而会更长。在工作中,愤怒都是因为恐惧。项目社会学:让不必与会的人可以放心离开,从而保证会议的精简。有一份公开的议程,并严格执行,这是最简单的办法。项目需要仪式。用小小的仪式来使人们注意项目的目标和理想状态:小规模会议、零缺陷工作等等。采取行动,防止人们随便发怒记住:愤怒=恐惧。随便对下级发怒的经理一定是因为恐惧才会这样做的。意见:如果所有人都懂得“愤怒=恐惧”这个道理,就能明显地看出发怒的人是在害怕。由于无法再隐瞒自己的恐惧,他也就不会再生气了。(这不能解决这些生气的人的问题,但是肯定可以让其他人好受一些。)“病态的政治”(旧话重提):别想根治一个病态的人不要浪费时间,也不要因为尝试治疗上司的病态而使自己受到威胁。有时候,你唯一的选择就是等待,等问题自己解决,或者等一个让你继续前进的机会。奇迹时有可能发生的(但是千万别去指望它)精兵简政:精兵确政是支败的公司使用的办法。它让员工负担失败的责任。公司的目标应该正好相反:兴旺而人性化。当你听到“精兵简政”这个词的时候,请记住它的弦外之音:失败和恐吓。基本常识:项目既需要目标,也需要计划。而且这两者应该不同。

简单就是最好的

将复杂的道理 藏在简单有趣的故事里。我一向比较喜欢这样的书。不像看那些大部头,看得累个半死。回头想想,也没什么东西。经历过软件项目的都可以在书中找到对应的情节,虽然总有人说国外的软件行业环境和国内的相差太大,但具体到项目中,每一个项目可能出现的问题,人的问题,政治的问题,时间的问题,钱的问题,我想都是没有多少分别的,可以从书中借鉴的东西真的很多。

管理是什么

借由故事引发道理,这是很让人喜欢的表达方式.粗浅的看了一遍,不能说有什么深入的感想,不过汤普金斯先生的日记确实让人看了有种眼前一亮的感觉.准备有空的时候再看一遍,温故而知新:P

这次的读书笔记,更多就真的是笔记

关于项目管理,其实,我真的没有多大的感觉,本书说的是软件设计的项目管理,是靠我最近的一个项目。不过,所有项目的互通感,让我了解到一、项目的组建,包括项目成员人数,项目产品经理的任命,职能1、人刚刚好,就好,如果所有的项目功能都设计好了以后,那就是任务分配的问题,如果到了这个时候,你就可以添加一些人咯2、项目团队的管理,是用心,不是用脑,用脑,人会和你一起做,用心,人会跟随你二、执行1、会议的执行,请务必请好需要的人,把所有的议程都提前写出来,这样大家才能知道,参加这个会是否有意义,另外,如果这个会议过程中,后面的议程和目前在场的人没有关系了,可以让参会人员提前回去工作。另外,提前退出会议的人,务必把关注的点,要交代的事,提前说出,给后面的议程一些建议2、压力,不能提高人的思考速度,另外,威胁、恐吓不是最好的管理办法,如果员工出现任何问题,那么,就是管理者的问题3、风险管控,要抓住风险的根源4、冲突解决,首先,你要争取冲突双方的同意,由你来协调(冲突只能协调),然后,你要让他们明白,其实大家的大部分利益追求是共同的,只是有部分的利益不同,因此,找个大家都能接受的点,然后,让大家更好地站在同一战线5、政治影响:有些政治影响,你如果不能控制,那就想个最好的办法控制其他的一些工作技巧1、多听,少说2、问下优秀的雇员,有没有其他的伙伴可以推荐下3、把每天都拿来作为赌注,项目的第一天与最后一天,同样重要


 最后期限下载 精选章节试读


 

农业基础科学,时尚,美术/书法,绘画,软件工程/开发项目管理,研究生/本专科,爱情/情感,动漫学堂PDF下载,。 PDF下载网 

PDF下载网 @ 2024