需求跟踪

一直没找到好的需求跟踪管理软件，但是今天我发现，在一个需求由极少人管理的工程里面，需要固定的人跟客户沟通的工程里面，开发人员不关心项目进度的工程里面，根本就不要跟踪管理软件，因为跟踪管理软件注重的，是确保需求的变更能够被跟踪与提高需求的响应速度。但是在实际的项目开展过程中，项目经理或者是项目的负责人，在需求跟踪上，所扮演的角色是非常重要的，更有甚者项目经理充当的是一个甲方和乙方的资料档案馆，开发人员依赖你，客户也依赖你，两边都要兼顾。所以我认为，对于开发人员人数不多（直接的项目规模评估）的情况下，项目经理的责任就更大了，这时候所有的需求，就应该如流水般，在项目经理这条堤坝手中牢牢掌控着，就算是辅助的工具，也只能作为记忆工具，还不如日程表来的实际。
项目经理所要担负的责任之重，可见其压力是很大的，怎样才能够有效的管理手下的开发人员，成了当前最大的难题，出路只有一条，就是解决开发人员不关心项目进度这一问题，只有将分散的思维和力量，凝聚在一起，才能够让目标如海中的明灯，给航行带来指引，项目才会朝着既定的需求目标进行下去。
（开会回来后，心情未收拾好，还是进来继续写）
对于功能模块业务独立的项目来说，经常一个模块是由一两个人来实现的，那么，这个功能模块的需求用例，应该完全由这一两个直接开发人员来实现，用例的实现过程中，是否有偏颇，那就完全取决于开发人员了。这样，就会出现一种和客户沟通不及时，到最后返工的风险可能性会大大地提高。工作的责任心是一点，但更多的是开发人员的脑海里根本就不会有跟客户沟通交流的概念，往往都会认为既然已经有需求文档了（更可怕的是这点，需求文档一般都不能完全描述清楚客户的真正需求），只要把用例代码实现，测试通过就可以高枕无忧了，但现实往往是事与愿违，等待他们的是需求变更和烦人的返工。
我一直认为，需求不应该是专门的需求人员区做，而应该是开发人员直接参与，这点我认为是王道，是真理，但往往因为这样会直接增加成本，而很多公司都不会走这条路，可悲啊，知道问题所在，但无法解决，因为钱是唯一的生存基础。
需求的确要跟踪，最好的跟踪，除了自身开发团队做好之外，还需要客户参与，大家是否遇到过客户开始时说的需求，过了一段较长的时间候，竟然会忘记之前的所提出的需求，并且提出需求变更。这是非常正常的现象，但我们就要有相应的措施来应变。现在我们一般走的路子，就是在这时候记录需求变更，然后再组织人员进行设计和代码的修改。这条路我觉得走得通，但代价高，最好的解决方法，就是在开发过程中，让客户的业务负责人参与进去，时刻跟踪需求的实现进展，这点，要做到，难度高，但完全可行，只要功能模块的代码开发人员直接跟客户沟通，就很好实现。努力吧，各位兄弟，埋头苦干，到最还吃亏的还是自己。