标签 产品 下的文章

企业在运作过程中,会产生各种各样的数据,这些数据通常以电子文件的方式保存在企业服务器上,能够反映企业运行各个层面的真实情况,因此,企业管理者越来越重视企业数据的安全问题。
一般来说,保护企业数据安全是从这样几个方面入手:一是保障数据不被损毁,包括由数据存储器物理损坏造成的硬性损毁和由软件故障或人为失误等造成的软性损毁,这实际上是一个数据有和无的问题;二是防止数据泄露,包括由外而内(通常由入侵造成)无授权的信息访问和由内而外,企业数据的非正常外流,这实际上是一个敌与我的问题;三是确保企业数据的实际价值,包括数据的真实性、及时性、针对性等等,这实际上是一个对与错的问题。
前两个方面由于多年来一直被各界强调,已经成为企业信息安全首要考虑的问题。随着近年来企业对自身数据处理及挖掘的能力不断提高,使企业的信息管理者们把更多目光投到保证企业数据实际价值的领域中来。

企业数据实际价值影响企业数据安全
企业投入大量资源,对企业数据进行分析,将分析的结果作为企业决策的主要参考依据,而不真实、不及时、不满足决策需要的数据可以视为企业数据中的“假冒伪劣”产品,属于不安全数据,基于这样的数据得出的结论,很难保证正确性。对一家企业而言,错误的信息无异于致命的毒药。在现实情况中,企业数据里必然存在一些不安全数据,要确保数据分析的正确性,就要把不安全数据占全部数据的比例减少到可接受的范围里,最大限度降低不安全数据对企业数据价值的稀释作用。

二、不安全数据产生的原因
根据不安全数据在企业数据分析中的影响,可以分为两种类型:
错误数据。这是一部分与真实情况不符合的数据,产生的原因主要有数据源错误、采集方式错误、输入错误、存储错误、输出错误等等。
垃圾数据。这部分数据虽然符合真实情况,但是不能满足分析的需要,产生的原因主要有数据兼容性差、采集不及时、数据冗余等等。如果在分析数据时提出了新的需求,这部分数据有可能“变废为宝”,为企业服务。

消除不安全数据的方法
不安全数据产生的原因很多,但是企业数据处理的过程基本是一致的,可以表述为这样的顺序:产生、选择、采集、输入、存储、分析、输出。从这个过程看,保证信息在过程中的准确快速流动,是消除不安全数据的关键,这就要求企业数据必须规范化。

数据规范化主要包括以下几个方面:
1、数据元素标准化
数据元素是数据处理的最小单位,数据元素标准化是数据规范化的基础。这里需要在企业数据库建立之前对数据进行分解,例如,企业要建立一个产品销售数据库,将这个数据库分解,就可以得到一个客户数据表;将客户数据表分解,就得到客户名称、性别、电话、地区、所属企业、职位、信用评级等等基本元素,这些元素就是构建起企业数据库的基础。
数据元素标准化需要一个规范说明表,用来规定数据元素的命名方式,规定其内涵及外延,阐述数据元素的作用及表现方式等等。规范说明表就是企业数据的“职位说明书”,能够减少数据元素的种类,降低企业数据的复杂性和出错概率。
2、数据库结构标准化
如果说数据元素是货物,那么数据库就是存储货物的柜子,而数据库结构标准化就是定义数据库,个柜子里抽屉的布局。数据库结构直接影响到企业数据的权限管理、数据库的兼容性与性能、数据管理及再挖掘的便利性等等。
数据库结构的标准化带来的直接好处就是企业数据库性能提高,增强数据库的可靠性,减少出错时间,这样就极大减少了冗余数据。;另一方面,结构良好的数据库兼容性好,容易迁移和升级,在改造数据库或关联其他数据库时的优势尤为明显。
3、数据存储标准化。
在企业数据电子化趋势加快的今天,企业数据存储除要求分类标准化外,还具有了一些新的要求:
编码标准化。电子数据信息都用一定的编码格式保存,常见的有GB2312、UTF-8、BIG5、ISO-8859-1等等,在实际的使用中,可以根据企业数据的阅读对象决定使用编码。例如,如果企业数据的阅读者有中文用户、英文用户、日文用户还有其他语言用户时,推荐使用UTF-8,该编码在各种操作系统中都可以正常显示;如果数据阅读者只有中文用户,可以采用GB2312,降低数据的存储空间。
存储格式标准化。企业数据的电子信息一般有特定的软件产生,这些软件又具有自身特定的格式,如微软的Office系列产生的格式有doc、xls、ppt等等。由特定软件产生的电子文件要求阅读者安装有相应的软件,对于未安装该软件的用户是一种阅读障碍,使有用的信息变成了垃圾数据。因此,存储格式的标准化应尽量采用常见和费用较低的格式。
存储标准化还包括存储设备标准化、存储平台标准化等等,目的都是为了达到一处存储,到处可读的效果。
4、输入输出标准化
数据的输入输出标准化是为了保证数据的可读性,两者在一定程度上相似,需要遵循以下原则:
最简化原则,尽可能减少数据的输入输出量和步骤。
步步校验原则,在每一个步骤都加入校验过程,降低出错可能性,宝马汽车生产线就是步步校验原则的最好案例。
稳定原则,这里的稳定是指设备和人员。

