标签 项目 下的文章

随机时间电击关在笼子中的狗,狗会本能回避,当它意识到电击是不可避免之后,就会消极低落,不再回避,绝望等待电击发生,这就是习得性无助,在软件团队中也可以观察到相似的情境,比如焦虑的项目经理和几个抑郁的工程师,当他们感到怎么加班努力都难以改变项目现状的时候,死气沉沉的氛围就产生了。

在软件开发这样一个需要创意和激情的工作里,无助的感觉可能来自控制感丧失或是选择性减少。当项目经理不能决定产品需求、开发进度和优先级的时候,理论权限与现实的落差会加重无助感;同样,当工程师不能决定开发思路,不能对开发事项表述自身观点或是表述无用的时候,无助感也会增加。无助感持续时间越长,团队成员就越倾向于把控制感丧失理解为永久性的,表现出意志消沉和被动顺从。

一个保姆型的团队领导容易让团队成员产生习得性无助,尤其是在研发型的团队中,技术经理事无巨细,控制到每一行代码,即使是善意的,也会让其他工程师感到自己只是工具。如果一个工程师对代码都感到缺乏控制,还能指望他有好心情吗?没有技巧的强制命令、朝令夕改的做法甚至是密集的进度考核都可能造成控制感丧失,需要项目领导者留意。

社会心理学研究表明,促进个人控制可以增强个体幸福感。在管理学中,也有“目标管理”这种让成员参与组织目标制定,通过自我控制来保证目标实施的方式。在软件团队中,软件功能和进度的确定在操作上容易让所有成员参与,有效提高成员自我控制感。成员的自我控制感是否持久,尝尝取决于成员是否有成功体验也就是成就感,因此,企业或是组织要帮助软件团队迅速实现阶段性成果,团队要帮助成员迅速完成项目里程碑,领导要帮助新人迅速完成入门任务。

人总归是复杂的动物,从100个电视频道选择1个比从10个频道选择1个要难,而且前者对选择的满意度要低很多,选择性多会带来更高的机会成本,后悔也越容易,这就是要规避习得性无助,首选是提高控制感而不是提供多选择的原因。

企业信息化让电子文档成为企业智慧财产的主要载体,信息化程度越高,企业产生的电子文档就会越多。能否管理好企业文档并充分挖掘企业智慧财产的价值,是企业信息化程度的重要考察指标。

传统上,企业文档无论保存在什么地方,都呈现出一个树状的结构,通过不同的分类,可以把企业文档保存在相关目录中,因此,可能会出现多级子目录的情况,虽然在理论上可以同从根目录开始,通过一条也许很长的路径(例如A电脑D盘C目录下的B子目录下的E文件),直到找到文档。在效率至上的竞争社会里,是不允许这样的,于是人们采用了搜索的办法来解决这一问题,将树状的文档结构扁平化,这同样也产生了一个问题,那就是准确性,这个问题就需要设计合适的排序机制来解决。实际上,排序在人机交互上是一个值得考虑的细节,一个合适的排序机制可以是企业文档更加有序,具有更好的可读性,提高文档管理工作的效率。

要理解企业文档排序机制,首先要对企业文档的基本构成进行分析。一般说来,企业文档由 文字、照片、图纸、表格、音频、视频 等等元素构成,类型相当复杂,电子文档的多样性给文档管理带来很大不便。大型企业一般会针对本企业的业务进行分析,动用天文数字的人力物力财力,建立起一整套完善的文档管理机制,而对于中小型企业来说,投入大量资源开发自己的文档管理机制是没有必要的,大都会采取如下几种方式:

一、 Email方式。通常是将文档保存在邮件附件中,这种方式在中小企业中很常见,它有自己先天的优势,那就是传播速度快,利用已有的成熟邮件系统及邮件客户端(如outlook、foxmail、thunderbird等),可以对企业文档进行归档和分发,这种方式,基本上是通过时间排序来管理企业文档的。缺点显而易见,如果采取自己搭建企业邮局的方式,一则企业邮局软件花费很高,二则受网速的影响很大;如果采用大网站提供的服务,除要考虑网速影响文档管理外,还要考虑邮件附件大小限制对企业文档保存的不利因素。更重要的是这些文档是分散保存在不同的邮箱之中,很难能适应一个企业文档可能出现多个版本的情况以及其他不可预料的情况。

