项目开发工作方法(需求调研角度)

本文描述项目开发的工作方法,侧重于如何在项目各个阶段,正确获取需求,保证需求不失控。

项目可按照如下阶段进行。

项目立项

前景分析、商务分析、需求概况获取、初步沟通等

  • 确认项目意向
  • 确认项目范围

调研

调研可分为两个阶段:

  • 业务调研:了解用户自身的情况,想解决的问题
  • 需求调研:了解项目的需求,确认我们的解决方案

两个阶段的目标可能互相有重叠,时间上也可能重复,不是先做一个阶段再做另一个阶段。只是侧重点不同,所以做了区分。

调研的主要形式是访谈、分析、记录。

业务调研

侧重了解用户的工作,想解决的目标。

目标:了解业务直到我们能承担项目范围内任何一个岗位的职责

对用户工作的了解,没有固定模板,需要具体项目具体分析。可重点根据以下几项内容进行调研:

  • 组织结构
  • 工作流程
  • 考核报表
  • 岗位职责

(参考文档《走出软件作坊》“文档知多少——设计文档编写方法”章节)

需要交付以下内容:

  • 访谈记录

时间、地点、人员、主题、结论

  • 用户一手资料

保留搜集到的,对项目有帮助的资料,要保持原样。

需要记录来源、名称、搜集时间、用途等内容。

以上内容,根据访谈会议、主题进行分组保存。一次会议应当解决一个或一组相关主题的内容。

需求调研

主要形式为:方案讲解、原型沟通

初期可能会有高端视角的方案讲解,后期大部分的时间都应该是做原型沟通。

原则:

  • 必须接触一手用户
  • 必须让一手用户获得实际的用户体验感觉

原型构建时技术选型的原则:要让用户有真实使用系统的感觉。所以:

  • 逐页翻ppt的方式不合适,因为用户感受不到页面跳转。

交付物:

  • 以会议或者主题为单位的方案、讨论结果、原型的迭代记录

需求分析

将调研阶段的成果系统化。

交付物:需求文档

需求文档的内容:

  • 项目背景
  • 需求概述(范围、功能分析、用户分析等)
  • 项目建模(这个名字有点故弄玄虚,我理解就是提供详略得当的抽象角度,让人几分钟就能大致了解项目要干什么)(核心流程图、核心用例、实体设计等)
  • 功能性需求(功能点拆分、各功能点描述、跨功能点流程描述)
  • 非功能性需求(质量要求、项目约束等)

关于上一章节调研阶段的方法是否掺杂了过多设计元素(比如原型图)的疑问:

那些只是与用户沟通的手段,目的是获取用户的全部想法。掺杂了设计元素带来的不利因素,可在需求分析阶段予以去除。

例如:

没有高保真原型的时候,用户会说,太难看了我不跟你们聊天,所以必须提供一个美观的样式,但是实际项目开发中,采用什么UI方案一定不会在这个阶段就确定下来。

在需求调研阶段,可以先“迎合”用户的想法,提供高保真原型,在需求分析阶段,根据获得的全部信息(用户提供的需求+用户对这个高保真原型UI的感觉+我们自身的技术评估),重新确认技术方案。

需求评估

每个功能点,除了要做什么内容的描述外,还应对其它因素做评估。现在想到的如下:

  • 可信度:某项目有些需求是完全由我们内部人员发挥出来的,标注一下可信度更有利于后续的工作。其余项目视情况决定是否需要
  • 优先级:紧急、一般、可选等。优先级会决定:项目历次迭代先做哪个需求、出现变动或者时间不够时会放弃哪个需求
  • 事务数:估算开发工作量,一个简单Action视作一个事务。或者采用其它基准评估也可以。不必要特别准确,不必要定义严格规则,在一个项目需求内标准统一即可。比如事务数为2的,不代表工作2人天,只是代表工作量大致上是事务数为1的功能点的2倍。

可参考之前的文章( http://nonesuccess.me/?p=379

技术评估

调研阶段、需求分析阶段,都或多或少的需要项目架构师参与。最晚到需求分析阶段结束时,需要得出明确的结论,当前的需求方案是在技术上是可实现的。

架构设计

由项目架构师负责。

需要总结项目所有的技术要求,技术方案。

可参考公司项目架构模板。

开发、测试、发布、维护

按照正常流程工作即可。

不再明确区分设计、开发两个流程,项目管理的最小个体是独立开发人员,此人员应该具备拿到需求后,直到上线的所有环节的工作技能。

需求、设计阶段需要确认的各项内容,如果因为各种原因,不能提供,则至晚到功能交付时,提供以下内容:

  • 核心用例
  • 功能点
  • 实体模型设计
  • 流程图
  • 实体状态转化图

在此过程中:

敏捷开发

能确定敏捷开发一定是正确的方法论,但是1、细节我还没想太清楚 2、必须是传统开发流程训练得十分流畅的工作人员才能更好的接受敏捷,直接采用敏捷方法一般不会顺利完成工作。

所以只列举几个我能想到的要点:

  • 不必等上一个流程完全完成,就可以把已经成熟的部分进入下一个流程。比如某一组模块进行了需求分析,比较完善之后,就可以进入开发阶段
  • 尽一切可能,让实际用户早日使用系统,每天检讨:今天的成果让用户体验了吗
  • “用户而不是客户”:找使用系统的人,而不是付款的人
  • 欢迎需求变化
  • 验收测试驱动:做事之前先想好怎么验收,以验收标准驱动工作。比如做功能之前,先想验收过程是,古林街孟姐用系统成功发证,那么任意一次迭代中都要评估,我就是孟姐,我发证试试,成功了吗,有助于发现很多问题

需求变动

项目开发过程中,会因为我们想法变化、客户情况变化,发生需求变动。

变动时需要交付:

  • 新一版的需求文档(用各种形式标注或者备注发生了什么变动)
  • 需求变动文档:记录本次变动的内容,以及变动原因等其它需要说明的事

交付后,本次需求变动的内容可进入开发流程。