|
「本文2800字，预计阅读时间5分钟。」 一 前几周，和软件部署的一个同事沟通现场问题了解到，由于设计原因，软件在现场涉及到用计划任务进行第三方数据上传时，有时候会断掉。各个环节都知道这个问题点，但因手头上有其他事情，所以最后经过讨论，开发人员给出先打一个补丁这样的解决方案——加入一个定时重启任务脚本。 还有一件事情，在和软件开发人员一起梳理软件功能的时候，发现之前延续下来的软件有很多“无用”的功能点，谁也说不清这个模块的价值，也不知道当时是基于什么信息而开发。“反正之前就是这么设计的，所以这一版也就延续下来了，具体为什么这么做不是很清楚。” 最让我感到尴尬的是嵌入式，这个环节最麻烦，但问题也最多。因为既涉及硬件本身的处理，又涉及硬件和软件的互联互通，还有数据处理算法。每每想好了方向，但执行下来一次次被现实打脸。其实嵌入式开发的小伙是一个特别认真的小孩，但在产品思维养成方面，还有很大的提升空间。 二 那到底什么是产品思维呢？我之前看刘飞的《产品思维》、俞军老师的《产品方法论》，里面都提到，产品思维是一个系统，最重要的是对用户的认知，对需求的理解和分析，反观具体产品的设计当然也重要，但其实没前面两个内容关键。 当然，上面两本书是给产品经理看的，其要求和侧重点与对工程师的要求不同。但我发现自工作以来，身边厉害的工程师或多或少都具有很强的产品思维，有的甚至比专门的产品经理更懂用户和需求，他们总是力求弄懂产品从诞生到最终退市过程中每一个过程。这样的工程师最后都成了产品专家或者公司核心负责人。 三 那具有产品思维的工程师有什么特点和普通工程师不一样呢？我试着列出几点，在此分享给大家。 1、谋定而后动 具有产品思维的工程师不会只满足于执行，他们在拿到产品文档后会先思考，然后针对产品的使用场景积极地和产品经理沟通，如果产品文档描述不清楚或者有歧义，他们会提出挑战，如果他们有更好的设计思路，他们会提出来。 这个在日常工作中其实特别常见，比如一句话可以这样理解，也可以是另外一种理解。有些工程师可能就稀里糊涂地按照字面的意思就去做了，不好的习惯是有时候已经想到了问题点，但懒得去求证。最后出问题的时候，要么说文档没写清楚，要么说自己理解错了。 当然这个锅首先应该是产品负责人来担，但很多工程师没有这个意识，这就把自己做成了工具。 2、主动沟通 关于沟通，大部分工程师其实不太擅长。但如果去观察，做得好的工程师都是能够进行主动沟通的那一类人。 他们会用逻辑代替技巧，会用详细的推理过程代替模模糊糊的论断。在自己不太确定的环节，可以先不给出明确的结论，一旦想得足够清楚了，会再次拿出真诚的态度去取得各个环节的信任。 我见过很多工程师，最后和其他部门形成了比较对立的情绪。总是觉得其他部门的同事不理解自己，说的问题对方也不理解，最后慢慢变得不沟通，一切事情都要求发邮件或者提供书面文件，这就走入了另外一个极端。 3、关注产品在现场的应用 具有产品思维的工程师会花时间去了解下公司对产品的定位，比如公司是怎么推广这款产品的？一年销售了多少？客户群大部分是怎样的？ 最重要的，他们会主动地去跟进产品在现场的使用情况。比如自己负责的产品功能或模块，客户是如何反馈的？每一个提出的问题背后代表了客户什么样的心理诉求？能不能做得更好一些？ 有一些工程师，他们会主动地去找问题点，主动地和现场负责人沟通。大部分人还是比较被动的类型，有问题了我就改进，没人反馈也就算了。其实产品的改进很难说有终点，追求更好的产品体验对个人来说也不是毫无价值，代码的质量是一方面，产品的综合度量更加考验认知。 4、足够的好奇心 在我以前做产品的日子中，我碰到过一些工程师，对一切充满好奇。比如，为什么做这个而不做另外一款产品？产品的功能为什么是这样而不是那样？这个地方竞争对手为什么做成这样而我们能不能独辟蹊径？ 前一阵子碰到一个LED屏幕刷新的问题，在我把问题提出来后，大家讨论了可能存在的各个问题点，经过和厂家沟通最后都认为是硬件故障。这时候我有点不甘心，潜意识告诉我找硬件问题可能是属于“懒政”，加上更换硬件耗费的成本比较高，于是我把这个问题交给了上位机负责人，提出了我的一些验证想法。 其实没抱太多希望，我同步联系了售后准备更换硬件。过了两天，负责人告诉我应该是找到问题原因了。他在反复对比之前的运行模式和新模式之后，发现代码运行之处有一个细微不同，他把这个地方改了之后，之前频繁出现的问题目前还没有再复现。 5、解决难题的淡定与面对问题的不淡定 无论是做产品还是做技术，总会遇到各种奇奇怪怪的难题。比如软件在现场崩了，性能跑不起来了，服务器挂了。在面对这些难题时，有产品思维的工程师总是很淡定，因为他们自己在设计之初就评估了可能，他们会淡定地看一下跟踪进程，检查一下日志，然后继续去做下一步的优化工作。 但如果是产品在现场出现了低级的错误，比如没有按照预想的去执行，某个功能或性能比预期差很多，不是客户想要的。他们在面对这类问题时总是非常不淡定，他们会像排查Bug一样去找到计划与实际之间的根本原因，会反复和产品经理沟通确认需求以及新的实现方式。 四 在写下上面这些文字的时候，其实我也是在反思自己。无论是作为产品负责人或者团队负责人，培养自身以及团队中每个工程师的产品思维，都是一件值得投入的事情。 很多时候人都是比较懒的。比如能通过一个临时方案解决的事情，我们就不愿再花时间去做深层的重构了。就像第一个案例一样，临时的办法也能用，或许就一直延续下去了。但这些其实都是“技术债”，看起来对当前无害，一旦交给公司其他人问题很可能会再来一遍。 再比如，很多工程师和我反馈，因为沟通不在一个频道上，所以和其他部门沟通起来比较费劲。这样的问题迫使我思考，工程师内心真正的诉求是什么，他们其实不怕问题，也不怕犯错误，他们最沮丧的是需求定不下来，刚做完的还没定型又必须改，反复几次他们就找不到自身的价值了。 而具有产品思维的工程师，他们不会将希望完全寄托在其他人身上。他们会实际去关注产品在现场的使用情况，对于与预期不符的点会反过来和产品经理主动沟通、确认，并积极地提出自己的建议，快速搭建一个原型，小范围地验证下效果，寻求进一步反馈然后再大面积地应用。 五 对于具有产品思维的工程师来说，在接手一个项目或者某个功能模块时，一般需要问自己几个问题。
做为一名工程师，技术是本，但如果再加上产品思维，就比其他人多了一项征服世界的武器，离优秀也会越来越近，你觉得呢？ |
|
|