二、文件共享服务器。在文件服务器中对文件进行分门别类存放,通过文件共享对文档进行管理,有比较简单的搜索功能,仍然很难对企业文档进行挖掘和再利用,这种方式基本上就是分类排序和时间排序的结合体。

三、专业文档管理软件。一些比较大的软件开发商,如IBM、用友、金蝶等,为中小企业提供了许多解决方案,开发出了许多专业文档管理软件,但是考虑到软件成本和培训成本,更多的企业采用SVN版本控制工具来管理文档,尤其是高科技企业。这种方式比较先进,能够很好控制文档的来源、流向、时间等等,只是技术门槛比较高、专业性较强、相关软件也比较复杂。这是一种混合型的排序管理。

在企业文档管理中采取的任何排序方式,都来自于对文档基本属性的定义。不管企业文档的表现形式是什么样的,都不会改变其基本属性:

一、time。基于文档的生命周期,产生了时间排序 ,根据企业目标的不同,文档的生命周期会有一些细微的变化,这里举软件开发文档的例子来说明。一个软件开发文档常常是这样的情况,先形成一个初稿,结果多次修改后,成为了开发文档,这时候文档就被锁定不再修改了,在开发过程中,又发现了新的问题,需要解锁文档进行修改,直到产品最终上市,开发文档终结,进入文档数据库存档保存。这样就基本确定了文档的时间点类型。
1、创建时间;
2、修改时间;
3、锁定时间;
4、解锁时间;
5、终结时间 ;
在查找文档的时候,这些时间点就成为了搜索的具体参数,由于时间的一维性,通常就是升序或者降序排列。

二、 location。基于文档的存放位置,产生了分类排序。 这里的位置绝不仅仅是指电子文档在存储设备中的存放路径,也包括了存储设备的物理位置,还有根据内容相关性确定的文档所属分类等等。例如, 企业的市场、行政、产品开发、服务支持、工程等部门,都存在着大量的文档资料 ,这就是一种天然的分类,属于某一个部门的文档在不指定特殊排序方式的时候视为是无序存放了,这种无序本身就是一直排序。

三、role。基于角色,产生了等级排序,与对文档的操作相关 ,如果只保存文档而不进行其他操作,就不能挖掘出企业文档的价值,但是操作也是有风险的,如果出现操作失误,同样有可能使文档价值受损。

1、文档安全等级 。企业文档通常包括了很多敏感资料,需要针对不同的人设定不同的保密等级来管理,这就产生了安全等级排序 ;
2、文档的重要程度,如 分为 核心文档、补充文档 ,并据此进行排序 。重要程度与安全等级并不直接相关,例如一家运作开源项目的软件企业,软件开发文档相当重要,但是并不保密,全部公开,也就是安全等级不高,而员工的薪酬表,重要程度甚至不如开发文档,但是保密,也就是安全等级高。

四、keywords。这里引入“ keywords ”这个 词来称呼 文档的 所有 特殊属性, 想设计新颖有效的排序机制,就需要定义很多有意思的特殊属性,通过这个keywod来排序文档,达到最优的效果。例如定义一个文档阅读次数的属性,就可以用次数排序来找到最受关注文档,以此作为文档重要性的关键参数,也可以定义一个文档搜索次数的属性,以此排序来找出用户最需要的文档等等,显然,这样的排序更有助于企业文档价值的挖掘,keywords是企业信息化因此创新的主要着力点之一。

一. 概述

在开始进一步讨论之前,我们先明确几个概念。

首先,本文是从开发团队,或者说项目组的角度来看需求问题。所谓开发团队,通常包括了程序员、测试员和其他一些项目成员,如配置管理员和软件架构师,以及基层的管理人员,比如项目经理。类比于传统企业,开发团队相当于企业的生产车间。但是,在大多数的软件组织中,开发团队除了担当“生产”任务以外,往往也是需求获取的主体;在某些较为正规的组织中,也许会有市场部门给出一些需求,但这些市场数据和有限的调研结果通常是远远不够形成需求规格书的。

