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