项目开始之前有很多准备工作需要进行，可行性研究、项目计划、风险管控、流程规范的制定，选择合适的工具对项目整体进行管控。除此之外，还要树立正确的认知，避免感性奔走。
文章目录
读的时候并没有觉得项目规划这部分会有这么多东西的呢，笔记整理下来真的是有点多哦。
1、可行性研究
可行性研究讲的是如何科学地论证项目的可行性，以及项目是不是值得做。如何科学论证是方式方法，是否值得做则是对投入回报比进行评估。
宝玉老师举了几个例子来说明可行性研究的必要性，以及在软件行业中大家对可行性研究的重视程度不高。
在过去的工作经历中，我是被要求写过可行性研究报告的，当时可能大家也只是觉得这是立项的一个必要文档，内容是其次的。但是我写的时候最大的困惑就是如何进行，至于有什么用，并没有想过啦~来来来，123来啦
1.1、如何做好可行性研究
当你决定要做可行性研究的时候，你就已经成功了一半了，怎么做反而是相对简单的部分！
忽略可行性研究报告繁琐的引言、背景、定义，从核心的地方开始，如何进行通常从这三个方面进行：
- 经济可行性：从成本和收益角度分析，看投入产出比。不仅分析短期利益，还要分析长期利益。
- 技术可行性：技术上是否可以实现，不能解决的问题能否规避。
- 社会可行性：法律、道德、社会影响等因素的考量。
光列出这三点还是很抽象的，具体分析的时候老师给了个示例，这里就不搬运啦，但是有一点觉得是很有必要的：分析最终都应该落实到具体的数字上。
经济可行性
从投入产出比的计算，来分别统计成本和收益。考虑收益的时候要对短期和长期都进行分析。
技术可行性
技术是否可行，关键还是在人。技术本身需要考虑两个方面：成熟度和覆盖面，对于不能解决的问题能够规避。
社会可行性
从三个方面考虑：
- 是否存在不良道德行为
- 是否存在负面社会影响
- 是否违反相关法律法规
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、管理好客户的预期
客户关注的其实就是项目的四个要素，质量、范围、时间和成本，因此满足客户预期可以从这个四个方面入手：
- 质量达标：高质量交付产品
- 完整交付：按照约定的功能范围交付
- 按时交付：按照客户人可的进度完成
- 预算之内：控制在预算内
出现矛盾时，按照软件质量与时间成本范围的关系来寻求平衡。
2、使用流程和规范来管理项目成员
好的项目管理，不需要直接去管人，而实管理好流程规范，项目成员不需要按照项目经理的指令作是，而是遵循流程规范。
2、管事
对项目中事情的管理，本质上就是对软件开发过程的管理。需要做的有：
- 选择适合项目的开发模式
- 制定好项目计划
- 对计划进行跟踪和控制，同时做好风险管理
6.3、经验分享
宝玉老师采坑分享：
- 控制你想写代码的冲动：因为对程序员写代码是舒适区，而且专注于细节之后，就很容易忽略项目中的问题。
- 团队的成功，才是你的成功
- 形成自己的管理风格
- 坚持就是胜利
哈哈哈，看到最后一条的时候笑了。
7、正确认识开会成本
宝玉老师的标题是：白天开会，加班写代码的节奏怎么破？
问题抛出来，第一步是冷静分析。
开会特点：
- 有价值的：比如立项会议，可以创建仪式感，传递项目关键信息。
- 有成本的：人力成本很夸张的呢
既然开会是有必要的，我们要做的就是让其高效进行。
会议是不是有效的，取决于它创造的价值是不是高于其成本。
要想提高开会效率，从两个角度入手：降低开会成本，增加开会创造的价值。
降低成本：
- 砍掉没有价值的会议
- 减少参与会议的人
- 缩短开会时间：比如站着开会，666啊
会议是否是没有价值的会议，可以参考以下标准：
- 没有目标的会议
- 不能形成决策，没有会后行动
- 你属于可有可无的角色
提升开会创造的价值主要是思考提升会议的产出。
哇，评论区有一道发光的评论，我觉得超级有用。
当然，评论区的宝玉老师依旧可爱~
8、如何写好项目文档
程序员不喜欢的事：
- 不喜欢写文档
- 不喜欢项目文档太少
哈哈哈，笑了
第一步，分析：为什么不喜欢写文档？
主要原因：
- 不知道怎么写
- 太忙没时间写或懒得写
- 敏捷开发所以不用写文档？excuse me?
为什么要写文档
- 帮助写文档的人理清思路：先写文档，就会抛开代码细节，去站在全局思考。
- 便于未来的维护和交接
- 团队更好的协作沟通
写文档最大的障碍是没想清楚，在心中只有一些未成型的混乱的想法和概念，必须要尼禄吧这些模糊的想法确定化和具体化，才能写出来。
如何写好文档
首先对文档要有一个正确的认识：文档写作，关键是通过文档把想法表达出来，至于用词、格式都是相对其次的。
有一些具体可行的文档写作方式可以借鉴：
- 从模仿开始
- 从小文档开始
- 从粗到细，迭代更新：先列提纲
- 掌握一些基本的画图技巧，使用截图
关于文档的建议：
- 文档很重要，但是工作的软件高于详尽的文档，平衡很重要
- 不需要为代码写很多文档，好的代码格式，良好的注释，完善的单元测试可以很大程度上替代针对代码而写的文档。
- 在线工具优于离线文档工具。在线工具有很好的版本管理，方便多人协作。
- 文档也应该作为项目任务放到计划中。
第二遍快速读完，第一条总结就是，树立正确的认知，先冷静分析，会更加不容易被卷入自己的小世界。