上周刚完成了一篇职场工作总结的推文，获得些许新朋友关注。今年经历了两个典型的项目，干脆就趁热再推出两篇关于软件项目实施的心得。今天先上第一篇
注：考虑商业机密，本文不涉及具体项目内容。
下面内容很长，但相信值得对项目管理有兴趣的你认真看看
项目背景介绍：这个项目分两部分，其中业务系统属于定制化开发，另一部分通过厂商的套装软件+业务咨询实现。
单从项目金额来看，算得上是一个大项目。但如果从软件的功能数和用户量来看，定制化开发的功能菜单不超过40个，用户集中在4个业务部门，人数不超过50人。对比其他ERP项目，如从实施内容和用户数，只能算中等项目。
下面我主要从项目需求管理、风险管理、后期运维管理分别谈谈甲方在项目实施的注意点。如果你在工作中有参与任何项目（不仅限于软件），都可以借以对照。
项目需求管理
甲乙方通过合同约定双方的权利和义务，对于非标类产品/服务，合同上的文字说明往往很难说清楚具体的工作内容。
我们说的项目合同就属于非标类产品/服务。甲方在合同上的需求描述，只能表达清楚想做什么？大概内容包含什么？无法清楚体现具体怎么做，工作量有多大？
那么这类定制化的软件项目，能讲清楚怎么做的，也就只有原型了。
据我的观察，国内传统信息化厂商在原型制作上都比较弱。而在互联网企业，原型是开发前必备文档。
个人认为从影响一个项目成败的占比来看，从项目调研到原型确认，基本占了60%。这足以可以说明原型在一个项目中的重要程度。
那么怎么样才能做出一个合格的原型呢？
这里暂不考虑产品概念阶段的分析，只考虑从业务需求转成产品需求的过程。
1、充分理解业务需求。注意这里特别说明要求充分理解。
充分理解要做到2W1H。知道是什么？为什么？怎么做？
知道用户说的需求是什么？为什么会提这个需求？目前TA是怎么做的？
注意：这三者遗漏任何一个，都可能会忽略重要的信息。
很多用户喜欢直接告诉产品经理怎么做产品。如果产品经理不加以分析，直接采纳，常常会被带沟里去。
原因是：大部分用户所说的方案往往只考虑自己的工作，只考虑当前业务。而产品设计是要考虑使用产品的所有用户，考虑当前与未来发展等诸多因素。
俞军方法论有句话：要听用户说，但不要按用户说的做。就是一句非常经典的调研守则。
关于产品经理如何做到较短时间内，充分理解用户需求，这个属于调研的具体术的话题，后面找机会再聊，我们暂不在这里展开。
这里我还想纠正一个常见误解：
不少非业内人士常常把软件从业者统一当成技术人士，这些技术人说话时会蹦出一堆技术术语，这让非业内人士觉得与技术人沟通有距离。所以我觉得有必要再说明下软件行业的岗位和其他行业的岗位的对照关系。
在前一篇职场工作tips中我讲了一般软件行业的主要岗位划分为：产品经理、UE、UI、前端开发、后端开发、测试、运维。
这里面除了前端开发、后端开发主要通过代码与计算机打交道外，其他岗位的岗位性质与其他企业的市场、企划、美工、系统用户、IT运维都是相似的。大家只是做的产品不同，但工作性质与岗位职责区别不大。
面向用户的前端岗位如产品经理的岗位职业是了解市场需求，熟悉用户业务，能够将业务需求转为产品需求。通过产品设计满足用户业务，同时为自己的企业创造价值。
这样一解释，相信你就明白产品经理其实就像一名业务/市场调研/企划。最后TA提供的原型是前面一系列工作后的产出物。就像一名企划前期做了一系列工作，最终要交付一份可执行落地的设计稿是一样的。
2、以用户视角检查自己做的原型
很多原型文件，到了用户手上，用户往往发现走不下去。
2B产品一般都涉及多个业务流程，大量业务管理规则。
这时设计出来的原型，包含了多个模块，一堆的功能列表，大量的交互页面。
产品经理提供的原型要有非常清晰的设计脉络，自己要能向别人讲清楚为什么这样设计，产品设计是如何满足一个个业务需求。
那么如何以用户视角检查自己做的原型呢？
基于前面第一点理解用户需求后，把自己当成普通用户，模拟用户的操作顺序，从一个个页面去检查流程是不是通？空间布局是不是合理？每个区域是不是有突出重点信息？信息排列是不是有顺序逻辑？
一旦能代入用户视角去设计原型，原型质量立马可以提升2-3个Level。
3、原型要能直接用于开发
开发人员拿到原型后，能知道具体要做什么？能形成开发工作列表，进行工时预估、优先级排列/版本发布计划。
开发人员能通过原型知道需要展现出的前端内容是什么？在展示这些内容前需要有哪些“背后的工作”，比如选择框控件的数据来源？前后页面的数据是不是有关联关系？等等
所以一份合格的原型要求能直接用于开发。产品经理通过宣讲原型后，开发人员能通过原型知道具体要做什么？开发经理可以通过原型翻译成开发任务列表。
请注意：从业务需求到开发任务，需要经过二次翻译。第一次是业务需求到产品需求；第二次是产品需求到开发任务。
这里的每次翻译都可能对原需求进行抽象、细化。这也是产品经理和开发的工作价值。
比如，一个用户故事如下：我是一名人事，我想要通过系统记录人事信息，便于快速查询人事的当前在职、离职、层级等信息。
翻译后的产品需求包含：需要有一个组织基础信息维护（公司、部门等）；一个组织架构图（数据来源于前面的基础信息维护）；一个人事信息（包含基本信息、工作信息等）关联前面组织架构；一个人事信息查询功能（能查询人事的在职状态、层次等）。
注：这些内容只考虑了结果记录，如要考虑过程，则还可能有入离职、晋升等过程设计。
翻译后的开发任务包含：借前面的产品需求，前端需要展示的内容可直接按照原型页面；前端规则控制可按原型的规则说明，或考虑将控制规则交由后端？
后端需要考虑数据库怎么设计？怎么样做接口设计？有哪些可复用的内容？等等
通过上面这个例子，一个看似一句用户故事的业务需求，翻译成产品需求，就成了多个功能；再翻译成开发任务，又成了多个具体的任务列表。
每次翻译都要对前面的内容进行一次理解、抽象、细化。所以需求调研质量，决定了原型质量；原型质量，决定了开发质量。
项目风险管理
从工作分工来看，风险管理属于项目经理的工作职责。作为甲方项目经理要注意的项目风险主要来源于如下3个：
1、乙方实施团队人员稳定性
软件行业属于知识密集型行业，这类行业的核心资产是人力资源和各类知识产权。
乙方实施团队的人员稳定性往往是影响项目成败的关键因素。特别注意乙方项目经理的稳定性。
乙方项目经理一般是全程参与从项目启动到方案确认的人，是整个项目的各种信息的汇集点。项目经理如果离开项目，对项目的影响程度可想而知。
两个建议方案：
1、规避风险。在项目合同上约定乙方项目经理需参与哪些环节？项目实施过程不能更换项目经理等条件。
2、降低风险。项目实施过程，注意过程文档的输出和质量。项目实施都有明确的分阶段，通过门径管理流程，每个阶段都应该有确定的产出物，产出物的质量往往影响下一个节点。通过管控产出物可以降低对人的依赖，降低一定的人员风险。
2、乙方项目经理的项目管理经验
市面上具备丰富项目管理经验的项目经理不多。单从质资证书来看，项目经理是不是有PMP等证书可以算是一种检核方法。
但注意：证书只代表项目经理是不是有学习、考试，无法代表TA是不是真的有实际的项目管理经验。
项目管理经验只能在一个个项目实践中积累。积累的速度和有效性则取决于不同人的特质、禀赋、理解能力等诸多因素。
那么有什么好的方法考核一个项目经理的项目管理经验？
目前听到的还是通过面试的方式，通过提出具体问题，询问项目经理的从业经历等，来判断TA的项目管理经验如何？
注意：如甲方想面试了解项目经理的项目管理能力，应有实际项目经验的人参与面试，才能提出具体项目问题，了解被试人的回答质量！
3、项目三要素：进度、质量、成本
最后我们回到项目三要素：进度、质量、成本。这是衡量项目的关键指标。
如何有效管理这三者呢？
进度：主要通过项目实施计划表，每周的工作总结和计划来跟进实际进度和计划是不是有偏差。
注意：每周的工作计划应该是项目实施计划的对应分解。在项目周会上，要多注意问题，少停留在吹嘘做了什么。
质量：前面的项目需求管理是质量的源头，后面进入开发阶段，可通过版本控制，分阶段提供开发的内容供用户测试，验证开发是不是符合业务实际需求。
具备开发能力的甲方IT团队，还可以通过参加乙方的设计评审、代码评审了解具体开发内容。做到从内到外了解整个开发过程。
成本：项目立项、合同阶段已定义清楚项目金额，这是投入的可见成本。但项目进入实施过程，甲方还需投入人力、时间成本参与项目实施。这部分往往也是甲方容易忽略的点。
甲方高层要有人力资源成本意识：人员投入项目，如果没有按项目计划时间完成，意味着人员还要继续投入项目中。这就是甲方要承担的额外成本。
再则一个项目一旦延期超过2个月以上，往往会影响团队士气，这就像打仗：再而衰，三而竭。士气衰，同样直接影响项目成败。
另外要注意的是，项目经理要防范需求新增、变更对项目带来的成本增加的风险。这也是最为考验项目经理的决断能力的点。
项目运维管理
项目运维是常被非业内人忽略的点。一个项目实施阶段做的再好，如果不能按一套既定的规范来运维，往往会把一手好牌打烂。
运维管理主要包含以下6点：
1、新需求管理
项目上线后，用户往往还会不断提出新需求，或对原需求提出优化。这时就要建立起一套新需求/需求变更的审批流程。
注意：每个需求都值得被认真对待！但不同的人提出的需求往往有其局限性。
比如专员提的需求一般是实操类，但到了其经理审批时，往往会考虑这个需求会不会有管理漏洞、风险等。
经理提的需求一般是本部门的管理需求，但到了领导层审批时，往往会考虑需求会不会造成部门之间的管理需求打架的问题等。
建议解决方案：
建立需求申请-审批-处理机制。将所有新需求纳入统一管理流程，规范需求的提交，树立全员认真对待需求的意识。
一件事一旦建立起仪式感，往往大家才会慎重对待。
2、基础数据管理
基础数据是一切数据的基础，比如客户、人员、银行账号、商品档案等。
基础数据由谁维护，可以达到维护及时性？如何保障数据的准确性，不出现一物多码？等等问题，这都是运维过程中要考虑的问题。
很多人会忽略维护基础数据的重要性。基础数据会被其他单据大量使用，同时也是未来数据分析的基础，属于地基部分。一旦地基歪了，就会直接影响整座数据大厦。
建议解决方案：
＊通过系统做到防呆控制。比如编码有唯一性要求，则系统要控制不允许重复。
＊建立数据维护规范。如果用户无法承担自主维护，可考虑统一由用户部门设立一个统一对接人，提供资料交由IT运维人。IT起到检查、导入数据的作用；如果用户可自主维护，则尽量每类数据只给1-2个用户统一维护，避免出现不同人标准不一的情况。
3、日常问题处理
这是大家最熟悉的工作。项目上线后，用户因不熟悉，或者前期准备工作不足，会反馈许多问题。
很多运维人员会陷入救火状态，疲于奔命。
建议解决方案：
＊上线前检查准备工作是否就绪（包括基础数据准备、审批流程配置、用户培训等）。一旦上线后爆发大量问题，会影响用户的使用体验，进而直接影响用户对项目第一印象。
＊接到问题及时记录，对每个问题有反馈。记录用户反馈的每个问题，特别是那些无法及时处理和反复出现的问题，让用户感受到提出的问题都能得到答复，提升使用系统的信心。同时运维人员也可以通过问题记录找到常见问题，统一处理、培训。
4、数据流监控
有经验的运维人员会特别注意，时不时要去关注系统上的数据流转是不是正常？
可以通过上下游单据检查数据是不是有串联？通过报表检查数据是不是完整、无误？
一个系统上线后，为企业最后沉淀的是数据资产。很多企业上系统只实现了将业务从线下搬到线上，一方面没有意识到线上化的规范，另一方面也没有意识到数据有什么用？
要想利用数据，就要时常关注录入数据的时效性、数据质量等。
判断一个人的经验，往往就在这种见微知著的细节处。
5、用户权限管理
用户的权限管理和日常问题处理都是运维的主要工作。
前面我们讲了基础数据管理、数据流监控的意义，用户权限管理是实现这两者的基本保障。
为什么很多大企业的人力、财务、IT直属CEO管理？
原因是：当代企业最重要的资产就是人、财、信息。
运维人员负责用户权限管理，就要做到根据每个人员的岗位职业来分配对应的系统权限。既不多给，也不影响其正常工作。
建议解决方案：
＊优先遵从谨慎原则。不轻易开放超过岗位职责的权限
＊通过审批流程申请系统权限。申请人通过审批流程申请权限，运维人员照章办事。
6、数据库管理
前面我们讲到系统上线后，数据是企业最重要的资产。那么数据库管理就是这项资产的最后一道防线。
数据库管理一般由负责基础架构的运维人员来负责。这块有很标准的各种备份（增量、全量、实时、定时）、灾难处理规范。这里不赘述。
写在最后
今天这篇推文，内容真的很长，如果你不是IT从业者，能打开来，说明标题起到了吸引点击的作用。而如果你真的读完，说明内容有些价值，真的留住了你。
读完它，对于非从业者，应该能了解项目管理的需求、风险、运维的概貌；对于从业者，可以作为工作清单，检查自己哪些做的不错？哪些有待改善？甚至你有更好的意见或不同的观点，也欢迎拍砖！
