在大厂做项目，如何沟通，排期和开发

但我也确实没想到这一停就是刚好一个月，这要是放游戏里，我这都成回归玩家了。

那么问题来了，这个 5 月我到底经历了哪些社会毒打？成为我在鹅厂的至暗时刻，最最忙碌，没有之一，以至于让我这么「嚣张」地囤了一个月素材。

接下来，大家自备酒水，我开始讲故事了。

一、5 月背景

• 我 4 月底换部门、5 月换了 2 位 leader
• 承接被毕业团队的业务，在完全不懂业务的情况，接手大量需求，并且需求是倒排的（就是 deadline 和需求定死，没得商量。人和时间不够，自己想办法解决。我愿称之为最恶心，没有之一）
• 需求上涉及范围特别大，涉及底层数据变更。如果做不好，用最坏的情况就是整个产品不可用，业务方直接掀桌子，我背锅 + 原地毕业。
• 个人职责变更：负责整个用户域业务，第一次带人，还是带 3 人，跨城市，同时承担开发任务。最忙碌时候，加上从别的小组借人，共有 8 个后端一起在做用户需求。（七淅以前做过六位数日活的 APP，后端都没 8 人）
• 开发团队的办公点不在一个城市，产品也跨城市，存在异地沟通成本

以上就是七淅在 5 月的情况，压力大到午休和晚上做梦都会梦到自己在工作，睡眠质量很差。

二、需求交付结果

背景交代完了，那从五一节后回来，截止到发文的今天，6 月 6 号，一共 23 个工作日，用户域的同学和七淅都做得怎么样了？

需求和 bugfix 一共上线 6 次，各占一半（假如每周一个版本，那 23 天只会发 4-5 次）

上线质量这块，反正不会是好的，就不多评价了。

小声 bb：我觉得在那个背景下，能按时交付，并且出现的问题可控。在我目前的能力上来看，我真的觉得很不容易了。

三、交付质量不好以及忙碌的罪魁祸首

9 成以上都是由 3 个原因叠加共同影响，用一句话来说就是：产研团队都是刚接触新业务，一上来就是超大需求，并且是倒排的。

最后，我们部门也和业务方达成共识，这轮结束后，后面拒绝需求倒排，否则不长久，dddd

四、浅浅聊下交付的过程

整个大需求在不同时间进行分批评审，因为时间关系，每次评审的用户需求不能在统一的时间上线。

所以七淅需要和其他小伙伴梳理需求的依赖关系，提供可分批上线的需求和时间节点

而期间不可避免的需求扯皮，人力协调等非开发事项就都是七淅去做（这里很锻炼软技能，以及多线程工作）

最后还是因为没时间，所以整个大需求期间，不存在技术方案评审，代码cr。谁承接的需求负责到底。

每天迅速过风险，不问细节和过程。只要进度正常且符合业务预期，不管用什么方式实现。如果中间有风险/阻塞，团队小伙伴会找七淅去帮忙处理。

就这样磕磕碰碰到今天，七淅在这 22 天内，通宵 2 次，1 点后下班 3 次，22 点到第二天 1 点前下班次数 10+ 次。

刚好今天是第 23 天，也是最后一轮需求的上线，对此我的希望是 —— 不要通宵就好。

到此为此，七淅的 5 月搬砖内容大概就说完了，下面的内容分享下我自己觉得有用的方法。

先给自己叠个防杠 buff —— 不同公司差异巨大，流程不一。我只是单纯分享遇到和见过的坑，存在一定的局限性。如果觉得对你没用，可以选择忽略。

五、小小经验&小小体会

【关于沟通】

1、如果是信息同步，结论前置。接下来再换行分段描述具体信息

2、如果是请教别人问题，（背景和）问题前置，接下来才是说你的问题描述/分析过程。之所以背景括起来表示可选，取决于别人是否和你一样了解背景。

3、在急需对方处理/确认的前提下，如果在公司通信工具发送消息后（比如企微、钉钉），对方依旧没有回复，直接电话联系，不要拖。

如果有更加紧急的事情，公司通信工具都不用，直接电话。因为没时间组织语言，去打一大堆字了。

4、如果自己的需求涉及其他部门，自己的进度被阻塞且没法进一步解决。及时将问题反馈给上级，让 ta 帮忙推动跟进。如果 ta 也搞不定，问题继续往上抛。

