软件项目版本和项目文档如何管理

管理软件项目版本：1、建立明确的版本号标识；2、确定版本的目标；3、制定版本内容；4、设计发布的策略。管理软件项目文档：1、保证有效沟通；2、与所采用的工程方法相匹配；3、满足产品生命周期管理的需要；4、区分文档的记录与整理。

一、管理软件项目版本

1、建立明确的版本号标识

为了使工作规范化、统一化，我们需要明确标识产品的版本编号。目前业界在软件版本的命名上，通常会采用以下方式：

版本号命名规则

例如：1.2.1, 2.0, 5.0.0 build-13124。其中，构建版本号通常由编译程序自动生成，对外不提供。

版本号更新规则

主版本号更新规则：产品功能发生全新的优化，包括页面、体验和技术上的全面更新优化。如下图所示两个产品的版本号升级。
子版本号更新规则：1、产品新增了重要功能模块；2、在原来功能基础上作了重要更新；3、严重Bug的修复。
修订版本号更新规则：1、新增或优化一般的功能模块；2、一般Bug的修复。

版本号后缀

版本号后面可以加入Alpha、Beta、Gamma、RC、Release等后缀，用来表示软件当前所处的阶段：

Alpha：内测版。此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在开发者内部交流，或者提供给测试人员测试用，一般而言，该版本软件的Bug较多，需要继续修改。
Beta：公测版。该版本相对于α版已有了很大的改进，消除了严重的问题，但还是存在着一些缺陷，需要经过多次测试来进一步消除，可以提供给一定的目标用户大规模体验测试。
RC 版：候选版本。是 Release Candidate 的缩写，意思是发布倒计时，该版本已经相当成熟了，完成全部功能并清除大部分的Bug。
Release 版：该版本意味“最终版本”。是经过前面版本的一系列测试之后，最终交付给用户使用的一个版本。该版本有时也称为标准版。

2、确定版本的目标

在确定版本上线需求的时候，往往容易只考虑那些最紧急的、用户反馈非常多的、所谓优先级较高的需求，然后将这些需求整合到下一次的版本发布计划中，但是这么做无疑是捡了芝麻却丢了西瓜，因为忽视了对整个产品目标的实现。

海盗模型是一种以用户为中心的、着眼于转化率的漏斗模型。这个经典的数据模型把目标整体分成了五个部分，即：获取用户（Acquisition）、激活用户（Activation）、提高留存（Retention）、获取收入（Revenue）和自传播（Referral）。

获取用户：即拉新，一般是用户的注册、下载、关注等行为。通常用新增用户数来作为考量。任何一款产品上线之初都避不开这个环节，而且拉新是会持续的伴随整个产品生命周期。一般在刚刚上线核心功能后，都会重点关注并优化用户的注册登录的路径，甚至通过不断的埋点来获取数据，从而做数据分并优化需求。
激活用户：即促活，一般会以用户的在线时长、与其他用户的互动频次等数据来做以考量。初期用户的活跃度是至关重要的，甚至对产品以后的发展会有很长远的影响。
提高留存：留存：指在经过一段时间后有多少用户留了下来，一般情况下会以月、周、日的时间维度来作为数据考量，也就是我们常说的DAU、WAU和MAU。
获取收入：即变现。不止是软件的开发方获得收入变现，用户也可以在这一步获得利益。
自传播：即用户可以自发的向身边用户推荐我们的产品。

3、制定版本内容

版本的目标确定了，我们就需要从需求池中挑选需求了。需求很多，但是开发资源紧张或存在其他一些客观因素，不能在一个版本中全部实现。那么我们怎么对这些需求进行排序呢？

基于KANO模型确定需求优先级

在KANO模型中，根据不同类型的需求与用户满意度之间的关系，可将影响用户满意度的因素分为五类：兴奋型需求、期望型需求、基本型需求、无差异型需求、反向型需求。

兴奋型需求：就是哪些藏在暗处的、用户意想不到的，需要挖掘/洞察的需求。
期望型需求：实现此需求，用户满意度会提升；不实现此需求，用户满意度会降低。对于这类需求，不仅要满足，还要保证质量。
基本型需求：基本型需求，即痛点，对于用户而言，这些需求是理所当然必须满足的。
无差异型需求：用户根本不在意的需求，对用户体验毫无影响，无论提供或不提供此需求，用户满意度都不会有改变。对于这类需求，没有必要花大力气去实现。
反向型需求：用户根本都没有此需求，实现这类需求用户满意度反而下降。所以这类需求不能去实现。

4、设计发布的策略

版本发布策略需要考虑的问题是：直接发布给所有用户？还是先让一部分用户试用？

比如说可以先让内部用户使用，内部用户对软件质量问题容忍度是很高的，还可以帮助发现很多问题。还有就是采用灰度测试的发布策略，让一小部分用户先用新功能，如果没发现什么问题，再继续扩大用户规模，如果有问题，也只是影响少量用户。例如：苹果的iOS系统，用户也可以选择安装最新的 Beta 版本，可以先体验新功能，但是必须忍受系统的不稳定。

二、管理软件项目文档

1、保证有效沟通

