以客户为中心

  自从“华为”这个低调的公司变成了网红界的翘楚后，越来越多的公司吵着闹着要学HW。而华为最最最著名的这句“以客户为中心”，成为了大家眼中华为成功的关键点，也变成了众多学习华为的企业的口号。但到底怎样才算以客户为中心呢，研发人员离客户比较远，往往由于不能直面客户，会导致产品输出与客户需求产生偏差。研发领域往往并不能深切的感受到“以客户为中心”的感觉。但是研发的每一点行为可能都会最终影响客户的满意度。本文就要讲讲研发人员如何做到“以客户为中心”。
  
  一切从需求开始

  我觉得以客户为中心的第一个要素，是充分理解客户需求。需求是产品的源头，如果需求都没有搞清楚，何谈满足客户。理解客户需求，并不是单纯的听客户讲需求，而是要在跟客户沟通的过程中，充分理解客户需求，并帮助客户深度挖掘需求，，在客户能力不那么足够的方面，做适当的牵引。这里强调“适当”两个字。客户需要被引导，但这个引导不是天马行空，也不是天花乱坠，而是切实的去感知客户的需求是什么，去帮助客户表述他无法表述清楚的部分，是用我们的技术先进性，去帮客户看多一步，看到他们还没有看到的商业价值。这也要求我们在面对一大堆杂乱无序的需求时，要对需求做整理，做识别，做澄清，做排序，把需求理顺之后，再动手开始项目。
  大多数时候初步的需求是由销售带回来的，但是又有相当多的销售其实是不懂技术的，所以在澄清、讨论需求的时候，研发应该跟客户直接对话，而不是缩在家里，让销售当传话筒，又埋怨销售不懂技术。
  产品的需求包，不只包含客户能感知到的功能实现部分，还包括了很多基础方面的需求，也需要在需求分析阶段进行识别。比如可制造性，可维护性，产品成本需求等等。
  可制造性看起来和客户的关系不大，但实际上并非如此。工艺是否能实现，生产制造的难易程度，直接决定了制造的周期和成本，而制造成本的增加最终也会体现在产品的价格上，同样的产品功能，客户是希望花钱更少还是更多？所以可制造性还是和客户相关。
  过度追求可靠性，提高成本，成本最终转嫁给客户

  成本是设计出来的，大家都听过这句话，但是在真正做开发的时候，工程师们有没有带着这个思维去考虑？有没有总是忍不住把自己的设计做得无比可靠，万无一失？或则给自己的设计加上一重又一重的保障？有个HW的案例：在某次大地震过后，其他厂商的设备都塌了，唯独HW的设备还屹立不倒，广大工程师们正在沾沾自喜的时候，任正非拍桌子了：该坏的时候不坏，这是浪费！！质量成本的浪费！！所以在产品设计的时候，怎么样去把握好这个度，怎样去平衡成本与质量的关系，是值得工程们好好研究的一门功课。除了产品的料本成本外，研发成本也是构成产品成本的一部分，最终都会折算到产品成本里面去。
  开发过程，端到端的交付意识，而不是只关注局部交付

  可能有人会说，开发过程完全是公司内部的事，和客户有什么关系？实际上，真的是这样吗？其他不说，项目的周期是不是跟客户满意度强相关？项目周期跟我们的开发过程能分开吗？很多公司都在抱怨项目周期不可控，项目延期，但是为什么会延期？我还没有非常明确的答案，但我能肯定的是，项目的延期并不只跟团队的研发能力有关。
  先看一个场景。
  

周一，某开发团队开例会。
项目管理问硬件工程师：你的BOM搭好了吗？
硬件工程师：搭好了。
项目管理问线束工程师：接口线束的图纸都搞定了吗？
线束工程师：有一个线束的规格还没有确定好，所以图纸还没有确定，料号还没有申请。
项目管理：硬件工程师，你的硬件BOM里不是应该有线束的料号吗？线束没给你，你怎么搭的BOM？
硬件工程师：技术主管要求我周五12点以前必须把BOM搭好，所以我就先搭了一个。今天等小李把线束的料号给我，我再走个EC吧。

  听到这里，我简直哭笑不得。主管叫你什么时候完成，你就什么时候完成，但是你完成的这个东西有用吗？提交了就算完成了，而不管实际能不能用？不但不能用，还要多走一次EC，浪费了一个流程，还给以后项目的EC分析增加了不必要的工作量，这算工作完成了吗？这样浪费的时间还不如去做点真正有用的事情。工程师经常都抱怨工作太多，所以进度延迟，实际上真的都做的是有用功吗？
  说了半天，这件事该怎么处理？硬件工程师发现线束料号没有给，就应该直接找线束工程师找项目管理进行协调，尽快完成线束的工作，然后再把BOM搭建起来。至于技术主管的要求，对主管进行说明，是什么内容耽误导致了不能在规定的时间里完成，我想技术主管不会为难你的吧？
  可能有些人要拿拿职责边界说事了，把职责边界当成推诿的接口。确实，每个岗位都应该有一个比较清晰的职责所在，这样大家才知道自己应该做什么事。但是在实际的工作中，总有那么一部分工作内容其实不容易分清楚界限，总有那么一些工作是需要配合完成的，这个时候怎么办？是主动牵头主动配合还是当大爷等着别人来推你来拉你？团队需要的是力出一孔，利出一孔，这样的团队才是高效的团队。今天你等我，明天我等你，拖拖拉拉，项目进度能保证吗？
  在这里发散一下，我们讨论下项目例会的作用。
  在我看来，项目例会是项目成员对项目进度，进展，风险，已经资源满足度的一个交流会，但在很多项目中，例会却变成了“作业催交会”，项目管理拿到list挨个催“作业”。过“作业”完成情况没有问题，但我觉得这只是例会的一部分内容，而且在过“作业”的过程中，“作业”owner应该重点给大家讲“作业”的完成过程，是否有需求其他成员注意的地方，是否有需要协调资源的地方，是否有一些风险需要跟踪……有做项目管理的朋友跟我抱怨，觉得工作没有价值，天天光催“作业”都忙不完了，哪还能发挥什么价值呢？
  有人说“作业”是保证项目进度的主要因素啊，项目管理不管进度，还要项目管理做什么？项目管理是管进度，没错，但是他对进度的管理重点应该在项目整体节奏的把控与周边资源的协调。只有在工程师们的觉悟不那么高，或则真的忙得作业需要提醒的时候，项目管理才不得不催作业，而不是把催“作业”当作项目管理的常态。
  设计文档也是对客户负责

  再说说研发过程文档，很多工程师都不愿意写文档，认为产品出来了就ok嘛，且不说文档对技术的传承，对后端工程师的重要性，单从客户来讲，越来越多的客户在重视设计过程的管理，会让供应商提交部分设计文档，包括一些过程的评审记录。我们还能不重视文档吗？发给客户的文档五花八门，前后不一，这些都直接影响到客户的满意度，还能说我们的开发过程与客户无关吗？
  千说万说，我觉得汇成一句：以客户为中心不能只是一句口号，而是应该好好的想想，怎么做才是真的以客户为中心。
  作者：毛宇菲 来源：硬件十万个为什么