对于一个项目经理来说，唯一的目标就是实现项目的目标，能够给客户交付一个满意的结果，所有的工作，行动和管理围绕该目标进行。 那么从你自己列出的两种场景可以看到，如果不管理细节那么一定是无法很好达到项目目标的，则结论就是需要管控细节。但是你描述里面首先由给自己下一个台阶，即自己精力和能力有限，我管控不好所有细节是理所应当的事情，如果是这个思维的话这个问题没有解。 回到问题本身，一开始一定是要管控所有细节，后续管理和努力的方向是如果逐步减少对细节的管理，如何让团队里面的人自己能够管理好细节。那么团队人员本身你已经分析到了只有两个方面的影响，一个是本身技能问题，一个是责任心和态度问题。而这两点的改进在刚开始时候往往并不需要过于复杂的方法论。 责任心问题：刚罚就罚吧，再人性化的管理该处罚的时候还得处罚，只有涉及到个人经济利益时候个人才会真正的重视，不是每个人都能够积极主动的。 技能问题：这个相当重要，即通过前期迭代的项目执行能够发现项目团队技能和知识上的缺陷，能够发现哪些细节内容本身就没有事先做好约定形成团队通用词汇表，哪些应该加强评审和检查。所有这些目的都是逐步形成团队的技术词汇表。有了这个即逐步有了大家对细节的共同认识，细节很多时候不是简单的态度问题，更多是技术归约不清的问题。 对于做不好的地方，不断强调并加强奖惩力度，逐步潜移默化为习惯。对于开始做的好的地方后续即可以逐步进行粗粒度和抽查式的管理了。对于细节把握相当好的团队成员，逐步提升为你的辅助管理者，分担管理和检查职能。 最后，再给你提一点，不要让团队里面的人认为你是一个单纯的管理者，只知道管理和安排跟催任务，而是要体现自己的技术角色，能够帮助团队一起分析和解决技术难题。技术类项目管理一个重点就是让下面团队成员从内心里认同你。

直接上方法，请依次进行： 1.人员列表。 做一个人员列表，标示出团队每个人的管理能力、需求分析能力、程序设计能力、编码能力、测试能力 。根据能力制定不同的层级角色，比如具体需求分析能力的人跟你一起做需求分析,具有管理能力和程序设计能力的人做开发组长...;再把当前的工作列表分配到每个人。 2.沟通。 团队中每个人单独沟通，了解他们对工作的期望，提升的欲望，激励他们在项目中发挥积极作用，如果这一句话做不到就直接跳过。告诉他们你的安排，要求每人每天下班前必须向你汇报。不会做的，做不好的没关系，每天向你汇报的时候你给他们解决方案。 3.短期培训，楼主当前的境况聊长期培训貌似不现实。看起来楼主急需一个业务需求沟通负责人和一个开发组长。前面已经找出了人选（不一定这个人已经具备当前的能力，只要他们有潜力有意愿就ok），接下来是重点培训这两个人，短时间内让业务需求沟通负责人和开发组长上位。 4.监控 通过每天的汇报和开发成果测试监控所有成员的进度和问题，同时也通过此步骤了解每个人的额能力。 5.优化 认定开发组长或者某个成员的工作之后，逐渐放宽对此人的监控细度。对于出现问题的人或者任务分析原因，调整方案，调整人员。开发组长时机成熟可以替你管理一两个人的开发。然后再培养其他开发组长... （通过楼主的表述貌似开发人员中暂时没有顶得住的人，因此出此策，如果已有人选做开发组长这一步会容易得多） 业务需求沟通负责人逐渐做一些与客户的沟通工作，直到他完全替代你與客戶溝通業務需求。 ﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣ 其實很多回答說得都對，只是貌似樓主急需一個方案解燃眉之急，因此直接給出了5個步驟。沒有人一開始就是一個遊刃有餘的項目經理，慢慢來慢慢學。

