前言
今天我们继续聊聊在 项目开发阶段，项目经理需要做好的事情 😃
二、项目开发阶段（续）
4. 控制好项目开发质量
要控制好项目开发质量，主要是依赖测试，好的产品都是靠不断地测试，不断地试错做出来的，比如程序员单元测试，后期的整体测试，有修改时的回归测试等等，不管是多伟大的信息系统，都不能违背这个规律。
有一点很重要的，就是不要相信程序员的自测，最好从一开始就指定成员专门负责测试，即便是只有一个 QA，也比全部交给程序员的自测要好，因为大多数的程序员对于自己的技术有一种 “迷” 之自信，认为从自己手中产生的程序是不可能有问题的，所以不会对所有的路径进行测试，而且程序员对于自己写出来的程序常常有一种特殊的感情，有时候就算看到问题了，也舍不得删除有问题的代码，心存侥幸地希望客户不会发现问题（这也是为什么很多项目的代码中有一大段一大段地被注释掉而没有删除的代码的主要原因 _）。
测试工程师最好从一开始就参与到需求分析、系统分析等工作之中，只有对业务需求了然于胸，才能有的放矢的写出精准的测试用例，我以前工作所在的 BDNA 公司，爱尔兰的一个团队，给领导和客户演示系统时，都是让测试工程师上台做演示的，整个演示过程如行云流水般顺畅，效果非常好，他们的测试工程师真的是整个团队中最熟悉业务和软件流程的人。
在项目开始编码时，测试工程师就应该同步准备测试用例了。写测试用例时一定要注意详细地写输入条件，期待输出结果等，这样才能够确保交付的功能是可信任的，在测试的过程中除了关注软件功能之外，尤其要留意进行边界值测试，根据我多年的经验，绝大多数的程序员在实现功能时，通常只使用常规的数据进行自测，但实际生产环境的数据会很复杂，所以在交付给客户之后经常出问题。
在测试出 Bug 时，测试工程师最好地写上详细测试数据、实际输出结果和期待输出结果，这样方便程序员进行问题重现和定位，减少程序员和测试工程师之间矛盾（程序员和测试工程师之间矛盾绝对是一个开发团队里最常见的人员冲突 _）。
理论上在测试过程中，所有出现过的 Bug 都是可以重现的，但我们在实践过程中，确实也发现有相当一部分 Bug 很难重现，这绝大多数跟环境和数据有关，所以测试工作其实是一个很枯燥，很需要耐心的工作，在这方面，女性测试工程师会做得比较好。
安全问题最好一开始就重视上，国内的企业已经越来越重视这方面的问题，而国外的公司，特别是欧美企业，对于安全问题，已经达到苛刻的程度，我以前为美国企业 Flexera 工作的时候，就被这些安全问题折腾得很痛苦！
最后再强调一点，软件测试是一项贯穿整个项目开发过程的工作，只要代码有修改，就不能忽略回归测试和整体测试，程序员修改好一个问题，却产生 N 多个问题是很常见的事情。
5. 做好沟通管理
在项目的开发实施过程中，作为一个信息系统项目经理，现在你要面对三群人：你的领导、你的组员和你的客户，和这些人沟通，让他们知道你打算怎么做，什么时候要他们做什么准备，这些事情将是你的主要工作。
和客户领导沟通时特别要注意，除非你需要对方给你支持，那么你才需要讲得具体一点，否则，告诉他一切正常就可以了，而且态度要积极一些，千万不要说一些领导不懂的细节，比如：“王局长，最近项目进度还算正常，就是经常发生一些内存泄漏的情况…” 王局长：“(*&$@@”
和自己的领导汇报也要注意这个问题，除非他是一个技术高手，你需要他的技术经验，否则一般就汇报进度是否正常以及有问题时你的对策和打算就可以了，有些需要他支持的地方，比如资源调用需要说详细一点。
和组员开会，除了一些项目进度跟踪会议以外，还有很多讨论会，需要大家用头脑风暴方法给出解决问题。与会人员很多都是技术人员，他们的特点是注重细节、缺乏大局观、有点消极悲观、自尊心强(如果总结得不对，欢迎大家拍砖)，所以，你作为会议的主持人，只要负责提出问题和记录下他们的观点，千万不要做评判者的角色。一个问题，有很多方面，从不同的角度看，可能是完全不同的，这些技术人员，他们往往精通一个方面，就自己的角度发表见解，除非一些很特别的情况，你都应该认为，他们提出的方案，从他们的角度来看是最合理的，所以，在会议上，你要充分尊重每一个人的意见，夸奖那些意见提得比较好的人，千万不要把会议带入无休止的争论。会后，你自己写文档，根据任务的优先级和轻重缓急来做决定。
6. 做好需求变更管理
最后再谈谈最让人头痛的需求变更问题，在我多年的项目开发和管理的职业生涯中，还没有见过需求不变更的项目，不管是多小的项目。可以说，在项目的开发实施过程中，需求变更是导致项目膨胀、延期和失控的最主要风险。
对于需求经常变的客户，你就一定要事先做好规矩：
一、统一联系人，客户指定一个人和项目组进行沟通，不能张领导、王领导都来说几句，如果他们意见不一致，那你只有得罪领导的选择了。所以，项目的最初就要定好规矩，我项目组只认一个的意见，有什么要求你们内部先统一再和我谈，我不想卷入你们内部业务部门之间的矛盾之中。
二、所有需求变更全部要有书面文字，这点切记！这样做好处多多：
-
有书面证据，以后他还想改，你有了他以前要求的证据，告诉他：你以前可是这么说的。
-
便于需求变更管理，需求如何慢慢演变的历史可以看清楚，从而更深切地体会客户的目。
-
对于客户来说，嘴巴一动最方便，反正是你们做，不花他的资源，所以要求是否合理，是否和项目的目的一致，他是不负责任的。但是如果要他写书面要求，还要签字盖章，他就要谨慎多了，而且一写东西，思想就会更加深入，很多无理要求也就这样胎死腹中了。
变更通常分为两种：
一种是部分更改了原先的目标，即需求变更；
另一种是没改变目标，但是客户不满意目前的实现方式，大到流程的实现，小到界面的布局，都是属于这类，碰到这种情况是难以避免的，主要是事先沟通的不够充分和客户随着项目的进展，慢慢想清楚了问题，改变了以前的思路。这时候，如果需要改并且你的战略是容许这种情况的，那么要注意下面两点：
-
确保以前的文档，就是记载着以前的结论的东西，客户是否签过字，如果没有，赶紧把你的工作停下来，赶快再和客户自己确认一下你的方案，然后让他签字，避免以后说话没有凭据；
-
和客户坐下来，探讨他修改的根本目的是什么，是不是有同样能达到相同目的、但是对你来说有代价更小的选择？
当接到客户正式提交给你的需求变更申请时，你需要做评估分析，分析对成本、进度的影响，在你的领导同意后，出相应意见书，主要是要说明更改设计的原因和指出由此带来的不确定后果(这个东西先写出来，后面如果真的发生了，至少不是你的错)。然后再让客户在上面签字。见过医院给病人做手术以前让家人签的免责条款吗？对，就学习那个，让大家都意识到任何的更改都有成本和代价。
项目开发阶段至此告一段落，下一篇准备聊聊项目验收阶段……
