前言
在业务项目中，我们一般承担的角色是一名开发人员，配合产品、UI、后端、测试，共同推进项目的上线。当你有足够的经验之后，你会有机会承担项目小组长的角色，也就是俗称的「Project Leader」。
我们应该如何当好一名「项目PL」呢？今天我来分享一下自己的经验。
正文
如果你们的技术团队是一个正规军，开需求会时，基本上都会有以下条件：
- 参与人员：此次需求的负责人、相关团队的开发同学、设计同学、测试同学
- 完善的文档：负责人会讲清楚需求的目的、预期、细节等等。
- 完整的UI：UI同学会展示UI的细节，注意点。
但其实，这并不是需求的开始。
立项
项目的第一步是立项。
当老板有一个想法时、产品有一些想法时、运营有一些诉求时，就会产生一个需求，需求会转到产品同学的手里进行落地，ta们结合多种情况，包括不限于：市场、已有项目、用户、产出等条件，先写一个简单的文档，也叫初稿。
定版排期
想法是无限的，一个产品可能有N个需求；但是开发的人力资源是有限的，所以不可能全部实现这N个需求。每个团队都有自己的周期，有的是根据版本、有的是根据时间，总之都有节点划分，所以会有一次排期会。
这个会议到场的基本都是大佬：项管、产品总监、各个产品负责人、技术总监、设计总监、前端负责人、后端负责人... 产品负责人们会简单阐述自己的需求，根据情况决定做还是不做。各端负责人会有一个基本的概念，知道自己这边是否有人力，是否有技术储备，并给出一些意见。
思考清楚之后，会决定一个项目负责人，负责跟踪整个项目的周期，负责人并不一定要清楚所有涉及的技术，但要有概念。
项目有大有小，有的可能是小改版，仅几天的工作量，就简单处理；有的是大型活动，可能会横跨好几周的时间；再大一点，就是专项，会横跨好几个部门、历经数月才能完成。这里以最大的专项为例。
技术调研
你作为此次项目的PL，接受到项目时，并不是前面提到的完备内容，可能是一个简单文档，也可能只有一句话。你要做的就是调研，调研内容有以下几个方向：
- 公司以往是否有类似项目可以参考。
- 市场是否有类似竞品可以参考。
- 该项目涉及哪些团队：APP团队？H5团队？技术后端团队？架构团队？其他业务团队？
- 该项目可能用到哪些技术栈：vue？React？SVG？cocos？Pixi?
- 会有哪些风险：技术储备不足？历史逻辑互斥？
期间会和产品和各端负责人进行多次讨论，以同步方案。
确认人员
涉及团队大概清楚了，技术栈也大概知道了，接下来就是确认开发人员，虽然在第一次排期会上有一次粗估，但是没有调研，不确认具体情况。这个时候就是做人员纠正，看是否需要加人、有没有实习生参与等等。
需求会
产品文档足够完善了，人员也定了，技术选型也有了，可以开需求会了。这时候就到了我们开头的那一幕。产品详细讲述需求的内容，其他同学根据自己的理解在会上积极提问，作为PL，如果有问题，会后抓紧确认，并进行同步。
技术方案
需求会结束之后，技术同学需要根据需求做出详细的技术方案。颗粒度越细越好，以H5为例：
- 项目逻辑梳理
- 项目组件划分
- 项目伪代码输出
- 项目难点解析及技术方案
分工和估时
根据技术方案，对每个细节进行估时，如果需要多个人力，还需要进行技术分工。
当你所在的端分工和估时完成后，需要拉其他端的同学以及项管对齐信息，以确保项目的合理安排。
启动会
这时候其实已经可以进入开发了，但因为这是专项，内容比较繁杂，时间跨度比较大，作为项目PL，你可以开一个启动会，一般会拉上所有和这个项目有关的人员。
这个会可不是为了开而开的，会上要强调已确认的东西，包括人员分工、估时、技术方案等等，最好能建立里程碑时间节点：A模块什么时候完成、B模块什么时候完成。以确保项目在既定的节奏中推进。
开发中
好了，开始开发了，耳机一戴，代码一敲，非常的快乐，但是你别忘了，你是项目负责人。最好是每天固定时间开一个每日站会，为什么叫站会，因为时间短。但是需要确认的东西并不少：
- 当前各端进展情况
- 明天开发计划是什么
- 有没有遇到什么问题
- 启动会提到的里程碑节点有没有异常
- 有没有人员变更
如果真的有问题，一定要及时解决。
比如有人员变更，必须抓紧联系端技术负责人，进行规划，否则项目就抛锚了。
比如有技术难题，也要抓紧跟进，因为可能涉及技术方案的变更。
提测后
开发人员当然希望没有一点bug，但是有bug也在所难免，同样，作为技术负责人，要每天监督bug的解决情况，如果有滞留，或者滞留较多的情况，一定要重点关注。和测试同学一起推进。适当的时候，可以组织体验会，邀请产品、设计、测试一起体验项目成果，一起发现问题，集中解决。
上线观察
在测试通过，产品验收完成之后，项目上线了，我们同样要关注项目的运行情况：
- 有没有BUG
- 是否有报错
- 性能情况怎么样
- PV、UV是否符合预期
如果有问题要及时跟进，具体流程可以看我另一篇《项目上线后bug如何处理》
复盘
如果是大型项目、或者问题出现较多的项目一定要进行复盘。
- 问题到底出在哪里？
- 哪些地方可以改进？
- 此次项目中学到了什么？
- 哪些流程可以沉淀并推广？
- 涉及技术是否可以提取和封装？
等等，项目的开发不仅仅是产出了项目本身，也可以学习到一些更高维度的内容。
文档
作为PL，在以上流程中，除了执行之外，也不要忘了文档记录，在这里也给大家分享一下我的文档目录：
- 项目启动
- 项目概要
- 项目排期
- 里程碑节点
- 技术设计
- H5设计
- 后端设计
- ...
- 会议纪要
- 遗留问题汇总
- 每日站会
- 问题谈论
- 测试体验会
- 项目复盘
- 问题复盘
- 流程沉淀
- 技术沉淀
总结
如果你没有做过PL，希望这个文档对你有所帮助；如果你作为PL，做了更多的事，也希望给我建议，我们共同成长。
