项目有风险

lsekfe

今天下午15点，团队成员D向他的主管Z反馈他测试的项目有风险：项目在测试周期内，但在用例评审时发现有一处功能逻辑有争议，需要产品经理跟业务方确认，可能出现的情况有：1 不变更需求，功能逻辑按现有实现处理；2 需求变更，功能逻辑对应地进行改动，会产生新的开发工作量和测试工作量。目前进展是已经提醒产品经理跟业务方确认，但催了两次依然没有最终结论。

主管Z意识到D的反馈略晚，但依然提醒该同学应该将现有的影响、可能出现的风险尽早同步给相关方（产品经理、研发同学、相关测试同学以及他们的主管）。为了确保信息传达一致，最好的形式是在聊天软件里将事情描述清楚，然后 @对应的人。于是D把Z拉进了该项目的沟通群。


进入沟通群后，Z翻看了群成员和该项目的聊天记录，很快发现了几个现象：

l  群成员：这个群里有该项目的产品经理、研发人员和测试人员，但除Z之外，没有产品经理和研发人员的主管在群里。

l  事项跟进：D同学昨天和今天上午均提醒产品经理要跟业务方确认，产品经理回应已经在跟进，但迟迟没有确定下来，并计划明天上午再进行沟通。

l  风险周知：D在群内更多强调了当前是测试阶段，需求确定不下来是不合理的、有风险的，但并没有提及风险点究竟是什么，是只影响当前项目上线延迟，还是影响多个需求上线延迟。

如上，Z认为有如下问题：

l  群成员：一线同学在日常项目沟通时倾向于只拉具体对接的同事进群，觉得没有必要拉主管。不拉主管，优点是自己做得不足的地方，主管看不到，心理压力小；缺点是自己做得好的地方，主管也看不到，而且主管不知道做得不好的地方是什么，他都不知道应该如何辅导你。所以，Z认为不拉主管进群的缺点更明显。且这个项目已经出现了风险，理应将这些风险同步给各方主管，所以群里没有主管是非常不可取的。

l  事项推进：推动他人跟进的事项，建议定一个deadline，否则，只要当事人说在跟进中，其他人就只好等着，等多久完全凭个人感觉。定deadline的好处是给彼此一个时限、一个契机，解决了更好，没有解决可能就需要问题上升了，因为超出时限未解决，通常不是需要再给更多的时间，而是问题超出了当事人的能力范围，需要引入更大的力量了。

l  风险周知：如果项目没有提测，作为QA，可以提醒大家有风险；但项目已经在测试周期了，这个阶段QA是主导角色，应该对时间更加敏感，对项目的风险更加警觉，应该非常醒目地把明确的风险和影响进行周知，比如该项目如果需求变更，需要新增多少开发工作量和测试工作量，进而对后续项目的影响是什么，等等。

当前项目的风险如何应对基于上述的问题，Z进行了如下动作：
1 把产品经理和研发人员的主管拉入群内；
2 针对当前的情况，请研发同学和测试同学分别输出了确定性的风险和影响；
3 @了产品经理和研发人员的主管，请他们特别关注该问题。@具体的产品同学：什么时间能给出结论，以便确定该项目的后续事项，进而降低项目风险。

3分钟后，产品经理的主管群内回复：我们讨论一下回复。

两个小时后，产品经理给出了结论，具体不赘述，大体结论是需要进行产品变更，产品经理的主管随即回复：给大家添麻烦了，这次改动产品侧按流程进行需求变更，请技术同学评估改动影响和风险。接着，研发同学和测试同学分别给出了工作量评估、项目上线时间和对后续需求的影响和对策。

此时，Z单独跟D同学聊天：看，这就是同步主管后的响应速度和态度。D同学反馈：解决好快！！！后面遇到此类问题，我知道该怎么做了。

以后项目的风险如何规避该项目上线后，应该尽快组织一次三方复盘，收集各方在本次项目中的痛点和痒点，并讨论出解决方案，避免后续项目出现此类问题。
思考：何时是理想的风险反馈时间点？在上述案例中，当前项目出现风险时，在什么时间点反馈，更为理想呢？
我认为，刚发现风险时就应该反馈风险，在本案例中是需求评审时，那么在需求评审结束后，可以对当前情况进行说明，识别可能产生的风险，并周知到相关方及其主管。其次，需求提测时，如果风险还在，也需要再特殊说明一次。因为提测后就进入了测试周期，这个阶段是上线前最后一个阶段，此时出现风险极大概率会导致项目上线延期，进行相关方周知一是报备风险，二是给到协同方一定的压力，促使协同方尽快把需求确定下来。