写在冬日的第一天--一个女程序员第十六年工作总结

冬天来了，一年又过去了。

这一年过的无声无息，差一点忘了是写总结的日子。看了去年的总结真的是觉得世界变化太快了，去年已经够鸡零狗碎了。哪想到今年世界天翻地覆至此。

技术上面

自三月开始就居家工作。代码写的挺多的，但是技术含量不高。绝大部分都是普通的商业需求，除了麻烦点没有特别的挑战。今年写了一些架在亚马逊云上的东西，听起来跟上了脚步其实还是很基础。我主要从技术上面辅助产品把大的需求切分，提出可执行方案。

产品上面

去年三条产品线齐头并进。今年只留下一条了。其他两条基本上就是最最基础的维护，每个月也就花个一天。来详细说说这个主要的产品。

借着这个产品来说说甲方爸爸，书面平衡，还有就是公司内部各自为战

公司三番五次说自己的产品自己决定什么时候发布，每次发布涵盖什么内容。这么说的目的主要是怕产品被客户牵着鼻子走，在长远看阻碍健康发展。在开发内部也说了开发和测试同步，每一个新功能或者bug修复都要配有相应的自动测试案例。开发代码和自动测试代码全部提交测试通过后才算等待发布状态。执行的时候完全不是这么回事，开发和测试同步，或者TDD,在甲方爸爸的哼唧下根本没有任何效力。产品经理说没办法在下次发布的时候包含某个功能，甲方直接找领导的领导。领导的领导KPI完全是钱说了算，于是就是自动测试先放放，上线后再补。上线后又有下个阶段的高优先级功能，测试又压下来。直到CTO发威，申请了三周的时间专门补测试。 这个时候补虽然功效没有那么大了也算是聊胜于无。另外甲方爸爸们说我们发布的时间对不上他们的内测时间，让我们调整发布时间，什么Continuous delivery就是个让公司看起来技术上没有落伍的幌子，什么时候上线对接要对方说了算。还有就是我们的产品伺候甲方内部几个部门，他们部门间各自为政，每个都希望自己的需求最先满足。但是他们内部不统一商量，都是单独联系客户经理给经理施压，然后压力转嫁过来....每次看看理想的开发模型都好像诗和远方，真正的日常工作扯皮就是苟且一堆

书面平衡，我们用jira来做项目管理。公司说一个任务最好在一周左右完成从开发到测试的流程。好吧，我们花时间在控制一个任务的定义上面。对于一个很小的小组来说花时间搞这个真不如多写点代码。不过没办