在你的开发团队转移向基于Microsoft .NET的项目的同时，针对你的终用户和开发人员的文档工作方案也应该随之跟进。你目前的文档工作方案只是一个出发点，.NET的引入意味着你的技术作者和文档化工作必须得到调整。
文档工作方案像是一个项目的计划和/或是随着一个软件产品的推出而被开发技术文档的标准要求。它包括针对文档结构，格式，进度安排和交付方式等内容的指导方针。
Microsoft.NET架构，用户文档和在线帮助
Microsoft.NET架构并没有为用户文档指定任何特定的帮助文档格式。不过，对于在线帮助解决方案，微软的HTML Help格式成为被业界普遍接受的标准。
向"DocumentationPlan.NET"转移
DocumentationPlan.NET并不是一个实际存在的产品，我提出这个名字的意思是强调你的文档将不得不升级至.NET，像微软的编程语言已经升级至.NET环境之中一样。属于微软开发人员项目的软件编制公司需要同时为程序员和技术作者进行技能组的更新，从而使他们可以开发基于.NET的应用软件。
要满足.NET的额外的需要，你的文档工作方案应该加入以下一些元素：
移动用户所需要的文档，其中包括文本和图形
在各种不同的平台之间可以访问的在线帮助格式，其中包括传统PC的Web浏览器，PDA，可访问Web的移动电话和其他设备
将打印文档转为在线格式的工具
在线帮助是一项真正的投资，但有时却经常被一些软件开发公司所忽视。Microsoft .NET中具有的机动性元素意味着，在用户通过他们的PDA或其他移动设备访问应用软件时不会再同时携带着打印文档。Microsoft .NET关注于平台的交叉和机动性，这给文档工作方案带来了很大的影响，因为交叉平台的兼容性和机动性对于很多的开发公司组织来说仍然是一个全新的课题。
在技术作者的邮件列表中或是技术写作专家的新著作中，你是无法找到那些客户和使用者的额外需要的。你的终用户将会给出这些需要，尤其是对于那些第一次向移动计算领域进行转移的公司组织来说。PDA和能够访问Web的电话也许已经成为那些先行者的标准工具，而一些非专业用户则可能需要通过一个移动设备来访问基于.NET的应用软件。
这样的结果是，以下的人员需要进行一些交叉功能性的工作：
产品经理和/或商业分析人员，他们的工作是满足用户对基于.NET的产品的要求，对用户的需要进行洞察，提供文档化工作和培训等内容
技术作者和分析人员，他们通过一个媒介使用户文档在线满足用户的访问需要
QA人员，他们通过用户访问应用软件时所使用的各种不同的设备对在线帮助进行测试
新型交叉平台式帮助文档开发工具
像程序员一样，技术作者也可以习惯于使用他们的工具，但是向.NET的转移通常需要有新型文档工具和方法的引入。通过多种平台对在线帮助进行访问的需要逐渐增加，这对现有的文档工作方案将造成大的影响。
Web基于服务的本质意味着在线帮助是为用户提供协助和培训的佳平台。对于.NET应用软件来说，在线帮助可以通过下面的方法实现：
基于服务器的HTML或基于Web的帮助：这样的服务器端文档可以是自定制的解决方案，也或者是利用eHelp的RoboHelp Enterprise这样的工具所开发的，RoboHelp Enterprise以RoboHelp为基础，使你可以开发基于服务器的和基于应用软件的在线帮助解决方案。
应用软件自身所提供的HTML帮助：目前已经有各种不同的工具可以使用，你的公司中也许有一些。
Web帮助：来自于应用软件或是服务器端。
加入XML和ASP.NET
如果你的文档工作方案中不包括XML和ASP.NET，你的文档需要进行扩展以加入这些内容。对于应用软件的终用户来说，对XML和ASP.NET的使用也许是透明的，但你的软件开发生存周期和结构性文档也要考虑到这个问题。
这可以通过多种途径实现，其中包括：
将应用软件XML DTD文档化。
将ASP.NET代码文档化，其中包括一般性项目信息，COM对象和构成ASP.NET的其他元素。有一些自动化的文档工具可以完成这样的工作，例如Living Doc。
移动用户
在PDA的使用逐渐流行起来的同时，也许有一些技术作者和分析人员还不是很熟悉PDA的环境。此外，移动电话的功能不断增加，使他们都能够对Web进行访问。
如果你的文档化工作还扩展到了用户培训这一方面，那么你要提供课堂和在线培训以满足人们的需要。有一些工具，例如来自eHelp的RoboDemo，他们可以让你产生运行在基于PDA的Pocket PC之上的介绍和教程，这些内容同时也可以在Web中进行访问。
接受挑战
要调整文档工作方案以满足.NET环境的需要，你要对用户文档进行一些改动，采取策略来适应被Microsoft .NET和用户社区所支持的多种平台。
