如何才能写出好的产品文档？

VUCA一词起源于上世纪90年代的美国军方，是Volatility（易变性）、Uncertainty（不确定性）、Complexity（复杂性）、Ambiguity（模糊性）的首字母缩写。VUCA概括了后互联网时代的世界特征——复杂多变。我们所处的世界变化越来越快，知识边界不断被突破，项目管理也不例外。

传统的项目管理虽然认识到项目具有渐进明细的特点，但在计划、执行、监控过程中还是明显强调瀑布特点：制定计划前要“清晰、完备、准确地界定项目的工作范围(SOW)，作为整个项目工作的基础”，然后是“分解出足够详细的工作步骤(WBS)”， 把WBS作为整个项目计划、执行、监控的核心。虽然传统的项目管理中也提到滚动计划，但还是以稳定为基调，把适应变化作为辅助，而VUCA时代恰恰是以变化为最大特点，传统的项目管理方法很难适应这个前提，从而使得计划赶不上变化，项目计划往往成为一纸空文。

传统的项目执行出现问题，多归因为项目工作范围界定不够准确、项目计划不够详尽。应对的策略也很粗暴：一方面是在合同谈判的时候尽量界定清楚、不含糊其辞；另一方面在合同执行的时候，据理力争，合同约定之外的尽量拒绝。

由于各种原因，合同约定一般很难满足SMART原则，“聪明的”乙方则会跟客户约定以“签字后的需求规格说明书”作为验收依据。这样“需求规格说明书”就成了双方的“必争之地”。在项目费用、执行周期固定的情况下，甲方项目经理自然希望乙方能提供更多的、更高品质的功能，至少可以更好地向领导交差；乙方项目经理则希望能以最小的资源投入、冒最少的风险、尽快交付，能拿到更多的项目奖金。

在“合同谈判”胜过“合作共赢”的情况下，乙方项目团队虽然在需求调研上投入大量的精力，但客户不愿配合、拒不签字的场景时有可见，更有甚者乙方会设计晦涩的需求文档、复杂的变更流程，甚至应用了多种心理效应，就是为了约束客户不要再变了。

对于第一种变更，乙方需求分析人员如果有丰富的领域知识与实 *** 经验，能设身处地地分析，大多能够避免。但由于人的思维定势及碎片化倾向，一次很难考虑周全，难免会有遗漏，譬如酒店管理系统中的入住功能，“团队入住希望能住到相邻房间”这样的约束，可能事先很难想到，只有在系统投入使用后才能发现这个不便。为避免这类变更，传统的做法是加大需求捕获与分析的力度，这容易事倍功半，也容易造成“过度工程”的问题。

对于第二种变更，传统的项目管理中一般归到风险范畴，譬如甲方换了领导或项目负责人，组织结构调整，外部环境发生重大变化、设备不到位等等，这些都是风险，都会给项目工作范围带来变化。传统的应对策略是识别、分析、跟踪、应对风险，增加缓冲资源与时间。但风险的概率特性，为管理层提供了侥幸的借口，风险缓冲很容易被上级砍掉，风险被直接转嫁给员工，通过员工的加班加点来弥补。

第三类变更，不是由于问题变了，而是解决问题的方式变了。在汽车没被发明的年代，客户希望更早到达目的地，只会想要一辆更快的马车，而福特却造出了汽车。同样的问题不同的解决方案，效果自然不一样，项目工作范围也会截然不同。

VUCA时代，复杂与变化已经成为主旋律。在这个强调以客户为中心，强调为客户带来价值的时代，项目还要因循计划、不拥抱变化，一方面确实不易做到，另一方面也一定会损害客户关系。

VUCA时代的IT项目管理该如何开展呢？

问题一：业务需求，用户需求，功能需求是什么意思？有什么区别 我们的软件产品或者项目，其需求都有三个层级和三个方面。一、我们首先看需求的三个层次软件需求包括3个不同的层次DD业务需求、用户需求和功能需求。业务需求 （Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业 务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。用户需求 （user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件DD响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。功能需求 （functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求 （behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什 么。注意：用户需求不总是被转变成功能需求。产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标 得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用 户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。系统需求 （system requirement）用于描述包含有多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。业务规则 包 括企业方针、 条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁 能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能 需求进行追溯时，会发现其来源正是一条特定的业务规则。功能需求记录在软件需求规格说明（SRS）中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库 或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试 、质量保证、项目管理和其他 相关的项目功能都要用到 SRS。除此之外，对于需求层次，我们还有其它的分法：组织级需求->业务需求->用户需求->功能需求（有时也叫行为需求）。组织级需求： 一 般代表着组织的愿景和目标。对于大的公司，一般是通过资深的咨询顾问和咨询公司得出的，呈现的方式是咨询报告。比如在ITSM或者企业信息化这方面。典型 的组织级的需求是：降低成本、减少库存成本、提升IT服务部门在企业中的价值、通过ISO20000、提高IT服务的效率、提高员工的满意度等。业务需求： 是要完组织的使命，达成组织的愿景的各个业务流程和业务单元具有的需求。业务需求服从于组织需求。用户需求： 用户级的需求，是在业务级的需求下，各个岗>>

问题二：用户需求说明是做什么用的 需求是客户向你提出想要的软件是什么样儿的，例如具备什么样儿的功能。手册指的是使用软件的 *** 作方法。这两个的对象是不同的。

