500人天的大项目，是一个什么样的概念？
对于一个工作量为500人天的大项目，背后意味着什么？
按1个全职员工每年正常工作250个工作日来计算，相当于2个全职的员工开发一年。是不是，有10个员工，就可以缩短5倍的工期呢？肯定不是的。
相反，500人天的大项目，通常参与的人员都会涉及到项目经理、产品经理、开发人员、测试人员、运维人员，甚至商务人员，项目干系人可能是10人至20人之间不等。另一方面，在时间和工期方面，整个项目从前期商务洽谈到落地实施到最后项目交付，其周期会持续一年或两年之久。
虽然，大项目意味着大订单，高客单价，但作为研发管理人员和老板，也要同时看到这背后的高成本、高投入、人员多、周期长、风险大等不确定的因素和风险点。
那么，如何进行研发管理，风险更可控？
如何进行研发管理，风险更可控？
现如今，软件项目研发，依然存在很大的挑战、不确定性和失败的风险。项目失败，表现在项目最终无法正常交付、或项目因开发周期远超出最初预期导致项目成本高昂而亏本、或因遭受甲方客户的业务调整变动而导致项目中断。
暂时撇开外部不可控的因素，作为项目经理或技术负责人，至少在内部的研发管理，可以从两大方面进行大项目的风险管控。
一方面是：对项目时间进度的把控；另一方面是：针对项目交付质量的承诺和响应。
简而言之，即：效率和质量。
下面结合YesDev多功能项目协作工具，分享大项目的成功管理经验。
汇总好项目所需要的资料，做好产品需求设计
1、整理项目需求
在前期，创建好一个新项目后，很有必要在项目文档中记录重要的项目信息和资料，包括项目背景、注意事项、参考资料等。
在前期，和甲方客户充分沟通好项目需求后，罗列好产品的需求清单，并整理成PRD产品原型文档，可以把PRD压缩包上传到YesDev，以便给客户演示和介绍产品方案，同时方便后续的内部需求评审。YesDev也会详细详情PRD的历史变更版本，可以随时查看过去的PRD版本。
PRD上传后，在线演示访问，效果类似如下：
以上，是产品经理或项目经理的需求整理工作。
2、拆解项目需求
下一步，就是拆解项目需求。关于这一点，颇有争议。到底应该怎么拆解需求，以及应该由谁来拆解需求呢？是按产品系统模块拆解需求，还是按前端后端拆解需求？应该由产品经理来拆解需求，还是应该由技术负责人来拆解需求呢？
对于前者争议问题，结合OKR的方式，应该以产品系统模块来拆解需求，同时可以体现系统模块的前后依赖关系。如通常，应该先有管理后台，再有前台展示；先有登录注册，再有功能的使用。
对于后者争议问题，则应该由技术负责人，结合现有的团队人员力量，以及对技术和业务的理解，进行项目从上往下、从大到小的拆解。先添加指派模块需求给到核心的技术开发人员，在添加需求时，可以关联PRD、指派负责人、计划完成时间等。随后，继续让对应的技术开发人员，在此需求上继续进一步拆解开发任务和评估工作量。分为两走。
值得说明的是，如果项目很复杂、很庞大，则应该水平上再创建一个项目。例如，PC版一个项目，M版移动端一个项目。则更为清晰，化整为零。
拆解好项目需求后，我们可以看到这样的需求清单，按负责人可以快速分组。
3、评估项目工时
有了整体的项目概述和资料，也对项目的需求PRD进行了需求评审，此时技术团队已经对当前项目有了一定的了解，已经知道需要做什么项目、用到什么技术、给哪些客户使用。同时，技术负责人也根据每个专业岗位，做好了需求的分析和拆解。那么，接下来，就是需要让一线的技术人员，根据所领取和指派的需求，继续拆解工作任务和评估工时。
评估任务和工时，这个动作很简单，但作用和意义是很巨大的。任务，是最小、最基本的工作单元，是可量化、可执行的工作事项。在添加任务时，可以指定负责人、评估工时、关联到需求、计划完成的时间等。
稍候会来介绍任务工时登记后的作用和效果。但这一步，务必需要让技术人员根据自身的情况，评估最真实的工时。如果一开始项目较大，还不能完全评估，那么至少也先评估两周内，或阶段性的工作量评估。
重复小结一下，项目初期，需要完成的三件事情：
- 1、整理项目需求
- 2、拆解项目需求
- 3、评估项目工时
项目启动前，做好排期计划
在完成前面的项目前置工作后，进入了即将正式启动项目。
这时候，需要技术负责人，或项目负责人，再宏观进行调整、确认和计划。
一方面，确认项目需求的完整性和一致性。确保客户重点关注的需求有得到记录和满足，以及甲方客户要求的技术条件和约束有被考虑。另一方面，在技术人员完成工时评估后，查看项目排期表，确保项目交付的时间在合同预定的时间范围内，并且从其调整团队人员之间的工作量和不合理的时间分配（例如一天5个人，要完成200个工时的任务是不科学的，因为每人每天不睡觉不吃饭都只有24小时）。
那怎么查看和判断项目排期是否合理呢？可以从以下三个方面入手。
第一个方面，从人员的维度，查看YesDev的项目排期表，查看每个人员的工作量是否合理。 是否存在某个技术人员工作量200人天，而同样岗位的另一位技术人员工作量才20人天。如果工时差距较大，则应该进行平均调配。如果实在人员不足，则应考虑找外援。
第二个方面，从需求的维度，查看YesDev的项目周报邮件的项目开发计划表，查看每个需求模块的开发量是否合理。 如果一个稀疏平常的功能模块，或一个在产品经理看来很小的一个需求，技术却要很大的工程量，如：登录模块需要30人天一个月的开发时间，明显超出行业工作量的话，就要认真review和技术人员核对是否对需求存在误解和把客户的需求复杂化了。
第三个方面，从时间的维度，根据YesDev自动汇总的项目甘特图，查看每个工作日的时间安排是否合理。 例如前文说到，每个人，正常每天工作8小时。是否存在10小时、12小时、甚至24小时的工作安排？如果有，则明显是不合理，也是不符合实际情况的，更严重的是给了项目经理和负责错误的信息。
在项目甘特图，我们可以清晰直观看到需求、人员、每天的工作量情况。稍微注意的是，在进行任务评估时，计划完成时间要考虑到放假和周六日的时间。在这方面，YesDev做得很贴心，会智能提示国家放假的日期。
重复小结，在正式启动项目前，需要做好三个方面的确认工作：
- 第一个方面，从人员的维度，查看YesDev的项目排期表，查看每个人员的工作量是否合理。
- 第二个方面， 从需求的维度，查看YesDev的项目周报邮件的项目开发计划表，查看每个需求模块的开发量是否合理。
- 第三个方面， 从时间的维度，根据YesDev自动汇总的项目甘特图，查看每个工作日的时间安排是否合理。
如果以上的信息和资料还不足以支撑你进行项目的分析、管理和计划，那么可以继续使用项目脑图，进行更直观的汇总和分析。
每天、每个星期或每个月，或定期进行进度的总结和复盘
做好项目前期计划后，当进入到项目正式开发阶段时，则要继续盯紧项目，做好每天、每周、每月和定期的项目跟进、推进和总结。
结合敏捷开发和实际的项目管理经验，推荐结合采用以下四个具体的方式对项目进行进度和风险的管理。
- 每天：使用 任务看板 进行每日站会沟通；
- 每个星期：成员做好个人周报总结，负责人做好项目周报总结；
- 每个月：做好项目交付指标和汇总和复盘；
- 定期：在里程碑节点或重大的交付时期进行针对性的会议沟通和总结。
下面，依次展开。
其实，每日站会是一个概念，目的是为了让团队之间有更加直接、一致、便捷的沟通方式。要确保我已经知道你知道的。每日站会，不一定非得每天早上都要召开。但最好是需要有白板，或者能连接电脑的地方。在每周的固定哪几天早上，叫上核心的人员参与即可。此时，可以用到YesDev的敏捷任务看板，支持沟通时快速的拖拉移动，更新任务状态。
在每个星期五时，让核心技术人员编写周报的意义和作用也是很明显的。YesDev可以帮每个人自动汇总本周的工作周报，你只需要稍微补充和调整周报内容即可。多做多学多总结，是在职场上快速获得提升的有效途径。而编写周报，特别是高质量的周报，对个人的能力提升也是很明显的。程序员和技术人员都不喜欢写文字、写周报，但要有提升，就应该去坚持和践行更优秀的工作习惯。坚持写周报，就是一个好习惯。还可以关联到项目。值得说明的是，通过周报，你个人可以有一个很好的途径向上汇报和展示你的工作成果，可以给领导留下更深刻的印象。
而项目负责人，或者技术负责人，则应该站在整个项目的层次和角度对项目进行周报汇总，而不仅仅只是停留在个人层面的周报汇总。因为你的角色，是要对项目结果负责。
YesDev为项目负责人自动、智能汇总了项目的详细周报。里面的内容包括不限于：项目汇总（整体情况概述）、项目排期（每个项目成员的工作完成情况和工作量）、项目开发计划表（每个功能需求的开发进度）、项目需求清单列表、项目问题清单列表、项目任务清单列表、最近已完成的任务和下一步的任务计划。此外，YesDev还可以自动跟踪对比上一次你汇报的项目情况，同时提供了Excel的附件导出，还可以快捷发送邮件。在汇总、汇报和使用上，都是非常方便的。但是，注意，但是，你还是应该继续人工补充更为重要、核心的信息。YesDev工具只能汇总已知的信息和数据，但对于未知和以外的信息，则需要人工补充和识别汇总。
在每个月，除了关注当前的大项目外，其实你的项目肯定也不只这一个。都会同时并行或多或少好几个项目。那么，可以通过项目周报、需求周报、测试周报，在更加宏观的角度，汇总和查看整个团队、或者整个公司的项目情况和进度。
项目周报，是面向项目经理和技术负责人的；需求周报，是面向产品经理的；测试周报，则面积测试人员。分别从项目、需求、质量，几方面进行整体宏观的汇总。同样，支持增量跟踪对比，支持邮件发送，支持Excel附件导出，还支持定时发送的配置。例如，每周二、周四接收重要的周报信息。
最后，是定期在里程碑节点或重大的交付时期进行针对性的会议沟通和总结。
这时候，可以从YesDev先下载详细的需求列表、问题列表、任务列表，再进行你作为管理角色所需要用到的基础数据，然后进行统计和分析。
例如，我们最近总结和提炼的以下需求交付指标的统计，就很有参考的价值和指导意义。从多个项目为维度，进行汇总和横向对比。结合项目参与的开发人数，完成的工时，人均完成需求多少，需求平均工时，总需求以及需求完成交付率有多少。坚持两个月，进行纵向比较，就可以明显看到整体团队的效率如何。是有提升，还是有落后。具体是慢在哪里？是需求，还是人员？
看图表和统计数据，不是看图表和数据有多华丽，而是要看懂它，看懂这些数字背后的意义。这点很重要。也就是透过事物表面看本质的本领，抓住核心问题所在。
通过测试用例、测试计划和缺陷记录，做好项目质量管控
当项目开发进展一定程度时，就会进行需求提测。
但先别着急测试，我建议，先让测试人员整理好测试用例和测试计划，不要做太多无用功。先把需求理清楚，并且和开发人员一起进行测试用例的评审，确保对客户的需求有一致的理解。
作为测试人员，你可以在YesDev录入或导入测试用例。
然后，创建测试计划，规划你的测试用例和模块。
最后，可以把多个测试计划关联到项目，进行统一的管理和协同。
对于测试计划，一方面，你可以借助脑图进行更好的梳理。从测试用到，延伸到用例模块、具体的测试用例、用例所关联的问题。层层深入。
另一方面，测试计划也可自动生成最新的测试报告，方便你进行测试进度的同步和发送测试报告。
当然，在测试过程中，离不开提bug。那么在项目早期，bug很多，没时间记录怎么办？这是一个好问题。通常，你可以让开发人员先演示一下新功能，让他们自己操作一遍，进行冒烟测试。在做好测试用例的评审后，先根据大致的核心业务流程进行一轮测试。如果是细小的问题，可以不记录，例如文案错误，但对于有争议和需要时间修复的问题，还是要统一记录到YesDev。这些都是重要的资料。
实时关注项目的最新动态和风险
项目之所以失败，很大原因在于信息不透明、信息不对等、或信息延误。
这时，你可能会很奇怪。明明团队人员也不多，为什么就会存在沟通困难的障碍呢？
因为，有可能是因为程序员不爱说话、不喜欢主动汇报、特别不喜欢说出自己没做到或做不到的事情，也有可能是其他原因。但在实际项目开发过程中，有两个场景是可以结合的。第一个场景，就是把YesDev和你们团队日常沟通的钉钉群、企业微信群、飞书群等对接链接起来，实时接收最新的项目动态和研发进度。
让团队内部有充分的双向反馈和接收信息的最合适的方式。即需求指派有通知，需求完成也有通知。不仅当事人知道，连项目的干系人员也能知道。这是“共同看见”的良好结果，也是促进内部正向沟通的有效方式。配置上很简单，你只需要在YesDev配置钉钉群的机器人链接即可，1分钟搞定配置。
而日常办公，也离不开邮件。你可以把YesDev项目研发管理和协作过程中，重要的邮件通知，同步推送到成员个人邮件，支持精准、图文、实时、恰当不扰民的重要通知。
更加值得称赞的是，这些流转和通知，都是同步的，并且可以和开发人员日常最常用的git代码提交自动、智能关联起来。
开发人员不喜欢说话、不喜欢主动反馈，这些习惯我们改变不了；技术人员喜欢用git提交代码，我们也改变不了这些工具；但是我们可以结合他们的习惯和YesDev这款工具，进行自然而然的协同和管理。这是一些更友好、更沉浸式的研发协同。
只有当开发者个人的效率有提升了，当内部沟通更顺畅了，当协同工具更匹配更贴切更顺手了，我们的项目管理也会更进一个台阶。
如果要特别过去的项目泥潭，破解研发黑洞，消除项目目前的种种风险，你和你的团队，不仅需要新的思维方式，也需要新的协同工具，更需要具体执行的魄力和能力！
