项目规划

项目规划

项目开始之前有很多准备工作需要进行，可行性研究、项目计划、风险管控、流程规范的制定，选择合适的工具对项目整体进行管控。除此之外，还要树立正确的认知，避免感性奔走。

1、可行性研究

可行性研究讲的是如何科学地论证项目的可行性，以及项目是不是值得做。如何科学论证是方式方法，是否值得做则是对投入回报比进行评估。 宝玉老师举了几个例子来说明可行性研究的必要性，以及在软件行业中大家对可行性研究的重视程度不高。 在过去的工作经历中，我是被要求写过可行性研究报告的，当时可能大家也只是觉得这是立项的一个必要文档，内容是其次的。

1.1、如何做好可行性研究

当你决定要做可行性研究的时候，你就已经成功了一半了，怎么做反而是相对简单的部分！

忽略可行性研究报告繁琐的引言、背景、定义，从核心的地方开始，如何进行通常从这三个方面进行：

1. 经济可行性：从成本和收益角度分析，看投入产出比。不仅分析短期利益，还要分析长期利益。
2. 技术可行性：技术上是否可以实现，不能解决的问题能否规避。
3. 社会可行性：法律、道德、社会影响等因素的考量。

光列出这三点还是很抽象的，具体分析的时候老师给了个示例，这里就不搬运啦，但是有一点觉得是很有必要的：分析最终都应该落实到具体的数字上。

经济可行性 从投入产出比的计算，来分别统计成本和收益。考虑收益的时候要对短期和长期都进行分析。

技术可行性 技术是否可行，关键还是在人。技术本身需要考虑两个方面：成熟度和覆盖面，对于不能解决的问题能够规避。

社会可行性 从三个方面考虑：1.是否存在不良道德行为。2.是否存在负面社会影响。3.是否违反相关法律法规。

2、项目计划

A：既然飞机老是晚点，还要时间表干嘛？ B：没有时间表，你怎么知道飞机晚点了呢？

看到这里有一点脸红： 见过很多人抱怨项目经理制定的计划有问题，却很少看到会有人愿意主动参与制定项目计划。如果你不主动参与计划的制定，最终就只能按照项目经理的计划执行了，出现计划不合理的地方，你也只能接受，工作就会一直很被动。

其实大部分情况下，计划出炉后，都会问大家的意见，然后鸦雀无声。

当然制定计划也不是那么简单啦，需要有步骤地去多方考量。

2.1、如何制定计划

制定项目计划，通常有三个基本步骤：
任务分解估算时间排任务路径。
1、任务分解 WBS（Work Breakdown Structure）：把要做的事情，按照一个树形结构去组织，逐级分解，分割成小而具体的可交付结果，直到不能再拆分为止。 在制定计划的时候，除了要拆解任务，还要反复思考各种存在的问题。对技术细节不清楚的地方，要寻求技术人员的帮助。

2、估算时间 主要是靠经验，要想估算准确，需要从两个方面入手：任务拆解越细致，想的越清楚，就能估算的越准确。要让负责这个任务的人员参与估算，

沟通最好的方式就是倾听和恰当的提问。

3、排路径 根据任务之间的关系，资源占用情况，排出合适的顺序。

2.2、设置里程碑

里程碑是承诺，不能轻易改变。 Deadline是第一生产力。 里程碑完成后，获得正面激励。

2.3、计划的跟踪调整

两种方式跟踪进度：
项目经理定期收集跟踪项目成员主动汇报。
好的实践：
每日站立会议看板。

3、风险管理

风险管理就是指在项目进行过程中，识别可能的风险，对风险进行评估，并加以监控，从而减少风险对项目的负面影响。

风险包含两个方面的内容：
发生后，会造成什么损失发生的概率有多大。
做好风险管理可以分四步来做。

3.1、风险识别

识别风险，经验很重要，因为大部分风险其实都是类似的。一个识别风险的方法叫检查表法，类似这样的：