一. 概述

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

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

其次,何谓“新产品开发项目”。简单而言,在本文中,新产品开发指开发团队需要从无到有将一个想法(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

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

Facebook很简单,所以上手容易。51.com的功能简直可以用弱智来形容,但是,就是那些上世纪九十年代的网页美化效果,网站的主要用户们乐此不疲,甘愿献上流量和金钱。

简与繁,是一个相对用户群而言的,任何一个网站,都有自己定位的受众,在互联网草创的年代里,面向最广大的用户群是必要的。举个简单的例子,在Google等互联网搜索巨头越来越强大的今天,还是有很多中小型的团队进入到搜索的市场中,只要获得哪怕1%的份额,就是十几亿或者几十亿美元的巨大市场,同样的,门槛低的网站面对的就是最广大的用户群,再烧上一笔钱,或多或少都能获得相当一部分用户。这时候,能不能活下去,比较的主要是两个能力,一是融资能力,继续获得投资者的亲睐,就能继续烧钱,直到竞争对手死掉;二是内部管理能力,降低内部消耗,依靠现有的市场份额养活团队,继续奋斗。简言之就是开源节流。当市场上出现了多个实力相当的服务商,那么,粗放型的发展模式就难以分出胜负,单纯依靠资金投入不足以开垦新的用户群,服务细化的时代就到来了。如果是粗放型发展阶段是摸索阶段,那么这一阶段的网站功能必然是简单的。进入服务细化时代之后,网站的目标变成了深耕细分市场,提高用户的忠诚度。假如是一个依赖广告费生存的网站,在这个时候最直接的表现就是开始投放有针对性的广告。举例而言,现在有一个汽车主题的网站开始展示某一款车型的广告这样的一个结果,我们可以推测它的原因:这个网站的用户群有购买汽车的意愿,也就是用户纯度高,投放广告就有了更多售出汽车的可能性。为了达到这个效果,最基础的办法就是为各种细分市场提供对应的产品,这就要求在内容上要有深度,还要满足小众用户特殊的功能需求,此时的网站功能必然是复杂的。

事物的发展是螺旋式的,Google的一系列产品展现了简洁的魅力,将复杂的处理交给程序,呈现给用户的用户最需要的部分,这是需要相当长时间分析用户需求才能得到的。可以拿桌面操作系统说事儿,现在Linux系统的图形界面已经非常好了,甚至比Windows还要好,但是,不能忘记的是:Apple和Windows都在调查用户需求方面消耗了巨大的资源,不只是报错时的声音、图标的大小、功能块的布局还是字体的选择,就连微软的经典蓝屏都是经过选择的,可以说,KDE和GNOME的设计者们在方面获益匪浅(当然KDE和GNOME开发团队或者说所有的开源团队在这方面做得的贡献一点要不少),Windows操作简单(说到简单,Leopard的概念可能更简单),并不意味着Windows背后的技术就简单。回过头来,Facebook很简单,并意味着Facebook的技术不行,相反,它的技术很好!

是什么样的内部矛盾推动了简->繁->简这样的发展呢?答案只有一个:人的需求

(本文是为了写而写的,没有逻辑性,看过之后笑笑以上废话就行了,哈哈哈哈哈哈哈哈哈哈哈哈哈~)

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

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

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

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

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

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

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

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

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

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

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