前言：
时光流逝，岁月蹉跎～
因为一个偶然的机会(朋友在某蓝做项目经理，便内推进去)从开发转型到项目经理，已历经5个岁月，工作目标不明确、恐惧撰写文档、领导询问基础业务，却苦涩尴尬摇摇头说不清楚、跟客户打交道唯唯诺诺，手心冒汗；
我是一名常年奋斗在一线的交付实施人员，做过双面角色(甲方、乙方)，再体验过6个月的甲方角色后，果断放弃(1.认为自己精力充沛还能拼搏；2.当时负责的项目群自认为简单且思考过程很少)重新登上乙方的快艇；
本文将对我5年的项目交付经验进行总结，希望能帮到工作转型迷茫的你；
why？
普通本科，日日增删改查，枯燥无味，迷茫，无法突破自身技术瓶颈，反而自认为项目经理很酷，每天不用敲代码，就是写写文档跟客户开开会，一天就过去了；再加上朋友的转型，头脑一热就顺利跟他待在一家公司下的同一个部门；
Dilemma？
虽然转型是顺利的，但过程却痛苦的；
合同金额90万………担任角色：开发组长…………人员规模：3人，模式:跨部门，瀑布管理 负责国内某家政策性银行小微企业信贷系统贷前的授信开发功能；“戴总，这是我们公司信贷部门的项目经理***”，这是我第一次 听到同事是以这样的方式介绍我；
大家都拥有2年左右开发经验，且开发模块整体被分散的很碎(当时介绍我的另一位项目经理协助的)，整体项目进行顺利。正当我窃窃自喜时，部门二把手来现场走查项目，一阵嘘寒问暖后，询问道：小伙子，客户现在评分是根据哪些字段的、分值范围都有哪些？我：…….这块不是我负责的，小强这块开发，他比较清楚??? 周报怎么不发？我：….没人跟我说呀?? 一系列的问题致使我呆若木鸡，然后领导笑嘻嘻就离开了。虽然我并没收到“毕业”的通知，但是在我离职不久跟一把手说这个事时，他说差点就把你辞退了，不过我们还是想看看你，毕竟你对工作还是认真敢言；
就这样，我算是稀里糊涂的完成了人生第一个项目；
Interview？
虽然自己没有经过过大厂的面试环节，但是以下的面试问题足以应对正常面试～
首先，自我介绍姓名、毕业于某某某学校，工作时间；目前就职于某某公司；转入正题，拿你最近的项目经验进行阐述，人员规模、合同金额、开发模式(瀑布/敏捷)，简要描述为何使用这种开发模式；然后从业务和技术两面进行切入，中途面试官可能会穿插你所介绍项目履历的业务或技术(不懂技术或技术遗忘，你可以解释说项目有固定的技术经理角色，你长时间做项目经理，详细技术层面已经遗忘，但跟开发沟通技术没有障碍)，最后就是目前薪资，期待薪资，入职时间等等；
以下是具体问题的回复描述(方向是正确的，给予你解题思路)
一、项目全流程：
1.销售阶段
线上漏斗
商机评审(客户沟通形成方案，部门poc支持)
概算投标(成本评估，销售报价，项目概算，领导层同步汇报决策)
合同签署(内部合同预审、评审流程，项目负责人移交至交付部门制定相应实施经理)
2.实施交付
项目启动(项目启动会，项目主计划、里程碑规划，需求规格说明书确认)
初版产品，开发、测试、实施(制定项目管理、关键节点控制等，二次商机)
验收交付(验收确认、文档整理归档、转入运维)
维保(巡检周期、生产问题处理、部门技术支持)
3.项目关闭
二、你觉得项目管理工作中最重要的是什么
1.项目交付趋势，
比如，我为客户做这个项目，部门公司是为了盈利的，那我就应该去着重控制我的项目成本，控制我的毛利率；成本控制：包含差旅费用和工时费用；一般部门都会有毛利率区间范围，如我上家公司毛利率为30%。对我们的项目作出预算；(哪怕你公司再怎么在意成本，也不可能出差让你住几十的酒店，不给你租房，不给你报销床上用品，水电费让你自己掏，剥削你的出差补助，所以成本控制更多的是体现在不要发生工作任务反工、上线失败、导致验收周期拉长)
那我的项目刚刚成型，研发部门刚出炉，公司比较看重市场布局，那我就去对我项目中的质量做，客户体验把控，注重客户的需求服务。
2.服务客户，把控质量。
客户的需求绝对了需求质量范围，是否要进行设计评审，是否要进行关键测试，与客户多沟通，通过客户的反馈来提升项目质量；
3.项目进度把控
项目中，节点按照项目主计划阶段进行排版，将工作任务解刨成多个小节点嵌套到主阶段中，明确开始结束时间范围，任务责任人，每日结束前都要跟踪进度，做好风险把控；按时完成
4.项目人员关怀
人员情绪的把控，精神层面的关怀员工，因为项目是你的，人员也是我的范围，都需要管理好；项目关键节点前/后，项目经费允许的情况下，一个月聚餐次/自掏腰包也可以(饭桌上，跟老铁们喝喝酒，引导他们倾诉倾诉、吐槽吐槽)
5.项目的可持续发展力，
识别新的商机，(通过和客户日常沟通，发现他们在引入新的系统，正好本公司也有改产品，将商机汇报给部门，商务进行跟进)，在项目管理过程中提升员工的综合能力，(某位项目组成员通过该项目转型管理者)，在交付过程中根据客户的意见需求形成功能升级改造，提升产品的满意度；
三、项目进度落后偏离轨道？
1.弄清楚项目的实施阶段；
2.审查需求不明确的问题
3.是否存在风险
4.剩余的开发功能，是否要加人还是加钱，或者申请延期，或者上线一部分功能，让客户消气；
四、客户频繁提sow额外需求
保证项目周期在可控的范围内，满足额外的工作需求，若提出的功能需求工作量大，且必须要做，可以对项目合同中约束的功能提出置换，注意：两者开发周期要评估需接近(因我做的项目大多数是银行类，我们直接与行内科部沟通，业务方是项目最终的拍板者，对科技部而言，他们比你更想尽快验收，所以额外的需求科技部绝大多数帮你回绝。)
五、同事未能按时完成任务
项目经理如何保证项目如期交付，首先先检讨自己是否任务安排超过了这个员工的能力。
如果没有超过，首先表示关心身体和状态，了解未及时完成任务的原因，如果原因是客观原因则一起加班跟员工来完成任务；如果是态度原因，则指出利害关系，责令其通过加班来完成。
1.项目经理和项目小组的成员应该努力采取补救措施，使项目能够重新回到预计的时间轨道上来；
2.为了保证项目能够如期完成，加班是一项很合理的措施。如果项目已经接近尾声，那么为了确保能够如期完成项目，加班可能是一个最好的办法。如果项目才刚刚进入初期阶段，可能还能够找到更为有效的办法。有一点不能忽视，那就是如果要让员工加班工作的话，加班费是必须要付出的；
3.项目经理首先必须清楚的了解哪些工作对于项目的成功来说是最最重要的。因为，如果项目不能如期完成的话，肯定是在关键环节上出了问题。了解了这个问题之后，就可以考虑重新分配资源来解决问题了。有的工作并不重要，那么就可以延期进行，把节省下来的资源运用到最最需要的地方；
4.反复检查项目工期安排；
5.确定可以缩短工期的工作；
6.交换资源：不太重要的工作留给那些工作效率稍低的员工去完成。
六、敏捷、瀑布区别
敏捷：
针对需求瞬息万变，产品需求的不明确性+技术发展日新月异(研发产品)，适应产品环境但却很难进行准确的资源规划，项目尽头无穷无尽(周期无法衡量)，难以准确定义“轻量的“或必要的文档。
瀑布：
1.严格把软件项目的开发分隔成各个开发阶段：需求分析，要件定义，基本设计，详细设计，编码，单体测试，结合测试，系统测试等；使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。
2.重视和强调过程文档，在开发的中后期才会看到软件原型，早起只能通过文档来了解系统的模样；在这种情况下，文档的重要性仿佛已经超过了代码的重要性。
3.瀑布模型把每个开发阶段都定义为黑盒，希望每个阶段的人员只关心自己阶段的工作，不需要关注其他阶段的工作。
好处是：可以让开发人员能够更专注于本职工作，提高阶段效率。
坏处是：a.由于各阶段的开发人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。
b.对于客户需求变更，编码人员会比设计人员更容易产生很强的抵触情绪。
c.在每个开发阶段都会有一些信息刻意的不让其他开发阶段的人员知道（本意是为了提到效率，但实际上有时候产生的是互相的理解偏差）。
4.瀑布模型遵循的里程碑节点，能让不太了解该项目的人也能看懂项目的进度情况（只有能看懂百分比就行），很适合向领导汇报用。所以管理人员比较喜欢瀑布模型，但是开发人员不喜欢，因为它束缚了开发人员的创造性。
5.既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。
软件生命周期前期造成的Bug的影响比后期的大的多。
代价比较大的主要原因还是每个开发阶段的步子过大，每一次调整都可能伤筋动骨。
6.更适合需求相对稳定的大型项目。
至此，5年的项目历程通过6点阐述完毕，突然又一次感叹，当初的毛头小子，到现在蜕变成行业内的资深玩家，有种看破红尘的感觉；未来可期，你我还需要继续努力～
最后，为梦想而拼，为专业赋能～加油！打工人
文章出处登录后可见！
