出走国企，转战程序员，终成最好的自己

本期邀请的嘉宾徐平胜先生，先后任职于国企、台资、民营和外企，几次历经开发语言的转变，从业余程序员到专业开发工程师再到部门经理。访谈还没开始，大梨就已经充满了好奇和钦佩！

梨：平胜你好，首先欢迎你来到《产品人说》和大家分享你的经历和故事。跟大家打个招呼吧！

平胜：大梨你好！大家好！很高兴有这样一个机会可以和大家交流，我从事工业软件产品开发和管理工作已经十一年了。目前在一家软件公司担任部门经理，主要负责一条有二十年历史的产品线的开发管理工作，最近还承担了公司开发流程管理的部分工作。

梨：看到您的简介，从业余程序员到部门负责人，虽然只有短短几个字，但能看出其中的不容易，能详细和大家说说吗？

平胜：其实我最开始是做电力器材制造的，焊电路板、汇编什么都做过，我还在高原变电站里焊过钢架呢（笑）。做了一段时间觉得不行，我想，我才20岁难道就要早早过上一眼看得到头的日子吗？当时就义无反顾地跑了。

▲ 徐平胜

梨：用现在流行的说法算“裸辞”了（笑）。

平胜：哈哈确实，以当时的企业背景，离职其实是很困难的，所以也是破釜沉舟地离开家乡。因为专业和工作背景，找到第一份正式的软件开发工作相当不易，后来进入了更专业的软件公司，才慢慢好起来，这样回忆起来，还是蛮感慨的。

梨：哪一次转折对你来说最重要，意义最大？

平胜：其实都很重要，如果说意义最大还是成为了专业程序员。现在三言两语很难再说清楚当时的情形，背井离乡又身无长物，那段时间有种走投无路的感觉，现在回头看那的确是一个正确的选择，依然为当时的决定感到骄傲。所以年轻的小朋友，一定要遵从自己内心的选择，同时也要主动！主动！主动！不要放弃任何一次机会！

做产品的人更是如此！不能被外界的授权和自己的能力储备限制住，需要寻找一切可能性去推进产品。当然有很多问题可能导致失败，但主动是解决所有问题的起点。

梨：前面说到您现在负责一条有20年历史的产品线，是什么样的产品呢？

平胜：我们的产品主要是帮助工厂设备符合行业规范 ( IEC/GB )的要求，生命周期很长，以维护和升级为主。产品的关键诉求就是合规，减少 Bug 降低维护成本。当然，现在我们也在做一些新市场的探索。

梨：重点在产品上市之后的管理，这个过程中有哪些难点？

平胜：我们的产品本质上是提供一个中间件或者开发包，是需要集中到客户的软件系统当中的，可以说是牵一发而动全身。

而维护的难点在于问题未知，有时候客户发现 Bug 我们做多次排查才能得出结论，是因为版本更新时，一个几年前的 Bug 又回来了，哭笑不得。所以客户的需求常常会精确，我就针对某版本，修复 ABC 三个 Bug ，其他任何变更都不要引入，这对于维护是非常困难的。

▲ 徐平胜

梨：所以维护其实有点像一个问题解决或者说风险控制的过程，你经过长期实践有没有一些经验可以和大家分享一下？

平胜：借助系统的力量，我们现在算是形成了一个比较完善的缺陷跟踪系统，这个系统是基于微软成套的开发系统之上，所有的变更都会被详细记录下来形成变更集，详细到谁、哪个客户、问题场景等等，方便后期随时查阅。这其中一个很重要的点是高度关联变更和缺陷，一方面这是查询度最高的信息，另一方面前面提到的“蝴蝶问题”修复之后也要关联到变更中。

梨：所以我们常常说风险不可控，是源于风险的未知性，当拥有的信息越充分，越便于查询，我们的风险控制和问题解决的能力就会越强。

平胜：当然比起解决，预防更加重要。这可能也是基于我们的行业特点，你看像微信这种互联网 2C 产品他们会有一个灰度发布，但工业软件不行，因为前面提到客户的变更成本是非常高的，所以我们碰到 Bug 第一件事不是修复，而是生成一条自动化测试，通过测试重现问题场景，再修复，这样就能保证尽可能减少同类问题的发生。

