内卷情况下，工程师也应该了解的项目管理

简介：大家好，我是程序员枫哥，🌟一线互联网的IT民工、📝资深面试官、🌹Java跳槽网创始人。拥有多年一线研发经验，曾就职过科大讯飞、美团网、平安等公司。在上海有自己小伙伴组建的副业团队，目前业余时间专注Java技术分享，春招/秋招/社招/跳槽，一对一学习辅助，项目接活开发。
🌈更多学习内容，欢迎👏关注👀【文末】微信公众号：IT枫斗者
🌟🌟程序员找工作，就上Java跳槽网：www.javatiaocao.com

内卷情况下，工程师也应该了解的项目管理

背景

作为研发工程师，我们的工作时间大部分时候都是在某一个项目上。一些较大的公司或比较注重项目管理的团队中会有专门的项目经理负责项目进度的把控，也有一些团队是由产品经理来负责。
作为研发人员，我们应该了解一些基础的项目管理概念，尤其是在当前更内卷的情况下，以便更好的与其他同事合作，提高自己抵御风险的能力。

项目管理基础概念

项目管理的三大关键要素
- 时间
- 资源/成本
- 范围/质量

项目计划

列出项目的工作分解结构

按照职能，时间阶段，主要交付物，列出项目的工作分解结构。要一直分解到能估量出单个任务的责任、预算和计划等，并确定交付标准。

工作分解参考原则：
- 对业务足够熟悉才能够更好的工作分解
- 确认是否有模板或先前类似的项目用来帮助识别活动，确定风险点等
- 需要考虑公司休假及国家法定节假日
- 任务尽量分解在一周内完成的粒度
- 任务需要考虑等待时间
- 一个任务尽量分解为一个人可以完成的粒度
- 任务历时的估算要以小时为单位
- 任务量的分配以工作时间的85%为宜
- 人员分配以后要确认人员使用率
- 缓冲时间不要分配到各个任务上，可在阶段后或整个项目后留出缓冲
具体到我们的工作中，一个需求首先是产品输出PRD文档，而后设计同学输出具体的设计稿。当研发收到需求后，会针对这个需求排一个开发内部的计划（我们内部管这个叫拆单）。
在我们的这个拆单中，我们会将一个需求的开发任务拆分成以小时为单位的任务，并以此确定最终的交付时间。例如经过拆单我们评估大致要一个人开发20个工作日，安排一个人从6月3日开始开发，去除端午节以及周六日的影响是在7月1日可以开发完成提测。

明确关键时间点或里程碑点

列出计划后，我们需要设置几个关键点，确定好每个时间点的交付物。同时在计划中预留出一定的缓冲时间，且缓冲时间最好是放在项目最后，而非切分到每个阶段。
回到我们的项目中，最终交付可能涉及到以下时间点：
- PRD输出时间点
- UX设计稿输出时间点
- 客户端开发完成时间点
- 服务端开发完成时间点
- 客户端与服务端提测时间点
- QA一轮测试时间点
- QA二轮测试时间点
- 上线：客户端发版，服务端发布

明确涉及的人以及所负责的内容

责任落实到个人，每一项任务分配一个且只能是一个负责人，负责计划、估算、监控及报告任务数据；负责人不一定需要亲力亲为，但必须对交付负责。
回到我们的项目中，整个项目的负责人可能是产品经理。具体到研发这里，假设客户端内部参与这个需求有三位同学，将这个需求划分为三个部分，每位同学指定负责开发其中一部分，但最终我们一定要指定一位同学负责整体客户端的技术方案和需求的落地，以及对外沟通协调。
这位同学可以是技术Leader，也可能是虚线汇报的Leader，也有可能就是有owner意识的开发同学。这样指定整体的客户端才能按时高质量交付，而不会出现客户端内部互不关心对方实现、出现遗漏功能、边界不清等问题。

输出项目进度计划

指定项目计划时需要考虑各种情况，例如
- 假期
- 跨部门合作
- 各个任务依赖关系等等
例如前面我们确认开发完成提测的时间时，就需要将端午节假期考虑进去。
不过前面没有提到的是，提测之前应该先和服务端确认联调时间，确保联调的时间要在提测时间之前，所以最终确定时间点时，一定是要考虑好各种依赖关系。

沟通确认

与各相关责任人就计划进度进行沟通和确认，对计划中不合理的地方进行修正，并达成一致。

项目进度得到确认承诺后，更能有效执行：
- 确认关键时间节点（不断与干系人进行确认沟通）
- 明确各自承诺的内容
确认好计划后，各个环节都要确认时间点没有问题，算是针对此给出了承诺。这里面有几个小点可以扩展聊一下。
做出承诺后，一定要做到
作为研发同学当我们给出承诺之后，我们是一定要做到的。否则不但会影响整个项目的推进，个人以及团队的信誉也会收到较大的挑战。
如果连续出现这种情况，那研发给出的承诺大概率都不会被信任，信誉也就破产了（如果需要裁撤人的话，这样的同学大概率也会被优先裁撤了）。
开发内部估时一定要相对准确
开发内部估时一定要相对准确，否则就是在坑自己。
在给出估时的之前，一定要先做好技术方案。整体的技术方案内部过一遍，可能还要再和服务端确认一遍接口协议等，大家都比较认可之后，再基于此来拆工作时间，这样可以做到相对准确。
不同能力侧重点的同学负责模块也应该不同
擅长复杂UI动画的同学，不让他去负责最复杂的动画实现，这样的安排一定是有问题的。能力强的同学就要去啃项目中最硬的骨头，处理最难的问题。
当然这样安排也会使部分同学的能力得不到锻炼，这里面最终会有一个取舍平衡的问题。如果是一个紧急且重要的项目，就要以能够快速高质量交付为目标来安排。

