CMMI on line

不少公司可能会让经验不多的人来写过程文档，甚至是让应届毕业生来写，这是很不妥的做法。
没有估算经验的人，会把估算过程写好吗？
没有设计经验的人，会把设计模板写好吗？

而由缺少项目经验的人写出来的文档，将会被有项目经验的人执行，这样岂不是让大家当“白老鼠”，后果严重的话，会严重影响公司的战斗力，最后会导致工程类人员与写EPG的对立，再进一步就是导致对CMMI误解。

项目计划部分的过程文档，应该由资深项目经理总结自己的实践经验来写。
需求部分的文档，应该让需求调研高手来写。
设计部分的文档，应该由设计高手来写。
......

高手写出来的东西才有价值，这样才会把高手的做法“复制”给大家，让大家一起达到高手的水平。

就好像如果你要去买一本书，你会选择高手总结经验写出来的书，还是会选择刚毕业的通过自学学到一些理论，然后总结出来的一本书呢？

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

就是啊，我们公司PPQA过程文档就让我这个刚毕业还没有一点QA经验的人来写

好在有二级的过程文档在那摆着，又有咨询老师的帮助

总算搞定，也通过老师的评审了。。。

文档是出来了，不知道是否经得起实践的考验呢？有机会谈谈你的文档的实施情况啦。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

今天刚把QA计划搞定，感觉还是存在问题，QA实际上就是一些检查及监控，产生的工作产品也就是检查表及工作周报之类的。可是有些过程域无法很好的进行跟踪，只能通过询问，但是如果你不懂那些技术及原理，只是一味地问他有没有完成，进行到哪一步，那他也只会敷衍你。比如说物料的采购、样机的制作、软件功能的实现等，感觉好多检查及监控的东西都是在询问。

针对这些，作为QA应该怎么来改进，让整个项目组都能对文档负责，而不是敷衍？

---

爱拼才会赢！

做QA很不简单，要做一名出色的QA，需要QA是项目的专家，华为曾经招聘项目经理做QA的。

作为QA来说要努力提高自身水平，但过程改进不是QA一个人的事情，过程改进是全员参与的，特别是需要高层参与的，如果整个事情，只有QA在出力，如论QA水平有多高，项目组也是应付你的。

有几个问题和建议：
1.公司高层，部门经理，项目经理对过程改进的态度是怎样的？不要要口头支持，还需要有实际的行动？
2.贵公司的过程是不是项目组自己建立的？还是“空降”的？“空降”的过程，注定是难以执行的。建议由项目组根据自己项目的特点，从保证项目成功的目标出发，让大家一起来约定过程，并在做的过程中不断检讨，过程必须要很复杂，也不需要一下子满足全部CMMI的要求，发挥大家的主动性和创造力，让大家先讨论决定项目的过程。这样QA就变成监督大家制定的过程的执行情况，因为过程是大家制定的，所以应该不会出现敷衍的情况。
3.QA的责任其实不是保证项目按过程执行，QA的责任其实是帮助项目成功，发现问题不是QA的主要工作，预防问题才是！QA要让项目组觉得，你是和他们一伙的，都是为了项目成功。
4.如果写出来的问题，如果项目组不看，只有QA看，这样的文档就不要写。简单有效，是过程改进的重要原则，另外也要注意不要拔苗助长，项目组一开始，可能是不需要也没有能力写这么多文档的。具体要写什么文档，写什么内容，和项目组一起商定，并在以后不断修正。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

我是新来的，午休时间就看了这个帖，随便说几句：）

好像讨论的内容已经不仅限于过程文档由谁写，而且演化到怎样写的问题。

我就还是先谈谈“规程由谁来写”的问题：）

由有经验的人写肯定比没有经验的写好，这个道理谁都能理解。但是如果企业里没有人有相关经验呢，比如CAR。

所以还是按照CMMI的要求，由EPG人来写（EPG就是立法的），即使由有经验的项目经理或开发人员来写，他们也要是兼职的EPG成员。否则各个部门就慢慢乱了，会搞出很多规程出来。想想如果一个从事律师行业30年的普通人，就可以制定国家法律，那这个国家会是什么样子。

