在谷歌如何开启新的项目，Senior工程师的一些个人总结

楼主毕业以后就在谷歌工作，已经6-7年了。现在是一个全栈开发小组的TL。来分享一下开启新项目的心得和自己的思考。

我个人成就感主要来源还是项目本身的成功和同事的良好关系，所以主要也是从这方面入手进行的思考。所以涉及维护人际关系的部分会比较少(?)，如果以后有机会也可以单独分享。


1. 为什么要谈开启新项目

从个人发展而言，从头到尾参与新的项目的经历很重要。很多时候可以帮助理解公司的流程，组织结构的关系以及背后的原因。作为工程师，总会有自己的想法或者想做的事情，不论事情的大小，学会如何推进项目也能在工作中找到更多的快乐。
当我刚毕业加入公司的时候，所有的工作都是从老板或者mentor安排的。就算如此，其实如何完成这些工作也有不少的自由度，很多时候同时也能发现大大小小的机会改进现有的系统。但是大部分情况下也只限于个人的时间安排，如果改动过大或者影响到了别的组，我可能就会主动放弃。
但是随着时间的推移，工作的责任越来越大，想做的改变也会越来越多。如何有效率地启动这些项目，扩大影响力就决定了自己能发挥多大的价值。

2. 新项目的点子哪里来

我总结了一下日常容易获得点子的几个渠道

• Top-down 来自大组的新计划，新项目 - 这个非常容易理解也非常常见，大的项目和计划总是需要分成小的部分来实现，参与其中自然也是开始新的项目。
• 来自平时和领导，PM的交流 - 在日常交流中可能知道了目前需要解决的问题，而你（经过思考后）正好有合适的解决方案可以提供。
• 来自平时工作中遇到的现实问题 - 在实现新的功能或者调研其他项目的时候你可能会找到当前系统中需要改进的地方，或者是用户/工程师的痛点。
• 来自日常交流学习 - techtalk中了解到的新技术和发展方向，和别的组leader吃饭的时候了解到的新项目，可能都可以应用于自己的系统中
  

总的来说保持日常的交流和获取新信息的渠道畅通，了解业界的发展，公司和大组的最新进展，别的相关项目组的情况。保持良好的同事关系在我看来十分重要，有时候别的组的TL会主动告诉我他们最近的项目并且提醒我可以应用在我们的场景中。保持和老板以及其他领导的关系也可以帮助你获得新的灵感，因为老板们平时接触的信息最多，如果他们能联系到你现在的项目或者组里的情况也可以帮助你获得不同的信息。

3. 什么是好的点子

我认为一个好的点子可以从几个方面来考虑。

自己能否胜任
一个理想的项目点子是自己能够执行的。你自己可能会受到各种制约以至于无法先实现这个点子，比如：当前的工作负担太重，自己无法获得相关的技能或者人脉，别的组更适合推进这个项目，等等。
自己不能胜任的话可以将点子推荐给合适的人选，你自己也可以选择成为其中一部分来获得经验以及credit。
当然也有项目比较小你可以delegate给别人的情况。

能否获得支持和资源
领导是否信任你，让你来推进项目。软件工程师的时间某种程度上是属于你的老板的，如果不能获得老板的支持那最好不要轻举妄动。
你能否从团队中获得需要的资源，比如别的依赖的组的支持，可能需要的PM和甚至UI designer。如果你获得了老板的支持他能不能帮你解决这些问题，如果不能的话你需要考虑是否有其他渠道。

能否组建团队
小的项目可能你自己就能够推进，但是大的项目一般都需要组建团队。你应该预估出需要的团队资源，如果可能的话最好是有自己的意见。比如你可以告诉老板我觉得我们组的XXX很不错，他有这方面的经验，并且最近的项目快要完结（或者我可以帮他快速完结）。
大部分情况下你都不可能获得最理想的资源，你需要考虑在现有限制的情况下是否还能顺利推进。