如果最后没法再往上抛了，和需求方讨论下问题是不是可以不用被解决，换别的方式，曲线救国行不行。

如果通通不行，一定要解决，并且自己的确搞不定 + 其他人，包含 leader 真的也都帮不了你。

那这边建议快逃。业务没法沟通 + leader 无能，继续呆下去迟早再被恶心。

【关于排期】

1、要学会为了保护自己。

在团队有项目管理或其他定排期的角色的前提下，如果业务方私聊找你 xx 功能什么时候可以做完，而这个 xx 功能是还没被安排的。

不管需求是简单还是复杂，开发不向业务承诺上线时间，可以让业务找项管安排迭代处理，具体时间看对应迭代排期。

比如说，即使需求实现很简单，我们开发以为 1、2 天后就能搞定上线了。如果就这么回复业务，假如测试没人力测，或者你刚好有其他高优需求插入，最后需求没能按我们承诺的时间上。

而业务方也已经和业务的老大说过这个时间，现在「延期」了，那业务方只会说某某说过可以在 xx 号上线的，现在说延期。

这时我们开发就很被动了。打工人不易，学会保护自己。做好没人夸，别人觉得理所当然；没做好反被说。

2、需求估时一定要往大估。

什么意思呢？就是你做需求 A，评估需要 16 小时，你就不要很老实的写 16 小时了。

因为你永远不知道，在你开发期间，会不会有线上问题要排查处理，时不时被拉去开会，偶尔来自同事突然的私聊。诸如此类意料外的事情占用了你的时间。

那这时如果你一开始就留有多出来的时间，事情处理起来是不是就不那么着急了。

我之前的 leader 和说我们说，估时的 70%-80% 足够你做完需求就好了。大家可以根据自己的实际情况调整，反正给自己留时间是一定的，不然迟早踩坑。

另外补充下，打消以下可能存在的顾虑：如果往大估时，leader 会不会觉得我的估时太久，怀疑自己摸鱼，或者产出低？

首先这个不用担心。因为这些都是合理的评估，大家可以结合自己的实际情况往大估。

比如你基本都在开发期间被拉去参加下个迭代的需求评审。那你就可以把这部分时间算上，就算 leader 真有质疑，我们也能够有理有据的回复。

3、对临时（的高优）需求的处理方式

不知大家有没有我这样的经历？

我不止一次在自己的需求已经排期好的情况下，东西做到一半，这时业务方突然找过来：七淅呀，你这边能不能帮忙做一个 xxx 功能，今天就要，做活动要用，发现之前漏提需求了。或者就是老板突然要，现有功能不支持

对于这种临时需求，我一般是先看是不是举手之劳。比如说不用改代码，就查个数据，几分钟的事。那我分分钟给你，请叫我雷锋（滑稽.jpg）

如果要改代码上线，不管简单还是复杂，我会需要产品让提需求，找我 leader 和项管安排迭代。

首先提需求不是找产品的茬，目的是为了存档和跟踪需求进度。万一其他人接手，别人也没见到相关需求，你说这是口口相传的，这似乎也不太合适吧。

那具体安排是马上做还是以后做，那就是大家讨论的结果了。

如果是现在做，而我目前又排满了，那么这个临时需求是不是可以给其他人做？如果一定要我来，那我手上的哪些需求是不是可以和这个需求置换？

这些就都是和大家讨论的内容，毕竟人一个，不会影分身。

如果大家有更合适的处理方式，希望可以评论区留言下，我学习偷师一波。

以上，都是建立在需求排期可沟通的前提下执行的。如果遇到需求倒排，那就只能加班了（需求倒排一生黑）

【关于开发】

1、如果组内有新人、比较年轻的开发同学。需要让稍微熟悉业务的，有经验的同学带一下，至少前期需要多跟进下 ta 们负责的需求。避免团队有的轮子重复造，也帮助其了解业务，评估需求的影响面。

2、技术是实现业务的工具。

3、完成比完美更重要。不管大中小厂，都有屎一般的，能符合业务需求的代码。只有业务做起来，才会对技术有更高的要求。

4、自己做需求时候，不要顺手改别人的代码逻辑，或者升级别人需要的底层依赖。这种夹带私货的情况，没出问题就啥事没有。一有问题，别人就会说你干嘛手贱。

如果真的要改，可以提技术需求来处理。这样大家知道有这件事，我们也好找之前的开发了解当时的业务逻辑和过测试。即使改出问题，也能及早发现