牵着客户还是被客户牵着

在软件开发的日常工作中,经常会遇到这样的场景:客户(专业咨询顾问)发来一个邮件说某项目有个新需求需要对原来的程序进行修改,然后客户会列举他想到的可能的业务逻辑,我们的工程师接到需求邮件后会先看看有没有什么需要补充的或者问题跟客户确认。

通常情况下,这样的需求邮件有70%是需要二次甚至多次确认的,原因如下:1. 业务需求模糊。我们见的还比较少,因为对方是专业咨询顾问,不是真正的客户。2. 需求说明没有覆盖所有的点。项目顾问毕竟不是工程师,思维逻辑没有非常缜密,不是因为项目顾问水平不行,而是因为他不是写代码的,很多业务冲突他在百忙之中不一定想得到。3. 需求改动成本估计。顾问发需求的同时往往会发deadline,说明什么时候必须交。有时候顾问“一句话的需求”在开发这边往往要“改动很多”,这个时候要么开发者和顾问辩论时间要么开发重新理一个estimation。

上周碰到的case是上面的第二点,这边的开发回信问“另外一种情况”怎么处理,用的是"what"开头的开放问题,然后客户回信说她要跟她的客户确认,不过在这之前请执行她想当然的“一句话需求”Plan A。

我在这个开发发出邮件后问他针对“另外一种情况”有无解决方案,他说有Plan B,符合业务需求逻辑并且改动代码不多,但是他没告诉客户他的解决方案。于是客户回复执行Plan A,改动非常大而且不太符合常规逻辑,但是又可以临时地满足需求。这个时候其实我们就被动了,因为是我们去问客户"what",然后客户回了Plan A客户就认为你会按照Plan A去做因为你“不知道”你才问,尽管你是有个备选方案Plan B,如果再提出来就有“怎么不先提出来”之嫌。

回到最原始的工作技巧:提出问题的同时提出解决方案
第一,客户没有开发者熟悉软件。这个软件之前是由一位开发者做的,那么客户肯定没有这个开发者熟悉这个软件,也不太清楚怎么用更合理的代码修改达到预期的业务需求改动效果。
第二,开发者提出解决方案是份内的事。咨询顾问从某种程度说是将客户的需求明晰化,转化为开发者能够看懂的需求甚至帮开发者定制了技术解决方案,尽管如此由于上一条,解决方案并不彻底。这个时候开发者理应通过客户需求和“部分解决方案”获得的感觉,提出“完整彻底的解决方案”然后跟客户确认。而不是又傻傻地回复"what", "how"之类的开放问题,这就相当于把开发者的工作转嫁到咨询顾问做去了。
第三,提出解决方案就占据了主动。正如这个case,其实Plan A和Plan B都可以解决问题,但是如果开发者在第一次确认的时候就已经提出了Plan B,那么客户的思维就不会再随意“发散”而是去思考Plan B,当然客户会同意Plan B。更重要的是,在这一封邮件回复中,开发者已经把客户的思维限定到对开发者有利的局面中了。率先提出解决方案的人从某种意义上讲在“控制”这个局。

那么话说回来,既然开发者已经有这么一个解决方案,他为什么又不告诉客户呢?其实一句话回答就够了,开发者不愿意或者惧怕承担责任
因为开发者已经有一个解决方案,说明他思考过而且结果还不错。不告诉客户是在想“我这个解决方案到底行不行”(不自信),“如果我的解决方案不行,客户或者上司会骂我,或者BS我,我很丢脸”(担心承担责任),“客户说不定有更好的解决方案呢”(转嫁工作,拒绝承担责任)。

牵着客户还是被客户牵着?“客户是上帝”告诉我们应该被“客户牵着”,但是客户之所以找到你帮他工作是因为“你在软件开发领域比他熟悉”。主动提出解决方案,帮客户想到他没有想到的问题,不知不觉你就会“牵着客户”了。

————————-后记————————-
跟同一个客户工作时间久了,双方应该产生足够的默契。软件开发中有很多问题,但是聪明的人不会每个小问题都问,因为问问题同样需要成本。客户希望看到的理想状况是他交给你一个任务,然后你下次接触到他的时候已经把任务做到他想要的一样了。意思很简单,火候到了,双方谁也不“牵着”谁,并行大步向前。