怎么确认需求以减少后期的需求变动

OYalivn 4人参与 0 次点击

如题,有时候感觉在开发过程中经常遇到疑问,然后有的地方需要需求方确认,而作为产品的自己当初又没考虑到开发遇到的这种问题,于是又要回去询问需求方,问多了他们会烦吧? 大佬们来指教或者讨论下?

    6 讨论 | 直到 2018-12-27 4:32:51
  • 汀蓝
    1

    1、改进

    对后期确认的问题进行归类整理,主要没考虑的是哪些问题:

    • 业务流程上的, 在业务流程梳理阶段进行规避, 我们的做法是各个业务流程图和客户进行确认;
    • 异常情况方面, 如断网、字数超过限制等, 这些可以整理个表格,供今后自查用;
    • 其他类型的,具体情况具体处理

    2、询问的方式

    • 内容分紧急程度,紧急的还上要优先问
    • 不紧急的,集中一起询问,或者跟需求方协商个时间, 一周固定时间集中反馈答复,或者不紧急的邮件发送邮件反馈
    • 区分哪些是可以自己决定,哪些是客户确认,哪些是自己决定告知客户即可的,可以和客户讨论个范围

  • OYalivn
    2

    汀蓝 这个有道理 受教

  • 呆萌
    3

    汀蓝是谁,很厉害的样子

  • ZGJ
    4

    呆萌 本站副站长

  • ZGJ
    5

    PMP中针对软件项目开发过程中的需求变更控制,做了如下的说明

    需求变更对软件开发项目成败具有重要影响,既不能一概拒绝客户的变更要求,也不能一味地迁就客户,所以实施需求变更之前必须做好控制。需求变更控制的目的不是控制变更的发生,而是对变更进行管理,确保变更有序进行。

        一、明确合同约束,建立需求基线

        需求变更给软件开发带来的影响有目共睹,所以在与客户签订合同时,可以增加一些相关条款,如限定客户提出需求变更的时间,规定何种情况的变更可以接受、拒绝或部分接受,还可以规定发生需求变更时必须执行变更管理流程。

        虽然软件开发合同很难在签订之初就能够精确定义每项需求,单靠合同是帮不上忙的,但也不能忽视合同的约束力。

        明确和树立需求基线是需求变更的依据。在开发过程中,需求确定并经过评审后(客户参与评审),建立第一个需求基线。此后每次变更并经过评审后,都要重新确定新的需求基线,做到小需求可以变更,但大方向要力保不频繁变更。项目经理博客

        例如,对于项目中的需求,可以实行分级管理,以达到对需求变更的控制和管理。项目管理者联盟

        二、建立变更审批流程

        在实践中,人们往往不愿意为小的需求变更去执行正规的需求管理过程,认为降低开发效率,浪费时间。正是这种观念才使需求变更变得不可控,最终导致项目的失败。因此,小的需求变更也要经过正规的需求管理流程,否则会积少成多,积重难返。

        明确需求变更审批环节、审批人员、审批事项、审批流程。这么做的目的有两个:一是将客户下达变更的流程尽可能地规范化,减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的无效变更。二是留下书面依据,为今后可能的成本变更和索赔准备好“变更账”。凡未履行审批程序的“变更”,一律是无效变更不予受理。

        三、分级管理变更,定时批量处理

        软件开发项目中,“客户永远是对的”和“客户是上帝”并不完全正确,因为在已经签定的项目合同中,任何新需求的变更和增加除了影响项目的正常进行以外,还影响到客户的成本投入收益。因此,用户不断提出对项目进度有重大影响的需求对双赢也并不是好事。

        当遇到客户提出需求,不及时处理可能会使项目不能验收通过时,也不能一味拒绝不予开发。因此,当客户坚持变更新需求时,可以建议客户将新需求按重要和紧迫程度划分档次,作为需求变更评估的一项依据。

        例如,每周或每两周甚至每月召开一次需求变更专题会议,集中研究处理这些零碎变更事项,主动控制好工作节奏,尽量避免由于处理零碎变更而影响项目进度。

        针对会议结果可向客户正式提交一份需求变更计划,注明变更引起的时间、成本、工期代价和增加工作量等。要求客户配合需求变更计划,确定变更时限,控制变更规模,过时变更不候,离谱变更不做,保大局弃小变。

        四、安排专职人员负责变更管理

        有时开发任务较重,开发人员容易陷入开发工作中而忽略了与客户的随时沟通。因此,需要安排一名专职的需求变更联络人员,负责与客户及时交流,跟踪和汇报需求变更完成进度和情况。

        同时,可以成立项目变更控制小组,负责裁定接受哪些变更,小组由项目所涉及的多方人员共同组成,应该包括客户方和开发方的决策人员在内。

        五、确认客户是否接受变更的代价

        要让客户认识到变更都是有代价的,要和客户一起判断需求变更是否依然进行。例如,变更是没有问题的,但是要明确客户能否接受由此引起的如进度延迟、费用增加、效率下降等问题。

        一般来说,如果客户认为该变更是必须的(不是其上级领导拍脑袋提出的)就会接受这些后果。通过与客户协商,这样开发团队即使没有回报,也不会招致公司和客户双方的埋怨。

        如果客户认为该变更虽然有必要但是可以暂缓,双方签署备忘录后留待以后解决。如果客户认为该变更可有可无,多数情况下会取消变更。这样即可防止频繁变更,也让客户认识到不是所有的需求都需要变更。

  • OYalivn
    6

    ZGJ 过时变更不候,离谱变更不做,保大局弃小变