用户需求说明是客户提出来的需求，编写好，给开发人员看的，根据需求说明来编写软件（在这里，有的是客户公司自己完成的也有的是软件开发公司人员完成的）。用户手册是开发完成软件之后，开发人员根据软件的使用流程写出来的软件使用说明，这样客户就可以按照手册来使用软件。

问题三：业务需求，用户需求，功能需求是什么意思？有什么区别 软件工程中包含需求、设计、编码和测试四个阶段,其中需求工程是软件工程第一个也是很重要的一个阶段，需求分析是要决定“做什么，不做什么”。在一个软件项目中，软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求:业务需说明了提供给客户和产品开发商的新系统的最初利益,反映了组织机构或客户对系统、产品高层次的目标要求。软件开发，能否获得成功，最重要的是需求分析的工作。因此，软件需求分析能力和水平，对软件项目至关重要。一般的分析方法和步骤如下：⑴首先调查组织机构情况 包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。 ⑵然后调查各部门的业务活动情况 包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。 ⑶协助用户明确对新系统的各种要求 包括信息要求、处理要求、完全性与完整性要求。 ⑷确定新系统的边界 确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。 常用的调查方法有： ⑴跟班作业 通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较耗费时间。 ⑵开调查会 通过与用户座谈来了解业务活动情况及用户需求。座谈时，参加者之间可以相互启发。⑶请专人介绍。 ⑷询问 对某些调查中的问题，可以找专人询问。 ⑸设计调查表请用户填写 如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。 ⑹查阅记录 即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。 通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。

问题四：什么是业务需求和用户需求 业务需求针对是公司，描述是公司想如何解决用户的问题，如何满足用户的欲望，并将利益最大化。重点是在后面，追求商业可行性与利益最大化。

用户需求针对的是人，描述的是用户想做某件事情所遇到的问题，或所想满足的欲望；

问题五：如何进行用户需求分析 1概念

需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求

关键的问题是一定要编写需求文档我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起系统的分析人员说:我们想与你谈谈你的需求客户的第一反应便是:我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统

百事通

而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人

需求的另外一种定义认为需求是用户所需要的并能触发一个程序或系统开发工作的说明有些需求分析专家拓展了这个概念:从系统外部能发现系统所具有的满足于用户的特点、功能及属性等这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的而下面的定义则从用户需要进一步转移到了系统特性:

需求是指明必须实现什么的规格说明它描述了系统的行为、特性或属性,是在开发过程中对系统的约束

从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的需求术语存在,真正的需求实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识

任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述

2需求分析的任务

开发软件系统最为困难的部分就是准确说明开发什么最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难

目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题

对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢

然而,即便并非出于商业目的的软件需求也是必须的例如库、组件和工具这些供开发小组内部使用的软件当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生

近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能结果这个小组只好手工抄写源代码文档以供代码检查这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了

相反的情况,我曾见一个要集成到错误跟踪系统中的简单界面写了一页需求说明而 *** 作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误

事实上,需求文档在开发过程中一直起指导作用

3需求分析过程

可把整个软件需求工程>>

问题六：什么是客户需求 客户需求：

客户的需求往往是多方面的、不确定的，需要去分析和引导。客户的需求是指通过买卖双方的长期沟通，对客户购买产品的欲望、用途、功能、款式进行逐步发掘，将客户心里模糊的认识以精确的方式描述并展示出来的过程。

暗示需求和明确需求

暗示需求就是客户对难点、困难、不满的陈述，明确需求就是客户对难点、困难、不满的具体陈述。

研究客户需求：

1，首先要圈定明确的客户群

只有明确的客户群

才能让我们很好去研究

2，学会用客户的语言来描绘产品

3，学会理解客户的多重身份

4，了解客户的价值观

5，理解客户需求背后的深层次心理需求

6，像客户一样体验，像客户一样感知他们的生活世界

1）像客户一样看（用客户看产品一样的心态来看待产品）

2）像客户一样用（把自己变成一个没有使用过产品的人、然后来看待这个产品的好和坏、使用方法的简易性、然后记录下来使用产品的感觉和效率）

3）像客户一样想（站在客户的角度来看待你的的产品、如果你是客户你会给你自己的产品打多少分）

去体验客户的生活世界，而不是客观世界。只有这样，才能像有经验的销售那样，能见到什么人说什么话。

问题七：什么是用户角色需求 界面需求分析必须围绕用户为中心，不同于客观功能需求分析，具有很大的主观性。虽然，界面设计人员可以按照通行的原则来设计，但是用户个体的文化背景、知识水平、个人喜好等是千差百异的，其界面需求也是相差很大。不同的用户，对软件界面有不同的要求，表达自己要求的方式也尽不相同。而且用户的界面要求通常不象业务功能需求那样容易明确、有据可查、可以利用专门工具进订分析。多数用户往往并不能提出明确的、全局的界面需求，其需求同自身主观因素联系紧密，是模糊、变化的。调查用户的界面需求，必须先从调查用户自身特征开始，将不同特征用户群体的要求进行综合处理，再有针对性地分析其界面需求。因此这里引出用户角色这个概念模型。

