[测试视角]软件项目管理过程中潜在的风险项分析

作为Tester中一员，最近参与了几个软件项目的测试工作，有的项目虽然已阶段性上线，但是项目开展过程中并不是顺风顺水，特别是项目后期上线进度的逼近，项目组内各成员身心俱累，特别是我们的开发工程师，项目初期持续加班到很晚有很多天，精神状态并不好，槽点自不会少，甚至某一时期内有成员之间关系一度紧张。
当然，本文不是为了吐槽而吐槽，而是从亲历的角色中分析项目开展过程中经常遇到的一些问题or风险点，同时以当前有限的认知程度下寻求应对之策，以抛砖引玉，大家一起分享这方面的经验和心得，互助提升！
一般软件项目从无到有，大致需要经历[市场调研->项目规划->需求编写->产品设计->前端切片->开发实现->质量测试->验收上线->交付使用->后期维护]的过程，实际情况除了此种单一线性的模式，还有其他模式，有的阶段其实是同步进行的，并非只有上一阶段完成之后才会输入到下一阶段。作为整个项目的一环，每个阶段都很关键，若某个环节没有处理好，很可能就会引起整个项目的受阻。

• 市场调研阶段

案例场景：
自己非专业的市场人员，没有深入了解其中的道道，不过曾经和某IT公司的HR聊天时有了解过对方公司产品项目的现状，公司当时有A和B两款产品，但是A产品已经基本告吹，当时连网站维护都没在做了。A产品是一款纯聊天的产品，之所以没成功，同类可替代A的产品如微信、QQ等的地位绝不是轻易能撼动的，而且纯聊天的功能被替代的可能性实在太多，其他同类产品还有功能多样性的优势。B产品是当时计划准备开发的产品，是关于直播类的软件，初期计划采用一对一直播聊天，观众给主播送礼的盈利模式。这次在上次的经验下，准备雇一个产品策划和推广的专员来推这款产品。和目前大众流行的多人观看主播和送礼的模式相比，B产品主推的应该是差异化服务项目。具体推广和营收效果会如何，在此不作预判，需要后续继续观察。
潜在风险：
缺少对项目可行性的评估，对项目中产品的潜在客户群体、需求市场的竞争度、盈利模式、持续性等缺少可行性分析，很可能项目前期花费了大量的代价（时间、人力/物力/技术成本）去实现，到最后才发现根本就没法盈利，没有预期的需求市场，最终项目不得不取消。
创业投资能成功本身就不是大概率事件，做决策执行之前，需要充分论证方案的可行性，以及期间会发生的各种可能性（有利&不利），并有相应预案，及时监控项目推进的方向在可控范围内。

• 项目规划阶段

一旦项目立项确定，需要对项目进行整体的规划：项目计划完成周期，项目包含的主要阶段组成有哪些，每个阶段需要关注点是什么，如何衔接配合，以及所需要用到的人力/物力/财力/技术的资源，项目上线的验收具体标准如何，项目过程中的风险防范等。
潜在风险：
【1】项目周期预估时间过短，导致项目各阶段所能分配的时间 << 所需的时间，项目质量得不到保证
【2】项目流程采用过于理想化or单一的模型，一些隐性且必要的流程（质量持续监控和反馈）没有被关注到和有效实施
【3】项目所需的某些阶段因某些原因而被省略，引发最终产品质量问题多多
【4】项目缺乏分阶段性的验收确认，到最后上线才发现很多根本性的问题，短期内难以调整而只能妥协
【5】项目所涉及各阶段的时间进度计划不够明确，项目成员执行任务计划时容易混乱
【6】项目过程中前后阶段的衔接，缺少准入和准出确认，导致上一级的问题累积到下一级
【7】项目所需的有效资源储备不足，使得项目开展过程阻碍较多，甚至延期上线
【8】项目组各成员对业务和技能的经验值差异较大，某些环节出现薄弱点而可能影响整体进度
【9】项目组内成员临时调整和变动频繁，导致承接性出现异常，短期内不容易把控项目的整体情况
【10】项目初期缺少对新人同事的培训快速熟悉业务和工作流程的机制，致使项目开展不顺
【11】项目组内部成员的情绪波动较大时没有及时得到引导，可能互不配合工作，项目推进受阻
【12】项目自始至终都没有一定的激励机制，or有也是非常不透明的机制，妨害公平性，有损员工积极性
【13】项目过程中可能出现的意外情况分析不足，过早承诺于人，当意外出现时有可能失信于人
【14】没有建立起适用于当前阶段可行的风险防范机制，对风险点预判不够，对风险的应对效果不理想

