1. 背景

软件需求是一个沟通的过程

沟通

一个项目的成功,依赖于很多不同的信息,这些信息来自各自不同的人员:

  • 一方是客户和用户,有时还有分析人员、领域专家和其他从业务或组织视角来审视软件的人
  • 另一方是技术团队

一旦任何一方在沟通中把持绝对地位,项目就会遭受损失。

  • 如果业务方把持绝对地位,他们就会关注软件功能交付日期,却很少关注开发人员是否能够同时满足这两个目标,或者开发人员是否确切了解需求
  • 如果是开发人员把持绝对地位,技术术语就会代替业务语言,从而导致开发人员无法倾听业务方的实际需求

需求的协同工作方法

协同工作

我们需要一种需求协同工作的方法,让双方都不占绝对主导地位,共同面对感情用事和办公室政治化的资源分配问题。

如果资源分配问题完全落在一方,项目必定会失败。

  • 如果只让开发人员来承担这些问题(他们通常被告知“我不关心你们怎么做,但请你们在6月份之前完成”),他们可能会牺牲质量来换取额外的特性,也可能只部分实现一个特性,或者自行做出一些该在有客户和用户参与的情况下才能做出的决定
  • 如果只是客户和用户承担资源分配的责任,那么我们会通常在项目开始阶段看到一系列漫长的讨论,项目中的特性逐渐减少。之后,在最终发布版本的时候,只剩下很少的功能,甚至少于被减少的功能

如何规避风险

规避风险

软件开发类项目本身是很难预先评估的,中间有很多因素能决定最终项目的结果和质量,这是软件开发本身的特点。那么我们应该如何来做?如何来更好的规避风险?

基本原则:

  1. 不要在项目开始阶段就做一套完善的、包罗万象的决策
  2. 把各个决策分散项目过程中

因此,我们需要有一个获取信息的过程,越早越好,越频繁越好

results matching ""

    No results matching ""