zoukankan      html  css  js  c++  java
  • 关于专人整理和分析需求

    PAM方向目前正在大规模的整理需求,希望能让产品需求、项目需求的需求分析工作更有序更专业。整理过程中遇到这几个问题:

    1、有专人根据各个项目的需求文档及之前讨论确定的内容把项目的需求进行梳理并分别归类纳入到不同的表中,但感觉这个表内容还不全面,有部分还存在大家脑子里面,所以希望各个项目负责人补充需求;

    2、为了更规范的管理需求,准备采用定期召开需求评审会的做法,希望集思广益、更专业的明确和管理需求;同时改变产品开发和项目开发形式,力求达到需求明确、产品和项目区分开发;

    3、专人整理需求时发现一个问题:最初整理这个文档的时候也想把每一条从场景、目标说清楚,但是这样做其实把我们需求规格说明书里面的东西搬到excel表来了。

    通过直接交流,总结出以下想法和建议:

    1.    目前存在好几个人在进行需求分析,那为什么还要专人整理需求呢?理由是: 
    1)一线需求分析人员很忙,经常出差和开会,没足够时间进行细化和整理; 
    2)一线需求分析人员紧密接触用户,更关注于原始需求和大量的隐式需求,重点是考虑需求从无到有、感性理解、口头表达; 
    3)那为什么不能让一线需求分析人员直接报告详细需求细节呢,原因是他们更习惯于发散式思维、他们认为理所当然(他以为你肯定知道)的就不会写下来了; 
    而由专人整理需求的好处是: 
    1)不是发散思维,而是更理性的细化分析,考虑重要不是要不要某个需求、假想需求,而是定性定量的描述需求 
    一般而言,提出需求的人多少都会带些个人情感和特点,不太可能做到很理性很细致的描述需求,而专人整理则只需要明白是什么并准确描述出来就可以了 
    2)统一汇总,把大家头脑中和口头上的理解说法以明确语言描述出来,达到汇集想法、统一理解的作用


    2.    需求管理表格的作用 
    1)对大量需求进行一览描述,更容易关注整体; 
    2)需求跟踪追溯,管理每一项需求的状态和时间点、相关人,对需求提出、需求描述、需求评审通过、作废或合并、进一步明确、设计开发所涉及的人、时间、原因进行记录 
    要实现需求跟踪追溯,就要做到任何需求的状态改变都不能直接删除,即使不想再看到也应当将需求条目转移到另一个地方,否则难以追溯 
    3)如果因为需求很多担心管理不过来,考虑将进入开发的需求采用分摊工作量和责任转移的方法由开发人员定期汇报各自的需求状态,再由专人汇总


    3.    如何做好需求整理工作 
    1)在需求评审之前就要把需求是什么弄清楚,需求提出人如果描述不清楚的话就由整理人员通过各种方法将潜在需求条件等挖出来,通过需求复述等达到两人理解一致,然后再到需求评审会上进行评审和补充;如果这两个人的需求理解都还不一致的话,那需求评审会上就会花费时间来讨论需求是什么样的,很可能需要多次评审。 
    2)基于目前绝大部分需求提出都很粗、需求描述二义性较大的情况,前期在规范需求提出采用需求模板时,需求模板应包含较少的项目,只需要包含最重要项,通过直接沟通来完善描述 
    3)对于使用什么工具来管理需求和描述需求的问题,应使用最简单的工具(Excel+Word+PPT),充分利用人的因素


    4.    需求评审 
    1)区分评审级别,例如宏观需求、需求项对应的粗略需求、需求内的功能点、技术条件等非功能项、采用何种技术方案、工作量及人员分配等 
    2)将评审和头脑风暴式的需求完善和改进区分开来,可能需求还不完善,但肯定能评审一部分内容,需求可以逐步完善和补充细化 
    3)怎样才算需求明确呢?关键参与人都对需求理解一致就行。具体到开发编码时如果还有地方不明确,则可以商量细化,或根据用户反馈来调整,整理需求时可以不用细化到能编码的地步


    5.    如何描述细化需求 
    需求描述如果能达到既完备又无二义性,而且还是正确的,这当然是理想情况,实际中只要做到涉及人员都能理解的程度就可以了,哪怕是一些简单的界面草图或几句话,只要大家都清楚就行。

    对于“最初整理这个文档的时候也想把每一条从场景、目标说清楚,但是这样做其实把我们需求规格说明书里面的东西搬到excel表来了”问题,我的建议是: 
    1.    假如原来的需求规格说明书本身没问题,就直接关联到原来的需求规格说明书,不需要另外再写,但需要“去伪存真”: 
        1)对于原文档中哪些冠冕堂皇的套话,需要留意哪些话是仅仅为了好看和提升文档档次、哪些话是真实目标和真实意愿; 
        2)将那些不敢直接给用户说的、故意模糊的语言,转换理解出客观需求或真实场景,具体哪些是假的可以问项目负责人,不要让这些误解往产品中传播 
        3)了解那些并不出现在需求规格说明书中的重要情况,如项目真实背景、用户公司情况、人员情况(水平、工作习惯)、运作方式、潜规则等 
    2.    根据各个项目需求规格说明书及相关隐含情况,让自己从全局上理解和把握需求的为什么,逐步深刻理解这个行业的需求和发展,最后不但自己明白了,也让更多开发人员明白 
    3.    需求规格说明书的理想情况是只有一份产品需求规格说明书(不一定是给集团看的)和每个项目的需求规格说明书(不一定是给用户看的),至于如何权衡冲突,可以自己先做做感觉一下,可以考虑自己维护一些内部文档。

  • 相关阅读:
    redhat 6.7 telnet rpm 安装包
    linux下网络配置 命令
    修复南尼U盘
    mac获取root权限
    ubuntu二进制包安装openresty
    ubuntu18源码包安装openresty
    Python监控rabbitmq的代码
    win10不能将文件拖到另外一个程序中去的解决办法
    docker配置远程管理端口
    nginx的代理配置
  • 原文地址:https://www.cnblogs.com/zhaolizhe/p/6945569.html
Copyright © 2011-2022 走看看