【头脑风暴】项目风险和问题度讨论

阳光小胖胖

各位好，最近在工作中遇到一些疑问，想听听各位的意见，请大家有空的时候，都来畅所欲言下吧！欢迎顶贴~~~~~~~~~~~~~~~~~~~~~~~~

1、
PM在日常管理的时候，需不需要根据问题措施的执行情况来刷新项目的“严重程度”和“紧急程度”呢？还是说一个问题或风险登记时是什么严重级别就不变了呢?（个人觉得需要刷新，这样我们才能更明确一个风险或问题的及时情况）

2、
对于每周来说，PM关注问题或风险的哪些内容呢？会不会关注本周关闭了多少个问题，新增了多少了？还是目前的各级别风险和问题有多少？还是……。

3、
对于项目结束时，PM最想看到风险和问题的什么数据呢？或者说一个新的项目启动时，PM最想借鉴以前的什么数据呢？会不会关注这个项目我曾经登记了多少个各级别的问题，主要是哪些类型的问题，每类问题的解决周期大概是多少呢，还是……。

上一篇：SEI关于提高客户满意度的文章
下一篇：CMMI V1.3 Word版

nini

是个好问题，说下我的想法:)
看起来风险管理和缺陷管理混在一起了，我不太清楚LZ的“问题”是不是特指缺陷，还是泛指可能影响项目目标实现的一切。我仅仅针对风险说下我的理解

我在本机索引关于风险的文件（插播广告：强烈推荐windows系统用户使用Everything工具，本地索引秒杀），没想到搜到的是之前老漂整理的，挺好，就直接上传了。这样说明起来很容易了。

一、关于风险是否及时更新

首先，我觉得风险就是可能影响目标实现的事件，而风险管理就是提前为发生这些事件做准备，比如降低事件发生概率、抵消发生后的影响等都是风险应对策略，所以这个一定是动态的，所以风险等级也一定是动态的。

但如果项目周期比较短，风险未必需要更新，有些事件大可不必每日跟踪。比如用户需求变更是个风险，但是否要每天改变对策，则需要看具体的项目阶段。

二、关于质量风险
LZ说的应该是缺陷，项目管理核心就是在既定质量范围内的进度管理，其它都是核心的外延或内涵，从这个角度看，分析问题的严重级别和风险要评估两方面，时间进度方面和质量预期方面，一些Team习惯从测试或者PM的好恶来看要不要做到某种程度，而不习惯真正站在投资者的角度来分析。
当然，这个取决于是否能够和投资者（也许就是客户，也许不是）密切联系。

三、谁最关心项目风险
所谓风险管理，首要的并非是做风险管理计划、评估风险、跟踪风险状态，关闭风险这些显示的流程。这是一种表现，即使在SQA的帮助下这份文档整理得非常好看，我认为这也只是次要的。
因为每个人的视野不同，判断力和决策力不同，把每个人的风险集思广益的列出来，大家讨论，制定风险管理计划，这固然是一个良好实践，真正首要的是核心人员识别风险的能力，这个不一定非要写在纸面上的。
举个简单的例子：比如Team核心人员（产品经理或项目经理、或部门经理）侧面了解到某主要工程师在寻求跳槽机会，他大抵是不会在Team分享他的信息。但他一定会想办法去做未雨绸缪，比如他会去和老板多要一个相当的资源，他会请当事人吃饭谈心，甚至会亲自设法去其它公司挖人。但这些SQA是否被告知或更早知道，则是未定数。

有些SQA总希望项目带队的人能够把风险管理得非常文档化，这个我觉得大可不必了。我觉得用私下个人对个人的帮助更让人能够接受。当然，SQA所有的事情都应该是帮助Team来识别问题。只是突出个人感受对工作有好处。

基于这些认知，我的理解是无论项目的Owner是谁，TA对于风险的控制应该是枚举而非度量，虽然风险也可以汇总，但汇总这种工作价值太低，一个待办事宜列表就可以了。

至于缺陷方面的度量，这个太多方法了，就不展开说了。

漂在生活

nini说的很好，顶一个。

msnshow

很好，顶

端木若希

有些SQA总希望项目带队的人能够把风险管理得非常文档化，这个我觉得大可不必了。我觉得用私下个人对个人的帮助更让人能够接受。

文档：可视为项目中的数据，QA执行过程中的一种依据，和项目成员达成的一致见解。风险管理文档化了，将是项目管理中非常有帮助的资料，可作为公司数据库的积累。

一啸长天

嗯，继续讨论，关注中！

yzltt

nini说到了SQA职责的一个问题，文档的标准化应该有一个标准的范围， 建议是根据文档性质制定模板框架，内容的信息点覆盖到就是，至于内容血和肉的如何融合 融合的完美度如何？一般的QA很难定义

个人拙见而已哈，呵呵

wuxiyaya

当然要进行风险跟踪管理，基本上定时进行，具体时间间隔要看项目情况。

霓馬

看起来不错

ζ那场婚礼

很有见地的探讨，先收藏着~

暗恋过

路过的帮顶

心鬼

路过的帮顶

向鈤葵の微笑。

确实不错，顶先

月考不愁！

很有见地的探讨，先收藏着~

大猫咪

看帖要回，回帖才健康，在踩踩，楼主辛苦了！