一、前言

　　越来越深刻的认识到，人是多面的，也许是因为在不同的年龄阶段，也许是因为遇到的周围的人不一样， 亦或许是因为要做的事情不一样，所在的城市风格不一样，所处的气候天气不一样，表现出来的行为会很大 差别，甚至来说，性格和心里情绪也会有很大的差别。

二、背景

　　在腾讯三个月了，试用期刚过，这期间，有多次敲响键盘，准备发表记录一些想法。文章的标题，随着每次的 心情，也是不断的改。最后决定以试用期这个时间点，作为契机，整理一下这段时间的所思所想。

三、关于焦虑

　　一直以来，我都知道，我是一个比较容易焦虑的人。尤为明显的时刻，我记得有：

• 还在大三的时候，就担心自己找不到工作，结果硬件类、软件类、行政类、通信类，都拿到了offer，反而，回忆起大学似乎并没有 特别值得我记得的娱乐时光。
• 在TW的试用期的时候，整天担心自己过不了试用期，以后没公司要，最后艰辛过了试用期，收获了组内所有人的认可，也包括 那个最不看好我的伪buddy，反而，没有真真切切的把握好在成都的那段时光。
• 在德国的时候，由于项目没有感受到自己的价值，担心自己在虚度光阴以后丧失竞争力，结果怒刷技术书，最后跳槽去了字节跳动，反而， 德国的那段最值得好好感受环境、生活的日子，我却用来了郁闷。
• 在字节的一年半，因为太忙而没有思考的时间，只记得纠结犹豫于自己的角色转换太过频繁，丢失了技术能力，最后选择了转岗来了腾讯。

　　看到有一篇文章说，大多数情况下，这种压力和焦虑，源于对「不确定的未来」的恐惧。其中有一些措施，似乎看起来比较可行：

• 培养起创作的习惯，这种创作，可以是写作，拍视频，也可以是动手做点什么东西出来 —— 总而言之，要动脑跟动手相结合， 每天拨出一点时间去创造。
• 记录生活中的美好，当你抱着「今天又有哪些开心的事情呢」的心态，那么你看待自己生活的眼光，也会完全不一样。
• 保持随时出击的能力，保持跟一线的联系，让自己时时刻刻都拥有「重新开始」的能力。只有这样，才能确保遭遇冲击时， 能够在动荡之中，寻找到新的机会点。

　　所以，及时记录自己走过的路，等你回头看时，你会发现你是有一些achievable的。

四、关于感悟

1. 节奏感

　　在TW的时候，on boarding很久，记得第一次真正意义的完成一个Story，是在大概上项目2个月之后吧。 后来回想起来，一个那么简单的工作，居然要过那么久，才能独立完成工作。
　　而后在ByteDance的时候，第一天去了就开始写代码了，似乎一下子就适应了快节奏的工作。
　　现在在腾讯，有导师，有onboarding时候业务讲解，一切那么熟悉，却又有一点说不出来的味道。 　　第一周，工作小结报告： 　　截止目前，对话数最多的一周：

2. 一些诱惑

　　曾经我以为我是一个比较稳定的、希望比较安稳的人。到现在，突然发现，在面对未知的事情的时候，却总想抱着， 如果不去试一试，以后会不会后悔的心态。
　　所以，离开TW的时候，我说的是，世界那么大，我想出去看看；在离开ByteDance的时候，我说的是，不设限应该利用 自己的优势，那就转岗吧，试试也无妨。而现在，面对了前同事的创业邀约，我犹豫了，有犹豫就说明我有想试一试的冲动。 面对着目前工作稳定，团队氛围也不错，刚刚适应这边的环境，这个决定似乎真的很难。

3. 一些矛盾

　　产品的功能、质量、发布时间和需要投入的资源这四者不能都是封闭条件，否则可能无解。需要投入的资源和发布时间 一般是大老板定的，所以产品、开发和测试只能在”砍功能”、”降低质量要求”和”程序员加班加到死”这三个选择上相爱相杀了。
　　一环接着一环的催进度，是常态。产品扔出需求之后，催设计进行UI和UX，催开发进行开发，然后催测试给出测试报告，最后 催那些突然收到bug的开发，紧急改bug。
　　集成测试的时间是真的长，一度让我理解了当初为什么有人不愿意双周迭代。一周开发一周测试，临时时间点，赶紧修bug。 每一个迭代像是一个作战计划，最后几天全名战斗的样子。其实，归根到底，是质量太差，如果每次测试都没什么问题，测试的 时间不会拉长，后面解决bug的时间不会很长，迭代的计划更好的排期。

4. 渐渐好起来的反馈

　　刚刚进行业平台的时候，感觉自己谁都不认识，角色壁垒很重，说话完全没分量，像是一个空降兵，推动大家做着大家不愿意 做的事情，而且还被背锅了好几次，背的莫名奇妙，也真的是无法反驳。
　　其实，当你真的全身心、用心、花了精力的投入一件事，是真的会有回报的，只是这份回报可能要过很久。当跟大家频繁沟通之后， 突然发现不同角色的人开始主动找我吐槽事情了，希望我做一个裁判。
　　当Leader说，我要用数字甩到他们脸上，直接说问题的时候，我内心不是很认可的，我不想站在对立面，这一点在一定程度上 帮我跟他们建立了信任感，他们不再隐瞒问题，而是主动暴露问题，希望我能给出一些建议。
　　当我分饰两角，一方面从EP提高效能，另外也作为一个测试人员，努力推进测试时，发现在面对测试这个领域的知识时候， 我说的话也能让他们非常信服。

5. 关于转型

