作者：徐刚 （深蓝君）
笔者在上一篇分享中提到在HR项目中HR应当积极担当项目经理把控全局。对于不少刚开始做项目经理的HR来说，通常会觉得项目千头万绪不知从何开始。那么从今天开始笔者就来帮助大家梳理一下HR如何一步一步进行项目管理。希望能通过一些简单理论的说明和示例能够让没有项目管理系统知识的HR们能够了解基本项目管理原理并能实际操作开展相关工作。
项目管理中需求的重要性及挑战
项目管理的一个重要理念是化繁为简，各个击破。所以从基本的管理目标来说先给大家介绍项目管理三角形。项目管理就是需要项目经理利用知识、经验和工具的应用，管理团队和项目，使得项目在成本预算范围内按时、按质完成项目所需要实现的范围。
我们今天先谈范围，也就是我们通常所说的项目需求，回答的是这个项目到底要做什么的问题。需求指引着项目的方向，任何方向的变化对于项目的成本、项目完成时间、项目最终成果的质量都会有相互影响。三角形的形状形象地体现了这一相互牵制的关系。
对于项目目标的制定，HR作为项目经理首先就是要协同HR项目团队制定项目需求文档。笔者觉得最重要的是先提高HR同仁们对需求文档的重视程度，只有重视了才会认真对待，否则再怎么讲可能大家都不会仔细听、认真想、积极做。所以我们先来看看如下一些项目需求文档在项目中的重要用途：
用于签订合同中的条款与供应商达成共识：合同具有法律效力，是有效保护用户与供应商双方利益的有效武器。但项目签订合同通常在项目早期阶段，这时往往容易对具体需求的明确上有疏漏。那基于有疏漏的需求签订的合同就很容易造成今后双方的矛盾与纠纷。
是决定项目预算和供应商报价的基础：对于项目的预算，只有通过需求描述我们才可以更好的让不同的团队和供应商基于同样的要求来估算费用和报价。同时也可以基于需求的细化来区分预算的用途，达到专款专用的目的。
是HR验收项目是否符合项目目标的标准：在项目后期，HR的一个很重要的任务是对项目是否达到目标效果进行验收，通常没有人能完整记住在项目开始初期所分析出来的所有需求和目标。因此需求文档可以很好地帮助我们逐条参考进行验证。
是变更管理的重要依据：基本所有的项目在执行过程中都会由于各种原因发生对于原来需求的变化。基于项目管理三角形，我们可以看到这对项目的成本和时间都会产生影响。只有基于项目之初明确的文档化需求及与之相对应的预算分配，我们才能比较与项目初期的不同并进行相应的预算增减和必要的项目时间线调整。
方便进一步形成用户手册和系统帮助文件：在项目成果交付后，从用户体验角度出发，对于所有系统的使用者通常我们是需要提供用户手册或者在系统中形成完备的帮助文件方便用户将来随时参考。因此完善的需求文件也能极大地方便我们制作今后的帮助文档。
通过以上的分析我们可以看到，需求文档化有着非常多的好处，可以通过文档确保需求被准确地传达给所有利益相关者，也有利于各方进一步对需求进行审核和持续改进从而提高项目管理的效率。项目的需求如果没有详细文档，仅仅通过口口相传，显而易见是不行的。
不过现实中知易行难，HR项目在需求文档化时通常会遇到如下问题：
需求文档化不全：由于项目初期准备时间不足，对于项目所有需要实现的目标不能完全概括记录，导致需求描述遗漏，影响整体项目规划和预算。
需求描述过于主观而缺乏客观量化要求：叙述不够逻辑化、没有简明扼要概括关键点。有时文字过多但又模棱两可，导致和实施方沟通不畅，浪费时间。例如对于用户体验的要求，如果只是简单描述要求系统用户体验好。这就像“每个人心中都有一个哈姆雷特”一样，每一位看到这个描述的人，心里都一定会有不同的期望值。过于主观的描述会由于缺乏量化导致很多不必要的误解和争执。对于项目组的项目执行也缺乏相应的约束。
后期需求变化管理缺失: 在制定初步需求后在后期有变化时，对于需求文档的管理不足，导致部分需求仍然停留在口口相传的层面或者散落在不同的邮件往来中而没有统一管理与更新。
需求文档化示例
接下来我就通过一些例子来分享下作为HR如何来文档化需求。我们以开发HR相关的IT系统的项目为例，一般来说HR对于编程技术、服务器、系统测试等很多领域是不熟悉的。那我们来看看从HR角度如何可以在不了解技术的前提下制定项目需求文档。其实基本思路也是和我刚才提到的项目管理推进思路是一致的，那就是化繁为简，各个击破。
通常我们最好能够定义一些标准的工具和模板来统一需求文档的格式，便于大家分工合作。具体模板的格式并不重要，模板只是为了方便统一整合，更重要的是如何分解工作的思路。
我们先引入一个简单易用的IPOQ（Input输入 -Process处理-Output输出–Quality质量）模板来记录需求。请看下面的例子，我们选取传统的薪资系统每月薪资处理的功能（例1）通过如下IPOQ的形式来描述基本需求。
例1：每月薪资处理功能IPOQ描述
大家可以发现，其实IPOQ的记录方式就是通过需求分解的方法引导我们把需求逐步文档化下来，在项目初期，需求描述只要在大范围上覆盖所有的需求点，那么对于详细规则可以后续逐步细化，对于技术细节和人工智能算法方案等完全可以借助供应商的力量共同进行完善，这样能够很好地与供应商进行有效的合作，在需求上各自贡献擅长的部分而不仅仅依赖外部顾问。通常外部顾问其实对不同公司HR的日常业务细节是不熟悉的，如果依赖外部顾问那很有可能会造成细节上的缺失。
通过这样的需求记录可以很大程度上应对我们之前提到一些制定需求时常见的挑战。例如对于需求不全的问题，由于我们把工作有逻辑地进行拆分，把输入、过程及输出都明确区分开，可以方便地引导HR进行思考并记录各个层面的需求。对于需求缺乏客观量化的问题，我们通过步骤描述可以看清楚每一步的前后关系。同时通过质量要求可以把最终的结果要求明确量化体现避免含糊其辞。这些质量要求将来就可以转换成供应商合同中的条款。对于项目实施过程中需求的变化，只要制定好管理规则，及时更新文档就可以避免新变化散落在各处，便于集中管理。
在IPOQ的基础上，如果项目的需求与更复杂的工作流程相关，那么我们就可以用类似于SOP（Standard OperationProcedure）的方式来描述。SOP其实在某种程度上也可以看作是一系列IPOQ步骤的集成。
很多HR都比较熟悉SOP方法中的流程图，其实在制作项目需求的时候，我们同样可以通过类似如下示例的流程图来进一步细化反映人与人之间或者人与系统之间的交互过程。
相信大家可以通过示例感受到在有清晰逻辑化的需求文档之后，我们就比较容易针对现有的白纸黑字的需求提出很多问题和改进建议。然后通过讨论做出决定后把改进建议反映到需求文档的修改中去，就可以逐步完善需求。这种需求文档化方式非常有利于在大项目组中分享需求信息和对需求进行持续改进。大家可以想象如果这些需求只停留在每个人的脑海中，那么要沟通清楚达成所有人的共识是多么的困难。
对HR日常工作及供应商合作的建议
我们也可以看出在日常工作中把工作流程SOP文档化是很好的一举两得的管理方式。有了平时的积累，我们在有新技术、新变化的时候就可以把已经有的SOP文档拿出来作为项目需求分析的关键资料。平时的文档化既方便了日常的持续改进工作又提高了项目需求分析的效率。
在HR制定了项目的初步需求后，通常我们会把此需求传递给供应商来进行报价，有了详细的需求，供应商可以更快更直接地了解到我们到底要做什么。完善文档化的需求也能方便我们让多个供应商同时进行方案设计，有效减少与不同供应商之间重复沟通需求的时间。
对于我们在文章之初提到的关于用户体验需求的描述，建议可以在需求文档质量相关的描述中尽量尝试用客观的方式来叙述，比如明确在什么功能页面有什么样的自动提示等。对于界面美观的要求也可以明确参考什么网站的设计风格等。对于这些比较难客观描述的定义，还有一个方式是可以在需求中注明此需求为待定事项。可以让供应商提出不同的解决方案和相应报价由我们在看到具体内容后进一步确定。这样就至少不会在将来遗漏用户在体验上的需求。
在项目实施的过程中我们也一定会让乙方实施团队进一步从实施的角度来完善需求。按照笔者的经验，甲方文档的质量会在极大程度上影响乙方将来文档的质量。甲方在项目最初高质量文档其实就潜在地为乙方设定了一个文档质量的高标杆，这样在项目初期就对项目质量起到了一定的促进作用。
今天的分享就先到这里，希望HR们可以在平时的工作中能够做好工作文档化。这样在应对项目需求时就会更加游刃有余。下一次我将分享项目管理中如何进行项目的预算，大家如有兴趣也可持续关注深蓝信息个人公众号获取今后推送。
如果大家觉得笔者的HR项目管理系列文章能在一定程度上帮助到大家的话，也欢迎大家点赞、转发与更多的朋友们分享交流，同时也欢迎大家留言共同切磋经验。