用户角色是指按照一定参考体系划分的用户类型，是能够代表某种用户特征、便于统一描述的众多用户个体的 。用户调查的目标是通过调查分析用户特征，将每个不能建立模型的单一用户归纳为 ，将用户 定义为角色模型，同时赋予不同的优先级别，了解记录其界面需求。用户的需求调查和其特征调查即用户角色定义，往往同时进行。调查的方法有很多种，如直接交流、资料统计、表格调查等。用户角色定义的原则是有代表性、同系统功能有关并有利界面的需求分析。一个用户角色可能包括大量的用户个体，他们对于界面的要求可以按照一定的界面模型进行定义。在一个软件系统中，用户角色定义时所依据体系可以多种多样，一个单一用户可以属于不同参考体系下的不同用户角色，但是一个用户角色要求能够代表一种界面需求类型。如收银员就是按照用户工作职位划分出来一个用户角色，如果按照 *** 作计算机的熟练程度，属于收银员角色中的系统用户又可以分为：熟练用户、生疏用户。

问题八：微信要满足的用户需求（或者说用户价值）是什么？ 想来想去，最后看到了张小龙说的这句话，我觉得可以作为一个精辟的总结了：QQ满足了用户同步通讯的需求，微博满足了异步通讯的需求，微信则提供较大的d性，让用户更加从容地按自己的意愿管理社交关系和人际沟通。

一般来说，产品文档分为产品需求文档和产品使用文档两种。产品需求文档主要面向的是产品的开发、设计者，期望是产品的实际开发人员了解产品的细节，让开发完成的产品达到前期设计需求的预期；产品使用文档面向的主要是使用者，使其通过产品文档掌握产品的功能使用，也就是我们常说的产品使用帮助；如果不搞清楚文档面向的对象，往往写出来达不到预想的效果。类似这样专业的文档文案，其实是有一定共通性的；掌握这类文案的写作技巧，尤其对我们IT从业人员来说，是一项非常不错的技能。笔者从业这两年，跟此类文档打过不少交道，在这里跟各位分享一些经验。

1、对象要清楚

开篇就提到了，清楚文档面向的对象的重要性。对于不同的对象，必须使用不同的写作思路来对待，尽可能的站在对方的角度去思考。他需要看到什么？什么内容对他有用？我如何阐述给他？对于产品设计人员，他所需要了解的是产品的样式、界面、交互等情况，对于实际编码人员，他则偏重于产品的可实现性，你的内容则需要偏注产品的功能细节和内部处理。所以，文档面向的对象决定了文档的功能和内容。确定文档面向的对象才能做到有的放矢。

2、条理要清晰

文档的条理清晰不仅让你的文档看起来比较顺畅，更让阅读者能够很清楚的理解。所以，下笔之前就应当知道自己的文档内容大致分为哪几个大的模块、模块下又细分了多少个子模块，然后在大纲的基础上，再进行详细的内容填充。笔者之前的经验，往往在文档下笔之前认真思考了好几天，总希望在下笔之前就希望把所有的问题都想清楚。这对于写作者来说，是一件不好的举动。其实，东西在脑子里转悠，不如在纸上来的直观。大纲列出来之后，然后再来反复的添加、修改，比你按笔不动要来的有效率得多。对于写作来说，最难的也是开始。

3、逻辑要严谨

产品类的文档不同于平常我们书写的文档类型。对于内容叙述的严谨性要求非常严格。因为你的文档不单单是一个你对这个项目、产品的理解，它更是需要做为一个协作的载体让其他的同事同时使用，更可能成为其他同事工作方向的指引。因此，严谨是必须的。所以，在满足了文档条理清楚的前提下，仔细斟酌、思考文档可能会出现歧义、漏缺的部分，反复修改文档成为了一项必须的工作。在大家协调工作的背景下，你一个人不可能将所有的问题都考虑清楚。所以往往出现同事指出你文档中存在的毛病和漏洞。但是你还是应当在前期多做一些考虑，将问题尽量减少。

4、用词要专业

专业的用词不当可以帮助你提升文档的专业度，更可以帮助你提升效率，减少重复和不必要的沟通成本。既然是行业那就需要行业标准，使用专业的行业术语是一种职业化的表现，这样既可以很快和同事达成共识，又让别人觉得你很专业。我想，同事之前这样的协作才是有效率的。当然，对于新手来说，如何掌握专业的用词，这就需要平时多看多读了。多了解小众的博客，多认识一些前辈和朋友，无论是对写作还是对工作的认识，都是很有帮助的。

5、格式要规范

对于一个IT行业从业人员来讲，规范化、流程化的工作模式是非常重要的。对于需要经他人手的文档、或者需要进行存档的文档来说，格式的规范与否是一个衡量你专业化程度高低的重要衡量标准。当然，说到这个规范，你在第一次写作之前就应该了解这个规范是一个什么样的规范。是行业规范？还是公司内部的规范？这取决于你所在公司或所从事项目的情况。对于大公司，你所要做的就是找之前前辈们写过的同类文档进行拜读，了解这些规范。对于小公司或者新创的项目，之前没有过同类产品文档的情况。你所要做的就是沿用标准规范再加上项目特点，尽可能细致的书写。相信，经过你的努力的，你写的文档将会成为该类文档的案例，成为规范。

其实无论是产品需求文档（PRD）、产品策划书还是商业计划书，其实都是需要我们下功夫仔细研究的。毕竟中国互联网发展才十几年，很多细节都还不是很专业。对于一个会思考的互联网人，武装自己的头脑，丰富自己的技能才能找到更好的职业发展。

亲，为你核查到的答案是:您好，IT行业写文档最多的岗位有：

1、软件开发工程师：负责编写软件开发文档，包括软件需求分析文档、软件设计文档、软件测试文档等；

2、系统分析师：负责编写系统分析文档，包括系统分析报告、系统设计文档、系统测试文档等；