我看过好多的帖子，要想做好QA，确实需要掌握很多知识，当时我们老板也是这么和我说的，QA是一个很有挑战性的工作。了解了工作的性质，我也在不断的充实自己，让自己有一个大的提高，以不被淘汰。

和高层及项目组的沟通真的是很重要，看过好多帖子都说项目组与QA都是相对立的，老觉得QA是在找他们的麻烦。看到这些我真的好担心，好担心自己的工作不好开展。但是我是不会放弃的，没有付出过努力，又怎么能不能行呢。

 

---

爱拼才会赢！

cecilia513 ，你也在深圳？方便告诉在哪里吗；）

你上面还有个问题是如何让整个项目组都能对文档负责，而不是敷衍？我来谈谈我的经验。

比如在需求阶段，我们要和项目经理或者系统工程师沟通，可以这样问他们：你们对需求阶段的质量是否关心？最关心什么？怎样才能够让你们放心？如果他们说不关心，他你就把他们的话记录下来做为需求里程碑的评审记录就OK了：）QA不是万能的。

如果说关心，那最关心的肯定是（新）开发人员是否理解需求。那怎样关心呢？我估计他们最多也就提出来一个同行评审。这个时候你就可以提建议了：写出来不如讲出来，应该让开发人言对自己负责的内容进行讲解，你们觉得还可以那才是真正的了解。然后把讲的内容记录下来，就不难了。（其实开发人员不愿意写需求，就是不知道该写些啥，除了进度因素这才是最主要的）

要想不让他们觉得QA是在找他们的麻烦。我亲身的体会有两件事需要做：一是一定要切切实实帮助他们解决问题，不能遇到问题转个邮件让他们解决。比如文档没放到CC上，那你就要友善的去问为什么没放，会不会放，顺便沟通一下感情，以后的工作就好开展了：）

二是一定要有实力，你要是不了解为什么要制定项目管理计划文档，而只是要求人家做，那人家当然就认为你在找麻烦。反过来你告诉他，你不做会有什么问题，又或是指出以前没做发生了什么问题，那就很好沟通了。

加油啊！相信你一定可以成功的!

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

没有相关经验，就在矮子里面找最高的来写呗。CAR我们之前也不知道怎样写的，也没有懂怎么回事，我们也是自己摸索一边实践写出来的。一下子让咨询公司提供一套过程或者从哪里拿一套过程过来，是比较难走通的，除非有人能详解解释过程的每一个细节，并且和实际工作结合起来。

过程改进是全员参与的事情，不是EPG的人也可以写文档，当然也可以做EPG兼职。我们公司的做法是EPG成员分为常任和客席两类，客场成员是定期轮换的，另外我们编写过程的时候，编写人员并不限于EPG内部的，全部员工都可以写。

当然，一个人写的文档，当然不能马上成为“法律”，还是需要评审的，最后通过评审的文档是集中了大家智慧的文档，所以不是一个人就可以“立法”的。

但话又说回来，过程还是和“法律”不能直接的等同，特别刚进行改进的时候，就算由经验的精英们写出来的过程，也不一定适用，但可以一边用一边改进，持续改进是做过程的重要思想啊。最开始的时候，过程执行可以弹性一点，到慢慢成熟，大家的对过程的理解、认识也逐步提高的时候，可以慢慢加强执行的力度。

关于过程的建立，我的建议是逐步建立，逐步执行，这个过程让大家都参与，其实所有人员都是EPG成员。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

这位兄弟或者女士的意见非常有价值！

