职场上的人情世故 - 初入公司的第一个项目

说下背景

来公司的第二周，上面下发了新需求，也是我参与公司的第一个项目。

我先说下公司一个项目的大体配置

产品经理 1~2人  一般中小版本就1人
UI      1~2人
研发前端 1~3人 
研发后端 1~5人（包含协同团队）  
   ps:其中后端中1人为项目负责人，负责整体项目进度和协调资源
测试    1~2人

好的，故事由此开始。先铺垫下，该项目是我从业以来最无力最绝望最想扯呼的一个。

需求评审

周一刚来公司，就被公司给我安排的导师L 叫到身边

导师L：「一会儿有个需求评审，我文档先发你，你先抓紧时间看看」

懵懂的我：「好的，我先熟悉下任务」

说实话文档看起来真的有点头疼，主要是上面的一行字我真的无语至极【与线上保持一致】。公司的项目还是比较大的，我上哪儿去了解保持一致是个啥意思......问下导师吧，他也在排查线上问题；问下其他同事吧，也刚来没多久不了解这块业务....

好吧时间应该够，我先打开系统，看看这功能到底在哪里。

「走，A2评审会」 导师L给了我一个眼神

大哥，我才看了不到20分钟，功能我都没看完......

我的情况稍微有点特殊，一般来说，大家跟随导师的节奏，问题都不大
看不懂的需求，一定要整懂了在动手，否则返工风险很大
时间不允许？那要再考虑下该公司是不是适合你了哦！！！总不能说能跑起来就行吧

过程我全程梦游，大家都在提问题：各种数据的兼容方案、功能冲突怎么兼容、有类似功能是否能套用、数据权限是否考虑、特殊逻辑的兜底方案.......

开始还能记一下笔记，后面发现 跟不上，根本跟不上 直接 弃笔，从容 面对现实了

从会议室走出来，嗯~~ 怎么形容心情呢。我高考语文作文那一页名字忘了写出考场都没这么忧虑过（当然作文最后还是有得分）。

分配任务

直接上对话详情，后端加上我一共3人

导师L：「任务我这边大概分配了下，你们先选吧」

我内心很慌，我一个都看不明白要怎么做

不知所措的我：「要不我拿剩下的」

同事P：「那把这个、这个、这个给我吧，剩下的你们分？」

导师L看着我：「那就这样分，你做那个、那个、那个，有问题随时找我」

不知所措的我：「好的，我主要是不熟悉这块业务，有问题我先整理出来再一起问下你呗」

这里有个关键点，整理完问题再一起咨询，切记遇到一个问一个
态度摆正，表现得自信点，第一次在同事面前"刷脸"，印象要留好一些

研发阶段

我的任务主要是客户群统计模块

导师给我开了两个服务的权限，让我先看看代码

懵逼的我：「L哥，要不大概说下在那部分写的统计数据？我应该从哪些表出结果？」

导师L：「你先看代码，里面都有逻辑，你看得懂」

无语的我：「好的」 内心（这么玩儿是吧）

知道那代码有多难懂吗？全都是A队列推到B队列，判断后再推C队列，并且还有了很多观察者模式。可能有兄弟姐妹问：「看不懂注释？」。注释少得可怜，也就一些字段含义，不过看单词也能看出来。

队列和队列之间很难看懂，并且很多跨服务的队列，给我开的两个服务根本不够，前后一共加上4个服务才把统计的逻辑串起来，我还专门画了个流程图出来

不管代码设计和质量如何，作为新人别公开喷前辈的代码
前期不要加入太多个性化的代码和设计，每个公司的要求不一致，最好的方式还是模仿
逻辑复杂的话，建议画一个流程图or时序图，架构图的话还是问下老同事，自己画可能不准确
不要轻易下手编码，确保自己很明确整体逻辑了再跟熟悉的同事复述一遍先

好吧，我终于找到逻辑线了（花了1天半时间，留给我开发的时间很近很近），但我发现，结果表很多很多，有AAA_statistics、BBB_statistics、CCC_statistics...... 我拿不定主意，刚好我也对这几个服务熟悉得差不多了，于是我拿着这些成果去问导师L

