从程序员到项目经理成长记录

一、入门心法

1）通常工作梳理用5W1H法： (P82)

当开始开发医疗APP的时候，还没具体了解这是个什么APP。做这个APP的目的是啥，完全没概念。只知道这个东西类似于挂号网，越做到后面，发现东西越多，需求都还没理清，就急急忙忙的做了，针对的客户是什么样的人也不清楚，就是闭门造车。完成时间定在了12月底，开始开发是11月头，短短两个月时间。并且中间人员不齐，开发人员也是在开发的过程中逐渐加入的。虽然出现了原型，但是没有好好的开过几次原型讲解会议，对原型的理解有很大的偏差，导致经常返工。越来越没效率。连基本的功能计划表都没有，更别谈高效开发了。完全处于混乱状态。

2）四象限法 (P83)

在做母婴APP第二版的时候，需求经常变来变去。需求改变后就要临时开会讨论，原先的手头工作就要放下，确定了新需求后，就又要重新做计划，原先的轻重缓急又得重新排，反反复复的效率越来越低，项目都还没上线，就已经很混乱了。

3）项目管理9大领域 (P94)

在做母婴APP前几个版本和医疗APP的时候，完全没有风险管理，只是在一味的赶进度，虽然加班加点的做，但是做出来的东西完全就不能用。需求产品等的延后时间，现在全部让技术来补了。质量管理也没有，由于功能点特别多，人员都是第一次配合，也没有积累的代码，都是全新的，能按时做出个能看的东西已经很费力。在做医疗APP的时候，人员都是重新招的，陆陆续续进来的，人力资源管理也不到位。当看到来不及，想加人的时候，也已经晚了，想外面找几个外包助阵会适得其反。沟通管理一开始大家还是做的很好的，为了同一个目标前进，加班加点大家也无怨言。但是到后面就不对了，成员开始厌倦这种没有产出的加班，脾气也上来了，成员与成员之间出现了沟通不畅，甚至误解，积怨也开始了。战线拉的太长，中间也没有里程碑，成员没有成就感。当初做APP的时候，费用管理倒不缺，可以说不计成本的做，完全不用担心资金问题。

4）项目三个目标 (P96)

就是时间、成本和质量，对应的就是“快好省”。

1. 时间：项目计划在什么时候完成？有哪些工作，分别在什么时候完成？是否发生了偏差？如果有偏差，怎么处理？

2. 成本：项目计划花多少钱？每项子任务分别打算用多少钱（多少人月）来完成？是否发生了偏差？如果有偏差，怎么处理？

3. 质量：软件功能完整吗？软件操作方便吗？运行结果正确吗？运行效率够快吗？软件代码符合规范吗？客户用起来满意吗？

5）项目管理方法 (P98)

1. 以客户为中心【医疗APP的产品也不了解真实客户，经常甩一句老板要这么做】

2. 以目标为导向【做医疗APP的时候，目标很明确，完成原型，但功能太多，人员等各方面因素，导致烂尾】

3. 以计划为基础【医疗APP就是没有制定开发计划，正式的原型会议也没有，拿到原型就开做】

4. 以控制为手段【12月的时候，项目已经处于暴走阶段，对原型的理解不深，经常发现需求理解错了】

6）打造“凝胶型”团队 (P116)

在这样的团队中，大家有着清晰的共同目标，彼此合拍，每个人都是全身心的投入，每个人贡献自己全部的智慧和力量，团队显示出超强的战斗力。

“凝胶型”团队可以分两种，星形和网格型：

二、理事的原则

1）项目执行的常见误区 (P163)

1. 目标不清 【母婴APP开始几个版本，就是目标不清，需求朝令夕改】

2. 不能坚持目标 【医疗APP经常会出现技术难点，这个时候就会耗费时间解决，其他功能就会延后】

3. 抓不住重点【医疗APP没有把主业务完美跑起来，倒是花了很多时间开发周边功能】

4. 拖延症【临时开会，人员面试，数据处理等经常会出现很多事情打断原先的任务，导致托到明天做】

5. 只管项目整体，对细节不知【在看原型的时候，只是看了个大概，但真做的时候，发现到处都是深水区】

6. 盲目求快【医疗APP为了在12月底完成，开发的时候就经常不考虑以后的扩展、维护性、效率等方面】

7. 无效沟通【由于第一次合作，客户端和接口端面对面沟通都会出现偏差，对问题的理解存在差异】

2）重要细节应问5个为什么 (P176)

在开发医疗APP的时候，基本都是在赶进度，也没想到过自问，每天就是踩坑填坑，扯皮，返工.....。浑浑噩噩的，毫无生机。

“连问5个为什么”的工作方法，可以用来问自己，刨根问底，分析项目中的潜在问题。例如“总体目标达成情况”，“团队士气如何”，“有哪些潜在的风险”，“软件总体质量如何”......