文档的主要作用是用于沟通，在所有的软件规划、设计、实现、运行、使用、服务等相关人员之间的信息交换。在文档编写过程中，要求所传递信息做到完整、准确、简洁，特别是要能够适合读者理解。紧紧抓住信息沟通这一核心目的，对于无论是制作文档模板还是编制具体文档，都是很重要的指导思想。记得早年学习过国标的软件工程文档规范，不仅文档很多，而且很多的文档的名列前茅章都是背景介绍，曾经试图按照这种规范来编写文档，名列前茅章写了几行就实在是写不下去了，这确实会令许多的软件开发人员感到抓狂，在今天更加强调响应速度的开发过程要求来说，几乎是无法执行的。因此，在编写文档时，关键就抓住两点：一时明确文档的读者对象，二是站在读者角度把读者希望了解的信息完整、准确、简洁的描述清楚。写文档和读文档，就如同是作者与读者之间在对话，把要传递的内容描述清楚，文档的目的就达到了。啰里啰嗦的无关内容，不仅浪费作者和读者的时间，也会影响对文档重要信息的突出。

2、与所采用的工程方法相匹配

在软件研发方面有许多不同的工程方法，瀑布式、原型法、敏捷开发等等，不同的开发过程实际意味着不同的生产工艺，那么在不同的工艺方法中各道工序的工作内容和要求不同、工序之间的衔接要求不同，必然也会对文档的要求产生不同。因此，在编写文档时，也需要考虑开发项目中所采用的工程方法的因素，在单位制定软件开发文档模板时，也需要考虑不同的文档体系，以支持不同的开发过程方法。

3、满足产品生命周期管理的需要

就产品文档而言，有的文档可以是增量式的，只说明某一个版本的具体情况，而有的文档则需要是全量式的，需要随着新版本的发布而不断更新，保持与最新版本相一致，最典型的例子就是用户手册，通常都要随着版本的更新不断进行同步更新，对应旧版本的用户手册已经没有实用价值。另外像产品使用的FAQ这类文档，也是需要不断加以补充、更新，并且以全量版本的方式发布。同时，像系统技术架构、数据结构、发生变更的代码等，这些其实也需要维护全量的最新版本，才能有效支持后续版本的设计开发的需要。因此在文档管理中，也需要对文档进一步细分，同时满足产品版本升级项目过程的需要，和产品生命周期持续发展以及最终交付使用及服务支持的需要。

4、区分文档的记录与整理

很多的人对于文档都很头疼，需要花费很多“额外”的时间来编写，但实际上我们看到，许多需要在文档记载的实质内容其实并不缺少，在软件研发的项目过程中，该讨论、该沟通的内容实质并不少。对此稍作区分可以看出，问题出在“整理”文档上。所以在实践中，可以将文档的形成分成两个阶段，一是在过程中形成的记录，这些记录可以是手画的草图拍成照片，可以是简单的会议记录，也可以是工具软件本身生成的特殊格式的输出文件，比如数据库设计文档、项目计划文档，这些专业工具形成的特殊格式的文件，其实比转换成EXCEL或PDF文档要好用，而且能够真正在后续的执行中继续发挥作用。能反映实质内容的这些记录形式，其实也是文档。

延伸阅读

软件项目文档编制要求

标准化：从需求分析开始到投产应用所有涉及的每一种文档，都要给出一个可以执行的模板，所有完成的文档从里到外都要非常工整，具有专业水准，符合ISO9000及CMM质量标准要求。
易用性：编制的各种软件文档，要便于不同的岗位人员进行阅读、理解、学习和使用。
简洁性：要求软件项目中需要编写的文档内容突出主题，只反映要描述的问题，不包含其他不必要的东西，语言表达简明扼要，一清二楚，如有可能，可以配以适当的图表，以增强其清晰性。
针对性：文档要按不同的类型、面对不同的对象，实行差异化编制，根据实际需要进行编写，也就是说文档编写目的要明确，因需而变。例如管理文档主要面向管理人员，用户文档主要面向用户，这两类文档不应像开发文档(面向开发人员)那样过多使用软件的专用术语。
一致性：文档的行文应当十分确切，对于同一现象的描写，不能出现多义性的描述，同一项目中几个文档描述的内容应当是一致的，相互之间没有矛盾。
完整性：任何一个文档都应当是完整的、独立的，没有遗漏和丢失的内容。也就是说每一种文档在设计时可以包含必要的图形、模型、叙述、表、索引、附录和参考文献，列举的这些内容都是完整的。同一软件项目涉及的几个文档之间可能存在部分内容相同，这种重复是必要的，不要在文档中出现“见XX文档XX章节”的现象。
灵活性：在实际操作中要针对软件项目规模和复杂程度的不同，对现行的文档进行修正，决定编制的文档种类。可以依据自身软件开发情况，制定一个对文档编制的规定，用列表的形式列出在项目什么条件下，应该形成哪些文档，这些文档的详细程度。
可追溯性：在软件项目的开发过程中，各个阶段编制的文档不是孤立的，而是与各个阶段完成的工作有密切的关系，随着项目开发工作的进展，具有一定的继承关系，体现出了可追溯的特性，如软件需求会在设计说明书、测试设计方案及用户手册中有所体现。
设定优先级：在软件项目众多的文档中，其中一些文档必定是关键文档，起到非常重要的作用。对于这类文档要设定优先级别特别关注，不能有任何的错误存在，对于一些关键的地方要特别标记，特别说明。