《从程序员到项目经理》内容记录

一、入门心法

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

1. Why     ——为什么干这事儿？（目的）

2. What    ——什么事情？（对象）

3. Where  ——在什么地方执行？（地点）

4. When   ——什么时候执行？什么时候完成？（时间）

5. Who     ——由谁执行？（人员）

6. How     ——怎样执行？采取哪些措施执行？（方法）

当开始开发医疗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.需求调研的要点

阶段	要点	说明
准备工作	理解用户业务	要听懂别人的业务术语，知道他们在说什么
	准备调研提纲	想达到什么目标，提哪些问题都要整理成提纲
	让客户做选择题或判断题	如果让客户做论述题，那信息的完整性和准确性将得不到保证
	准备系统原型	图形化的系统界面更加能激发用户的思维
调研中	做好笔记
	不要不懂装懂	要敢于问问题，“连问5个为什么”，在理解对方传递的信息时，也需要打破沙锅问到底的精神
	主动复述	将客户讲的内容，用自己的话复述一下，由客户来裁定你的理解是否正确，存在偏差就能及时纠正
	问问题要具体
调研后	每天整理分享调研成果	将调研成果整理出来，分享给相关人员，确保大家理解一致
项目整体	调研过程要有计划有层次	先整体后局部，先粗略后细化。方法上分三个阶段，先收集资料、再填写需求调研表格，最后细化访谈
	如果有可能，让客户编写需求文档

 

三、第三只眼看项目管理

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. 需求过多，系统过于庞大复杂 2. 需求不稳定，用户无法决定他们要解决的问题 3. 需求模棱两可 4. 需求不完整		团队中缺少 资深人员	资深人员通过丰富的经验 可以给项目组提供成熟的解决方案 帮助项目组识别风险、解决突发事件等
拙劣的计划和评估	对项目的难度和工作量评估不准确		硬件/软件供应商的 低劣表现	将项目中的部分工作或产品外包 如果供应商不给力，只有干着急的份儿
采用新技术	1. 项目组成员对新技术掌握有限 2. 新技术不一定成熟		质量无法满足要求	1. 功能做了一遍又一遍，每次接近一点，但始终不能达到 2. 如果性能或可靠性出现问题，可能给客户带来重大损失
缺乏或根本不具备 项目管理方法	1. 没有章法，想到什么做什么 2. 等事情做，有问题才觉得工作很充实 项目问题不断冒头，成为“打地鼠式管理”

 

四、项目管理中的迷雾

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    从程序员到项目经理