诚恳的我：「L哥，帮忙看看这几张表，我感觉有一些数据是重复的，还对不上数，帮忙看看呢？」

导师L：「逻辑都捋清楚了吗？」

我直接掏出了我的流程图

导师L：「这是JW（我们组的TL）给你的吗？」

求知的我：「我自己画的，不晓得准确性怎么样，帮忙check下呢」

导师L：「主要是我这还有点事，你再看看吧，晚点我们过一下」

前期难免会有很多问题，但自己也要有点准备，否则被问成麻瓜，印象分直接拉低
不知道的不要说"不知道"，可以说"我还不太熟悉，我先去看看逻辑，X哥要不跟我说下大概位置或则有啥文档？"

到了晚上7:00左右，我发现L哥不见了，后来才晓得那天他溜得挺早的。只剩我原地爆炸，明天要联调了，我关键的数据组装service还只有一行//TODO。没招了，我按照我的想法和数据指标，找了几张最合适的表，把数据产出了。

第二天

我早早地来公司，重新check了下代码并又调试了几次，除了数据对不上没啥其他问题。导师L带着早饭来到公司，我还等到吃完早饭再去问了下。

疲惫的我：「L哥，你看我用这张统计表去输出功能有问题没？」

导师L：「就那么几张表，你造几条数据不就看出来了」

疲惫的我：「我造了几条数据，但是昨天的数据我看今天才过来，昨天忘了记录过程」

导师L：「怎么可能，你怎么造的数据，算了等会儿我看一下」

......

过程就不细讲了，总之，不好受...... 最后问题也定位到了，是导师L当初做测试，把定时任务往后延了1天。好吧，这还有定时任务的事儿？我只能看代码看到一堆数据同步的接口，真的是应征了那句话：【最怕的是：我不知道我'不知道'】。

时间允许的话，着手开工前还是留一份概要设计的存档，别把坑都留给后面的人了
流程图、时序图、架构图等，前期多花时间，少走弯路
心态摆好，我们是来打工挣钱的，交不交朋友是其次而已，关系不恶化怎么着都行

而后，比较顺利地进行到提测阶段，bug真的是多得要命，主要是以下几点：

1、数据权限没加（就是prd文档上写的跟xxx模块保持一致逻辑）

2、数据同步时好时坏，排查后发现是定时任务不稳定，大家都在一个环境提测版本，都在修改功能

3、未做改造的功能点测出历史bug（功能类似，故测试同学也纳入了测试范围）

4、服务被其他版本覆盖

导致最终版本交付时，我个人产生了大概20+个bug。周五下午TL专门找我谈话，约谈此事，大概意思是版本复杂度不高，但bug数过多，对我的版本质量不满意。对此，我也阐述了我的解释，这里我就不细说解释的话，大概从以下几点去阐述

不要丢锅，先把由自己粗心产生的bug讲一下，记得提一下数据，因自身代码质量产生了X个bug，后续会加强编码质量，多自测
也不要背锅，说下由于环境问题导致了X个bug的产生，并给出自己的建议，是否能做环境隔离，一个环境只能容纳服务不冲突的1~2个版本
注意下，TL直接对话的机会并不是很多，可以结合自身入职以来的经历，提一些建议（不用管是否重要）
总之，事事多总结，否则像这种情况下TL突然找咱们约谈，说不出个123，印象分会很差

项目总结

在项目研发中，不一定能得到公司前辈们的"关照"，这时候就需要先自己憋一下（注意合理安排时间），怎么着也能憋出点内容，那这这些内容再去咨询，效果会好很多。像我这种被孤立的情况，我也不好说是不是常态，我个人还是认为好同事还是居多的。总之还是与同事搞好关系，或者关系一般遇事能帮忙也行，不要跟任何同事把关系闹僵（哪怕脾气差、技术菜、背后勾心斗角）。

还是那句话，遇事不要慌，先调整好心态（道理都看得懂，但希望大家都能做得到），尽力吃透项目再开始施工，否则返工或者低质量产出不好避免。

多做总结，不甩锅不背锅，不管是项目总结还是转正答辩还是晋升答辩，都能有个有条理有依据的总结出来。这点在职场中至关重要。