一篇不错的项目管理之道

转载

Java海洋 2022-11-15 12:41:08 博主文章分类：管理经验

一、入门心法

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. 等事情做，有问题才觉得工作很充实项目问题不断冒头，成为“打地鼠式管理”