周二参加了中心的部门经理会，在会上了解和Review了项目R下周一上线投产的准备情况，除了项目组的开发、修复Bug的计划和人员安排外，我们主要在风险、服务层面对项目组R和部门经理T提出一些需要考虑的问题。
项目R除了我们开发服务方，还有业务监理方、业主方以及最终用户，根据合同的安排，项目的培训、部署和实施服务由监理方负责，我方定位在开发服务，所以各个方面的工作需要安排协调妥当。
具体的风险、服务层面的需要进一步细化安排的如下：
技术功能层面，数据权限漏洞以及数据授权的传递要求，是在本周最后的业主方测试才发现出来的问题，在此阶段发现问题是风险很高的要素。要求部门经理和项目组R马上和业主用户达成共识，安全问题具有一票否决权，数据权限的问题是系统部署上线的终止条件。一个系统不怕有功能上的Bug，但是怕的是业主和最终用户对系统丧失信心，看到自己不应该看到的数据，只会让最终用户担心自己管辖的数据是不是也让其他人窥视。另一方面，如何加大项目组的内部测试，保证在上线前对权限的检查到位，避免再次发生类似状况。
数据质量层面，系统涉及旧系统的数据迁移，系统迁移的工作由监理方来完成，但是数据质量的检验和校验工作方面，监理方会负责对数据迁移数据的总数校验，但是没有对数据单项和属性要素的准确性验证，我们应该提出这个方面的风险并且达成共识，虽然迁移数据已经做过了几次演习，但是数据校验和检验工作不能停留在抽查的层面。如果需要，可以参考我们公司的另一个项目的具体做法，涉及金额和数量的生产系统，就应该这样谨慎。
服务流程层面，因此项目组R和监理方达成共识，我们的项目组只从内部维护系统接受监理方的服务单。对应这一方面，我们觉得有两点需要考虑和达成共识，第一，根据以往经验，业主的最终用户会通过电话/QQ/内部维护系统提出服务要求，只落实了一个渠道，还欠缺其他两个渠道；第二，我们服务完毕后，是否由我们直接进行业主最终用户的反馈。
服务记录层面，询问服务记录的情况，项目组R和部门经理的回答是，通过内部维护系统的服务单，已经在IT系统内部体现，通过电话/QQ发起的服务记录，则由监理方负责记录。我们在这个方面，要求项目组R必须进行服务记录，好比将钱存在银行，银行有一本账，你也会有一本账，不是信任不信任监理方的问题，是必须这样做。
我们做好服务记录的必要性，能够在上线后有效地分析负责服务工作同事的工作量负荷，也能在上线后分析出我们产品、系统的稳定程度，同时如果需要我们进行反馈最终用户，这个记录也是重要的基础，而且更能够在以后配合管理中心的客户满意度调查的要求提供最终用户列表，甚至也能够在以后进行监理方和我方服务质量的差异性分析。
服务人员组织安排层面，上线最坏的情况不是上不了线，开发与修复Bug项目组R不欠缺这方面的能力，最坏的情况是上线后发现系统不稳定，有故障，类似“死机”。哪些同事负责Bug定位和修复，哪些同事负责协调，哪些同事负责对IT系统进行健康监控，上线的关键前几天，时间安排如何，在业主现场还是在公司进行服务等等这些组织安排工作要求部门经理和项目组R必须落实。
心态上，虽然系统的培训、部署和服务由监理方负责，但是我们要和监理方互相补位，系统虽由监理方进行安装和部署，但是假如出现故障或者系统问题，一定还是我们双方要去解决的，去努力做到双赢的局面，避免双方双输。
小插曲，为了检验项目组R是否做好服务准备，通过询问，了解到由项目组成员C负责跟进监理方的安排部署，我在会后抽查了项目组成员C，问的问题如下：“假如现在系统出现故障，我需要找到系统的访问日志和错误日志，请你从服务器上给我在5分钟内找出这些日志！”。答案是，C无法做到，告诉我监理方安装程序安装在那里还不知道！我们将情况反馈部门经理，要求他进行整改。
看来，系统实施层面不是解决说的问题，还要下好功夫解决做的问题，说到了无法做到，一切都归零。QA只能做好一个抽检的工作，队伍在服务意识上、心态上，离职业的道路还有不少要走的，而且管理中心还需要在实施中加大管理、抽检的力度，将防范能力进一步扩大。
最近从不少接触的同事了解到，业主的其他服务提供商，其实在服务意识上以及服务质量上都有比我们高的地方，我后面会让同事写下来他们的故事，向我们的合作伙伴学习，向我们的业主客户学习，向我们的竞争对手学习，只有打心里从心态上摆正位置，这样的团队才有可能成为业主、伙伴和对手都尊敬、佩服的团队。