3、IT技术支持工程师：负责编写IT技术支持文档，包括系统安装文档、系统维护文档、系统升级文档等；

4、网络管理员：负责编写网络管理文档，包括网络设计文档、网络安全文档、网络维护文档等；

5、数据库管理员：负责编写数据库管理文档，包括数据库设计文档、数据库安全文档、数据库维护文档等。

以上就是IT行业写文档最多的岗位。

项目管理系统，就是项目的管理者应用专门管理项目的系统软件，在有限的资源约束下，运用系统的观点、方法和理论，对项目涉及的全部工作进行有效地管理。它从项目的投资决策开始到项目结束的全过程进行计划、组织、指挥、协调、控制和评价，以实现项目的目标。

按照传统的做法，当企业设定了一个项目后，参与这个项目的至少会有好几个部门，包括财务部门、市场部门、行政部门等等，而不同部门在运作项目过程中不可避免地会产生摩擦，须进行协调，而这些无疑会增加项目的成本，影响项目实施的效率。

而项目管理的做法则不同。不同职能部门的成员因为某一个项目而组成团队，项目经理则是项目团队的领导者，他们所肩负的责任就是领导他的团队准时、优质地完成全部工作，在不超出预算的情况下实现项目目标。项目的管理者不仅仅是项目执行者，他参与项目的需求确定、项目选择、计划直至收尾的全过程，并在时间、成本、质量、风险、合同、采购、人力资源等各个方面对项目进行全方位的管理，因此项目管理可以帮助企业处理需要跨领域解决的复杂问题，并实现更高的运营效率。

项目管理系统的应用从80年代仅限于建筑、国防、航天等行业迅速发展到今天的计算机、电子通讯、金融业甚至政府机关等众多领域。目前国内，对项目管理认识正逐渐深入，但要求项目管理人员拥有相应资格认证的还主要为大的跨国公司、IT公司等与国际接轨的企业。

项目管理系统是基于现代管理学基础之上的一种新兴的管理学科，它把企业管理中的财务控制、人才资源管理、风险控制、质量管理、信息技术管理（沟通管理）、采购管理等有效的进行整合，以达到高效、高质、低成本的完成企业内部各项工作或项目的目的。

随着IT行业的发展，IT行业内的项目拓展和投资比比皆是。为了提高项目管理水平，赢得市场竞争，特别是在加入WTO后在国内、国际市场上拥有与国际接轨的项目管理人才，越来越多的业界人士正通过不同的方式参加项目管理培训并力争获得世界上最权威的职业项目经理（PMP）资格认证。

技术评估报告模板

技术评估报告模板。评估报告是为了合理地评价项目目标成本的执行情况,总结成本管理工作的得失,为后续项目的成本测算和作业管理提供参照依据，下面是技术评估报告模板。

技术评估报告模板1

第一章 总 论

一、项目提要

1、项目名称：内蒙古鄂前旗毛盖图小尾寒羊良种繁育工程建设

2、建设性质：新建

3、项目建设单位：鄂托克前旗毛盖图苏木 法人代表：林霞

4、建设地点：内蒙古鄂前旗毛盖图苏木

5、项目申报单位：内蒙古鄂前旗扶贫开发办 法人代表：贺西格道格陶呼

6、投资规模及构成：总投资40万元，其中购买种畜38万元，其它费用2万元。

7、资金筹措：项目总投资40万元，其中财政扶贫资金30万元，群众自筹10万元。

8、项目辐射范围及带动能力 项目建成之后，将直接带动毛盖图苏木150户农牧户，可使毛盖图苏木牲畜良种率和单位产量得到进一步提高，通过良繁体系的建设，畜种质量的改善，销售利润大幅度增长，可使项目区农牧户人均纯收入增加500—800元。

二、可行性研究的依据

1、财政部农业综合开发办《农业综合开发多种经营项目可研报告编制提纲》；

2、农业部《西部地区农业开发建设规划》；

3、国家计委、建设部《建设项目经济评价方法与参数》；

4、鄂前旗“十五”经济建设规划；

5、鄂尔多斯市《建立畜牧业强市、绿色大市的决定》。

三、综合评价和论证结论

1、综合评价 本项目建设对于该地区牲畜良种繁育体系建设具有示范带动作用。对于探索在生态建设的基础上发展优质畜牧业，从而实现生态经济和社会可持续发展具有重要意义。项目区具有良好的饲养基础，当地农牧户饲养经验丰富，经过培训，完全可以按照先进的技术规程生产建设，鄂前旗有着广阔的草原资源和庞大的牲畜养殖阵地，鄂前旗畜产品清真市场已开始投入运营，

已具有很好基础，由于清真市场产品以无污染和高质量而拥有了较高的信誉，对项目产品的销售极为有利。目前市尝产品已与宁夏有长期销售合同。整个项目技术先进，经济合理，相比传统牲畜饲养方式，可极大地减轻对草地资源的利用强度，提高牲畜整体质量，提高资源转化效率，因此我们认为项目可行。

技术评估报告模板2

一、工程概况及特征

（一）工程概况

本工程位于永嘉县江北街道码道村，南面为阳光大道，北面为码道南路。总建筑面积为26507、26m2，地下室建筑面积3855、93㎡，地上建筑面积22651、33㎡,由1幢16层办公楼、1幢4层商业裙房和大底盘地下车库组成的商业办公区。办公楼为地下1层，地上16层，属框架剪力墙结构，建筑高度为78m，地下室一层层高4、97m，地上16层，一层层高5、4m，