干QA的活，很多是看细节的，和项目组沟通要有技巧，要让项目组觉得你是在帮助他，而不是找麻烦，另外越到具体的工作，可能就越需要理解这些工作。我这里也举一些例子：
1.某项目决定只写一份很简单的设计，而完全不写架构设计、模块设计，也不做设计方案的选择，原因是这个项目是基于成熟的产品做开发的，产品已经有详细的设计并且做了方案选择，项目就不需要再重复了。如果QA不理解，很可能会抓项目写一大堆设计文档。
2.某项目测试，发现了很多缺陷，比起公司类似的项目发现的缺陷数量，超出了好几倍。如果不了解项目的情况，会认为项目质量很差，而实际上发现这么多缺陷的原因是，本项目其中一个重要的工作是改造客户原有的程序，大部分的缺陷是由于客户原有的程序产生的，而且我们事先就估计到，并且已经和客户确认会有这样的问题的，因为客户原有程序是很难改得动的。
3.某项目以实施工作为主，实施预算要占整个项目的60%以上，这时QA的工作重点是盯住实施部分的过程，而不需要把大部分精力放到开发、编码、测试上，因为这个项目是基于产品稍微改动后就可以给客户部署的，实施才是项目的重头。

我要求我们的QA，要大致了解每个项目的业务和技术特点，要知道每个项目的工作重点是什么，不要用过程一刀切，要用灵活的眼光来看待，并且要在项目制定自己过程的时候，要发挥作用，提供意见，然后按照项目定义的过程来监督项目，而不是都按过程来统一看待每一个项目。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

我就是遇到以上的情況﹐工作經驗不足卻被安排做確認這塊﹐現在發現越來越困難﹐有沒有什么好方法推荐一下﹐謝謝

你提到的“确认”应该是Validation吧？

我想首先你们应该确定你们的什么工作是“确认”，这个事情需要用集体智慧来确定，当你们确定后，你再看看相应的这些内容你是不是这方面的专家？如果不是，你应该找相应的专家和你一起来协商，应该如何制定相关的过程和标准。

很多公司最开始的时候都会按PA分任务的，这是很正常的，但EPG各位成员一定要互相支持，其实一个PA涉及的内容是很多的，往往一个人是搞不定的，负责这个PA的人，就要起到带头推动的作用，组织相关人员来完成，而不一定非要自己亲自抓破脑袋来想自己不熟悉的领域的过程。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

是validation﹐我們公司是做手機研發的﹐我們部門主要是測試﹐所以確認這塊就分到我們來做了﹐我目前是validation 的PA owner,有軟件設計﹐硬件設計﹐硬件測試﹐軟件管理部各一人協助我的。 我遇到的主要問題是﹕1.公司剛成立不久﹐個人覺得不夠成熟﹐沒有一個 項目是完整走過整套流程﹐而且我發現公司流程在測試部門不適用﹐我們測試部門比較獨立﹐有自己的一套測試流程一直在和別的公司合作類似外包。

2. 協助我的人包括我自己經驗都不足﹐更談不上是專家。公司一個月后會安排找咨詢顧問﹐不過前提是我們先要寫validation process,validation plan and managment guideline and so on﹐開始接觸這個﹐感覺不知道如何下手。

謝謝幫忙

你们的validation是不是就是你们的测试？但一般来说测试是verification的一种，不是validation来的。不过目前不好判断你们的对应是否合适。

话说回来，我觉得你们暂时没有必要非要去做什么对应，既然你们觉得测试部门的过程可能需要改进的，那就可以先行做改进。改进不一定非要对上CMMI标准的，你们觉得有用就做。

到时你们可以让你们的咨询顾问对你们的做法提意见，同时问问他们你们当前的做法，和CMMI的标准的如何对应。

你们只需要考虑怎样改进，对应这事情你们还不是CMMI标准的专家，就让咨询顾问来做，你们是给了钱给顾问的噢。

另外CMMIonline推出免费的培训及咨询服务，欢迎你们申请：
http://cmmionline.net/files/23/trainingmaterial/entry8161.aspx

 

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

对于做cmmi咨询,过程文档最好还是由懂得cmmi的人来写好些

过程文档应该让最终执行这个过程的人来写，找该方面的专家让他们来结合实际工作情况来写，只写自己能做到的过程，不要写貌似满足CMMI要求但又执行不了的过程。

过程是用来执行的，不是用来过级的，希望大家都是以这样的态度对待CMMI。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx