敏捷开发一千零一问系列之十六：如何让开发人员学习产品？

这是敏捷开发一千零一问系列的第十六篇。（在这里提问，之一，之二，之三，问题总目录）

这个和上一篇“敏捷开发与CMMI谁为主”都是最近一次培训被大家选出来的最有价值问题。

问题

开发人员一般都只关注开发，如何让他们去关注产品呢？

方案

方案1简单但不彻底，方案3彻底但不简单。

方案1：产品经理在计划会讲解产品背景

计划会是一个产品经理宣贯产品的好地方，但是我们山东籍的程序员就会问：“你啰啰这些没用的黄子做么”，西川籍的程序员也会说：“瓜娃子，直接说要做啥子就得了么”

一来二去，计划会很可能变成需求会，需求会又会变成功能会，功能会再变成设计会。

当然会有人说：“产品经理定义好需求，让大家按照做，不也没问题吗？”

这个就要说说世界上最伟大的产品经理之一：乔布斯。乔布斯见到产品原型的时候最常说的话是：“垃圾”。这透露出两个信息：乔布斯要求很严；乔布斯也无法提前说出想要的产品，避免垃圾。

那到底谁能呢？所有人，整个团队。

如果产品经理能够发动大家思考用户的真实环境，以及要帮助用户解决的真实问题，产品做出来可能就完全不同了。

在很多互联网公司里边，这些事情做得相当好了，首先大家对于网站做成什么样子这类事情还是很愿意发表自己意见的，其次这类业务相对大众化一些，比较容易理解。

在外包项目、政府OA之类的环境中，这些事情不容易做好。多数情况下客户过于强势，导致一般人不愿意惹事，于是停下思考“倾听客户声音”。其实这种思路存在问题，因为“倾听”和“说”这两者都有变形，这导致明明他说的我们听的，最后做出来他不认账。

所以即使在后者的环境中，也应该“主动倾听”，去理解功能背后的业务是什么，怎样才能最终让客户满意。

方案2：设置产品经理岗位

“我们公司早就有了”，不是的，是设置那种真正责权利到位的产品经理岗位，高风险，高回报，权力大，责任大。

大约在2001年之前，最盛行的词汇是UML、面向对象、设计模式，最盛行的行业人才是高级程序员。

大约在2001～2010年，最盛行的词汇则是CMMI、PMP、敏捷开发，最盛行的行业人才是项目经理。

大约在苹果复出后，最盛行的词汇变成产品、创新、用户体验，最盛行的行业人才是产品经理。

所以，闷头干活还梦想加薪升职的开发人员们得注意了，自己很可能已经落伍两轮了。

方案3：形成基于产品的共利群体

一般认为，产品经理对产品的定义负责，卖得好卖不好都是他的事情，程序员只管开发。

如果是这样，产品就很难做好，也很难卖好。

在一些行业，情况正在转变。

一些游戏公司，在工资之外，还将20%的运营收入分给开发团队（包含策划和美术），用于激励大家做出更好玩的游戏；在一家外包公司，项目将获得合同额10%作为奖金，用于激励团队尽早、高质量地完成项目。

这些团队的个体，除了关注自己的开发工作之外，无疑要问一个问题：我做的产品或项目，是客户想要的那个吗？

分析

“无我”是令开发人员能走出局限的方法。

方案1提到了如何让开发人员走出小我，去看看外面的原因；方案2提到了过去的我与未来的我的关系，时间在变，我也要变；方案3，则提出了没有了我，应该有什么的问题。

那就是大我，应该把整个团队作为共利群体，分散责任，也分散利益，从而把团队动员起来。

 

下面一段对所有一千零一问系列都有用，先暂时写在这篇的结尾。

很多人会说：“你说得很好，但是有几个企业能做到啊”

我有一本圣经，刚读了一半。在第1页的下半页，上帝造了人类；在第5页的下半页，上帝后悔造人类，并降下了大洪水来消灭大部分人类，只有诺亚一家存活；剩下的1000多页，就是那些当年上帝选择存活下来的人，世世代代又被不断选择的内容。

所以，上帝（如果有）本来就没准备让所有人或企业活下来，所以也没创造一种方法让所有人很轻易就可以做到，而做到后又活得很好的方法。

所以要找一种轻易就可以做好的方法，只能等下次宇宙大爆炸之后了。

如果是企业的管理者，应该正视那些很难但很好的方法，努力让自己的企业其他企业之前践行，赢得主动；如果是打工者，应努力推进那些好方法的实施，力图把自己所在的企业退向好的方向，如果发现自己的企业中“好方法很难推行”，那么存在问题的就不是方法，而是企业了。