3）项目执行为快不破 (P187)

抓住重点的20%，也就是“二八法则”。注意以下问题：

1. 重点处理客户的核心业务需求

2. 将核心人员用在核心问题上

3. 面对问题时，要分析主要因素，并加以处理

4. 将大部分时间处理少部分重要的工作

还是那个医疗APP，住业务没跑起来，倒是把积分、消息等这些功能先加上了。不过这个项目的主业务流程也非常复杂，主业务里面分导诊和挂号。数据整理也非常费事，疾病信息、医院信息、医院挂号信息、医生信息、科室信息、评论等都得整理出来，导入导出抓取人工整理。我们在面对问题的时候，感觉就是救火，也不深究引起这个问题的主要因素，救完这里再去救另外一个地方，周而复始的，问题每天都会出现，看似是新问题，但其实很多都是因为没有根除导致的连锁问题。

4）打造团队执行力 (P200)

1. 有效沟通，在沟通中经常会出现失真的情况，导致理解出现偏差

2.需求调研的要点

三、第三只眼看项目管理

1）胸有成竹 (P220)

其实胸有成竹只是一种表面现象，就好像一座冰山露出水面的部分，水面以下还有庞大的支撑。

最近的一个新母婴APP，目标是授课，在这个APP中可以获取孕育、育孩等知识，顺便还能交友互动，工期是2月8号之前，开始日期是12月23日。要求各个功能能使用，大概有14个模块，接口40个，客户端页面55个的样子。2个客户端2个PHP1个测试1个前端，资源明显不足，风险很大，我们在计算时间后，发现起码要到3月底才能上线，但管理层不能接受这个时间，又不肯减功能，两边产生了巨大分歧。技术点有OSS封装、极光推送、短信封装、NOSQL封装、缓存封装、队列技术等。由于人员变动、需求更改过大等原因，采用全新PHP框架开发。由于这个框架没有使用过，很多地方要重新封装，后台的皮肤也是，基础方面要重新构建。项目的主业务是发频课程，用户能够浏览获取知识，并做测试题目，发评论互动。

2）项目失控的表现 (P233)

看看你公司现在占了几个？

3）项目失控的7大原因 (P236)

再看看你公司占了几个？

四、项目管理中的迷雾

1）响应变化重于遵循计划 (P250)

变化的原因可能是因为计划不周导致的。例如母婴APP中，有个咨询专家的功能，客户端展示的像一个聊天界面，后台的回复页面却不像聊天一样有历史记录，这样导致人员在回复的时候，不清楚过去聊了些啥。当初设计这个咨询，仅仅是一个反馈的结构，并没有考虑到后面会变成聊天模式，设计上的一个缺陷，后面只能返工修改。

出现的原因有以下几点：

1. 经验不足或过分依赖经验

2. 考虑不周，所谓“百密必有一疏”

响应变化重于遵循计划有2个重要思想：

1. 拥抱变化，而不是追赶变化。应对变化，高声呼唤“让暴风来的更猛烈些吧！”【在APP开发的时候就是追赶变化】

2. 计划中应包括如何应对变化【开发医疗APP的时候计划都没有，更别谈这些了】

2）滚动计划以适应变化 (P252)

项目执行中会出现意外情况，产生偏差，有些可以修正，有些无法弥补，这时候就根据实际情况来“修改路线”。注意以下2个问题：

1. 要随时评估项目，要时刻有一副如何到达目标的地图。许多次小的变动可能让你的地图失效。

2. 思考变更的原因与必要性。需求变更通常是客户提出的，而客户的想法有时候不是深思熟虑的，我们就得帮助他们想透彻、理清楚。

滚动计划有2个方面的内涵：

1. 计划需要认识的加深而修改。在项目启动的时候就要做计划，即使需求没确定，其实需求调研需求分析也是计划的一部分。

2. 近期计划细致些，远期计划粗略些

3）在现有的资源下做出成绩 (P255)

1. 把项目组调动起来，充分挖掘，在不影响项目把控的情况下亲力亲为。

2. 用好现有的资源，用好每一个人。首先要把事情理清楚，让大家明明白白的做事。

4）怎样对待需求变更 (P279)

1. 需求没变，是我们对需求的理解在变。也就是我们没有理解清楚客户的需求。

2. 管理需求，减少变更。深入挖掘需求，不要停留表面，需求评审不可少。

3. 变更流程要书面化正规化，提出申请、评审（是否有必要变更、是否有替代方案、对其他功能影响等）、跟踪（监控评估变更的效果，避免产生新的问题）

参考资料：

http://www.cnblogs.com/watsonyin/category/262280.html    从程序员到项目经理