做基架的后端，需求如何合理安排

[0xABCD]

这边做基架没有 PM ，需求排期靠拍脑袋决定，有时候一个需求还没做完，另一个需求又来了，并且业务说很急，需求也很合理，所以不得不同意支持。而且业务很多咨询问题要回答，自己的开发时间也不太好预留。

这么搞下来搞得自己好累，请教下这种情况应该如何应对呢？是我的问题，还是提需求机制有问题。

[tyrantZhao]

排期跟你 ld 说啊，你 ld 应该会帮你挡掉一部分需求的。

[me1onsoda]

你们鸡架的结构啥样，正常是给 leader ，让 leader 做路由下发需求

[0xABCD]

@tyrantZhao 有的不是那种大需求，是那种需要一个小时左右的小需求，但是顶不住每个业务都来占我一个小时

[sunjiayao]

业务爷爷说啥就干啥（逃）

[0xABCD]

@me1onsoda 基架里面比较独立的子系统，一两个人负责的那种，业务都是直接找负责人的，有时候从帮业务排查问题开始的，查着查着就变成小需求了，一两个小时过去了

[8355]

如果你是负责人首先考虑招人，这是最简单的解决方式，本质上现在一个人同时做不了两个事，不是管理的问题，现在跟不上业务发展就会影响收益。
招不了就让业务 pk 或者找老板沟通评估实现成本和优先级问题

[emSaVya]

有需求来 先拉扯一段时间 开几个会 反复确认。开发周期就拉长了。

[crossoverJie]

@0xABCD #5 深有感触，现在把一些业务常见问题做成了功能，节省了不少时间；不过既然做了基架就得面临这些问题，往往排查一个小问题会扯出一堆需求

[liahu]

@me1onsoda leader 跟需求方一起的，这个需求来了，leader: 今天就要弄完，我当场谢特

[chevalier]

听 leader 安排，做不过来就问 leader 优先级怎么拍

你的绩效是 leader 打的，不是业务和 PM 打，你对 leader 负责好就行

否则会出现你干了很多活但都不是 leader 重点想做的方向，出力不讨好

[IvanLi127]

让他们提需求的打一架，谁赢了先做谁的，把矛盾转移出去🤓

[0xABCD]

@crossoverJie “常见问题做成功能”是什么意思？大佬展开说说

[pengjl]

@0xABCD 别说一小时，就算 3 分钟改完我都要跟 leader 确认是否先更改这个

[crossoverJie]

@0xABCD #12 我的场景是比如业务团队对 k8s 不太熟悉，导致对应用占用内存、CPU 这些理解有误，我就写一个 wiki ，再有类似问题先看 wiki ，这样会减少不少“甩锅”性质的排查问题。

再就是一些我排查问题的套路，因为需要进容器，而业务方可能会没有权限，就把相关的操作直接做到了管理台，即便是不进入容器也能排查了；类似的套路吧，主要就是把自己从一些重复的流程中解放出来。