转眼，在黑车公司工作将满四年。这期间，在各位大佬对我的关照与指导下，过得充实有趣。自己也在敝司如过山车般起伏的环境中，摸着石头过河，有了些粗糙的想法。在硅谷，尤其是这几年快速发展的创业型公司，四年是个大家提到便会默默微笑的时间点。虽不知前路如何，但把过往的体会与思考总结一下，想来也是有裨益。所以写这篇文章，更多是为自己理思路，会带有许多主观与局限，欢迎大家多指点批评。
我作为应届毕业生进入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年会面试，其中一个环节是用两三句话，把自己专业领域的概念，让一个零背景的人听懂，我觉得就是很好的习题。
需求与实现间的权衡
产品和程序员日常博弈的一个主要议题，就是“这个需求能不能做？！”。世界上没有做不出来的需求——只要给足人，和时间。在有限的资源里，从工程师的角度，我觉得想清楚以下几点十分关键：
回答这些问题，需要对系统实现与扩展的扎实理解，以及与非技术部门持续的沟通，在绝大多数情况下，是工程师才有机会和能力做到的。每个项目出现的问题都多少有不同，在推进过程中对其反复推敲，也是我觉得这个工作特别有趣的一点。
理解快速迭代的成本