在中小企业公司里，技术部里会包含需求人员，开发人员，测试人员，发布运维人员[如果人手不够还是技术人来实施部署]，但公司不管怎么小，做技术的必然缺不了开发人员，有时开发会变成全才，会听取整理需求，实施计划开发，测试功能到位，部署指定环境，这一整套龙套必不可少，如果中大型公司几百台几千台万台服务可能还有监控系统，(⊙o⊙)…有点扯远了，下面切入正题，我对技术部各个岗位功能职责的保留意见，有问题别喷，欢迎指正！
需求，作为大部分开发任务的源头，在我认为它是比较重要的环节，需求的好坏有一定因素决定着项目是否能健康的发展（对新项目来说成功的落地前提必要基础）；
所以需求在前期需要做大量的调研工作和沟通成本，需求文档的严谨性，内部功能的确定性，业务流程的完备性，后期开发当中协调开发人员和需求方产生问题共识，最终开发出成品的验收结果等，可以说它具备了牵头羊的效果。我只能大致描述，因为不是专业需求人才，嘿嘿，不过我偏向重视需求的设计是否合理化，对需要的计划安排是否妥当是一个重要环节，因为饭是一口口吃，事情需要一件件去落实。
测试工作繁重性，也是不亚于开发；初次开发完成后的上线测试，需要精细踩点，对于各种不合理的功能运用或者更严重的BUG需要不断的进行请求回退开发，然后在后期发布前对其不断的进行性能压测，最终得出一个测试报告，这样就知道待上线功能的吞吐量，并且评估是否真的具备上线要求，否则到时弄不好部署上去后会导致整体系统雪崩瘫痪。那么我可以说测试这个岗位里需要的是两种测试职责：功能测试和压力测试；前者是初步验证，确保功能完整性和预案需求的一致性，后期压测是确保线上稳定生产，这两个环境不能丢弃。
说起开发，我相对比较了解很多，因为俾人就是开发的。拿到开发任务后，首先确保和需求要深入沟通需要知道做的是什么，你是否理解透彻，这个是确保你做出来的东西尽快验收，减少自身的版本迭代开发；
其次在实际开发当中注意需要测试代码紧跟你的逻辑代码，并且合理的项目构架还会带来事半功倍的效果，那测试代码肯定是属于我们开发的单元测试，不管是Mock或者Fakes，这是必不可少，这样对逻辑代码内部功能的踩点也是一目了然；
最后的期望也是希望让开发者自己进行硬编码的压力测试，自己确保每个功能点的高性能高吞吐，在最终交付时领导对你也是点头称赞
发布，运维的活，之前我看过一遍软文写运维人员的要求，他们称知最佳的运维人员需要懂服务器配置扩展等必不可少，最好还能懂点代码，不用精通，可懂即可，语言上也是希望多掌握几门。当时我就蒙圈了，这个也太牛逼吧，接近初级开发了，既然这么说那初级开发人员如果转行到是一个合适的机会，前话说这么多是告知大家发布这事情需要运维的人还真不简单，首先发布时是全手工、半自动、还是全自动，发布失败后，能全回退否还是部分回退还是评估后不影响整体功能上可立即上线解决，发布中产生问题能得出报告并且指明问题点告知开发者，部署时是否需要再次升级环境配置等相关方方面面的工作，那懂点开发这样的运维人员发布部署上线和开发者还能快速协同找到问题点，当然越自动化发布越省心，对整体系统的构架也越严格，自动化也带来更多的技术人力资源储备。
说了这么多，以上的技术部各个大岗位工作每个能做到80%-90%，我觉得已经相当不错，也是我的纯属个人意见，如有不妥欢迎纠正！
本来还想上点什么组织构架图，或者工作流程图，我是个懒惰的人，这个就算了，从简至上......
相关文章
