Research & Development Engineer
日记
回想我迄今为止的 职业生涯，最早我是意外得到的实习，也是在实习中顺其自然加入的工作，一直以来靠着惯性做着「前端工程师」这一岗位，而鲜有对「工作」本身的思考，颇有一种“当局者迷”的即视感。
经历过一轮大环境影响下的 裁员，跳槽来 MoeGo 至今，不觉我正式工作已将近三年。有了更多的自我意识，我也开始尝试在市场的视角去观察我所在的位置，进一步延伸出可能的下一步规划。关于我在市场中的价值立足点在哪里？作为一名研发工程师，我能够为他人提供什么？又是如何去面对和影响这个世界的？
就核心目标而言，研发工程师主要职责是开发与维护软件。我们常说工程师的工作不仅仅在写代码，但对于具体做什么，也没有一个明确清晰的定义。毕竟有人在写代码，也有人在做 PPT，纠结着如何有艺术地向上汇报，实在让人迷茫。来到 MoeGo 的小半年，在其相当务实的氛围感染下，我对这方面的理解似乎也开始走向清晰，慢慢地就有了这篇东西。
想来工程师更多的是，作为“研发团队”的一份子，服务于软件开发运维的整个生命周期。具体的行动上，大体可以从我们日常工作中，一个项目流程从想法产生，策划到上线运维的不同阶段涉及到的各种具体行动去切入：
- 策划阶段
- 根据需要，做技术调研、可行性的评估等，给老板、产品经理、设计师等角色提供可靠的信息输入和参考，支撑业务层面的决策
- 产出形态：调研结论、报告、文档、Demo、口头的信息沟通等
- 开发阶段
- 方案设计：代码架构、改动点评估，项目任务拆分，成本、人力、排期估算等
- 开发测试：任务执行，写代码、debug、解决 bug、测试、上线
- 产出形态：技术方案、代码改动、测试用例、文档沉淀、服务变更 等等等
- 上线后运维阶段
- 密切关注相关数据指标、反馈，及时发现风险并同步团队
- 清理项目执行中遗留的技术债务，梳理技术层面的优化点
- 根据团队需要，得到进一步的优化方向，形成新的任务 / 项目继续推进
从纷繁复杂之间回到根本，需要关注的恰好在于两点，Research 和 Development，Research 主要作用于策划和方案设计的阶段，Development 则主要作用于开发测试阶段。通常我们在思维的惯性下，容易只关注到已进入 Development 的写代码部分，而忽略了 Research 环节的价值。
但其实前者也同样非常重要，未考虑清楚的贸然行动，往往在项目后期各类风险会逐步暴露出来，附加的排查 bug、进一步修修补补耗费的人力，并不一定比前者 Research 环节花费得少。因此在前期思考、调研的时间精力花费，还是有必要的；面对这个结果导向的世界，项目是要上线工作的，不可能总停留在 Research 环节。两者具体如何分配和平衡，就不太好在比较抽象的层面得出结论，需要的是具体问题具体分析，还有个人在众多项目经历的锤炼下累积下来的对软件开发的直觉。
这一切恰好就是 Research & Development engineer (R&D) 这一职位的核心职责所在，我想，清晰认识到这一点，或许也意味着从“程序员”到“工程师”身份的一个跨越。毕竟局部最优不是全局最优，工作面临困难时，也需要及时从一个更全面的视角去把握，得到更合适的解决方案。不长时间陷入一些具体繁琐的问题细节、或因不在自己层面能解决的问题内耗太久而绊住手脚，乃至于让自己的节奏被打乱。
在满足这一职位的核心价值稳定输出前提下，理论上工作的体验也会有机会重构的，既满足工作的需要，也满足个人在家庭生活、技术成长等角度的需要，而非简单粗暴的内卷表演式加班文化。具体来看，在一个比较理想的工作状态，在时间上大概是相对明确的上下班的时间节奏；在空间上则是实现可选的远程办公，不受地理局限的“数字游民”模式。
那么这样的体验该如何实现呢？我想可以从两方面入手：一方面是在个人视角主动出发与团队目标对齐，让自己的行动匹配团队的工作目标，在时间投入方面达成共识，平衡出一个合适的节奏；另一方面是信任感的建立，需要的是个人信誉的日积月累，形成类似“品牌口碑”的认可，彼此都不用费太多心思作无谓的猜疑和检查，获得相对更踏实和自由的工作状态。基于这两点，再结合当下足够发达的在线会议、文档、表格和任务管理等等效率工具，可以让我们逐步从时间和地理的限制中解脱出来。
当然这里说得可能有些理想化，关键在于老板怎么想。但我相信，只要自己保持上述的稳定价值输出的状态，回报啥的都不会是大问题。毕竟在创业公司，大家讲求的是 show me your code 的效益，那些算计与内耗，会尽可能都扼杀于摇篮之中；再不济，有机会的话自己当自己老板，也不是不可以？