The Art of Project Management

Scott Berkun

出版时间

2005-05-02

ISBN

9780596007867

评分

★★★★★
书籍介绍
这不本教你套用流程模板的工具书,而是一部提醒项目经理「先看清人,再看事」的书。它反复强调:进度表救不了糟糕的设计、模糊的目标和低效的沟通,它只是暴露问题的镜子;真正决定项目成败的,是领导如何把复杂目标简化成团队愿意为之努力的方向,又如何在灾难来临时第一时间做损害控制。书中大量篇幅留给「该做什么、不做什么」的取舍——为什么需要这个项目、客户真正卡在哪里、为了它必须放弃什么。它尤其适合程序员背景的从业者:如果你正困在「既要懂技术、又要管项目」的双重疲惫里,它会给你一套接地气的判断框架。但请留意,它刻意以「Art」而非「Science」立论,重过程、轻体系,追求严密方法论的读者或许会觉得它散。
作者简介
Scott Berkun worked on the Internet Explorer team at Microsoft from 1994-1999 and left the company in 2003 with the goal of writing enough books to fill a shelf. The Myths of Innovation is his second book: he wrote the best seller, The Art of Project Management (O'Reilly 2005). He makes a living writing, teaching and speaking. He teaches a graduate course in creative thinking at the University of Washington, runs the sacred places architecture tour at NYC's GEL conference, and writes about innovation, design and management at www.scottberkun.com.
AI导读
核心看点
  • 本书摒弃枯燥的理论堆砌,以幽默风趣且无行话的风格,深入探讨项目管理的‘艺术’层面。作者强调,进度表不仅是时间承诺,更是促进团队协作、追踪进度及分解任务的工具,但明确指出进度表无法挽救糟糕的设计或低效沟通,管理者需认清其局限性。
  • 书中重点剖析了项目经理在团队中的核心职责:不是线性产出代码,而是通过简化目标、增强团队价值来推动工作。作者提供了关于损害控制、应对突发危机的具体策略,强调在问题发生时,首要任务是让项目回归可控状态,而非追究责任或陷入混乱。
  • 作者结合微软IE、MSN等真实项目经验,深入讨论团队政治、人性弱点及沟通障碍等敏感话题。书中强调管理者需在自我与无私、独裁与授权、容忍模糊与追求完美之间保持平衡,并指出良好的商业视角要求团队明确项目对业务的必要性及客户真实需求。
读者共识
  • 读者普遍认为本书虽缺乏严谨体系,但提供了大量关于团队人性、沟通及危机处理的真实洞察。许多读者赞赏其幽默风格及对‘人’的因素的深入探讨,认为其启发性强,有助于管理者理解团队动态,但同时也警告其内容松散,不适合作为唯一的学习资源。
  • 多数读者指出本书不适合初学者建立基础框架,也不适合寻求标准化流程的专业人士。部分读者认为其内容平庸或无聊,甚至表示读不下去。共识在于,本书不能作为项目管理的主修教材,但可作为补充读物,帮助管理者在复杂情境下获得非技术层面的思考角度。
  • 读者一致建议不要购买中文译本,因翻译质量参差不齐,且原文幽默感难以传达。强烈建议有英语阅读能力的读者购买英文原版或影印版,以获取最佳阅读体验。同时,读者提醒,本书内容可能已过时,需结合现代敏捷开发等新方法论进行批判性吸收,不可全盘接受。
精彩摘录
  • "第一,是对什么时候完成任务的承诺。... 进度表的第二个作用,是鼓励每个人把自己的工作看做整体的一部分,并且全力把自己的工作和他人的工作结合起来。... 进度表的第三个功能就是提供了一种能够追踪项目和把工作分成若干个易于管理的小块的工具。 进度表在一二小团队上出现问题可不是一条好消息,但是在这样的案例中,半天的事故只是代表三个人付出额外半天的努力,所以恢复到正常状态还是可能的。有的人熬一晚就行了,或者可能的话,整个团队一起来帮着赶时间。但是,在一些较大的项目上,拥有数十或数百的成员和模块,一天的延迟可能会迅速叠加,并且产生各种各样的难以预料的问题。而这些问题的严重性往往超过了团队可以恢复的程度"
  • "进度表并不能解决项目本身带来的所有问题。进度表不能挽救糟糕的设计或者编程实践,它也不能保护一个项目免遭无力的领导,不明确的目标或者低效的沟通。"
  • "如果同时发生很多问题,或者发生了某种破坏力很强的事情,第一步要做的就是损害控制。这意味着从第一时间起,你最优先的工作就是让项目回到可以接受的状态;"
  • "项目经理必须足够说服力,让团队为他们所做的工作努力的目标简单化,而不要把编写优良可靠的程序代码所牵涉的复杂性最小化。 工厂或软件公司的经理,不像受聘的工人或程序员那样产生线性的工作量。相反地,受聘的领导者和经理用来增强周围每个人员的价值。"
  • "A good business perspective means that the team has answers for the following questions: - Why is this project needed for our business? - What unmet needs or desires do our customers have? - What features or services might we provide that will meet those desires and needs? - On what basis will custo"
  • "The important questions from the customer view include: - What do people actually do? - What problems do they have trying to do these things? Where do they get stuck, confused, or frustrated? - What do they need or want to do but aren't able to do at all? - Where are the specific opportunities to ma"
用户评论
很贴合M$的一本书
bachelor_UIBE
读之前不知道这个是特别针对对程序员的项目管理的书 感觉一方面要弄明白程序员的项目是什么情况 一方面要搞项目管理 一半之后累觉不爱了。。有涉及到的时候再看吧 最好找一本普遍一点的来读
对比针对startup项目/产品写的<rework>,<getting real>或者<lean startup>实在很强... 那两本看了很激动, 这本完全啃不动一看就想睡觉... 努力看完吧...
花了好久的时间读完了,感觉收获特别多!希望以后能在实战中多多练习和运用!
我读不下去这本书了,挺无聊的后面。
一晚上读完;DDL第一生产力
中规中矩,许多实用的干货,但缺乏一种我期待的灵气,PMBOK之外的一本实用技巧书籍,“术”的范畴。
求书
收藏