0. 写在前面
刚重置了"中文博客"，发现空空的，这很不好；正好现在换工作，就写一点项目管理的东西。
本篇主要有哪些内容呢？(后续可能有一些微调)
- 正儿八经的项目管理全貌
- 小团队管理的一般流程(excel展示)
- 一个完整的案例展示(Merlin Project)
- 项目经理的主要工具，我的替代工具
- Excel放飞自我(用Excel来排进度)
- 从技术到管理后的变化(逢人让三分，应对突发事件)
1. 正规军的项目管理理论
理论来自于实践，而又指导实践，但最初可能总结于一些高手团队的实践，然后用于非正规的项目。
我听到的最多的，关于这些指导理论的评价是: 学院派，过于理论，不切实际，无法实施。
不做评论，只讲一句: 存在即合理。
正规军的理论大致来自于 PMP 以及 IPMP 两大派系(美国的 PMP 大致相当于欧洲的IPMP Level D)，但国内以及国际多认可 PMP。(您可以参见一下 暴雪 的高级项目经理招聘要求看看)
PMBOK 总共包括 10大知识领域，5大管理过程，47或者49过程矩阵，我直接这里贴一个图吧:
图片知识来源于 PMBOK，图片本身来源于这里。
- 仅仅通过我这里列举的也就算有了个概念，具体还需要系统学习 --- 对于 newbee 而言
该有的都有了，就不展开了。
哎呀，我超赶时间的。
2. 小团队的项目管理工作
小团队的项目管理工作一般是比较累的。
怎么讲？
如果你只是纯粹的做项目管理的话，其实比起一线编码的技术工程师，活少一些，但压力明显大一些。然而小团队&创业团队&startup，最严重的问题就是缺人，人员流动性太大，而且普遍的情况是，人员的编码素质&效率偏低(如果你在大厂待过的话，就会发现大厂的人专门负责某个模块，编码以及解决问题能力要强的多)。
- 老板或者总监心里大概也知道，但也无奈，既要盈利，人员也要生存。--- 人招多了也不好，利润被压没了
故而做项目管理的工作，时不时的还要去补缺。且资源也不足，导致可用于建设完善项目管理的精力又被进一步挤压。
同时，有时候项目多了，可能一个人就需要管3，4个小项目的进度以及沟通交涉。(我这里还没有谈组织团建什么的)
但麻雀虽小，五脏俱全。越是有挑战，越让人懂得集中精力完成优先任务。
2.0 整理流程概览
一般为了减少后续返工的概率，也还是会遵循一定的规章制度&计划流程。
当然肯定不可能是完整的 软件工程 那样步步到位啦，但小团队的流程(SOP)该有的还是有的，大致上就这么个流程: (草图)
当然实际项目肯定不能是草图，我只是说明一下意思。一个简单的项目所需 文档集合 大概如下:
这里我还没有给出用户手册呢。
2.1 详细展开说明
上面的文档不能都展开，单挑一两个出来展开吧，主要给那些没有相关阅读权限的工程师当过过眼课:
比如测试用例:
比如需求进度管理:
等等，按照上面那个草图，项目经理一般做好项目整体流程把控，但这个表一般给自己用以及汇报用，示例如下:
如果有时间，除了进行 单体测试(UT)，可能还需要进行 系统测试(ST)。
基本形式差不多就是这样。(但很多小团队连这个基本都做不到 --- 技术负责人&总工没有把好关)
2.2 我经历的大厂项目管理
大厂怎么搞？ --- 如果是项目型组织，比如一些咨询公司(先确定是哪类的咨询，然后Case分到各个项目经理)，他们会更加规范规划。
我经历过的硬件大厂，除了有 项目部 的项目经理，还有具体事业部子部门下面的软件经理，做类似的全职监督和负责某个大项目的具体某个版本的工作。
具体您还是参考 PMBOK 吧。
3 完整案例演示(Merlin Project)
"来，说干就干"。(好污的台词啊)
这里我先用专业的软件 Merlin Project 弄吧，后面再说 Excel 怎么搞。 (业内大佬，让您见笑了)
我为什么不用巨硬(Microsoft)的 Project 2019/2016？ 因为用不起，感觉订阅太贵了！(盗版？祝你永远不会踩到高压线)
实际上 Merlin Project 我也不是主用，现在主要用 Excel。
由于是演示项目，工时就用天代替，项目周期姑且算作一个月吧，来先启动项目(kick off)。
然后为了简便，这里就直接启动了 -- 直接认定要做这个项目(赚这个钞票):
一般设定时间最好还是只设置最早和最晚(而非精确设置)，给与一定的灵活度:
然后就是通用的，需求调研，概要设计，详细设计等:
而且就我的开发经验而言，在这里就要完全确定好数据的流向，格式，模块协作的媒介(一般要
解耦的话不会直接通信的)
- 插曲: 有一次听到有人翻译的
概要设计这个词汇时，用的是 gerneral，怎么说呢，其实更加准确的说是PD，preliminary design phase概要设计阶段。
详细设计编码以及测试:
最后评审，交付，总结，归档:
难么？真的没有 --- 我说的是用这些工具。困难点可能来自于各种突发事件的应对以及抗压能力。
(见下文)
4. 项目经理的主要工具
我是说硬工具，而不是 soft skills。
就我用过的来说，没有别的，就是 office套件，外加项目管理工具。(如果项目经理还干研发，还干需求，那就不止了 --- 还需要 IDE，原型工具等)
而项目管理工具，根据项目的不同&公司投入资金的不同，选择的工具的也不同。除开各领域的集成工具，比如IT研发领域比较常用的有zen(缺陷管理)，jira，IBM研发供大公司使用的莲花等，然后就是通用领域的项目管理工具，常见的Microsof 的 Project，macOS平台的 Merlin Project。
当然我们一般为了省钱都会用 Excel 这种万能工具来折腾。
您还别说，挺好用的。
5. 我的替代工具
如果公司能有钱订阅 MS Project，那我肯定用专业的啦，如果没有呢？
那我就用 Excel，主要是记录项目开发计划(就像上面的)。
其实如果是甘特图，扇形图等等，图形 plus 数据相关的，一律都是 Excel。
没办法，能省就省。节约不见得是美德，但日子能过下去。
其次我也用数据库，SQLite，Access 等这类单机小体积的(mysql, meriadb以及nosql, new sql就算了)，毕竟技术出身嘛。
(其他非项目经理专属的，我就不列举了)
6. Excel来秀一波
我不算是 Excel 大佬(大佬都是拿 Excel 来分析股票的吧)，只是在用而已。
或许我玩 IDE 的时间都比 Excel 长 --- 这并不表示 Excel 可玩性差。
- 插曲: 很长一段时间里，我都没有意识到 Excel 的强大 --- 认为那只是非 Pro 人士的选择，我们能 Coding 的直接用 脚本语言了(比如 shell, python --- 主要是 python)
OK，回到正题。
(开一罐薯片)
新建一个 Excel 文档，然后准备一些基础数据，大致如下:
然后制作甘特图只需要 开始时间 和 持续时间 就够了。
然后需要先选中数据，再插入相关图形图形:
- 选中
任务名称和开始日期两列 插入--图表--柱状图---条形图---堆积条形图
你会看到条状堆积图。
其实只有横纵坐标是我们需要的，蓝色的条形图其实不需要。后面在通过设置格式来把它消除掉吧。
接着再来添加 持续时间，选择蓝色的条形图，选择数据:
- 点击右键，也会出现
选择数据的选项。
然后此时注意一下这里的设置，先选择添加一组数据才行 --- 点那个 + :
然后对应的数据选择 持续时间 那一列，操作如下:
最终效果:
蓝色的条形图还是消除了吧，选中蓝色条形图，然后设置格式:
大概就是这个样子了:
OK 有点意思了，但横坐标的时间貌似和想象中的有点儿差距啊，调一下横坐标的显示:
看来需要计算一下了，怎么算？你是不是第一时间想到了 Google 一下？其实不必要，观察一下图形即可:
- 最大值跟最小值之间，相差多少天？120 天，对应了最大值和最小值是多少: 44200，44080。此时可以计算单位天对应的距离是:
(44200-44080)/120=1 - 44080 对应的是 2020/10/13，而现在横纵表的起点是 2020/09/06，中间相差了38天。相差多少距离呢？
38*1=38，也就是说最小值扩大一下设置为44080+38=44118
最大值也是响应的计算方式，但要缩小最大边界值而已。(别算了，我算好了，直接直接设置为44190吧)
顺便把 数字格式 设置一下:
还能再好么？OK，是时候根据自己需要来绘制更多功能的图了。
就点到为止吧。
简单吧？简单么？您做做看看就知道了。
7. 从技术到管理的变化
7.0 技术榜身
除非是高级项目经理或者有专门项目管理团队PMO，一般而言，技术大概率还是要榜在身上的。
不同的是:
- 做工程师时，你要熟悉模块&领域的每个细节，技巧，常见问题及其一般解决方案，注意并没有讲"仅仅是解决思路即可"，而是应该具体到提供解决方案，快捷解决手段。
- 做项目管理时，也要熟悉技术，但此时要熟悉和记忆的，并非具体的知识细节了，而是要记住大致的技术选型，一般的解决思路。为的是，在必要时可以拼接、搜索资料弥补相关一线人员的空缺&或者在排工期的时候不被其蒙骗
这里用词比较腼腆: "必要时刻" --- 因为总是缺人的话，请向上级申请招人，否则自己很容易成为两个工作领域的半瓶子水，影响自己职业生涯。相对而言，大公司分工明确，一个萝卜一个坑，要好的多。
7.1 个人过渡案例
我个人选择项目管理，大致是三年前，那时候我已经玩技术玩到了kernel层了(BTW，大学时就没少玩，什么 arp 攻击抢室友网络，查看tcp/ip内核实现，linux系统编程，c++ qt, java spring, web service等)，但感觉不到任何满足(成就感可能还是有，可能就是交大作业的时候吧)，但距离我的人生两大目标太远，故而转型。
然后，其实这里还有一个最关键的因素， 机会和条件。我当时是因为有熟人(自己人)袒护和携带，才慢慢走过来的。
- 至于离正规军(国际水准)有多远？我猜可能还有点距离 --- 这也是我要回到资源丰富的地方 --- 大平台发展的原因。
7.2 逢人让三分
转型之后，我体会最多的问题不在解决问题上，也不在为客户创造价值上，更不在完成交付上，在需求理解上！
- (包括后续的需求变更，交付扯皮根源都是这里；但添加功能，做二、三期工程则不属于次范畴)
我曾经在需求研讨会上发现东西已经做了一阵子了，又发现双方讨论时需求还是有一些大出入，而且问题还比较烦，因为程序员很多都很固执，有脾气，一般都觉得自己牛，然后客户那边儿呢我不晓得他是在以前的基础上改变过需求(这一次会议自己追加的)，还是碍于面子自己没有理解程序员&实施人员的内容(因为多半是程序员做了一些东西，然后客户先确认一下是否偏离了方向，或者阶段性成果验收时，先由程序这边讲解，然后双方交流)，敷衍过去导致的。
可能两方面都有。
需求方中途跑来说，做的东西可能有点出入!!! What the xxxx?
你说客户是需求变更吧，他不承认，他说这边做跑题了。(当初需求会议上你怎么亲口确认总工的复述的？)
但我敢得罪甲方爸爸么？？？
当然这也是很久之前的问题了，借着需求来说明沟通，处理和协调中存在的问题。
虽然问题各不一样，除开故意埋坑的，多数情况下，我个人总结对于需求的理解问题，还是 智商上的差距，然后需要情商来弥补 (照顾双方的面子，哪怕有一方你明显听出来对方不专业)。
工作中人与人的智商差距，真的有很大的影响。
这一点不管是上学时还是工作后，都很明显：反应力，接受能力慢的人，再不勤奋一点，注定成为团队的扶持对象。
回到主题，程序员多半比较实在(你看他们的job position&title 也看的出)，然后就是能忍耐(可能也是因为薪水非常高或者非常低吧)；相对的客户啊，业务员啊，销售啊，那就有点虚了，你看他们的 title 随随便便都是个 consultant(顾问)，然后就是某业务负责人，区域负责人blabla。这里没有贬义，可能职业需要，必须要讲一些高大上的，阳春白雪的东西吧。
所以，这里就需要一个种技巧，那就是逢人让三分，和气好生财 --- 即便对方确实不专业，确实水的不行。（注意必须先确立个人做人的原则！别跑偏了）
能够 包容 这些的存在，然后把项目做成，交付。
(但这其实也算不上高手的招，因为我目前也不在高段位，还在不断接触高手，学习高手的过程中...)
7.3 突发事件
程序员可能也会遇到突发事件，比如莫名其妙的，昨天自测能走的代码，今天就不行了。然后仔细查了查看到了，某个家伙合入代码的时候，没有考虑公共开关(多模块共用的参数，变量等)，然后自个儿就能解决。
但是项目经理遇到的突发事件能有这么简单，自个儿琢磨一下，私底下就解决了么？不存在的。
往往是涉及到多个干系人，存在多种利益纠纷，然后要解决，就得想办法沟通。
有时候气的没有办法还要请中间人协调或者摸清其中利益干系后在行动，比如某要用其内部数据测试刚实现的模块，但对方掐着网关死活不给你放行，怎么搞？我哪知道啊，但还是要硬着头皮，想办法啊，总归是要解决的呀。
其次就是程序员遇到突发事件绝对没有项目经理多，因为负责的范畴广了，时不时的就会来事儿，极其考验一个人的抗压能力 --- 因为每次可能都是新鲜的！！！
可能还有其他的，但是我只写了我经历的和个人见解。
此篇算是 田篇之作，有不妥之处，万望斧正，谢谢您的时间。
(始终走 D小调，不发布到网站首页了)
YanYueIO Oct 13, 2020 afternoon