接受需求
程序员的工作源头来自需求文档。业务方提出需求，然后由专门的需求人员/产品人员根据业务来进行编写需求文档，因此需求人员其实是业务和开发中间的桥梁。可想而知，一个好的需求人员最主要的标志就是业务精通，如果他还懂一些开发常识就更好了。
银行的需求人员大部分也是外包，水平参差不齐，水平一般的占大部分。曾经遇到过一个需求人员宣讲需求时，需求人员和业务就某个业务内容忘我地讨论了一个小时，最后决定要大改需求。
并且后续开发的时候，发现他很多业务场景都没有考虑到。很多时候都是我发现不对劲，提问后他才发觉遗漏了。
一个水平差劲的需求会给你的开发埋下定时炸弹，他的考虑不完全，可能会在上线后暴露出来，导致生产问题发生。也会严重影响你的开发进度。
字节的需求人员，或者叫做产品，就比较专业了，据说招聘的时候要求就很高。在设计产品的时候，考虑得十分详细，各种场景推演都列了出来，内部评审很多轮。--只针对大需求。
但是缺点就是需求文档定稿太慢了。。为了保证进度，开发需要确定好那些一定不会变的内容，提前开发，不然无法完成既定时间目标。
需求文档一般需求团队内部会先进行评审，评审通过后，会给开发和测试进行宣讲，开发提前查看需求文档，在需求宣讲期间或者宣讲后几日内提出疑问，需求人员进行解答并修改完善。
当需求文档最终定稿后，开发根据需求文档编写设计方案（概要设计），测试人员编写测试案例，然后分别进行内部评审。评审的时候都会互相邀请参与。
作为刚转行的我，很幸运，第一个开发任务是接受原来开发同事的开发任务，技术方案已经写好了，我要做的就是问清楚技术细节，例如我具体该改哪一块代码，以及该怎么改。当然了，并不是意味就不需要思考了，我还是需要看大量原来的逻辑，明白他的设计方案原理，甚至有时候会问出一些他也不确定的问题，自己找到答案。
需求的提出一般是按照一定周期进行迭代版本的，在银行的时候是一个月是一个迭代，字节一般是2个月大迭代，中间夹杂一些小需求迭代。
Bytheway
题外话说一下程序员之间的差距是什么，曾经做一个需求时，遇到一个问题，根据git提交记录，找到原来的开发请教，结果他也不懂，他只是依照老代码写的代码，并不了解本质原因。
我内心是很惊讶的，因为这个问题，我认为如果不搞清楚，就这么写上去，如果出现问题，连原因都会找不到的。如此没把握的代码，在没弄懂之前我是不会写的。
我想表达的是，程序员应该尽可能对自己写的代码有把握。要弄清需求要求，看明白老代码，写明白代码。
外包大部分程序员都比较平庸，呆久了可能也会变得如此，这也是为什么我一定要跳槽离开的的原因。
最后
总之，接受一个需求以后，要深入理解这个需求，这是做好开发的前提。记得多问需求人员，多找需求人员确定，不要自己想当然，避免返工。下一篇不出意外，我会继续分享：写概要设计、开发往期推荐?转行码农的银行外包日常（一）转行编程必备技能--Debug一个字节程序员的平凡日常来开发个能赚钱的