质量315，你遇到了什么？
恰逢315，质量又被提上了日程，各种质量打假与曝光也被纷纷登场亮相，特别的有意思，也特别适合各种行业外小白去深入的了解行业黑幕，噢，不对，是内幕。
我们也盘点一下IT项目中很容易出现的各种需要被打的假吧！
如有雷同，纯属巧合，请不要对号入座。
315之资源
问：“你们的项目经理做过类似的项目嘛？”
答：“PM具有丰富的项目经历，经过了公司上岗认证，并且刚从上个项目上撤出来”
打假：
做过项目不等于做过成功的项目，通过上岗认证不等于能力具备，资源撤出不等于资源能力高超。
看项目经理是否能力足够，不能只看简历描述，最好面谈沟通，询问做过的具体的项目背景材料、甲方客户基本情况、业务描述吻合度、项目贡献与价值总结，对该项目的分析与风险识别，是的，初期应该有一个风险识别。
如果是PMP，基本上可以认定对项目管理有了体系的掌握，业务能力的具备与否再识别一下就基本靠谱了。
问：“项目团队是否配备足够？关键资源是否稳定？核心技术人员投入在我们项目的工作量如何？”
答：“项目计划中有资源计划，并且都会安排到具体的工作日，项目是公司非常重视的重点项目，核心技术人员一定会保障”
打假：
资源计划排定了不一定执行，即使到了具体的工作日，公司对每个签单的合同项目都会重视，核心技术人员一定会优先投入到战略客户或者VIP大合同项目中。
所以自己先分析是否符合这两条吧？
项目计划制定后，密密麻麻的看起来非常复杂，尤其是对于不经常看项目计划的人而言，不要以为有了非常详细的项目计划，项目资源就会按计划投入并有所保障。
要注意，资源是随时可以调整的。
不看计划看里程碑，要看WBS工作包，看每个交付阶段的交付物质量与交付时间，相信我，你会有自己的判断的。
315之方案
“PM带领项目组非常积极配合，认真的倾听，基本同意了我们提出的每个要求，这个项目一定会成功的实现我们的预期”。
打假：
每个项目的需求和方案都是值得反复推敲和斟酌的，项目团队如果只是“好好好是是是”的工作态度和方式，那么基本可以认定，这不会是一个成功的项目。
因为成功始于细节和小节，尤其是对于业务方案来讲，某一点的差异将对IT系统的成功部署实施有着决定性的的关键。
相信我，敢于说不并且提出方案的PM值得你跟他认真深入的研讨，或许，这就是项目成功的关键。
315之软件质量
问：“系统不好用，出现很多问题啊”
答：“软件都有bug，即便是微软系统，不也要定期更新补丁包吗？”
打假：
软件都有bug，不代表软件都不能用，bug有大有小，如果连基本业务都无法顺利跑通，那这可不是业界的惯例，一定在软件开发过程出现了问题。
软件测试是开发后的基本环节，无一例外！
如果项目工期催的急，那么测试环节有可能被压缩，毫无悬念。
如果测试地位不高的话，那基本上测试=打酱油。
遇到软件出现严重问题时，第一时间可以与项目经理沟通，有权了解白盒测试和代码走查的方式方法，并直接与开发经理沟通，这可能是最有效的方法。
问：“系统问题怎么总是出现？开发人员水平有问题啊？这么一个问题总是改不好”
打假：
如果一个bug总是频繁出现，如果每次都伴随着版本的更新，那么可以肯定，软件开发过程的配置管理出现问题了，代码版本管理不规范是罪魁祸首。
配置管理和代码版本管理一般而言用户方不会得知，但实际上，由于种种原因，很多项目的配置管理做得并不好，这种情况，一定要询问版本管理是如何做的？有没有项目专职配置管理员？
看似不起眼的小角色，可能会把多个项目搞的一团糟。
315之计划
问：“项目要实现的功能按评审意见调整一下”
答：“可以，跟开发反馈一下，尽快改完”
打假：
如果需求变动没有任何的工作量估算、影响分析、审核、签字确认的话，那么可以预见项目需求管理过程的不规范性，项目能否做好需要打一个大大的问号！
正常来讲，对于规范的项目，遇到需求变更时，PM有权决定变更的空间非常小，更多时候应该反馈到CCB，进行变更的分析与批准，同时需要用户方进行确认，必要的时候签字确认。
这看起来麻烦，实则对项目负责，而随意的更改必定缺少一系列需求、设计、开发、测试、部署等分析，缺少了这些环节，欠下的债，早晚要还的。
质量315，你在项目中都遇到了什么？
~~~~~~~~~~~华丽丽的分割线~~~~~~~~~~~
专业项目管理提升，打造现代卓越人生
想学习的进步青年，
请拨打：0531－86559518
想投稿的有料才俊，
请来信：jnpmapmi@126.com
想提升的专业人才，
请访问：www.sdpmp.com