其次,何谓“新产品开发项目”。简单而言,在本文中,新产品开发指开发团队需要从无到有将一个想法(idea)转化为产品(product)。新产品开发不同于产品升级,开发团队没有一个已存在的基础;新产品开发不同于开发一个实验型的作品或者演示、原型之类的东西,开发团队最终的产出必须是产品,在功能、性能、可用性等方面都有比较高的要求和期望;新产品开发不同于承接一个软件开发项目,也不同于为明确指定的用户或者客户定制产品,开发团队最终面对的是广泛的市场,是一个由众多独立的最终用户(同时也是客户)组成的群体。新产品开发项目更加不同于维护型的,或者其他类型的项目。

第三,本文所讨论的需求基于需求的传统定义,即软件需求指用户对软件产品明确的和期望的要求。这些要求直接影响了用户对此产品的满意程度,或者更直接的说,影响了用户的购买决定以及对产品和开发商喜好的判断。对于开发团队而言,在实际工作中,需求问题往往和设计问题,特别是高层(High level)的设计纠缠在一起,很难有明确的界限划分。但在本文中,需求问题不涉及与具体实现相关的问题,比如技术选型,人机界面。

概括而言,在一个新产品开发项目中,开发团队面临的需求问题涉及到需求的获取、分析和管理。本文的余下部分将重点讨论新产品开发项目中典型的四大问题,分别是:有限的需求来源、模糊的需求界定、CPD陷阱和NV陷阱。

二. 有限的需求来源

新产品的想法可能来自老板的拍脑袋,也可能来自市场部的报告,或者也可能来自研究部门的某个创意;但不管怎样,可以肯定的是,没有人具备足够的信息来准确的描绘出未来的产品(而且通常这个未来也不会很远)是什么样子。如果项目组成员恰好属于这个产品的用户,比如这个产品是一个字处理软件,或者仅仅是搭上一点关系,比如这个产品是一个个人理财软件,那获取需求的任务就更加理所当然的落在了开发团队身上。

表面上看,由开发团队自己定义需求会使得需求相对稳定,对开发团队是有利的。但事实上,开发团队会面临不少棘手的问题,最直接最明显的,就是需求的来源受限。开发团队最需要的就是明确的(最好也是稳定的)需求,而现在,要开发团队自己去获得,而且获取需求的来源又很有限。

由于是新产品,在组织内部,开发团队通常找不到足够的帮助。而要从外界获得,又受到时间、经费和职责等因素的限制。在这种情况下,学习竞争对手的产品是一个很有效的方法。开发团队可以从研究和剖析类似产品着手,例如,如果要开发一个电子邮件客户端软件,那么,Outlook和Foxmail就是很好的学习对象。亲身的去使用和体验这些软件,仔细阅读它们的用户手册、在线帮助,甚至联系它们的客户服务。而且,这项工作应该让整个团队一起参与,增强每个团队成员对产品的理解和感性认识,当然,参与的程度和时机可以有所不同。

面对有限的需求来源,引入资深用户是另一个解决方法。所谓资深用户,他们可能很熟悉同类产品的使用,或者了解用户通常需要些什么。比如开发个人理财软件,那么一个理财顾问,或者一个理财高手就是很合适的资深用户。对于面向群体用户的产品,特别是那些大众消费类软件,这些资深用户事实上并不如想象中那么难获得。个人关系是主要的获取途径。为了减少个人偏好的影响,应该尽可能多引入几个资深用户。对于某些产品,比如前面提到的电子邮件客户端软件,似乎团队成员中就可以找到资深用户。但在团队内部发展资深用户并不值得鼓励。其中的原因在“CPD陷阱”一节中会解释。

三. 模糊的需求界定

在一个新产品开发项目中,某项需求是否需要、它的优先级如何、某项功能或者要求究竟如何表述,这些界定问题由于没有一个确定的用户或者客户说“要还是不要,好还是不好,急还是不急”而会变得模糊不清。