二层至四层层高5、2m，五层至十五层层高均为4米，十六层及大屋面层高为4、08m、4、2m；商业裙房为地下1层，地上4层；为框架结构。地下室一层层高4、97米，地上一层层高为5、4米，二层至四层层高均为5、2米。

办公楼剪力墙框架的抗震等级均为三级；商业裙房框架的抗震等级为四级；纯地下车库抗震等级采用四级。地震基本烈度为6度。±0、000相对于绝对标高4、700m。

混凝土强度：主体柱墙1至4层C40、二至五层梁板C30，其他零星构件C25。

砌体工程：±0、000以上一至四层内外墙采用A5、0蒸压加气砌块，Mb5专用砌筑砂浆砌筑

建设单位：

设计单位：

勘察单位：

监理单位：

施工单位：

质监单位：

施工许可证编号：

二、主体结构施工过程简述

本工程于20XX年X月X日～20XX年X月X日完成主体1～4层混凝土结构；

20XX年X月X日～20XX年X月X日完成主体1～4层填充墙砌体；期间混凝土留置C40混凝土试块18组、C30混凝土试块共25组，按规范要求评定合格（评定表附后）。

砌体结构共留置M7、5水泥砂浆2组，MB5专用砂浆4组，按规范要求评定合格。

给排水工程

给水主管采用钢塑管，丝扣连接，给水支管采用PP–R管，热溶连接，消防、喷淋管DN≥100的管采用沟槽连接，DN100以下采用丝扣连接，所有穿楼板管路均按设计要求预留。

电气工程

电线导管户内采用PVC管，消电、应急照明采用镀锌钢管，及时的做好隐验记录，同时经建设单位、监理单位和公司工程质检人员等有关部门现场验收。

三、质量监理控制情况

监理部根据《委托监理合同》、《建筑工程施工合同》、施工图设计、相关规范和法律法规以及本工程特点及时编制《监理规划》和详细的《监理细则》，在业主单位授权下严格按照监理工作程序及工作制度进行工程监理，在建设单位、质监站等单位大力支持和施工单位的积极配合下，顺利完成了主楼一层至五层结构的监理工作任务。

（一）监理工作统计

（二）施工准备阶段监理工作：根据施工合同及委托监理合同对该工程承包商现场管理人员及特殊作业人员资格进行审查，并对施工单位编制的施工组织设计和专项施工方案进行审批，要求施工单位严格按照已审批的施工组织设计和专项方案施工。严格工序报验制度，上道工序不合格，不得进行下道工序施工；

（三）见证取样：

1、监理部严把工程材料质量关，对进场原材料及构配件，监理部认真核查出厂合格证明文件，在施工单位自检合格的基础上进行外观检查。并按规范规定进行见证取样检测，在检测合格并完成材料报验程序后，方可用于工程施工。

2、对钢筋焊接、试块制作等严格按照规范要求进行见证取样、送检。

（四）旁站监理：根据《监理规范》、《国家旁站监理规定》和《浙江省建设工程监理管理条例》规定，对桩基工程、土方开挖及回填过程、砼浇筑及梁柱节点隐蔽等关键部位及工序的施工过程实行旁站监理，确保分项工程施工质量，预防质量通病的存在。对施工存在的问题及质量缺陷进行跟踪旁站，确保隐蔽前不留隐患。

（五）平行检验制度：监理部对施工单位申报的检验批、分项及隐蔽工程的验收，均在其自检合格基础上实行了平行检查和检测后进行验收，均有详细记录。

如在砌体工程施工过程中，填充墙砌体施工时要按施工规范要求进行砌筑，砂浆按配比单计量，并着重对拉结筋部位、斜砌、门窗洞口部位的砌体施工检查。在施工过程中，跟踪检查墙体的表面平整度、垂直度及阴阳角方正。要求施工单位进行认真处理，确保了施工质量。

（六）、隐蔽工程验收，均经监理和建设单位、施工单位三方共同到场验收，隐蔽工程检查验收记录齐全。

（七）、水电安装工程施工质量简述

在主体工程施工过程中水电、消防及智能安装施工同步进行。依据《建筑电气工程施工质量验收规范》GB50303—20XX和《建筑给排水及采暖工程施工质量验收规范》GB50242—20XX，对与主体分部同步施工的水电、消防及智能分部工程施工质量检验批进行了验收，并形成质量检查记录；

四、工程质量控制的依据

1、施工图纸、图纸会审纪要、设计变更联系单、合同及工程建设强制性条文；

2、《建筑工程施工质量验收统一标准》（GB50300-20XX）；

3、《混凝土结构工程施工质量验收规范》（GB50204-20XX）；

4、《砌体工程施工质量验收规范》（GB50203-20XX）；

5、《建筑给水排水及采暖工程施工质量验收规范》GB50242-20XX）；

6、《建筑电气工程施工质量验收规范》（GB50303-20XX）；

7、《钢筋焊接及验收规程》（JGJ18-20XX）；

8、《工程测量规范》（GB50026-20XX）

9、《屋面工程质量验收规范》（GB50207-20XX）

10、《混凝土强度检验评定标准》（GB、T50107-20XX）

11、《通风与空调工程施工质量验收规范》（GB50243-20XX）

12、《自动喷水灭火系统施工验收规范》（GB50261-20XX）

13、《火灾自动报警系统施工及验收规范》（GB50166-20XX）

14、经批准的施工组织设计及专项施工方案。

五、工程变更