1. 管控所有的细节。 因为项目的特殊性，客户这一环节无比重要。因此能及时的解决问题和反馈客户的问题显得很重要。因此如果管控所有的项目实现细节，就能很好的沟通交流。由于团队成员技术、业务已经责任心等参差不齐，如果不加以管控，很可能做出来的功能就不符合要求。管控起来，能及时回复成员的疑问就能更好的指导大家做功能实现；但现实是精力和能力有限，并不能每一方面都能很好的了解以至于掌控；

作为项目经理一个人，企图管控所有的项目实现细节，事无巨细事必躬亲，眉毛胡子一把抓，这在实践中往往既做不到，也是错误的。因为并非所有的项目细节都重要，值得一个团队领导亲自抓，而决定项目成败的往往只是少数关键细节。 要管控项目开发的所有细节，不是依靠 PM 一个人之力，而是应该依靠团队的整体力量，尤其应该为项目团队建立起一套完整的质量管控体系与成熟的软件开发流程。二十年来国际上可参考的标准模型和最佳实践已经很多，如 ISO 9001、CMMI、UP、Agile、PMBOK 等等。团队有了成熟的管理流程和方法论，把项目风险、责权利等等分解到每个人而不是 PM 和少数个人英雄身上，才能实现有效率、高品质的项目管理、服务管理，做到万无一失。 题主未提及团队规模，以上分析主要针对大中型团队。对于小微团队（如 <10 人）PM 掌控所有细节是有可能的，因为这些项目本身细节不多，也不是很复杂。这在 2000 年以前国内软件工程的蛮荒时代比较流行，当时的 PM 与架构师常常是一个人，既抓管理也抓技术，还要搞好客户关系，而很多需求文档、架构文档也是 PM 写的。不像现在角色分得细，除了 PM，还有产品经理、业务分析师、需求分析师、系统架构师、软件架构师等等。

2. 不掌控所有细节，粗放的只盯大的功能实现和进度等；

这句话只说对了一半。 PM 的正确做法是抓大放小，风险驱动，客户价值优先，利用有效的时间和精力只抓住关键细节，而不是所有细节。抓这个关键细节的管理不是粗放的，而是精细、精准的。 例如，你们有 100 个需求，PM 要抓住所有这 100 个需求的细节？不可能吧。通常的做法是，PM 只抓住这其中 10-20 个对客户最重要、最有价值或者实现起来难度最大、风险最大的需求，重点了解它们的需求定义是否符合客户需要，实现难点和技术障碍，如何克服困难、消除瓶颈等等细节。 其他的 80 个需求怎么办？细节 PM 只能大致了解，它们的实现和进度管控应交给你的助手，团队里的其他管理与技术骨干（如 TL、架构师），以及项目的整个质保体系、开发流程管理来负责或保障。

粗放的盯进度实现，这就对团队成员提出了更高的要求。团队成员需要不断站在用户的角度思考问题，例如用户体验等，需要站在项目的角度思考功能，比如这个功能是否是客户真实想要的，是否可以有更简单的实现来代替，从而节省人月等；

做到以上这些并不难，现代软件工程方法里有许多成熟的需求管理、需求分析实践，关键在于你们团队里是否有足够成熟、掌握这些技能的需求分析师、需求工程师、产品经理等。如果没有，每个需求都要 PM 自己来盯，那会把 PM 累成狗。

但是让成员做决策又基本不可能，毕竟不在其位不谋其政，工程师的思维也不是那么好拗过来的；责任心不强的工程师，做出来的东西简直是要骂街的。

软件开发中的决策多种多样，有大有小，有主有次。如果所有决策都让 PM 来做，PM 也要累成狗。PM 一般只负责管理决策，让架构师负责主要的技术决策。每个工程师如何实现自己负责的需求，他有这个决策权。涉及到架构的技术决策，通常需要集体讨论，架构师有最终决策权。 如何保证工程师做出东西的质量？主要靠成熟的质量保证流程，在需求、设计、测试等等许多环节都可以设置评审、抽查、运行、演示等等检验和反馈步骤，而不能单纯靠工程师的责任心。