　　还记得5年前，在成都的WILD活动上，我对自己未来的规划是技术Leader。说来也可笑，明明一开始就想好了自己规划，但是 岗位职责的变化却有些令人惊讶。开发、咨询、DevOps、Scrum Master、PMO、SRE、专项技术测试。
　　曾今一直念叨放不下，如今突然感觉，每次工作的变化和调整其实都是一次蜕变和成长，放下过去都不是一件容易的事情， 也许一切都是最好的安排。

五、关于小Tips

　　很庆幸现在的我，是真的比较抗压，能够去深刻的理解别人的立场和说出来的言语过激之处；也很庆幸，现在的Leader不管怎么 跟我说话，我都能相信他是真的为我好，在给我提意见。很庆幸，这个团队带给我的能量不是我预先想到的负反馈。
　　所以现在，EP方向的日常工作里，在涉及了很多的沟通里，还是总结了一些小经验的。

1. Plan A & Plan B

　　如果你想推PlanA，那么你最好先提出PlanB给大家去challenge或者对比。

2. Tweak一点点

　　一次性一大步，比较困难，但是你可以一点点的Tweak。

3. 面对老虎型的领导，给他足够的空间去表达，去下最后的决定，必要的时候要示弱

　　最近看到一个数据，鹅厂的”猫头鹰”占比有35%，支配型的老虎、外向型的孔雀、耐心型的考拉，占比一样，均为21%，恰到好处的 多元与平衡，而善于调整角色适应环境的变色龙则是鹅厂的稀缺品，仅占2%。 　　又有数据展示各个部门的，占比情况：

• CSIG，多老虎，TOB业务需要那份结果导向，不易妥协的果敢；
• CDG，多变色龙，金融、广告等前沿创新环境中游走折中；
• IEG，多老虎，背着目标拼命前行，让腾讯游戏冲向世界；
• PCG，多孔雀，内容创造因热情有趣、能带节奏的他们传播更广；
• TEG，多考拉，与人为善、行事稳重，最靠谱的内部合作伙伴；
• WXG，多猫头鹰，且特别多，相信微信不会出现排版没对齐；
• S1，多孔雀，行政、法务等团队都热情的服务着鹅厂小伙伴；
• S2，多考拉，穿梭于费用、表格之间，财务要有过人的耐心；
• S3，多孔雀，仿佛一下看到口若悬河、人际敏感的HR。

　　老虎比较适合项目管理、业务规划等有挑战、有权利的工作，果然，推动的过程中，遇到了一些老虎型的产品，善于控制局面，逻辑清晰。 这时候，尝试去跟他们讲道理？讲不过的，其实道理他们懂，你做的只是告诉方案的优缺点，需要一个他们来下决策。

4. 组织活动时候，先observate，然后看他们自己battle，最后再给出回应

　　组织一个人数比较多的活动的时候，难免会有一些比较有想法的同学，会有自己不同的意见。其实，并不是所有的时候，你都需要 最快的速度出面去回答对方的问题。这个时候，先作为一个观察者，让其他也有想法的同学去说出不一样的意见。让这个小团体先自由 生长自由选择，看他们互相battle，等到差不多的时候，收一收，做个总结，下个决定，给出回应，也是组织者的一种智慧。

5. right VS right

　　很多时候，你会发现出现矛盾的双方，说的都是对的，但是还是会发生不可避免的冲突。其实，需要认识到的是，并不是只有正确的 答案，这就是所谓的 Right VS Right Resolution Principle 提供了一种找到”最正确”的做法：

• 基于目标，选择对于大多数产生最大利益的选项
• 基于规则，选择制定的通用标准
• 基于关心，选择对你影响最大的选项

6. 组织团建的时候，先买票，敲定下来，大家才不会改来改去

　　有一种思维方式，先定大框架，再订细节。团建也是如此，先定下来回的时间和目的地，然后中间具体的行程另行敲定。不然， 很有可能被带节奏，各种打乱安排重新来过，毕竟取消机票和酒店是有成本的。

7. 以终为始

　　在TW的时候，你知道，这个事情是对的，大家也都在践行着。但是如今，这个事情依然是对的，大家没做，你知道需要push大家去做。 但是，你却不能直接撸起袖子就干，因为，你需要告诉大家当前现场是什么，做了之后的现场是什么。而描述这个现场，你不能只用 主观感受去描述，你需要用度量的方式去体现，去敲打。
　　如果这个度量的方式，不能体现的时候，这个时候不是忙着去救火，而是应该及时的去更改这个度量，否则，就有可能白忙活一场，最后 什么都说不出来。以终为始，并不是说只盯着指标，而是想清楚你的目标到底是什么。

8、用数据说话

　　第一次被Leader拉会议室，教育一小时，是因为三个月过去了，度量的数据依然不准确。我仿佛已经陷入了救火状态，忙着拾遗补缺。 其实数据不准确，也是可以拿出来说的。
　　比如LeadTime的开发时间那么短，是因为开发没有挪状态，要想改变这一现象，不是我一个人跟着改状态，而是跟开发Leader沟通， 如果不生效，向上一层，再上一层，直到找到有权利协助的Leader。再或者，如果这个只是一个人力就可以解决的事情，那么招一个外包 帮我跟进状态，也不是不可以。再或者，强势的态度，如果时间一直很短，是不是可以认为开发时间很多，可以放进更多的需求？最后， 示弱的态度，跟开发同学们卖惨，说自己因为数据不准确挨骂的委屈，一般都会帮助克服的。 　　方法有很多种，唯一要注意的是，把其他人的意见当做建议，而不是防备式心里，自己内心也会很愉快去接受去改正。

References

• Right VS Right
• Resolution Principle 提供了一种找到”最正确”的做法：