项目经理不一定要技术最好，但技术好的项目经理在进度推进困难的时候将起到很大的作用。
分析、设计阶段（也可以加上测试，但千万别说编码或开发阶段）。根据《人月神话》的观点：1/3计划、1/6编码、1/4构件测试和早期系统测试、1/4系统测试。
管理能力和经验的综合题，可能没有人有相同的观点，那你可以按照某些思路来侧面解答：我会挑选一个技术过硬的人作为我的替补和项目的轻骑兵。团队中必须有机动人员，否则你的项目十有八九会夭折。其他的人会被平均的分配任务。我们会在每周进行全面的任务分配，每个人获取一周左右的工作，然后每天的工作由他自己完成并汇报。
根据林锐博士的观点：企业的根本目标是合法地赚取尽可能多的利润，使企业利益最大化。企业所有的特定目标和行动都是围绕上述根本目标开展的，任何背离根本目标的行动都将对企业造成伤害，应当杜绝。基于此任何人都不要强调我将严格遵守XX模式，带领团队开发出具有XX等级的产品，企业需要的是能够带领团队按时、合格的开发出产品的Manager。
不用回答你看过的课本，枚举几个经典的当然前提是必须真的看过至少浏览过主题和目录。比如《Java编程思想》、《Java模式》、《人月神话》等。由于将来要做的是team中的替补leader或真正的leader，所以你必须说出软工的东西。
依赖关系可以通过将任务及其后续任务的标识符进行关联来表示。
依赖关系说明了任务之间关联/并列的要求。依赖关系可以是指在另一个任务能开始之前有一个任务必须完成。例如，逻辑模型必须在物理模型前完成。但测试并不是要在所有编程工作完成之后才开始，如：没有完成的程序对线性测试没有影响。项目计划加入依赖关系，就能找出项目的关键路径并且能够确定它对项目工期的影响。
PS：线性测试
线性测试的每个脚本都是相对独立的（不产生其他依赖和调用），所以任何一个测试用例脚本拿出来都可以单独执行。
优点：每一个脚本都是完整且独立的缺点：
根据组织使用的具体的工具（如tower、tapd），可以将资源拆成更小的资源/单位，或者可以将任务拆成更小的任务。
价值：这些报告对已实现工作的评价和作为，会在计划下一个工程或阶段的输入时有价值。另外这种比较也可以将范围变更对项目的影响记录下来。
项目计划是实现成功系统的路线图。它提供了一种手段来通知每个人他们做什么及何时完成。它帮助项目经理使管理层，商务用户和支持团体了解项目状态和调整特殊的资源。逐项列记的“一览表”协助对任何变动的影响进行迅速评估。当实况报告与计划联系起来后，项目计划为今后项目的任务划分和估算提供了有用的信息。
进程安排是一门艺术。根据已知有关业务目标的事实，公司一般标准，以及可以利用的过去的经验。可以从清楚地定义范围和目标开始。把项目的风险和制约做成文件。差的估计源于对业务知识和项目范围缺乏了解。可以从项目任务分解入手，例如先划分阶段，然后定义每个阶段的活动，再定义每个活动中的任务。识别里程碑和可交付产品，并将他们文档化。项目计划是当信息变得可以利用的时，不断细化的有生命文件。很好地记录进度的变化对项目经理，开发团队，支持团队，以及管理层，商业用户都有益处。
先在不考虑资源限制的情况下制定开发计划。在任务旁边加上诸如数据模型制作者，业务分析员和用户等角色。再加上能将任务重叠起来的补充性的资源。在计划中要考虑开发团队包括支持团队和用户代表失去一个或多个资源的情况，要在每个任务上增加15%的余量。要使项目小组的组成容易理解，要有角色所必备的技术水平的说明。
如果使用得当，测量标准是一个有价值的工具。它们提供测定开发系统的复杂性和工作量的方法。度量结果为制定项目计划提供了信息输入资源，并且是确定发展方向的有价值的历史信息。软件测量标准将有助于开发更好的软件。不过，最好有3年的历史资料。
在增加培训任务的同时要扩大工作量，缩小每个工作单元。在评价新技术在开发中的影响的过程中加上额外的原型和检查点（里程碑）。
首先，确定和区分项目的优先次序，哪些项目是必须在今后的18个月内完成的。把绝对的最小的总人数与每个项目联系起来。向管理者和用户说明对进度表的影响。因为也许两者都不愿意接受进度表的变化，因此或许可以给你一些例外。减掉顾问比去掉一个雇员要好。每个项目的顾问也许可以用雇员代替。坚持运用学习曲线理论并逐步减少顾问人数。可以把一些顾问的工作从一周降低到一星期中的2或3天以应付人员削减。如果公司有提前退休的一览子法案，赶紧寻找一些有资历的、适用的雇员。牢牢记住失去“老资格的人”你也许就失去了有价值的知识。尽可能将一个快退休的人和新手组合在一起。以满足业务目标为前提，确定剩下员工的重要性以及他们在每个项目中的重要性。使新手和经验丰富人员的比例适当。两者都是确保项目和公司不断成功的财富。
这是经常发生的不愉快情况。雇员总是认为他们能胜任某个职位而管理层还没有意识到这一点。因此，要进行如下调查：员工的管理能力、阅读评估和状态报告。
当雇员变得不合作时试图发现一些变通的方法并且针对这种状况进行一些个人谈话，谈话内容包括：
弄清楚状况；与员工一起分析他具有的能使他得到提升的资历；强调初期协作的必要性和管理层是如何高度重视合作关系的。
自由的大小取决于每个人的技能和专业水平。一个好的经理是“面向结果”的，并且能创造一个能使团队广泛交流的环境。无论如何，每个员工每周需提交项目和商业目标有关的状态报告并且经理要进行审查。这有利于加强组织建设并使每个员工致力于他们自己应完成的工作。
即将退休的员工能提供大量的信息。一个人在把所有业务知识和关系网拒之门外时必须三思而后行。因此，要利用这些人的能力：他们在某些特殊技能方面可以作为新手的老师。明确主要的工作利益，要使项目能充分利用这些技能，可以利用他们从非正规途径得到的必要支持（不用通过正规的，官僚的途径完成工作）。
首先，判断这些员工的模式。换句话说，是偶尔还是一贯如此。
钱不是仅有的激励因素。人们需要了解他们是否对项目有积极的贡献。因此，要强调拥有的自豪感并且举行业务会议，在会上让用户谈谈他们对项目组的良好印象。同时，让用户对他们的功能和业务提出一个概括。培训是一个激励因素。因此，状况会议可以作为一个非正式的培训课程。不定期地举办有关新技术的内部研讨会。如果培训课程费用太昂贵，可以租赁技术录像带。订阅杂志，有许多技术杂志是免费的。必须记住的是，忽视培训将使团队的精神低落。这样会影响产品的质量和数量。
首先，做一个工作所需技能的描述。如果你不了解现在的需求就很难雇到合适的人。
其次，要了解团队成员的个性，列出团队现在缺乏的技能或工作风格。与人力资源部门讨论所有这些情况，包括调动现有员工。
最后，当候选人到来，针对现有工作进行面试，同时还要了解他是否具有新岗位所需的技能。
辨别出人的不同个性。分别向员工表述每种风格的价值。当与冲突双方试图分析申诉或冲突的原因时应持有客观的态度。
外援：和管理顾问的方法相同。不过，他们可能有一个经理来负责外包合作。首先要和这个经理一起组织日常会议。坚持做工作周报和可交付产品的拷贝。
直到找到问题的原因时，问题才能解决。原因不一定是分析问题或解决问题的能力差，可能是一个管理方面的问题。该员工：
如果不是上述原因，要注意观察，找出原因所在。例如当所有人遇到问题时，都会找这个人。那么，这个人的工作经常会被无数次地打断。检查:典型活动：交付后的三到六个月对目标成本，开发工作，可见/不可见收益进行检查。典型交付：实施总结报告。
贯穿整个项目。
眼见为实。因为它是验证功能、业务规则、用户需求数据和测试的一个好工具。值得注意的是，原型不会成为粗制滥造的产品。原型需要较好地维护。原型应能在过程和数据不完全的情况下，显示各个窗口和窗口间的导航关系。
基于C/S开发的项目需要额外的任务编制各部分的计划。各部分计划中必须包括对事件、数据和网络位置的检查。必须根据用户的要求决定C、S的分布。在C/S环境中，要运用外观建模技术和制作图形界面原型相结合和方法。
维护本身就含有负面意义。许多公司认为维护工作是不好的、第二位的、费钱的，并且是对现有应用的不断修改。
必须懂得维护也有它的生命周期。因此，应建立一个围绕维护活动的控制和质量的工作计划。新的开发计划包括：
这样可以使项目经理和用户看到变更对项目进度的影响。
维护阶段/活动有：
面向对象的项目团队人员较少，团队成员不需要有太多创意。重要的是技术和个人的角色。每个成员需在项目的不同阶段承担不同的角色。因此，每个成员必须了解他们自己的优缺点。围绕一个或多个人员的角色有：设计师（系统的整体结构）、抽象工程师（类和类族）、应用工程师（完成和组装类和类之间的消息）由于传统的开发方法，个人角色是不能互换的。软件开发是个人的努力的结果。即使是由最优秀的，最聪明的人组成的团队，如果他们不能为共同的目标而工作，那么就是最简单的项目也不能成功完成。
人员管理能力成熟度模型。PM-CMM和CMM都是卡内基.梅隆大学的软件工程研究所开发的概念模型。PM提供了人力资源管理的组织方法。
五个层次是：
一个开发或维护的生命周期是描述一个特定项目的开始，中间环节和完成的方法的。一个生命周期包含了完成特定目标的所有步骤，任务或活动。每个活动可能有一种特定的方法。例如，制作数据模型可能会按照JamesMartins建模方法。对象建模可能会采用IvanJacobson方法。生命周期通过运用所有方法来完成业务目标。
项目计划中应包括如下阶段（不是以瀑布/线性次序）：
项目管理
需求分析
设计
开发
测试
实施和支持
然后，分解项目任务，找到可以优化的路径，与公司高层沟通，得到支持，以使用项目得以继续进行，直到成功结束。
早会，分解任务，分配任务，解决问题，跟踪项目进度，风险预测，风险控制。
以人为本这是前提，只要保证将合适的人各就各位，这为项目的成功奠定了良好的基础。成本、功能、质量、进度是矛盾统一体，要想以最低的成本按进度要求的完成一个功能完备、质量高的项目，这多半是理想状态下的情况，真正的项目实施之后很难达到这个要求，所以，我们必须在做项目分析和做实施方案时，做一些取舍。
首先严格控制成本，这是做一个项目的最终目的，我们需要盈利，亏本的生意我们不做，除非我们的项目组是无需盈利的机构组织；进度与成本成比例，进度越快成本越低，所以保证进度是控制成本的手段。
其次项目质量和功能，已定义好的必要功能是一定要的，多余的内容尽量暂不考虑，在设计之初多考虑一下系统的可扩充性，设计一个易于修改和测试的系统，严把测试关是保证项目质量的有效手段，一个项目最重要的是在设计阶段要尽量考虑全面，这对项目经理来说，经验很重要。
简单总结：首先考虑成本，然后再对其他4项做出取舍，在项目整个过程中，根据进度适当调整。当然最好是能以我们最理想的情况下成功的完成整个项目。
我们无法完全规避风险，只能把未来的风险控制在尽量低的范围内。
需求变更，这个是所有的项目经理都会遇到的问题。我一般的方案是看需求的重要度和项目基准：
我在日常工作中经常会遇到这种情况，我目前很多时候都在处理2类人的关系：程序员和产品，程序员的前端跟后台。
一般我的方法是，把他们拉到同一个房间去沟通，做中间人去调解，因为大家都是要做事的，所以总会找到一个折中的办法。我也有遇到不配合自己工作的同事，我是用自己的办法解决的，就是，没有一顿饭解决不了的问题。吃个饭，聊一下。很多时候都是沟通没到位，说开了就好了。
我们一般是去到公司跟用户去聊，然后用笔和纸记录下来用户所有的需求，回来之后我们会进行需求评估和需求排序。哪些优先级比较高，哪些可以先不做，很多时候用户想要的是一个大而全的东西，但是一般来说都不是一蹴而就的事情，所以我们会拿着排好的需求给客户确认，然后才会敲定，本次开发的需求。
（这块我有点懵逼，说的不好）我们获取需求一般是观察客户流程，因为我们的软件是需要知道客户如何一步一步操作的，然后再跟用户去聊，需要注意的事项。有时候，我们也会用到问卷调查。例如有一次我们需要调研某一个建模功能是否需要筛选行业的时候，就发出了调查问卷。
【下次再遇到类似问题，我就说，我们一般有几个渠道，一个是市场反馈，也就是说市场那边根据客户需求，反馈给我们的需求，另外就是我们和产品一起出去需求调研，收集需求。最后就是我们在产品中有一个留言板，如果用户给我们留言了，我们也会收集到相应的需求。】
（一连串的问题，问蒙了。假装淡定的回答）我们这个调查问卷的发出去有100来份吧，得到的有效数据大约只有20分左右，我们做这个调查问卷之前其实已经有一套方案了，但是在发布之前，还是确认一下用户的意向。其他的案例，应该没了。（虚汗。。。）
就像我刚才说的，对需求的控制是一方面，与客户确认好要做的事情。同时，在开发的过程中，做且只做项目范围内的事情，防止发生镀金事件。
【首先应该是规划，当时我没说，应该是在项目开始时，其实要制定好规划和里程碑。也就是wbs。】
首先范围，范围的确定……&*%&*（上面说的范围控制）。
最后就是质量控制，质量控制一般我主要是抓测试和验收。我们会经过2-3轮测试，测试BUG不超过3个才能达到验收标准，然后我们在交付给用户使用之前，也会有一个自我验收评审的过程，只有经过验收评审会议的产品，才可以正式上线，所以我们这边用户的投诉比较少，质量还是可以的。
PS：WBS是一个描述思路的规划和设计工具。它帮助项目经理和项目团队确定和有效地管理项目的工作。工作（work)--可以产生有形结果的工作任务；分解（breakdown)--是一种逐步细分和分类的层级结构；结构（structure)--按照一定的模式组织各部分。
总监：哦，（写下了抗压，沟通，学习）说到抗压，你说说压力吧。
我：我觉得我抗压还行吧，曾经2点起来改BUG，三个多月没怎么休息。
总监：你这仅仅是工作方面的压力,能说说其他方面吗。比如来自用户的压力，来自团队内部的压力，还有来自上级的压力。（然后写下了用户，团队，上级）
我：
我觉得跟客户，就是需要耐心的沟通，很多时候沟通都是要有技巧和耐心的。（其实我没怎么对应过这些，真不知道如何回答。）很多时候客户可能只知道业务，不懂需求，多沟通，多聊下业务，需求就自然出来了。
【其他网友观点：强势也分很多种，我的想法是从专业的方面赢得信任，抓到客户痛点，积极迎合吧，沟通上主动、谦逊，就事论事，效率高。】