软件项目的风险主要分成以下几类：
项目风险：项目预算、进度、用户和需求等方面。

人员风险：人员离职、人手不足等问题技术风险：采用的技术可能带来的风险。

商业风险：与市场、产品策略等有关的商业风险。
建议：定期针对风险问题开一些头脑风暴会议，一起发现可能的风险。让项目成员有合适的渠道来反馈可能发生风险的问题。

3.2、风险量化

风险识别出来之后，需要从两个方面去评估：

发生的概率后果的严重程度。

划分优先级来制定策略。

3.3、应对计划

针对量化后的风险，主要分成以下几个策略：

回避风险：对可能发生的风险，放弃或修改导致风险的方案，从源头消除。

转移风险：将损失转嫁出去，比如对自己不在行的服务，购买专业的服务产品。

缓解风险：在风险发生前采取措施，降低风险发生的概率。比如涨工资来留住核心成员 。

接受风险：在一些风险本身很难避免，或者应对风险的成本超过风险发生后造成的损失，那就勇敢一点吧！

3.4、风险监控

要做好监控，需要做好三个方面：

能对监控的内容量化设置阈值要有后续的报警和处理机制。

4、流程和规范

好的项目管理，不需要直接管人管事，，而是管理好计划和流程规范；项目成员不需要按照项目经理的指令做事，而是遵循计划和流程规范。

为什么要有流程规范：

提升团队效率：将好的实践标准化流程化，让大家可以共享经验借助流程规范，让项目管理从人治到“法治”。

4.1、如何制定好流程规范

可以通过四个步骤来开展：

明确要解决的问题提出解决方案：可以参考软件工程中，大家公认的好的实践。

达成共识、推广执行：要得到大家的人可，还需要配合奖惩措施来保障执行。

持续优化，不断改进。

非常重要的一点就是：应该尽可能借助技术手段来推动甚至替换流程规范。

5、项目管理工具

一切管理问题，都应思考能否通过工具或技术解决，如果当前工具或技术无法解决，暂时由流程规范代替，同时不停止寻找工具和技术。

项目管理中的工具可以三大类：

项目计划工具。

基于Ticket的任务跟踪系统。

基于看板的可视化任务管理。

5.1、项目计划工具

MS Project在分解任务和排计划方面十分方便直观。

MS Project缺点：不方便跟踪任务进度、进度不直观。 俺的结婚计划就是用MS Project，任务分解的时候很爽，但是因为没有同步协作，所以开始准备后就丢在一边没用了。

5.2、基于Ticket的任务跟踪系统

Ticket跟踪最早源于客服的工单系统，每次客服接到一个问题，就创建一个工单，后续和客户的每一次交流和处理，都要更新工单内容和状态，直到结束。 一个Ticket应该包含的信息如下：
标题：摘要性地描述Ticket内容类型：属于什么类型的Ticket：Bug、需求、任务内容：Ticket的详细内容。如，bug的话，包含bug内容和重现步骤。创建人优先级状态：未开始、处理中、已解决、重新打开、关闭等指派给谁历史记录。

利用燃尽图可以直观的预测工作将在何时全部完成。

缺点：整体Ticket状态不是很直观，不能清楚看到哪些任务在进行中。

5.3、基于看板的可视化任务管理

通过看板可以很直观地看到当前任务进展情况。

普通项目成员使用看板的流程：

5.4、工具的选择

项目计划工具：MS Project（windows）、OmniPlan和Merlin Project（Mac） 基于Ticket的任务跟踪系统：Jira、Azure DevOps、Github的issue 国内同类产品：

工具的选择就根据项目特色、团队成员和价格服务等因素来考虑。

6、技术转管理的建议

如果想技术转管理，先试试管好一个项目

宝玉老师真的是按照做项目的思路来讲的呢，首先分析，然后给出好的参考设计，具体编码和最后的验收就要看个人咯。