是否与其他团队构成竞争/合作关系
如果新的项目点子和别的组有关，尽量做到合作共赢。维持良好的团队关系能帮助你的成长也能让自己的工作更加愉快。你也不希望别的TL在peer review或者calibration的时候给你下套对不。
有些情况下冲突和分歧可能无法避免，这显然是一个考虑点子的扣分项，但是假设你还是需要推进的话一定要作为优先项目妥善处理其中的关系。

4. 如何开始（获得批准和必要支持）

假设你确定了一个点子有价值，并且希望继续推进，你需要获取必要的支持。我建议第一步是确定关键人物（stakeholders）。他们的最重要的作用是有权力批准你的计划，并且提供必要的支持。

确定关键人物

• 团队老板 / TL
• 相关组的TL（包括可能的冲突组）
• PM / Designer
• 技术专家
  

提前识别可能的问题，准备解决方案

常见问题：为什么？

• 收集必要的数据
• 总结历史问题
• 了解相似问题的解决方案
• 公司/大组能获得的收益
• 预估成本(cost)
• 人力成本
• 其他成本
  

常见问题：怎么做？

• 技术问题
  

• 提前准备可能的解决方案（构造性证明）
• design
• prototype
• 相似项目的成功案例（非构造性证明）
  

• 非技术问题
  

• 其他组的关系
• 了解项目依赖的需求，大致确定解决方案
  

提前获得反馈

• 平时积累良好的同事关系能帮助你从多个渠道提前获得反馈，获得建议和可能的问题，提前做好准备。
• 尽量收集多方面的意见，公开讨论自己的想法。
• 不要害怕批评，对待批评和意见最好能做到主动接受。如果不是特别必要不用直接否定。保持反馈的畅通可以减少背刺。
  

处理分歧

• 在讨论中遇到意见的分歧是很常见的（另一方面也证明了你工作的价值）。
  

• 在处理分歧的时候最重要的一点是寻找大家共同的目标 - 如果有可能可以避免一开始直接切入不同点，以公司/大组的利益为基准，从共同的目标出发确定解决方案。
  

• 讨论应该基于事实而不是情绪宣泄
  

• 提前列出事实，收集数据和证据
• 站在不同的立场上思考，了解双方的诉求和痛点
  

• 沟通的重点是获得信息，细化问题 - 将大的分歧缩小，可以分类讨论或者分情况分析，获取冲突的真正原因。
  

• 如果无法进行及时停止
  

• 如果确实找不到合适的突破口，最好及时停止，认真思考以后再做打算。
• 获取领导或者其他权力的支持
  

5. 总结

• 保持良好的老板同事团队关系，不要一人对抗整个团队或者组织
• 提前做好准备和预案，寻找合适的渠道化解冲突
• 沟通是最重要的武器，很多一开始看上去无法理喻的问题都是可以通过沟通化解的。
  

匿名者 发表于 2021-3-8 06:00
感谢楼主分享

那篇帖子我也关注了。最近自己也在尝试面试所以也有一些感触。

关于behavior轮，自己从头开启和领导项目必然是可以获得很多帮助的。你能遇到很多在“技术实现”上没有考虑过的问题，你还能从“项目发起者”以及“公司/大组管理者”的角度来思考问题。这些都切切实实可以反映在behavior轮的面试中。

关于system design，我个人的看法是system design的面试和平时在工作中的design有比较大的区别。在谷歌工作中的design由于公司infrastructure无比成熟所以很难考虑到一个startup公司需要考虑到的方方面面的问题。另一方面来说也不能说在谷歌的经验完全没用，但是你需要额外的功课将自己的经历和公司外的技术栈给联系起来，了解不同系统设计的相似性和不同。如果完全不做准备的话确实会发现帖子中提到的问题。

