wxya（个人网站）产品工程师
转眼，在黑车公司工作将满四年。这期间，在各位大佬对我的关照与指导下，过得充实有趣。自己也在敝司如过山车般起伏的环境中，摸着石头过河，有了些粗糙的想法。在硅谷，尤其是这几年快速发展的创业型公司，四年是个大家提到便会默默微笑的时间点。虽不知前路如何，但把过往的体会与思考总结一下，想来也是有裨益。所以写这篇文章，更多是为自己理思路，会带有许多主观与局限，欢迎大家多指点批评。
我作为应届毕业生进入Uber，在China Growth工作了半年左右，简单接触Matching与Pricing方面的项目。中国业务与滴滴合并后，大组解散。我加入Subscription team，和组里同事一起从0到1搭建起整个产品线。从Boston的一个小实验，发展到如今在全美40+主要城市和印度铺开，涵盖rideshare, food delivery, bike&scooter多个领域的成熟产品，我亲身参与了组里大大小小的的迭代、扩张与转型，也从组里的小兵逐渐成长为tech lead。因此厚着脸皮，把我在这个岗位上的思考总结一二。
产品经理的要求不是圣旨
关于程序员与产品经理的爱恨情仇，业界人士已经有过很多生动描述。从我个人的体验来看，许多问题是由先入为主的偏见以及随之而来的怠惰造成的。尊重专业人士的专业意见绝没有错，但不能因此放弃了主观能动。工程师对于产品需求以及迭代方向有想法，就要通过各种渠道主动提。好的工程经理与产品经理，也会欢迎不同角度的意见，并合理地消化、反馈。换个角度，亲身参与产品需求与方向的讨论，也能帮工程师更好理清具体实现的思路，并且在系统设计中，给未来可能的迭代留出合理的余量。
对非技术领域的探索
作为工程师，技术实力自是立身之本。然而团队要做出好产品，仅有一流的技术是不够的。哪怕是像无人驾驶这种目前以技术驱动的行业，也需要工程团队之外的各个职能部门紧密配合：产品、设计、财务、用研、数据、市场、运营以及法务等等。工程师如果只关心技术细节，那上到讨论产品大方向，下到制定项目小需求，便容易陷入被动，被其他职能牵着鼻子走。时间一长，就真的成了code monkey。掌握这些领域的基本技能，再结合对技术细节的了解，就更容易提出其他部门考虑不到的，建设性的意见，并得到更高质量的反馈。
与非工程师沟通的能力
这算之前一点的展开。做技术的人讨论工作时，大多不需要交代背景或解释术语。可与非工程师交流时，时常会出现沟通不畅、反复讨论却达不成一致的情况。这一点我觉得更多涉及到同理心的问题。程序员的职业性质，一是专业术语多，二是思维方式偏直截了当。所以我们的沟通语境往往与其他职能的人不同。有时候我觉得和某PM/Ops/designer交流特费劲，心想他们连这么简单的问题都聊不清楚，十分傻X。但事后反思，自己的“想当然”也是问题的重要原因。意识到要多站在对方角度想问题，理解对方的诉求，问题就能解决大半，而后就是练习具体的沟通技巧。当年ASES年会面试，其中一个环节是用两三句话，把自己专业领域的概念，让一个零背景的人听懂，我觉得就是很好的习题。
需求与实现间的权衡
产品和程序员日常博弈的一个主要议题，就是“这个需求能不能做？！”。世界上没有做不出来的需求——只要给足人，和时间。在有限的资源里，从工程师的角度，我觉得想清楚以下几点十分关键：
- 100%实现需要多少时间与人力？
- 如果时间、人力不允许，什么样的需求可以拿掉？拿掉后如何影响核心的产品指标？如何衡量后续跟进的优先级？
- 工程方案是否考虑到未来可能的迭代？
- 保证系统灵活性和可扩展性的成本是什么？对未来的迭代有多大帮助？是否会影响项目发布的时间？项目延后的代价是否值得？
- 如果实现过于复杂，可否做impact相近，但开发成本极大降低的feature？
- 对于一些复杂的边界条件，是否有办法用非技术的方式解决（调整需求，客服指导，提示用户重试、更新等等）？
回答这些问题，需要对系统实现与扩展的扎实理解，以及与非技术部门持续的沟通，在绝大多数情况下，是工程师才有机会和能力做到的。每个项目出现的问题都多少有不同，在推进过程中对其反复推敲，也是我觉得这个工作特别有趣的一点。
理解快速迭代的成本
快速迭代，这一点不管是在各色创业指南，还是商业教材里都应该都被说烂了。MVP先行试水，再根据市场反应与用户反馈，小步快跑的策略，倚天屠龙一般，剑锋所指无往不利。然而快速迭代对于工程师来说，常是个头痛的词。追求速度，往往意味着代码质量下降，系统设计缺陷，文档更新迟滞。技术债长期积累，系统容易变得碎片化，低内聚高耦合，代码难读更难改，不易维护和扩展，反过来拖累整个产品的优化速度。作为工程师，权衡开发速度与质量，定期回溯并检视系统状态，寻找合适的时机做重构与性能调优，并让其他职能部门清楚意识到这些工作的意义，是应有的坚持。这样做，也许会有各种压力质疑，甚至拉锯扯皮一类糟事。但我认为把原则问题想清楚，做明白，哪怕结果并非水到渠成，过程也是有价值的收获。
主人翁意识
早期做项目，我一个明显的问题就是，专注开发，却忽略了从项目策划，需求分析，到产品发布，关键指标监控，再到数据分析总结，后续跟进优化等一系列重要步骤。就像前面说的，这其中的每个环节，工程师都该有能力参与，甚至与其他职能部门一起领导推动。后面自己开始注意这个问题，体验过end to end交付一个项目之后，收获到的是全新维度的经验。而产品组往往能给工程师更多这样的机会。还是那句话，不要用职位头衔给自己设限，你在其他领域的收获，总会正向反馈给你的本职工作，这波不亏。
做产品工程师 == 没有技术深度？
和许多像我一样刚入行的工程师交流时，这个问题是被反复提及的。在产品组做了几个项目后，开始觉得工作中的技术难度不够，写业务逻辑就像搭积木，比不上infra或platform组，有机会掌握一门专精技术，technical impact大，将来跳槽也容易。我没在infra组工作过，无权评论比较个中优劣，只根据我的理解说说想法。
从电子，晶体管，芯片，到体系结构，汇编语言，操作系统，到单机程序，计算机网络，分布式系统，再到顶层各式的业务逻辑，IT行业整个链条通过不断的抽象化，模块化，协议化，把复杂的下层实现细节简化成上层可理解、易组织的接口，层层递进，化繁为简，提升效率。从这个角度看，越往上走，系统的专精度越低，但解决问题的效率越高。另一方面，业界的专业划分度如今愈发细致，在存储、计算、网络、通信等几个大方向下，针对不同的使用场景以及需求，已经出现了大量成熟的工具和技术。因此从解决实际业务的角度，我觉得在产品组工作的技术挑战有：
- 快速掌握主流工具、模块的特性以及适用场景
- 根据业务需求，做合理的技术选型
- 在没有现成可用的工具或服务时，判断“改轮子”与“造轮子”的优劣
- 利用有限的资源，高效率的组织已有模块
- 对产品可能的演进方向有预判，并在系统设计时留适当余量
个人愚见，虽然产品组和infra/platform组的工作内容不甚相同，但方法论以及思维模式上还是有可以互通的地方。而对像我这样业界经验不丰富的工程师，培养扎实的代码水平，实践常用的设计模式，提升快速学习与推演的能力，熟悉开发、测试、部署、监控、异常处理等一系列的工程实践，都是重要的基础。而这些在产品组，我认为都有大量提升的机会。
搭积木说起来简单，但最终成果，也有小木屋与万里长城之别嘛。
结语
一个好的产品工程师，我觉得是个弹性很强的角色，进可撕需求，退可撸代码。厌倦了写码，也可以考虑当个产品经理玩玩（误）。以上这些，算是一半总结、一半目标，希望自己继续努力，希望各位大佬多多指教。
Loading...