6.1、技术人员转型管理的障碍

管理最重要的一点就是大局观，要能从整个项目的角度，从整个团队的角度去思考，去确定方向，去发现问题，对问题及时解决及时调整。

程序员更多地把注意力放在技术细节上，就容易忽略其他事情，例如和其他人之间的沟通、不关心当前项目进展。

站在更高一点的角度来思考会冷静些，哈哈哈 不一定要转管理，但是大局观的思维转变，于个人也是有莫大的好处的。

6.2、如何管理软件项目

软件项目的管理分两个维度：管好人和管好事。

1、管人

项目管理中的人，主要涉及两类：客户和项目成员。

1.1、管理好客户的预期 客户关注的其实就是项目的四个要素，质量、范围、时间和成本，因此满足客户预期可以从这个四个方面入手：
质量达标：高质量交付产品

完整交付：按照约定的功能范围交付。

按时交付：按照客户人可的进度完成。

预算之内：控制在预算内。

出现矛盾时，按照软件质量与时间成本范围的关系来寻求平衡。

1.2、使用流程和规范来管理项目成员

好的项目管理，不需要直接去管人，而实管理好流程规范，项目成员不需要按照项目经理的指令作是，而是遵循流程规范。

2、管事

对项目中事情的管理，本质上就是对软件开发过程的管理。需要做的有：

选择适合项目的开发模式制定好项目计划对计划进行跟踪和控制，同时做好风险管理

6.3、经验分享

宝玉老师采坑分享：
控制你想写代码的冲动：因为对程序员写代码是舒适区，而且专注于细节之后，就很容易忽略项目中的问题。团队的成功，才是你的成功

形成自己的管理风格坚持就是胜利。

7、正确认识开会成本

宝玉老师的标题是：白天开会，加班写代码的节奏怎么破？ 问题抛出来，第一步是冷静分析。 开会特点：
有价值的：比如立项会议，可以创建仪式感，传递项目关键信息。

有成本的：人力成本很夸张的呢

既然开会是有必要的，我们要做的就是让其高效进行。

会议是不是有效的，取决于它创造的价值是不是高于其成本。

要想提高开会效率，从两个角度入手：降低开会成本，增加开会创造的价值。 降低成本：

砍掉没有价值的会议减少参与会议的人缩短开会时间：比如站着开会，666啊

会议是否是没有价值的会议，可以参考以下标准：

没有目标的会议不能形成决策，没有会后行动你属于可有可无的角色

提升开会创造的价值主要是思考提升会议的产出。

8、如何写好项目文档

程序员不喜欢的事： 不喜欢写文档不喜欢项目文档太少

第一步，分析：为什么不喜欢写文档？ 主要原因：

不知道怎么写太忙没时间写或懒得写敏捷开发所以不用写文档？

为什么要写文档
帮助写文档的人理清思路：先写文档，就会抛开代码细节，去站在全局思考。便于未来的维护和交接团队更好的协作沟通。

写文档最大的障碍是没想清楚，在心中只有一些未成型的混乱的想法和概念，必须要尼禄吧这些模糊的想法确定化和具体化，才能写出来。

如何写好文档 首先对文档要有一个正确的认识：文档写作，关键是通过文档把想法表达出来，至于用词、格式都是相对其次的。 有一些

具体可行的文档写作方式可以借鉴：从模仿开始从小文档开始从粗到细，迭代更新：先列提纲掌握一些基本的画图技巧，使用截图。

关于文档的建议：
文档很重要，但是工作的软件高于详尽的文档，平衡很重要不需要为代码写很多文档，好的代码格式，良好的注释，完善的单元测试可以

很大程度上替代针对代码而写的文档。在线工具优于离线文档工具。在线工具有很好的版本管理，方便多人协作。文档也应该作为项目任

务放到计划中。

第二遍快速读完，第一条总结就是，树立正确的认知，先冷静分析，会更加不容易被卷入自己的小世界。