严格工程变更程序，所有工程变更均需设计单位出具工程设计变更联系单后，现场才能进行施工。

六、有关实体质量的检验和抽样检测

1、于20XX年11月22日委托永嘉县建筑工程质量监督站检测室对一至四层混凝土结构后锚固拉拔进行了检测，检测结果均满足设计及规范要求。

2、于20XX年11月30日委托永嘉县建筑工程质量监督站检测室对一至四层混凝土进行了回d法检测，以及钢筋保护层检测和实体取芯检测，检测结果均满足设计及规范要求。

3、于20XX年1月16日主楼板厚层高委托温州市灵霓建工质量检测有限公司对一至四层进行了检测，检测结果均满足设计及规范要求。

七、沉降观测情况

按设计及有关规范要求，在施工过程中，科信大厦工程一至四层共预埋14个沉降观测点（其中办公楼9个沉降观测点，商业裙楼5个沉降观测点。）在主体施工期间每施工一层观测一次，合计观测4次。最后一次于11月1日观测，沉降观测反映出本工程沉降比较均匀，沉降过程中无异常现象，沉降曲线基本趋于平缓。

八、安全生产与文明施工

在工程施工过程中，注重安全监理，坚持以“安全第一，预防为主”的方针，始终贯彻“安全为了生产，生产必须安全”的管理制度，并定期召开监理会议，督促施工单位对全体员工进行三级安全教育，对各分项工程进行安全技术交底，

且由班组长负责本班组的安全工作，使安全工作贯穿于整个施工过程中，做到安全生产文明施工，在日常监理巡查过程中发现问题及时要求施工单位整改，有效的消除了安全隐患，杜绝了重大安全事故的发生。

九、主体分部工程质量评估情况

1、工程质量控制资料基本齐全、完整，符合要求，

2、主体工程所含分项工程均经监理验收合格，

3、混凝土强度经现场回d检测符合设计要求，砼试块强度评定为合格、砂浆试块强度评定为合格。

4、工程观感质量情况

①室内墙面垂直，阴阳角方正，砖墙平整度、垂直度、水平灰缝平直度等均在允许偏差之内。砖缝砂浆饱满，无通缝。

②混凝土现浇结构件没有发生影响工程结构的质量缺陷。

观感质量评为“好”

综上所述，我监理部根据《建筑工程施工质量验收评定统一标准》GB50300-20XX相关规定，评定该主体一至四层工程质量“合格”。敬请永嘉县建设工程质量监督站及在座的各位专家领导予以核定并提出宝贵的意见，我们将努力认真地予以整改和完善，为我们更好的开展以后工作不断的总结经验而努力。

技术评估报告模板3

1、概述

1、1

目的与概述

长期以来，申银万国信息中心担负着对申银万国证券公司内大量业务系统的运维工作，并在长期工作中形成了一套完善的手工运维作业管理体系。

随着申银万国业务系统的进一步集中化(目前正在进行大集中项目，将各营业部的系统集成起来)，对于运维工作准确性、稳定性的要求将大大加强，运维的工作量也将大大加大，因此原有的手工作业方式将不能适应这种变化趋势，需要借助信息化系统的手段将这些作业自动化，从而提高作业的准确性、稳定性，并且减少工作量。

1、2 覆盖范围

复旦光华销售人员及售前团队 可能的实施团队

1、3 名词定义

运维：在本文档中特指申银万国信息中心对相关业务系统的各类运行维护工作。

作业：运维工作的细化及分解，一个作业通常包括在指定时间进行一系列指定的动作。作业可以手工执行或者自动执行。

监控：作业的一种内容，特指仅观测或者采集相关参数和信息，对被观测或采集的对象不发生影响或者发生的影响极为微小可以忽略不计。例如采集CPU占用率、查看指示灯的状态等。

*** 作：作业的一种内容，特指会对所 *** 作的对象产生较大影响的。例如启动、关闭程序、传输文件等。

1、4 参考资料

中心机房集中监控子项目招标书XX0117(初稿)、doc 申银万国作业管理系统技术评估v0-1、doc 大集中机房作业表范例、xls CA报价单- SYWG、xls

2、1

文档内容

本文档将主要包括以下几个部分：

1、背景描述和客户说明。主要指说明客户的组织机构和关键用户

2、业务描述和需求描述。业务描述是指客户方实际的业务描述，需求描述

是指从业务出发对IT系统的需求。

3、相关涉众。如果有其他涉及方面，包括其他厂商、中间人或者

4、市场分析。整体的价值如何体现，如何达成对双方都有利的结果，我方

在这个局势下如何定位，将来的发展。

5、项目实施中的潜在风险和关键点。各类风险评估和难点、关键点。

6、附录：接触背景和资料说明。描述和用户的接触情况以及获得的资料。 以上各部分的总体结论将在本节整体说明中进行阐述。

2、2 总体结论

关于价值：

项目利润较小

市场前景较大，可借此切入IT运维服务领域 可培养技术力量

可借此接触证券行业(和公司整体发展策略有关) 关于实施：

本项目实施风险中等，但头绪较多，比较繁琐 投入人力较小，但用户方对人员要求较高 关于投标：

如果事先有关各方(用户、CA、光华)达成妥协，本公司获得此标的可

能性应在八成以上

3、1

组织结构

暂无

3、2 关键用户

郭：申银万国电脑网络中心经理，为本项目用户方的决策者 邵斌：电脑网络中心应用开发部经理。该项目的管理者。