背景类似于给电信运营商做外包的项目，管理经验太浅，这个问题尝试了很多办法，一直得不到很好的解决，希望大家能不灵赐教。 ... 以上两点算我目前的背景详情。另外我知道可能中庸的做法是取平衡，但平衡之术难比移山。

平衡的思路很对！二十年来世界上主流的的项目管理、软件工程管理方法论都是讲究平衡的，在中国管理 IT 项目尤其应该如此。 PM 不应该抓所有的细节，而应该只抓关键的细节。这 20%（或更高的比例）关键的细节随着项目的进展，是动态变化的。 你们目前的一个主要问题就是还没有找到一套适合自己的管理方法论和体系，所以思路有点乱。事实上世界领先的软件工程与项目管理已经很成熟了，成熟的方法论与知识体系就摆在那里，只是需要大家去学习。建议赶紧找点资料、参考书研究下。 除了确立团队开发的管理方法、流程之外，还需要把管理的人才梯队建起来，让管理和技术骨干们掌握必要的技能，而不是把所有细节、压力都压到 PM 一个人身上。只有这三个方面结合起来，才能实现高效、成熟的项目管理。

结论开头：没有必要掌控所有细节。 项目经理有两点关键任务，两者做好了，才能算是一个成功的项目经理，做好第一点，只能算是合格： 一、对外，顺利交付项目，保证项目质量，超出客户预期，达成占坑目的，即客户认可我方结果，希望与我方再度合作。 二、对内，让兄弟们成长，获得物质和精神上的双重奖励，制造项目归属感，为我方下一个阶段的拓展奠定厚实的人员基础。 而项目经理的本质是什么？ 是项目经理通过绩效管理手段，通过和项目组同事反复沟通，明确思路，确认结果的一个过程，而在这个过程中，所谓的掌握所有细节，仅仅只能是一种手段，而不能作为一种固定流程。我们可以在一个阶段掌握所有细节，来保证新来同事的成长和对我们要求的明确，而一个项目正式上了轨道以后，项目经理绝对不可以掌握所有细节，否则则肯定会发现无法掌控项目。 项目经理应该掌握什么样的细节？ 1、项目经理首先应该把注意力放在项目范围和职责上，该处的细节必须项目经理完全掌握，才能保证项目最后的成功交付； 2、其次是对于新的项目成员的思路和结果进行反复CHECK，保证项目成员双方都能对于结果认知相同； 3、第三是所有的交付物，在安排检查人员的同时，应该尽可能对于最后的结果进行某一个层面上进行详尽的把关，作好最好一道交付； 4、剩下的也就是把注意力放在项目难点以及项目成员的心态上，保证难点的攻克，以及项目本身有一个很好的归属感；难点决定进度，项目归属感决定未来； 项目经理不应该掌握什么样的细节？ 1、所有时候的进度情况，项目经理应该关注的是项目关键节点，以及难点问题的解决情况，剩下的问题关注多了，反而失去项目的归属感； 2、应该给熟悉的弟兄们过程上的自由，结果上的check；一定要让大家认可，我们对于大家的期望； 最后，借用《人人都是产品经理》里头的一句话，短视的人把方法当作目标，远见的人把目标当作方法，所谓的掌握细节只是方法中的一种。

建议了解下scrum + xp。虽然敏捷开发国内有各种观点，但敏捷开发有很多很好的实践来应对你所说的这些问题。 比如管控所有的细节，这种想法是比较典型的瀑布式的做法。瀑布式能成功吗？当然可以成功，但前提是有一个强悍的项目经理。:) 从需求分析，到设计，编码，测试等等每个环节都要力求正确。 敏捷开发提倡团队协作，团队共进退。传统项目经理可以把很多决策的权利交给团队，以期实现团队的自我管理。当然达到这一点还是非常困难的。但不是说不可以达到。我们团队本身做项目管理软件的开发，我们自己的过程也是按照scrum的框架来走，同时辅助于适合我们自己的开发实践。这五年多下来，效果还是很不错的。

