现在的位置: 首页 > 综合 > 正文

需求跟踪

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

抱歉!评论已关闭.