确认确认再确认

记得去年软件园安排北大一教授给我们做项目管理的培训，讲了满满一天的课，很多东西都没记住，有一点却深深的印在了我的脑子里：确认，确认，再确认！ 讲课的老师是在北大做教授的，同时也是IBM的9级员工（据说IBM给员工都要定级，9级是很厉害的一级，10级在大陆都是比较少的）。他在一开始便提到了这一点的重要性，在讲课的始终贯穿了确认确认再确认的思想。别的没记住，有一个例子却很深刻的记住了。 讲课的最后，他要求大家记他PPT上的名片，给了足够的时间，大家几乎都把他的名片内容写下来了，他提的问题是：我的电话号码是多少？听到这个问题，大家的第一反应是13XXXXXXXXX，但是马上都反应过来了，于是一部分声音回答：你问的是座机号码还是手机号码？ 当然这也是他听到的较为满意的答案，确认确认再确认，他一再强调的观点，总算在最后被我们记住了。 时隔不到半年，我就犯了这个错误。在A公司的系统开发中，我总是将一些细节想当然地按照自己的习惯来进行，结果当然是引起了一些误差，还好这些误差没有更多地偏离。最让我头痛的是：客户总是连自己的业务流程都不了解，很多问题都是不能给我确定的答复，而我对这些不确定性答复，也没有让客户确认。结果可想而知，我们辛辛苦苦做出来，客户却为难地说：能不能改成这样？当然，大多数时候客户提出的都是可有可无的功能，一般不会答应。可麻烦的是，还有不少，甚至一些核心业务，却不得不大篇幅改动。 还有一点，客户有时会对自己提过的要求也记不住。结果是当你拿给客户看的时候他却说：我没有说过这样做哦。这样，一个记录文档或许就很有必要了，而且每次让客户去签字，甚至让他们的负责人也签字。 确认，确认，再确认。千万不要为了省事简化流程。正如那位教授所说的，你一再让他确认，哪怕是一点小小的改动，也要让他们的工作人员、项目经理、甚至更高级的经理，一个一个来签字审核。这样，或许他们会因为一些繁琐的流程主动放弃更改。