我个人比较重视的个人培养方向是让自己能够独立承担更大的项目和工作，当然在谷歌的环境外工作也是很重要的考量因素，所以平时可以多积累相关的知识，包括和公司外的朋友交流，阅读相关的书籍和技术文章都可以同时帮助个人成长以及在谷歌内部的工作。

tianchez 发表于 2021-3-8 09:35
我也是做产品方向的engineer，请问楼主找新项目的时候， 你其中提到的第几个方向分别占比多少？如何平衡fea ...

我觉得每个组的机会和想法都不一样，占比差距应该挺大的。

我体验下来，比较小的项目，能一个人（我自己，或者delegate给一个我同组的同事）在半个Q做下来的中大约能有三分之一是工作中发现的改进，三分之一是老板安排的，还有三分之一是和别人交流以后提供的建议。

比较大的项目，几个人做超过一个Q的应该有三分之二是从大组的新计划中的一部分，另外三分之一是自己想要做的，通过沟通以后得以实现的。

当然没有计算由于种种原因没有做，放进backlog里或者都没有放进去的东西。另外其实分类也不完全准确，很多时候其实并不是单一渠道，比如小的项目也可以搭上大项目的便车得以获得资源。


关于平衡feature development和core infrastructure其实是一个很复杂的问题。说实话我们组的feature development的压力是比较大的，很多时候作为工程师如果想要推进core engineering的项目需要找到一些折衷的办法，比如feature正好需要某个功能，那么在做的时候就可以适当扩大化这个功能以满足infrastructure的需求。这个在操作中最重要的是获得老板或者其他stakeholder的支持（大部分时候并不难）。

如果有比较大的需求最好是能提前计划。从管理者的角度考虑问题，一般来说feature development是属于“紧急”的事情，core infrastructure是属于“重要”的事情。在工作安排上通常会往“紧急”的事情资源倾斜，所以“重要”的事情怎么获得关注呢？正常的策略是单独划出时间和资源处理“重要”的事情，我的策略是如果不能当场获得支持，那就一定要能放进planning的计划中以获得正确的处理。

shenghuo 发表于 2021-3-9 11:30
非常感谢楼主的耐心回答，其实我就是想问这个“lead credit”具体是怎么得到的呢？implementation的credi ...

一般来说一个健康的奖惩体系里credit是不会越分越少的。所以假设你把自己当作TL的话这会是非常正常的情况，你提出了想法并且大约知道如何做了以后再让组员来实施。你不但获得了提出想法的credit也获得了正确delegate的评价。如果可能的话你甚至应该把调研和验证之类的过程让给组员来完成，这样组员能获得更加完整的体验，成长更快。
另外据我观察，大部分情况下作为TL如果你想快速promotion那么一般来说这种可以delegate的小项目你做再多帮助也不会太大。你还是需要知道什么时候需要自己动手lead或者execute整个过程，比如重要的或者复杂的项目（或者是可以写进你的promotion packet的）。

感谢楼主分享


在谷歌开启新的项目能避免“谷歌senior跳槽惨败的迷思”里楼主提到的种种问题么？
能的话，有什么特别要注意的点呢？
不能的话，在谷歌开启新的项目有什么实质性好处呢？

谢谢楼主的分享

我也是做产品方向的engineer，请问楼主找新项目的时候， 你其中提到的第几个方向分别占比多少？如何平衡feature development和core engineering project的平衡？

地里的匿名用户 发表于 2021-3-8 09:56
我觉得每个组的机会和想法都不一样，占比差距应该挺大的。

我体验下来，比较小的 ...

多谢楼主！有种醍醐灌顶的感觉！

tianchez 发表于 2021-3-8 10:00
多谢楼主！有种醍醐灌顶的感觉！

不用谢！我在工作过程中也有很多类似的关于如何平衡A和B的疑问，我发现最有效的手段是寻求有经验的或者经历过类似事件的人的帮助，每个公司每个组都有一些不同的地方，能了解老同事的经历很多时候就能根据情况抄作业。

感恩的心。

优秀！紫薯紫薯