这种模糊的需求界定也发生在开发团队内部。每一个成员都可以声称“用户要这个功能”,或者“用户根本不可能那样操作”。需求的界定常常成为“公说公有理,婆说婆有理”的争论。

在现实世界里,开发团队往往处于一个尴尬的境地。他们通常被认为有义务制定出需求规格,并对此负责,却没有被赋予对需求规格最后“拍板”的权力。在这种情况下,开发团队以及开发团队的领导要明确自身的立场,并将相关的责权利落实到纸面上。

在技术层面上,解决“模糊的需求界定”问题的一个方法就是采用原型。利用原型来讨论,利用原型来证明观点,这比“空对空”的争论要有效得多。拓展出去讲,在界定需求的时候,尽量用事实和数据来支持观点,避免“可能怎样怎样”的猜想,如果不能肯定,就落实到概率上,这样可以通过风险分析的技术手段来帮助决策。

四. CPD陷阱

CPD是PMT的一个词汇,意即“无谓的创造-追求完美-自我否定”。团队成员过多涉足需求的开发(即使可能存在进度上的压力,项目的初始阶段也几乎总是一段美好的时光。进入一个新鲜而陌生的领域,团队的每个人都容易发现一片崭新的世界,每个人都能够为新产品添加一系列“激动人心”的特性。但这些特性是否合适、是否有必要却往往被“激动”淹没了。追求完美是计算机技术人员一个很普遍的特征,这一特征会促使这些无谓的创造继续下去,直到大家觉得“这个产品做得再好也不过如此”,于是,自我否定就会接踵而来。

为了防止陷入CPD陷阱,开发团队只需要个别人参与新产品的需求开发,而其他人则可以以已开发的需求作为进一步讨论的基础。这或许限制了团队的创造性,但却是更高效率的。产品开发不同于研究。产品开发更多的是需要一种“收敛”,从“想法”到“产品”的“收敛”。如果你发现这种做法埋没了团队中太多富有创造精神的成员,但你要检讨团队的成员结构,或者你现在的团队适合研究而非产品开发。

五. NV陷阱

NV是PMT的另一个词汇,意即“下一版本”。在功能性需求上,CPD陷阱是常见的。而对于非功能性需求,比如产品性能上,NV陷阱是很容易陷入的。陷入NV陷阱后,往往到时候产品的质量会大打折扣,甚至“拿不出手”。另外,不完整的需求也容易导致错误的设计,这种架构上的缺陷实际上很难在“下一版本”轻易的改变。

除了主观上对非功能性需求的不重视,陷入NV陷阱的原因常常还有迫于时间压力,或者毫无来由的乐观。开发人员常常认为他们在以后的同样长的时间里可以完成多得多的事情,而且这些事情通常是现在不大愿意做的事情。

“这个版本的确不够稳定,下个版本再说吧”,这是经常可以听到的说法。为了防止陷入NV陷阱,非功能性需求从一开始就要被提出来,并受到应有的重视。如果这些非功能性需求是确实需要的,就应该被写入需求规格书,并在产品开发过程中接受实现状况的检查。

有限的需求来源、模糊的需求界定、CPD陷阱和NV陷阱是新产品开发项目中常见的四大问题。除此以外,新产品开发项目中也存在其他的一些特殊问题,比如在需求的跟踪管理上,新产品开发项目就与其他类型的项目有不同的地方。PMT将继续这方面的研究和实践,并期待和广大读者的交流。

你的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段而且你要写软件需求说明书。这份说明有些大,但客户会很重视,所以说明必须得到赞同。

现在你正在设计其中的一个特性,已经发现了需求的一些问题。你可以用多种不同的方式解释需求15;需求9 的说明正好与需求21相反,你因该相信哪一个?需求24非常含糊,你根本不明白它的意思;你不得不花上一个小时与2位开发人员讨论需求30,只因为你们对其各有各的理解;并且,唯一能够澄清这些问题的客户没有给你们答复。你被迫破解众多需求的含义,并且你能预料到,如果你错了,你要做大量的重复工作。

许多软件需求说明书(SRS)写得非常糟糕。任何产品的质量需要其原始材料的质量保证,糟糕的软件需求说明书不可能产出优秀的软件。不幸的是,几乎没有开发人员受过与需求的抽象、分析、文档、质检有关的教育。而且,没有非常多的好需求可以借鉴学习,部分原因是很少有工程可以找到一个好的借鉴,其他原因是公司不愿意将其产品说明书放在公共区域。

这篇文章描述了高质量需求叙述和说明的几个特性(特点)。我们将用这些观点检查一些有缺陷的需求,带着痛楚重新编写。而且我会谈一些如何编写好的需求的提示。你也许想通过这些质量标准评估你的工程需求。对于修订,也许迟了,但你会学到一些有用的东西,并帮助你的小组在下次编写出更好的需求。

不要期望能够编写出一份能体现需求应具备的所有特性的SRS。无论你怎么细化、分析、评论和优化需求,都不可能达到完美。但是,如果你牢记这些特性,你就会编写出更好的需求,生产出更好的产品。

高质量需求叙述的特性

我们如何从一些有问题的需求中分辨出好的软件需求?这一节将分别介绍需求叙述应体现的6个特性,下一节将从整体上介绍SRS文档应具备的特性。判断每个需求是否具备应有的特性的一种方式是由持有不同观点的工程资金管理人所作的正规检查。另一种有力的方法是在编写代码前依据需求编写测试例子。测试例子能够明确显现在需求中描述的产品行为(特性),能够显现缺陷、冗余和含糊之处。

正确:每个需求必须精确描述要交付的功能。正确性依据于需求的来源,如真实的客户或高级别的系统需求说明书。一个软件需求与其对应的系统需求说明书相抵触是不正确的(当然,系统需求说明书本身可能不正确)。

只有用户的代表能够决定用户需求的正确性,这就是为什么在检查需求时,要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的:“这是没意义的”,“这可能是他们的意思”等众所周知的猜测。

可行性:在已知的能力、有限的系统及其环境中每个需求必须是可实现的。为了避免需求的不可行性,在需求分析阶段应该有一个开发人员参与,在抽象阶段应该有市场人员参与。这个开发人员应能检查在技术上什么能做什么不能做,哪些需要需要额外的付出或者和其他的权衡。

必要性:每个需求应载明什么是客户确实需要的,什么要顺应于外部的需求,接口或标准。每个需求源于你认可、具有权说明需求的原始资料,这是考虑必需的另外情形(译注,此句翻译不顺,请参照原文:Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements)。跟踪每个需求回溯到出处,如用例,系统需求,规章,或来自其他用户的意见。如果你不能标识出处,可能需求只是个镀金的例子,没有真正的必须。

优先权:为了表明在一个详细的产品版本中应包含哪些要点,需要为每个需求,特征,或用例分配实现的优先权。客户或其代理都应有强烈的责任建立优先权。如果所有的需求都被视为同等重要,那么由于在开发中,预算削减,计划超时或组员的离开导致新的需求时, 项目经理将不能起到作用。优先权的作用是提供给客户的价值,实现的相关费用,实现相关联的有关技术风险。

我是用3种级别的优先权:高优先权表明需求必须体现在下一个产品版本中,中优先权表明需求是必须的,但是如果需要可以推迟到晚一些的产品版本中,低优先权表明有它很好,但我们必须认识到如果没有充足的时间或资源,它可以被放弃掉。

明确:需求叙述的读者应只能从其得到唯一的解释说明,同样,一个需求的多个读者也应达成共识。自然语言极易导致含糊。要避免使用一些对于SRS作者很清楚但对于读者不清楚的主观词汇,如:用户友好性,容易,简单,快速,有效,几个,艺术级,改善的,最大,最小等等。每写一个需要都应简洁,简单,直观的采用用户熟知的语言,不要采用计算机术语。检查需求模糊的有效方式包括需求说明书的正规检查,根据需求写测试,建立用户的假想来说明产品某个特定部分预期的特性。

可证实:看你是否能够做出测试计划或其他验证方式,如检查和实证,来决定在产品中每个需求是否正确的实现。如果需求是不可验证的,决定需求是不是正确的实现就成了判断的事。需求之间不一致,不可行,不明确也能导致不可证实。任何需求如果说产品将要支持什么也是不可证实的高质量需求说明的特征

一个完整的SRS不仅是包括长长的功能性需求列表,还包括外部接口描述和一些诸如质量属性,期望性能的非功能性需求。下面描述了高质量的SRS的一些特性。

完整:不应该遗漏要求和必需的信息。完整性也是一个需求应具备的。发现缺少的信息很难,因为根本不存在。在SRS中将需求以分层目录方式组织,将帮助评审人员理解功能性描述的结构,使他们很容易指出遗失的东西。

在需求抽象时,相对于系统功能,你过多的注意用户的业务,将导致在需求的全局观和引进不是真正必需的需求上显得不足。在需求抽象上,应用用例方法会发挥很好的作用。能够从不同角度察看需求的图形分析模型也可以检查出不完整性。

如果你知道已缺少一些信息,使用TBD(to be determined)标准标志可以突出这些缺陷,当你在构建产品的相关部分时,就可以从一个给定的需求集中解决所有的缺陷。

一致性:一致性需求就是不要于其他的软件需求或高级别的系统(商业)需求发生冲突。需求中的不一致必须在开发开始前得到解决。只有经过调研才能确定哪些是正确的。修改需求时一定要谨慎,如果只审定修改的部分,没有审定于修改相关的部分,就可能导致不一致性。

可修改性:当每个需求的要求修改了或维护其历史更改时,你必须能够审定SRS。也就是说每个需求必须相对于其他需求有其单独的标示和分开的说明,便于清晰的查阅。通过良好的组织可以使需求易于修改,如:将相关的需求分组,建立目录表,索引,以及前后参考(照)。

可追踪:你应能将一个软件与其原始材料相对应,如高级系统需求,用例,用户的提议等。也能够将软件需求与设计元素,源代码,用于构造实现和验证需求的测试相对应。可追踪的需求应该具有独立标示,细密和结构化的编写,不应过大,不应是叙述性的文字和公告式的列表。

需求质量的评审

这些有关需求质量的特性的描述在理论上都是非常好的,但一个好的需求到底是个什么样子的呢?为了体现得更切合实际,我们做个小练习。下面有几个从实际的工程选出的需求,依据上面的质量标准,评估每个需求,看看有什么问题,然后用更好的方式重写。我将对每个例子都提出自己的分析和改进的建议。也欢迎你提出不同的见解。我所占优的只是我知道每个需求的出处。因为你我都不是真正的客户,我们只能猜测每个需求的意图。

例1.“产品应在不少于每60秒的正常周期内提供状态信息”

这个需求是不完整的:状态信息是什么,如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分?状态信息间隔真的假定为不少于60秒?,甚者每10年显示一条新的状态信息也可以?也许它的意图是消息间隔不应超过60秒,那么1毫秒是不是太短?“每”这个词导致了不确定性。问题的后果,就是需求的不可证实。

弥补缺陷,重写需求的一种方法:

1、状态信息
2.1后台任务管理器因该以误差上下不超过10秒的60秒间隔,在用户界面的指定位置显示状态信息
3.2如果后台进程处理正常,那么应该显示任务已完成的百分数/比
4.3任务完成时,应显示相关的信息

后台任务出错应该显示错误信息

为了分别测试和追踪,我将其分成了多个需求。如果将几个需求串接在一节中,在构造和测试时就很容易漏掉一个。

例2.“产品应瞬间在显示和隐藏不可打印字符间切换”

计算机在瞬间不能做任何事,所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己?或者用户为了模仿更改要做一些动作?而且,在文档中改变显示的范围是多大:选中的文本,整个的文档,或其他的?这也是个模糊的问题。不可打印字符合隐藏字符一样吗?或者是一些属性标志或一些控制字符?问题的后果,就是需求的不可证实。

象这样编写需求也许更好一些:“用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换”。现在就很清楚,不可打印字符是HTML标记。由于没有定义触发条件,需求对设计没有约束力。只有设计人员选定了触发条件后,你才能编写测试验证触发的正确操作。

例3.“HTML分析器可以产生HTML标记错误报告,帮助HTML入门者快速解决错误”。单词“快速”使其模糊,没有加进错误报告的定义也是其部完整。我不知道,你怎么验证这个需求。找一个自称为HTML的入门者,看看能不能根据错误报告快速解决错误?

试试这个:“HTML分析器可以产生一个错误报告,错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误,就不会产生错误报告”。现在我们知道了,什么会被加到出错报告中,但是出错报告是个什么样子,则留由设计人员决定。我们还指定了一个例外:如果没有发现错误,不产生错误报告。

例4.“如果可能,主管号码应通过联机校验,而不是通过主全体主管号码列表校验”。真感到绝望,什么是“如果可能”:如果技术上可行?如果主全体主管号码列表可以联机获得?要避免象“应该”的这类不确切的词。客户是需要这个功能性还是不需要。我曾看过一些需求说明书,采用诸如:应,将,应该/将要等一些词描述优先级的细微差别。但我更喜欢用“应”清楚的说明需求的意图,指明优先级。这是修改后的:系统应校验输入的主管号码而不通过联机的主全体主官号码列表。如果在列表中没有发现主管号码,将会显示一条错误信息,也不接受指令。

在理解各个已完成的糟糕需求上,开发人员将会遇到的难题是:开发人员与客户将会在审核需求,未达成共识前发生激烈的争论。详细检查大的需求文档不是一件轻松的事情。我清楚有人做过,而且他们花在检查上的每一分钟都是值得的。相对于开发阶段和用户的抱怨电话,在这个阶段修补缺陷是便宜的。

编写质量需求的方针

编写优秀的需求是没有公式化的方法的。这需要大量的经验,要从你在过去的文档中发现的问题学习。请在组织软件需求文档时,严格遵从这些方针。

句子和段落要短。采用主动语气。使用正确的语法,拼写,标点。使用术语,要保持一致性,并在术语表或数据字典中定义它们

要看需求是否被有效的定义,可以以开发人员的观点看看。在内心将“当你们做完了找我”这句加到文档尾部,看看能不能是你紧张起来。换句话说,你是否需要SRS的编写者的额外解释帮助开发人员很好的理解需求,以便于设计和实现?如果是的话,在继续工作前,需求还需要细化。

需求编写者还要努力正确地把握细化程度。要避免包含多个需求的长的叙述段落。有帮助的提示是编写独立的可测试的需求。如果你认为一小部分测试可以验证一个需求的正确,那么它已经正确的细化了。如果你预想到多种不同类的测试,几个需求可能已挤到了一起,需要拆分开。

密切关注多个需求合成了单个需求。一个需求中的连接词“和”/“或”建议几个需求合并。不要在一个需求中使用“和”/“或”。

通篇文档细节上要保持一致。我曾看见过多个需求说明书前后不一致。如:“对于红色合法的颜色代码应是R”及“对于绿色合法的颜色代码应是G”就有可以以分散的需求分离开,而“产品应能对来自语音编辑指示做出反应”应作为一个子系统,不应作为单个的功能性需求。

避免在SRS中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读,但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新,避免不一致性。

如果你遵从了这些方针,你能够尽早地经常正式或非正式的审查需求,这些需求对于产品的构造,系统测试以及最后的客户满意,都会成为好的奠基石。并且要记住,没有高质量的需求,软件就象一盒巧克力,你永远不知道你会得到什么。

转自:
"http://blog.ourhtml.com/?action=show&id=259&page=1":http://blog.ourhtml.com/?action=show&id=259&page=1

多看多学习,任何时候,产品经理都应该比其他人想得更多,真的是很难,而且文档只是产品开始的第一步,剩下的实施将更为困难。一个足够复杂的文档自然有好处,在实际运行中可以做减法,这非常容易,如果要做加法则会比较困难,需求增加更容易影响到产品的最终逻辑,何况,交给技术人员的文档越明白越好,如果你足够剽悍,甚至可以精确到代码层面。这里不是说让技术人员纯粹的垒代码,而是尽量把技术人员的精力集中到解决程序难点上,避免多余的思考,当技术人员询问你:“这个东西到底怎么是什么?”的时候,就说明产品经理的工作还是有不足之处的。

一个清晰的思维方式有利于产生一个优秀的产品,最近有一点思索,记录下来。

从开始说起,一个完整的产品,如同一篇文章,也要回答这样几个问题:Who、When、Why、What、Where、 How,这里还应该加上How much,也就是所谓5W2H原则。

Who:回答面向什么样的用户、项目由何人负责、设计由谁出任、运维由谁负责、反馈由谁处理等等。
When:回答项目的生命周期,包括开始时间、时间跨度、测试时间、上线时间等等。
Why:回答项目目标、产品设计原则等。
What:回答产品内涵、属性、功能等。
How:回答产品实现方式。
How much:回答产品消耗资源。

产品工作很复杂,想面面俱到是很困难的,个人认为要经历一个从繁到简的过程。
繁:分解以上的5W2H,越详细越好,可以按结构分、按功能分、按时间分、按人分。
简:整个产品项目只需要按一种方式分解,从头到尾,保持思维的一致性。

有两个原则是一定要注意到的:
1、信息流的双向性,通过跟踪信息流,可以完整了解产品的各属性。“刺激-反馈”是信息流的基本运动,无论是在产品设计过程中还是产品运行的过程中,信息的一来一回,才是平衡的。
2、时间流的单向性,时间成本越小越好,因为时间不能循环。

职能错位应该分为两种,一种是管多了,一种是管少了。现实里,总有一些组织或人,该管的不管,不该管的瞎管,无利益的不管,有利益的争着管,这种怎么算呢?个人觉得,应该算犯贱!

组织职能的具体实施者是人,人员的素质是保证职能不错位的关键。以一个职位为例,它应该是职能、职权、职责三位一体的,在组织的职位说明书中给予明确规定。同样,一个组织也是职能、职权、职责的统一,在法制的大框架下,组织的活动是受到限制的,趋小,未在法律中明文规定的行为,都是禁止组织实施的。可是组织里的人员是否理解和遵守这些规则?

在现实中,组织有自我膨胀的趋势,尤其是掌握公共资源的组织,更倾向于掌握更多的资源,形成更大的影响力,因此,跨职能、跨职权、轻职责的行为就出现了,一些组织和个人无知及无畏的丑恶闹剧一再上演。

将个体放大到城市这样的级别,城市也可以视为有职能、职权、职责这样属性,将过多的功能集中到一个城市,会造成大城市病,一定区域里的多个城市也会形成金字塔结构,公共资源向上聚集,大城市获取到更多资源,只能在事实上强化城乡二元结构,尤其当金字塔顶端的城市不具备与其地位相配的经济能力时,矛盾尤其明显。不过在韩国,有一个有趣的例子,汉城(首尔,YY无限的韩国人,将文化洁癖表现得淋漓尽致,国内也有一些自称是学者的人就像他们一样。)地区聚集着韩国大部分的人口,但是这一地区也产出了相对应比例的GDP。

我从来不认为在一个区域强化一个城市的地位是一个好主意,城市崛起并不意味着地区崛起,当一个城市从所在区域脱颖而出时,也就宣示了周边地位为此做出了重大牺牲。在物质水平并不是那么丰富的时候,二次分配以公平为主的原则只应强化,资源的转移本身也要消耗大量资源,如果这种转移不能带来公平与和谐,就是得不偿失。从形式上看,这就是一种城市的职能错位。在经济新兴区和其他欠发达地区的重要城市,不能盲目COPY某些历史上形成的核心城市,安分一点,先从完成自己的城市职能开始,不要想什么资源都集中在自己这里。

电影《功夫》里有句话:能力越大、责任越大。错位职能的组织和个人,你担得起职责吗?