一、入门心法
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.需求调研的要点
阶段 |
要点 |
说明 |
准备工作 |
理解用户业务 |
要听懂别人的业务术语,知道他们在说什么 |
准备调研提纲 |
想达到什么目标,提哪些问题都要整理成提纲 | |
让客户做选择题或判断题 |
如果让客户做论述题,那信息的完整性和准确性将得不到保证 | |
准备系统原型 |
图形化的系统界面更加能激发用户的思维 | |
调研中 |
做好笔记 |
|
不要不懂装懂 |
要敢于问问题,“连问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 从程序员到项目经理