梨：这个特别像我们的流程优化，当流程中发现问题，除了解决还要想办法如何从更高一层出发把问题规避掉。

平胜：对，因为我们没有办法预料用户使用软件的场景，这是有不确定性的，但是如果我们长期依照这个模式：发现问题-测试覆盖-解决问题，至少同类问题会大幅的减少，其实同类问题是最影响用户体验的，所以解决的效率和客户的满意度都会提升。

梨：您还有提到一个主要的职责是做流程改进，这方面能不能给我们举一个例子？

平胜：学过 NPDP 的小伙伴应该知道产品经理和项目经理的差别，我们经常遇到一个情况，项目经理按照白纸黑字写下的需求把产品做出来，但东西不是客户想要的，从而衍生出很多产品和项目的矛盾。产品经理抱怨项目和开发没有客户导向的思维，项目经理抱怨产品需求提的不精确，浪费开发时间。

梨：这个网上也有很多调侃的段子，可见这个问题蛮普遍的。

平胜：对，但这其中有一个关键的要素被忽略了，那就是信息流。首先文字描述难以准确地传递需求信息，再经过传递和分配，到达开发人员的手里可能会进一步偏差，我们在做一个改进，在采集需求时每个功能点附带一条信息：哪一个相关方通过这个功能可以获得什么价值，并把这个改进纳入流程系统。这样就可以避免很多无效的开发浪费，也解决了一些两个 PM 之间由于信息不对称产生的一些矛盾分歧。

当然，由于立场和认知的矛盾还是存在的。因为我自己是技术出身，又带过项目所以特别理解，项目经理的认知很多时候基于过往的经验和流程，他们有自己的交付压力，有些甚至还要承担不少开发工作。这个时候你让他细细揣摩用户需求是很难的，更别提一线开发人员了。

另外，可能越优秀的项目经理，转变到产品思维的挑战就越大。因为他们通常很擅长实现确定的东西，以及把具体的功能落地，所以这也有一个适应和转变的过程。

▲ 徐平胜

梨：互相之间的理解和认可真的非常重要。

平胜：对，你会发现，没有开发经验的产品经理和项目经理的矛盾会多一些。因为他们的确比较难理解一些功能实现的难度和挑战，当然他们也有自己的优势。但是如果你只说“我更懂产品，你照着做就行了”，这不是合作而是使用工具。

之前有一位嘉宾也有提到一个方法我觉得很棒，就是把产品开发的相关方都当做自己的内在客户，为开发团队介绍基本的行业背景和用户画像，讲讲哪些客户可以获得什么价值，让大家充分地认同所开发的功能和产品，这样第一在实现上能够更好得把握细节。对于产品也会有更高的积极性和热情，这时候不合作反而是低概率事件吧（笑）。其实这一点有很多互联网产品做的很好，他们内部会公开探讨自家的产品，这一点其实是值得学习的。

学完产品之后再做管理工作，会有一个更深的感受，我自己最大的三点收获，和大家分享一下：比起细致精确的功能描述，更重视客户通过这个功能可以获得的价值；比起详细华丽的流程定义，更重视同事通过这个流程可以获得的价值。我觉得价值导向，就是产品思维的本质。

▲ 徐平胜（右）

梨：感谢平胜的分享！其实一开始看到你的履历我特别兴奋，这么跌宕起伏，一定会很博人眼球，现在想想反而很惭愧。我觉得这次访谈给我最大的感受是温暖。

每个人的经历都是独一无二的，他人的故事再精彩，最终留下来的也只是与自己共鸣的部分。或许是艰难时刻，笑一笑咬牙忍过去的决心；或许是一百次受挫之后，一百零一次主动上前的勇气；或许是成长过程中每一次的变化带来的领悟和蜕变。

尤其是下半程我们聊到产品和项目的关系，我想到很多词汇和课程，《非职权影响力》、《团队的冲突与协作》等等。大梨常常在想，我们到底在讲什么？所谓影响力、所谓冲突的本质到底是什么呢？希望这篇访谈能够给你们一些启发。我们下期再见哦！

相关阅读

“不是你做不到，是你的投入和产出不符。”

产品经理应该如何正确处理老板不靠谱的需求？

点个赞

再走吧