零碎需求项目如何管理

发表于:2017-11-28 09:58

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:流氓贵族    来源:51Testing软件测试网原创

  刚刚完成了一个项目,这个给我的感受项目总结起来就是一个字"累"、两个字"很累"、三个字"非常累",不是项目有多么的紧急或者是流程有多么的复杂,而是中间的需求变更频繁和相关参与人员变更导致这个需求变得很零碎。常常一个功能点已经接近尾声就接到通知这个功能点需要有变动或者是要在此基础上增加功能点,屋漏又逢连夜雨,由于项目是在跳槽黄金季做的,其间参与人员有的离职,有的紧急调到其他项目以应对其他紧急需求。这个项目看起来"碎碎"的,实施起来更是"碎碎"的。需要负责人很细心并且有耐心,尽管这样还是分分钟有想要扛起炸药包冲到甲方和甲方同归于尽的冲动。咔,好了,刚刚的场景也就能在心里想想,实际上要是这样做了还是得被甲方"杀得片甲不留,羽败而归",最后还是要把项目做下去。下面分享一下,这个"碎碎"的项目遇到的问题和应对的方法。
  一、项目需求的部分功能并没有确定,因为项目紧急,先开发后确认细节问题
  这个情况在某些公司是经常会遇到的,需求服务于市场,但是这种情况着实会给项目的实施带来很多的不确定性,以及上线后留下许多隐患。比如,这次的项目是三方共同做一个项目,功能主要依赖于接口之间的报文传输实现。但是,由于细节没有具体定下来,导致三方的部分实现细节不一致,如果剥离开三方的话,实现的功能都是符合需求的。
  细节的问题在一些情况下过于深究是没有意义的,但是如果需要几方合作细节问题就需要沟通明白。当然这就导致了一次本可以避免的需求变更以及重复工作,修改需求比新增需求要趟了"雷"多,因为要测试修改的部分,还要估计修改部分的影响范围及是否会改坏测试通过的功能。
  其实,错的统一只要功能实现了,往往会有负负得正的效果;但是,对的不一致也是一种错。这就是为什么一定要沟通。最后,还是三方统一了细节一并修改,
  二、在原有实现功能上扩展功能
  一个完整的框架可以一下子搭好,一个完美的框架不可能一下子搭好,它需要在上线后不断的根据市场和用户的需求做调整,所以拓展功能和废弃原有功能是不可避免的。但是,很少会遇到基础功能还没有做好就要做扩展功能的情况。此次便是这样,基础功能在即将上线的时候,产品开会回来通知项目组,需要添加功能,我都想去买个彩票看看能不能中奖了,500万,我来啦,咔,别做梦了,这种小概率事件不会落在你头上。
  在入行之前,我一直认为选择一个技术行业就不用看别人的"脸色",会有很多的自主权,然并卵,我想多了,任何一个行业都有其无奈,都会有制约。这些,从项目进度的角度来说是有些无理,但是客户必然有自己的理由,更何况,客户是上帝这就是条亘古不变的真理,要说吊打客户我只服乔布斯,但是"苹果"只有那么一个"苹果",咱们都得听客户的不是?明明是只"小绵羊"就别装"大尾巴狼"。
  最后,整个项目组的成员加班把新增的功能做好,并与涉及的范围详细分析和比对,确保不会对原有功能有影响。
  三、项目过程中的参与人员变更
  由于项目的开展是在跳槽的黄金季,项目期间有同事离职,导致任务由其他同事接手,而一个常理是既然人家已经选择离职,那么交接工作的时候,通常就是简单的交接后就抽身离开了,交接的细致与否便是情分多少,显然大部分的人都没有很多的情分,导致新接手任务的同事对原有的功能实现不是很熟悉,出现了一些由于生疏而出现的问题和任务完成延期。同样其他项目的同事也有离职的情况,就紧急调动了部分人员去其他项目帮忙,也导致了人手不够的情况。
  这样就涉及了人员管理的范畴,通常突然被通知要放弃自己已经跟了很久且已经熟悉的项目而去接手一个陌生的任务,大多数人的反应是"不甘+恐惧",这样会产生抵触情绪。另外,被增加了任务,会有中莫名的压力和紧迫感,还有不满。这些情况都会导致工作效率低下,工作进度延期。
  实际上,这样的情况是不可避免的。作为负责人要时刻关注项目组成员的情绪,调动成员的工作积极性,发现成员的情绪不好要及时的安抚。负责人除了要关注项目的进展,还要注意成员的心情和工作氛围,让大家在愉快中完成任务,才算完美。有很多的负责人都过分的关注项目的进展和成果而忽视了工作的氛围,个人觉得那是一种畸形的工作态度。
  总结
  项目过程中的变动,不管是需求变动还是人员变动都是不可避免的,我们要做的事情整理如下:
  1.首先是摆正心态,不要产生抵触和负面情绪,当然不是每个人都有马上调节情绪的能力,可以通过暂时的放空或者转移情绪目标来排解情绪,作为负责人除了要调节自己的情绪还要注意组内成员的情绪变化。
  2.做好需求变更和人员任务变更的记录,分析前后的差别,不要遗留变更点和影响原有功能的测试点。
  3.修改需求的测试点实际上要比新增需求的测试点的"雷"要多,要注意不要遗漏涉及功能的测试点,还有代码改动的影响范围。主要产生影响的因素有两个,一个是代码的质量因素,一个是人员的情绪因素。

作者简介:原本是学的偏硬件的专业,在找工作的时候听了一次招聘软件测试工程师的宣讲会,遂发觉做软件测试更适合自己,就走上了软件测试这条道,也希望越走越远。做过手机整机测试+web测试+app测试。略懂自动化、性能方面,学习ing中。
版权声明:本文出自《51测试天地》原创测试文章系列(四十七)投稿。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。
相关推荐:
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号