金磊：电脑网络中心运行管理部技术人员。该项目的项目经理。有丰富的IT运维经验，为人比较认真。

3、3 历史情况和未来走向

申银万国作为证券行业的主要企业，其IT运维在证券业界居于领先水平，但长久以来缺乏自动化。

随着业务系统大集中，对于IT运维的`要求随之提高。

未来IT运维很可能将采取以自有力量为主，结合外部公司的做法，关键是确保系统的稳定。

4、业务描述和需求描述

4、1

IT运维的基本概念

参见IT服务管理

4、2 IT运维价值链

参见IT服务管理

5、相关涉众

5、1

IBM

申万硬件设备的主要供应商，和申万有长期的接触，本次项目也有意参加，其意图是成为主集成商，并且使用其产品Tivoli。

但是其产品针对性不强，且价格偏高，用户方不是很认可。

5、2 CA

本项目的系统软件供应商，其提供软件包括Autosys和NSM，目前用户方比较认可，但价格偏高。

5、3 复旦金仕达

申万业务应用系统的主要开发者，传闻IBM将和金仕达合作投标。

5、4 某小公司

传是由某CA前工程师创办的公司，比较熟悉CA产品，应当是用户方的谈判筹码。

5、5 竞争者比较

以目前形势来看，主要难点在于我方和CA的合作定位，若双方不能达成妥协，则我方的利润空间将受到极大挤压。

6、市场分析

6、1

价值链及我方定位

作为一个运维项目，我方将依靠比较丰富的经验实施该项目，并在以后争取和申万建立长期合作关系，提供IT运维的长期服务，创出品牌。

6、2 市场前景

有可能在证券行业形成示范效应，但是由于采用的厂商的系统软件，因此在推广时将受到CA方面的很大牵制。

6、3 其他利益

暂无

7、项目实施中的潜在风险和关键点

7、1

潜在风险

1、该项目内容比较复杂，牵涉面较多，对于我方的项目管理是个很大的挑

战，且有多个第三方参与。

建议应对：指派具有第三方供应商控制经验和谈判技巧的项目经理 2、由于本项目用户指定了技术架构，因此实施的技巧性较高

建议应对：指派具有灵活思维的技术人员，不要选派技术攻关型人员3、随着业务系统的集中，后期需求扩张

建议应对：和销售一起严格按照合同进行控制

7、2 关键点

1、软件性能

2、第三方控制

7、3 建议项目运作路线

基本划分为两个大部分，

一个部分为软件部分，包括系统软件实施和脚本编写 一个部分为其他，主要在于第三方控制

8、附录

8、1

接触过程

之前由信息安全部相关人员进行接触

20XX年12月28日我和武勇开始参与接触，与金磊讨论 20XX年12月29日我和武勇到申万和邵斌交流 20XX年1月17日协助用户方起草标书 20XX年1月19日在CA进行产品验证 20XX年1月24日在CA再次进行产品验证

8、2 用户意见

1解决方案难写在哪里？很多人对写方案非常没有信心，一涉及到方案的事情，就束手无策，到处求人。作为一个公认的方案打手，意思是写方案就象打字员一样。 因为你不敢让你的同事知道你只能用很少的一点时间写方案，让他们担心方案的质量和进度保证，进而对自己的后续工作质量没有信心。写方案不难，知道怎么写才难。有结构就有思路，有思路就有方案。另外真正写方案的人，对自己写过的方案是永远不会满意的，只有这样，每次都会进步一点点，解决方案水平质量就会随公司能力不断增长。基本上原因可以归为四类：11 第一种是没有体系一旦用户要求提供关于PDM的方案，很多人大脑是一片空白，完全不知道从哪里下手。很多人说起自己的产品来，好象知道不少卖点，不过真要写出来，又觉得无从下笔。这种情况一般是写方案者不熟悉自己产品体系造成的，知道一两个甚至更多的产品卖点不难，但难就难在成体系，知识就是成体系的点构成的，而不是一句一句离散的说法构成的。因为这个行业从业人员说句不客气的话，大部分对所销售实施的管理系统并没有很深入的研究，都是半路出家，从头开始，在学习过程中熟悉，在熟悉过程中领悟。所以一下子去驾驭一个整体方案是很痛苦的。只有当一个人对一个产品思路有体系以后，才能够写出完整的方案，否则就是一个单元也要费尽脑汁。所以一个人要想写好一个方案，首先要把自己产品的来龙去脉，功能模块，适应领域，典型客户实施情况有一个全面的了解，这样才能建立一个完整的知识体系，然后逐步补充竞争对手知识和一些技术性知识，不断深化自己的知识体系。12 第二种是没有思路有很多用户看多了模板化的方案以后，想看一些针对他们自己的业务的个性化内容，这个时候有的人按照标准方案模板修改还勉强能对付，但对于个性化内容针对性方案就速手无策了。这种情况从根本上讲还是写方案者不熟悉企业业务造成的，写方案，特别是针对性方案不仅仅要求了解企业的需求，而且要知道这些需求是在何种业务需求下产生的，用户提出这样的要求到底想解决什么问题，把这个问题找出来，一般针对性解决思路就有了，有了思路，自然可以很好的写方案。所以一个人要写好方案，还需要了解下游客户的业务，了解业务最有效的方法就是亲自做几次详尽的业务调研，有了业务调研做基础，在调研过程中把握用户关注重难点问题，自然可以比较好的确定方案的个性化内容思路。解决方案就是把客户的利益和产品特性之间建立一个逻辑性的桥梁。13 第三种是没有素材一般不经常写方案的人，在写一个方案的时候，即使有想法，有思路，但往往也会很累，就是因为缺少足够的素材。很多项目现在都是投标，不同用户可能有不同投标的要求，这样很难用一个方案去适应所有的用户，因此在每个方案中都有一些需要准备的内容。这些内容基本上是通用的，但如果没有足够积累每次编制方案就需要花费大量时间去准备，造成方案完成周期过长。所以写好方案必须具备这三个条件，第一方案编制者对企业业务要很熟悉，或者有相关业务调研经验，第二方案编制者对产品非常熟悉，至少对自己产品功能模块作用很清楚，第三方案编制者手上有大量可公用的素材库。14 第四种是没有层次很多人刚和用户接触没有多久，为了表现自己对客户的重视，马上表示要提供方案，当然有的客户刚刚开始选型，也不知道到底要什么搞，也要供应商马上提供一个方案。结果拍胸脯容易，写方案难，自己写不出来只好求公司，公司没有安排专人了解情况，只好按模板制作一个，用户一看几个供应商内容都差不多，觉得不好，又总结出一些个性化要求，于是大家有开始折腾第二轮方案。其实方案编制在不同阶段有不同策略，不要轻易提供方案。刚开始接触是可以提供项目合作建议书，类似可行性报告，项目需要考察软件技术，可以提供标准的产品技术白皮书，到了经过售前调研，有所准备，在演示前后阶段和其它竞争对手刺刀见红的时候，才在知己知彼的基础上提供解决方案或者投标书。过早提供方案只能匆匆了事，时间紧急，质量自然不高，自然也就觉得方案难写。想急就又能解决问题的事情，本来就是一般人做不来的。方案想要写得好，一定要用心，用心就一定要耗时间，指望用几个小时写出一个高质量的方案是不可能的。如果你做了精心调研，你写不出一个好方案唯一缺的是技巧。写方案是一种技巧性工作，明白了这一点，大家都可以经过练习写出好的方案。21 第一个容易犯的错误：只有论点，没有论证不好的解决方案粗看起来非常厚重，其实都是功能罗列，象产品手册摘要版，不象方案书。不好的方案是一大堆内容，淹没在一堆纸里面，也不知道想说什么，给你一个厚度，证明我们的工作质量很高。我们国内许多的企业客户特别是大型企业都很在乎这点，认为可以从方案厚薄中看出对项目重视程度。如果你做了精心调研，你写不出一个好方案唯一缺的是技巧。写方案是一种技巧性工作，有个金字塔式的写做原理，也就是说文章一定是有结构的。所以真正好的方案，不一定厚，但能看出你用心，你认真。现在的解决方案一个不好的倾向是"长、厚、全"，看起来面面俱到，其实对决策者没有帮助。所有的方案无差异性，每家供应商都说自己能解决这些问题，而且都有成功案例。结果所有的方案都无法给决策者简明的判断依据，不得不费更大劲去做产品演示和用户考察。其实很少有企业高管不知道自己的毛病，在企业你随便去找一个人，对问题都能讲一通，在企业你费很大劲可能都找不到一个人能告诉你这些问题可以怎样去解决。通观这个方案并没有研究为什么企业会产生这么多问题？问题是这些问题是什么产生的？为什么出这么多问题？而是不断说"我能！我能！选我，选我！"。如果不能找到解决这些问题的原因，简单地去解决这些现象，就象治病不能治根一样。这样一个模板化，自我膨胀化的方案想打动用户的心是非常困难的。不好的解决方案最大的问题就象写一篇议论文，能够发现问题(这个也是模板化的，可惜中国企业大部分没有意识到自己很多问题并不少见，总以为自己是特殊的一类企业)，提出答案(搞信息化)，但没有论证(为什么搞信息化和企业管理进步有联系呢？)。没有论证的东西不管内容陈列得多么繁复，名词多么吓人，但是无法打动用户，特别是那种理性的用户。看到方案时候，其实很多用户下不决心，他会感觉每家都差不多。如果从没看过方案的人，突然看到这几个方案，你为什么会感觉某个方案写得好呢，关键是有的方案图画的好，通过图，通过表，会感觉这个公司还不错，很规范。但对内容认可程度并不高，实际上没看懂。22 第二个容易犯的错误：业务解决方案成为功能列表解决方案省事的一种方法就是将产品功能描述作为技术方案内容进行罗列，或者参照软件用户手册罗列，这种解决方案不是按照用户业务去准备的内容，而是按照软件商自己的喜好去编制的解决方案是很难得到用户认可的。大凡按照功能列表组织的解决方案用户会有一个体会，庞大而庸长，但要看到自己想看到的部分非常困难。而且这种方案还有一个特点，一个问题反反复复的提，在业务背景中指出某个问题，讲一通，在价值分析中又重点解释一通，到了功能介绍时又将某个问题来龙去脉概要说明一下，给用户感觉是一堆资料的堆积，哪里体现出了方案的针对性呢？按功能列表准备方案的做法在很长一段时间内不会消失，这和我们普遍是4P销售人员，还缺少SPIN(顾问式)销售人员有关，在资源不足的情况下，要保证效率就只能提供功能列表方案了。)评论(0)

以上就是关于VUCA时代的IT项目管理（一） ——困境全部的内容，包括:VUCA时代的IT项目管理（一） ——困境、用户需求是什么、如何才能写出好的产品文档等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！