• 需求阶段

需求，最直接和本质反映用户的期望，需求的客观、充分、清晰，是后续阶段工作开展的重要基础，产品、设计、开发、测试、验收、上线交互-整个流程都会依赖于需求而进行，因此真的真的非常重要，非常重要，非常重要！
潜在风险：
【1】没有需求文档，产品设计、开发、测试、验收过程中缺少基本的参考标准
【2】需求不明确、模糊不清、前后逻辑矛盾、重要业务逻辑项定义不清晰，对后续阶段工作开展多有不利
【3】需求频繁变动，项目后期依然有较大的变动调整，影响开发和测试工作不充分，可能产生负面情绪
【4】需求管理的版本没有及时更新，项目组成员获取的需求版本不统一，参照系不一致，可能会做无效功
【5】项目成员没有充分对原始需要进行分析，一些潜在的问题点没有及时被发现
【6】没有及时召集项目相关的所有成员参与需求讨论会，导致某些成员实际开展工作时出现困扰
【7】一开始没有建立起需求管理控制，需求整理遗漏，导致新同事短期内熟悉业务比较困难

• 设计阶段

设计阶段，基于上一阶段的需求文档，建立实现产品功能的原型图、设计图，从UI图形化层面建立模型，供后续开发、测试和验收参考。这个阶段也很关键，毕竟用户使用一款产品的第一印象往往是通过UI界面开始的。
潜在风险：
【1】对需求理解不充分，设计图、原型图的构建出现与实际需求的偏差
【2】需要中有不合理之处，完全沿用需求来设计，未及时提出来调整，延续到后面阶段才发现问题
【3】因工作任务累积混杂较多，有可能对某些项目的设计工作缺少足够的精力，设计遗漏or错误
【4】缺少对浏览器、设备分辨率、设备类型的兼容考虑，导致后期经常性折返回来重新调整设计
【5】产品经理未对设计阶段的输出成果进行验收确认，把存在异常的设计样式直接转给开发工程师
【6】新人产品同事可能缺少对整体项目的把握度，以及协调各方人员和资源推动项目的技能不足，过程中存在的问题没有及时解决，项目后期才爆发出问题来

• 开发阶段

开发阶段，基于前面的需求文档、原型图、设计图，把需求中所期望的功能进行编码实现，集成为一款实实在在完整的产品。这个阶段是承上启下的一个关键节点，项目推进的一个里程碑表现，意义重大。
潜在风险：
【1】对上一级输入的成果未作确认是否符合开发的要求，直接编码，一旦上一级成果需要修正，编码也不得不调整
【2】未充分理解需求，致使编码实现的功能模块有遗漏or实现的业务逻辑不对
【3】没有把需求和设计图/原型图中存在的不合理提出来调整，而是完全依照而编码
【4】选用的开发框架在某些设备上可扩展性不佳，后期修改部分功能时不方便调整
【5】没有严格按照公司规定编码规范操作，缺少必要的注释，不利于复查，代码出现不必要的重复，影响产品的性能
【6】开发功能之间的耦合度过高，一旦调整某个小功能，很可能引发一系列的问题出现
【7】实现了某个业务流程及其功能，但是没有对其中可能出现的异常情况进行判别和处理
【8】有新人开发同事可能对业务不够熟悉，对编码的经验不足，导致开发工作缓慢，进一步压缩了后续测试的时间

• 测试阶段

