这是芃篙君的第【345】篇原创
本文适合在软件行业发展的朋友。大概2000字，阅读需要7分钟。
你好呀，我是芃（péng）篙，一个相信思考和努力能够拿到结果的家伙。
今天我们来聊第二部分，我们开发的软件产品，以及可能存在的配套的服务。
01
前面我们聊了客户，客户是站在交易的另一端的实体。
再离我们近一些的位置，就是从承载着交易的产品与服务。
能够产生交易的前提是，我们的产品或服务，解决了客户的某个需求，提供了某种超出客户预期的价值。
所以，更懂客户也好，更懂产品与服务也好，都是对我们日常开发的那些软件做更加延伸的了解。
更懂客户，对应的是更懂客户的组织模式、更懂客户的需求痛点。
在这个基础上，更懂产品的服务，大概就能更加理解，我们给出的软件与服务的解决方案，到底能不能解决客户实际的问题。
02
我们日常能够看到不少典型的“程序员”行为。确切的说，是初级工程师视角看起来没啥问题，但是中高级软件工程师视角下，就有点问题的行为。
比如，只对需求是什么感兴趣，对需求为什么是这样的，不感兴趣；
比如，只对自己负责这部分软件感兴趣，对完整的解决方案，不感兴趣；
比如，只对组织要求的职能边界内对应的需求和问题感兴趣，对其他人职责范围内的，不感兴趣。
类似的问题，芃篙在多篇内容中也都提及过。
从个人能力的角度讲，这样的观念，属于典型的执行者思维，会丧失决策权，也可能会无法做出更合理的技术方案；
从个人和组织效能的角度讲，这样的观念，属于典型的局部视野，比较容易让日常工作陷入到效能地狱之中；
从发展空间的角度讲，这样的观念，属于典型的自我封闭，会丢掉提升个人影响力的窗口，会丧失掉机会。
把上述各种角度都丢在一边，单纯看想更加理解产品与服务这个角度来讲，这样的观念明显会阻碍自己理解完整的产品与服务的基本信息、设计逻辑和实际效果。
所以，一切的开端，是打破自己思维里面那堵墙，从自发的希望了解更多信息、并参与其中开始。
03
所以，如何才能“更”懂产品与服务呢？这里也仅仅供你参考。
上面我们聊的是主观状态上愿意去“更”懂，上一个大章节我们是通过“更高效”来解决或者缓解客观上存在的时间上的问题。
在此基础上，芃篙认为，首先在于思维上要具备更全的视角，不给自己设限制。这里并不是说我们需要去完成产品、甚至商务的工作，而是需要把产品与服务的生产、销售、使用场景、售后运维等各方面的链路了解清楚。
有一本书叫《责任病毒》，讲的是团队管理和协同时，产生协同上的不合理的问题。我们去了解更多信息，并不是去感染责任病毒、主动拦下其他职能岗位头顶上的猴子，而是为了加强自己对产品和服务的认知后，更有效地通过技术手段来提高它们的竞争力。
其次，是想办法去理解产品和服务为什么会发生交易，换句话说，就是客户或者用户为啥会花费时间、精力或者金钱使用你开发的软件。这些内容，一般会出现在需求文档的背景和价值描述部分。但是，真实的情况，最后是从客户订单、用户评价等维护来反馈验证的。
单纯只是接需求、开发需求，属于管杀不管埋。验证需求，不是单纯的完成软件测试，而是要看这个软件是否在使用者手中体现出价值。这样才完成了从用户角度的 ROI 闭环，才能更深入理解产品和服务的核心竞争力到底在哪里。
再进一步，就是更新颖的、或者更成熟的技术，如何能够帮助到产品价值的真正升级。
最后，特别是对于软件产品来说，软件工作人员可以运用数据思维来辅助对业务的理解。在程序员阶段，我们可能更关注埋点、数据缓存与上传优化、大数据云端架构与清洗等技术原理方面的课题。
实际上，我们但凡再往前走一步，延伸到数据分析上，就可以更客观、更直观地透视产品和服务的真实情况。
你可能会说，我平时只负责埋点进去，也没有权限去看那些数据呀。
这个可能确实是大部分人的现状，但是未必没有解法。
比如，你可以跟产品人员有更多相互支持的互动，从而了解相关的数据；
比如，你可以走正常的数据申请通道、找你的老板申请去看这些数据；
比如，你可以在需求评审上，关注这些数据的应用情况，以及在发现没有按照数据思维设计需求时，提出合理的质疑，来侧面了解数据情况；
……
办法毕竟都是想出来的。
我们前面讲更懂客户，可能再懂也没办法比销售更懂，毕竟人家是全职的，并且可以成功让对方掏出真金白银，或者类似的东西。我们只是兼职，属于后方工程技术人员，
同样的道理，对于产品和服务，我们也很难说做到比产品经理更懂。但是这并不是问题，我们更懂产品和服务，并不是要成为产品经理，而是经过这样的提升，更明白自己的技术优势在哪里，应用在哪些地方更加合适，本质上我们的目标是：技术可以更好地支持业务。
关注芃篙君⬇️，每日获取思考与践行的认知更新...
可获取软考备考资料；
亦可加微信探讨开发者、职场与管理、IoT行业等话题；
共同成长，穿越周期！