［行业干货］ Jason最近在读Jack R.Meredith的《项目管理Project Management》很受启发，在回想之前半路出家从攻城狮被提到项目经理岗位带队完成大小项目的经历，虽然最终呈现的结果是被客户认可和肯定的，但是一路磕磕碰碰走了不少的弯路，心情也经历着像过山车般的跌宕起伏。在此书中找到了不少共鸣和感悟，所以打算写出来，一是和大家分享、学习；二是自己对之前项目的再次梳理，提醒自己不要再犯类似的错误。这个系列打算用一月的时间陆陆续续的写吧，以Jack的著作为主，辅以自己的观点。 还是那句话，本人能力有限，水平一般，还请大家多赐教。 在旅行之前，先了解一下将要经过的路线是非常有用的－－写给之前自己对书本派的不客观认识。 项目管理是一项独特的挑战，它需要有自己的战略和方法，可能更为重要的是，它需要人们主动行使领导人的职能。项目经理必须为整个过程制定适当的计划，而且要为自己的团队完成目标提供方法、支持和信息。通常有能力的项目经理常常不以发号施令者或者独裁者的身份出现，而是以推动者、团队成员和拉拉队长的身份发挥作用。 项目经理常常在公司位置非常特殊，往往也很不稳定，就像大家所说，项目经理要发挥王者作用，但是却不没有王者的权利，又或者权力往往得不到明确的界定。所以项目经理的管理风格必须侧重于说服和影响，而不是强制和命令，特别是当你的项目复杂度高，所需协同的技能组合度高时。 成功的项目管理是同时迎接人员和技术的双重挑战。它要求领导人员具有长远的战略眼光，并能够灵活地解决每天都会产生的各种冲突和问题。要想获得成功，就必须学会洞察并应对项目团队所面临的各种约束条件和团队散漫行为，同时要对最终目标保持清醒的认识。 项目经理需要谨记的12条规则 一、了解项目管理的背景情况 项目管理不是单纯地对项目进行管理，而是一种对项目经理的独特挑战，其特殊环境构成一种额外的困难。项目游离于组织原油的等级结构之外，这种环境与其说是对项目工作的一种支持，不如说是一种威胁，因为它们总是不断的发生各种变化。对于项目经理来说，在慷慨就职的同时，还需要睁大眼睛，密切关注自己将要面对的任务所具有的独特性质。 二、将项目团队的冲突看做项目进程中的必然现象。 项目经理对项目成功有害的时间（比如团队冲突）都会引起他们的严重焦虑。然而，现实中，这些人际关系的紧张是将不同背景的人员组合起来协调行动的必然结果。冲突作为团队发展的各个阶段的必然现象，通常是团队逐渐成熟的标志。 在发生冲突时，项目经理可能犯一个重大的错误就是不对其本质进行分析，就立即将其压制下来。尽管很多人际关系上的冲突起因是因为个人，但是也有一些源自于工作性质的不同，需正面对待，不然重复爆发是必然发生的，而且会带来更严重的后果。 一旦对团队成员之间所发生的冲突性质进行了分析，就可以正确应用多种多样的冲突解决方法，比如回避、引爆或者解决问题等。 三、了解利益相关者的情况及其需求。 项目管理是一种平衡活动，项目经理要在众多实力强劲的利益相关者所提出的种类繁多而又相互冲突的要求之间周旋。最佳方法之一：在项目的早期就进行现实的评估，并且明确各个主要利益相关者的情况和需求。当一方的去权益得到满足往往会以另一方的利益损失为代价，所有满足所有利益相关者的需求是不可能的，需要找到平衡点。 四、接受并运用组织的政治性本质 有人的地方就有江湖，就有政治，接受并运用它。可通过与其他利益相关部门的成员结成同盟、构建关系网络、相互之间童工谈判为那些表面看起来无法解决的问题寻找双方都可接受的解决方案，学会讨价还价。 五、身先士卒，勇往直前 项目经理需要如实地评价自己的优缺点。任何人都不可能掌握所有需要的知识和信息，也不可能精通所有的项目工作。承认自己的局限性，充分发挥下属的长处，作为项目的推动者。而且还需要具备的能力有：到哪里去寻求合适的帮助，以及如何提出正确的问题。 提出问题不是简单的问话，好的问题是对下属的一种挑战，这类问题都需要做出明确的回答，而不是似是而非。项目经理的工作就是提出问题，要求下属从各个角度和各种可能去考虑问题，并协助他们做出合理的决策。 六、理解成功的含义。 项目的成功不但受预算、进度和绩效影响，还有第四维度－－客户使用效果和满意度。所有工作都必须保证符合客户的需求为己任，项目经理必须听取客户的意见和建议，并作出相应改善。项目的未来使用者才是项目成功与否的决定因素！ 七、建立并维系团结紧密的团队。 团队氛围越健康，项目成功可能性就越大。极尽所能建立并维系这种团队。 八、热情和绝望都具有很强的感染力。 对项目的信心，团队整体都会从项目经理所表露的态度和情绪获得暗示。当团队成员提出建议或者了解到最新进展情况时，项目经理必须以诚相待，态度诚恳永远比敷衍了事更能赢得团队成员的感激。 九、向前看远胜于向后看。 用不停歇的提出“如果...那么..."的问题。“如果...那么..."的问题实际上表明，我们永远也不应该满足于项目工作的现状。导致项目失败的首要因素就是缺乏解决问题的机制。所有保持长远眼光可能对某些经理人员来讲非常扰头，但是这做法有非常重要的意义。我们无法控制未来，但是我们能够积极地对其做出回应。 十、时刻牢记自己真正的使命。 不要失去对项目自身目标的认识，不要被琐碎的小事所困住。项目经理无论是使用何种技术手段，都必须让所有团队成员保持对整体目标的清醒认识。成员是否领会？可通过“间断地考察他们对目前状况的认识。他们应该了解自己对于项目整体计划做出了怎样的贡献。他们能否清楚地认识团队其他成员的具体贡献？ 如果不了解，则需要更多的精力去建立他们对目标共同的认识。 十一、谨记利用时间。 ＊进行现实的时间预测，不要给自己留过多的余地。 ＊确切了解上级或客户的具体需求 ＊准备应急计划（进度顺延，团队关键成员的流失） ＊在需要时随时修正最初对时间的预计，并提供一系列变通选择。 ＊确保各项因素的落实（具体内容、资源情况等） ＊学会说”是的，并且....“，而不是”不，但是。。。“谈判时解决问题的关键。 十二、最重要的是计划，计划，计划 尽可能在第一时间就对各类事项做出正确处理，包括但不局限进度安排、构建团队、明确项目具体内容和制定预算。但过分精细或复杂的计划可能对项目也会有不利影响。所以项目经理必须进行计划，但是还必须保持足够的清醒，以便随时发现错误并相应修正自己的战略计划。俗话说“计划没有变化快”。

1.你可以不知道所有细节，但当你需要知道时你要知道这些细节在哪里。 2.不需要你驱动团队，因为你不是买单的那个人。你存在的价值，是让团队始终代表客户的价值并以此为努力的方向。 答案很抽象，可是我觉得无数项目管理的工具、方法都是以此为目标的。

门后的秘密 (豆瓣) 推荐这本书，里面的很多经验对你会有帮助

答案一定是“否”，当然项目人数在七人以下的可以例外，毕竟可能技术总负责也是你兼任的。 之前有个回答可参考：http://www.zhihu.com/question/19677325/answer/85506527 我也是做运营商行业的项目经理，向来把人放在第一位，准备进项目组的人要打听能力和工作态度，口碑不好的找个借口换掉。面试优先级最高，超过一般的会议。 另外以前我也是个喜欢做监控的人，整天盯着进度和承诺，近来逐渐有些改变，一直在给项目组灌输：交给你的事就应该做好，如果做不好提前叫，提前求助。不会再耗费自己的精力盯着别人干活，队伍反而成长的很快。 当然，我会有一个合格的技术负责人，如果没有现成的，那就培养一个。

1. 细节的基本设定当然要去了解，后期也得让反馈来看看效率；
2. 主要看战略目标是啥。