也谈工作

临近年底，工作逐步进入“淡季”，抽时间总结下这一年多时间工作这点事。
刚入职的时候，项目临近deadline，开发处于紧张的编码阶段，测试工作几乎等同于未开始，没有测试用例，当时这个项目组没有专职的测试人员，只是从总部调来了2个人临时负责该项目的测试，其中1个跟我同一天加入项目团队，完全不了解业务知识和系统需求，本指望另外1名从需求阶段就介入的测试人员能提供一些支持，在没几天的时间里发现希望破灭了，该大仙儿到最后系统培训-上线的时候还在问我他负责测试模块的相关业务知识。汗……好在有功能模块流程图，结合开发出的功能，也许自己领悟力的确不错，在系统评审前，不仅熟悉了负责模块的业务知识，对整个系统也能完整的演示下来。
正因如此，项目上线后，领导让我负责部门内对外需求对接人，负责接收、整理需求文档及跟踪需求状态。
此时遇到的第一个问题是，其他系统我没有接触过，接需求的时候就会很吃力，基本的页面功能都还不了解，更别提内部的逻辑关系。现在想来为什么当时不要求加以培训呢？！
紧接着的第二个问题是，接到需求邮件后，个别开发包括领导在内，对此置之不理，别说能给出大概的上线时间，就连可行性也不做回复，所以我夹在中间很为难。现在想来还是当时跟踪的力度不够。可能由于新来，加上办公氛围相当压抑，所以做事风格比较小心翼翼，开发给不了确切的回复自己也束手无策，只是转身安抚业务。
之后各系统相对稳定后有了闲置人手，领导让我想需求，开发一套内部使用的需求系统，我心里那个激动，终于可以摆脱这些窘境，然而出乎意料的是领导自始至终没有想过要使用其他人提供的系统功能，他的做法是，把数据库表设计好，加上备注说明，交给开发去实现，哪里不明白了去找他，临时想起什么了就要求加上。当出现问题问他的时候，听到的还是那句话：你们先好好考虑考虑。系统最终还是投入使用了，好不好用放一边，令我们惊愕的是这不是一套需求系统，这是一套人员工时管理系统。可就算是一套工时管理系统吧，还不能科学有效的达到监控、统计的效果。得用且用吧。-_-`
时至今日，需求跟踪的问题虽然不再是我纠结的问题，但是并没有本质的改变。因为没有提醒没有督促，一些人员的需求还是会一直挂在那里。这是部门流程制度的缺失引起的，但是我够不着，决定不了。我能做的是把测试做好，准备利用年底这几天清闲日子规范出管理流程，年后开始实施。