当开发工程师把初步实现的项目交接给测试工程师，对应的是系统测试，根据需求来设计包含业务流程、功能模块的检查点，构造测试用例，运用专业的测试方法对每个检查点进行测试，检验产品的功能是否按照需求所预期的来实现，及早发现影响业务和重要功能的Bug，转开发工程师修复。依不同的项目要求，其中也可能涉及接口测试、单元测试、集成测试，还有一些专项测试，如性能测试、安全测试。
在符合公司利益的前提下，通过不断测试-修复-回归，最终确保在主流设备、OS、浏览器、分辨率环境下，基本的业务流程、功能模块、功能点实现能符合需求，对用户可能的异常操作进行有效预防，对大量访问操作的页面和功能进行性能优化，对涉及敏感操作和用户隐私的功能进行安全检查，且用户体验尽可能符合用户使用习惯，按质按量上线，交付给用户使用。
潜在风险：
【1】测试计划不合理，测试周期、人员的评估不足，导致测试时间紧迫，测试不够充分
【2】没有分析好项目的复杂度、功能模块的数量、业务的交叉关联性，就直接随主观感觉测试，导致主次优先级混乱
【3】对需求理解不充分，导致测试用例设计不合理，测试覆盖度不够，有漏测的情况
【4】复杂的业务逻辑分析不到位，某些场景or条件没有考虑到，不能及早发现关键性问题
【5】对构造不合理的用例，缺少评审，导致可能大量出现重复性的用例，花费了较多时间也不一定能达到较好的效果
【6】需求分析、测试计划、用例设计、用例评审、测试的Bug记录、修复状态及原因分析-输出的文档，没有有效管理，当转给其他同事的时候会不容易快速熟悉需求和业务
【7】对需求中没有明确的问题，没有及时和产品经理确认，导致所提Bug可能无效，or重要问题被遗漏而没有得到及时修复
【8】对测试环境和正式环境的切换配置出错，导致测试数据放出到正式环境，影响正式环境的用户体验
【9】缺少团队内部的经验交流，致使彼此不了解对方的业务，对个人的技能成长也不利，有的问题A遇到过，很可能下一次会是B遇到，若提前有交流和预防措施，可以更好地减少不必要的失误
【10】新人同事一开始对业务和测试经验不多，短期内直接接收项目，可能会遇到很多困扰，项目推进缓慢
【11】与开发同事缺少有效沟通交流，当开发调整一个功能时，测试没有get到，对全功能进行测试，抓不住重点，造成过测试而花费过多时间

• 验收阶段

当测试工程师完成了内网环境和线上环境的测试工作之后，且回归完成开发工程师所修复的问题，确保无其他异常的时候，交由产品经理再次作确认，确认若发现异常or待优化的地方，则继续提给开发工程师修复；若无异常，则验收确认，由我们的运维工程师更新到正式环境。正式环境更新之后，也需要产品经理再次确认。
潜在风险：
【1】在测试阶段和产品初次确认阶段，都没有发现有的问题存在，更新到正式环境后暴露出的问题，对项目不利
【2】因测试环境和正式环境的差异，同样的功能在测试环境是正常的，到了正式环境可能出现异常`
【3】更新到正式环境，产品经理没有及时确认，有可能有的问题一直暴露在正式环境而没有及时被发现和修复，影响用户体验和公司形象
【4】因某些原因导致上线延缓较长时间之后再做确认，而此时可能同步在上线其他项目，不容易专注于此

• 后期维护阶段

维护阶段，主要是对以上线的项目提供持续稳定的服务和支持，确保用户访问的正常，后续用户实际使用过程中，若有发现异常or需要优化的地方，由产品同事收集后排期安排进行调整和更新。这个阶段其实也很重要，特别是我们的运维工程师和测试工程师需要持续跟踪项目上线后的情况，一旦发现异常，就应该及时反馈和修复，控制损失到最小。
潜在风险：
【1】服务器异常or不小心关闭正式环境的服务器，导致用户临时访问异常
【2】新的优化项，没有经过测试和产品确认就直接更新到正式环境，可能引发一些新的问题也没有及时发现和修复
【3】没有提前预估好实际用户的访问量压力，某个时间内可能访问量极大而服务器不足以支持，出现卡顿、甚至页面打不开的情况
【4】缺少安全预防的配置防范，当攻击者恶意操作的时候，引发网站异常，使得合法用户不能正常访问