计划的复核与修正，发现问题、解决问题

计划执行过程中，肯定会发生各种各样的问题（下一节我们会详细讨论项目风险管理）。我们需要注意的是要让风险尽早的暴露出来，而不是项目即将交付了才反馈存在问题，此时想要挽救可能也无力回天了。
过程中也要回看制定的计划是否是合理的，如果最初制定计划时，由于比较急切或者经验不足，确实制定了一个不太可能完成的计划，那么也要做好及时的修正以及预期管理。

项目风险管理

正确认识风险

风险与不确定性相关，不确定性越多，风险越大
负面的风险称作威胁，正面的风险称作机会
具有风险管理意识则项目有序，没有风险管理意识，则项目无序、状况不断
具体到项目中，首先是制定技术方案时尽量考虑完善。其次在拆单时，尽可能将单子拆的比较细，一个任务4-8小时会比较合适，这样就控制住了不确定性。
可能在制定技术方案时我们识别到了某个点存在技术上的不确定性，例如客户端开发不确认此处是否能够实现，需要调研；或者此处可能存在厂商兼容性问题，需要做兼容性测试。

识别风险

识别出那些当真实发生时会对项目造成影响具体的不确定性，需要注意的是：项目风险必须是具体的，而不是空泛的担忧或疑虑。
前面我们提到可能某个点不确定能否实现，此时上报时间点时就要具体说清楚是哪个点。这里千万不能有担心我提出这样的点会不会被认为技术不行，而隐瞒的心里。
开发需求时技术能力的差异可以通过调整为组内其他同学来负责的方式补足，或者给时间去调研、反编译竞品App的方式学习补齐。如果因为隐瞒，而最终导致项目延期，这样的问题实际上会更加严重。
所以在识别出风险后，一定要及时提出来，上下游都要清楚，同时要言之有物。

确定风险发生的概率

评估风险出现的概率来确定一个特定时间或场景出现的可能性，可以用数字或次序值来评估概率。

风险评估分级

风险 = 影响*概率

风险应对措施

避免：改用其他方法消除风险
缓解：降低风险概率或风险影响
转移：转嫁给第三方
接受：接受风险和结果
针对不确定的点，明确提出来需要调研的时间。可以在制定项目计划时反馈，先确认其他部分的时间，不确定的这个点给出一个预估时间，例如大致要一周时间，也要明确说出来这个预估时间不准，调研后可能立即就可以解决。或者一个预估的时间也给不出来，那么可能要看看是不是要安排其他同学针对此专门去调研，不占用这个项目的同学，这个项目先正常推进开发。
甚至可以协调产品经理看看这个点在产品设计上做好调整的准备。在一个成熟的团队，这种情况是有可能发生的，产品经理的想法也许是天马行空的，他（她）在确认需求之前可能不会从如何落地的角度去考虑，具体如何落地是开发需要考虑的事情。

风险管理要点

培养自己的风险管理意识，提升项目控制能力
控制粒度越弱，风险越高
了解项目的主要风险及应对方案
提前指定风险应对计划
手上要有一定的缓冲
手上要有备选方案

项目执行与控制

项目跟进的频率

确认好时间节点之后，提前告知对方需要配合的地方。
制定技术方案时，就要确认好前后端需要联调的点，即将到达联调时间点之前也可以与服务端沟通一下，看看可以先联调哪个点，后联调哪个点，确认好顺序。
千万别出现重来不沟通，客户端等着服务端找他，服务端等客户端找他的情况，直接死锁了。
认可对方的努力，及时给出正面的反馈
比较成熟的做法是，当对方的工作做的非常好，也要学会夸夸模式。
例如服务端同学考虑的非常全面，弥补了你的技术方案上的漏洞，或者联调时接口逻辑都是通的且没有Bug，沟通时积极正向，整体体验非常棒。
QA同学测试的比较全面，测试过程中考虑到了很多逻辑边界，涉及其他模块的影响，以及资源占用如内存泄露等问题，让你觉得非常靠谱安心。
在项目群中，启动夸夸模式，没有人是不喜欢赞美的，尤其是对方主管也在群中，效果更佳。及时正向的反馈，会让后续的合作更加顺畅，其他同事也会更加喜欢与你合作。
当然夸人也是有一些小技巧的，别夸的太尴尬。一般从专业性、工作主动性、沟通与团队协作几个方面入手就行了。别太假，更别两个人约好在群里互相夸对方，那画面不敢想象。
沟通中存在的问题，采用逐渐设计的方式提醒
私下沟通
项目群中沟通
与对方主管沟通等
已经到了联调的时间点了，但是服务端的同学还没有准备好接口，客户端可以通过其他方式先好自己的逻辑，但是没有联调过终归是不能提测的，此时你可以先私下来沟通。
如果对方不回复你（已读不回），也不说他到底啥时候好，你可以再提醒一至两次，结果还是没有改善。此时就要将问题上升了，例如在项目群中反馈给项目经理或者产品经理"本该昨天甚至上周联调的接口还没好"，后续交给项目经理去沟通。
注意此事不是为了甩锅，也不要觉得不好意思。可能这位同事存在其他问题，主动PUSH问题的解决就是在保证项目能够按时去交付，何况你已经提醒过几次了。