大约一年前，我曾经在blog上写过一篇文章，讲述了我对于SharePoint解决方案开发模型的一些想法，其中包括了SharePoint解决方案开发的方方面面，从开发团队，到开发环境的建立、物理与逻辑架构的设计、开发流程、信息架构、测试等等等等。这些主题我相信对于SharePoint开发人员、架构师、项目经理而言，都是非常有价值的。
既然直到现在，国内仍然没有任何SharePoint开发书籍（当然也包括我的《SharePoint 2007 开发入门指南》）讲述上面这些主题，所以决定开始在自己的blog上面，陆续就每个主题，撰写一些文章。希望这些文章能帮助到SharePoint技术社区。
每每涉及到比“具体”技术细节更高一层的架构、流程、方法论的东西，通常都很容易引起争议。这是很正常的现象。这些主题和具体的诸如C#语法、怎么做一个Web Part等等都不相同，因为这些主题根本就不会有一个标准答案。每个人心中都对如何设计一个架构、如何实施某个流程都有自己的想法，而环境与条件的不一致，更是使得所谓的“最佳实践”在很多场景中都不适用。所以，如果你对我撰写的文章中的某些内容不认可，没有关系，这些文章中的内容本来就不是“金科玉律”，甚至在你所处的场景中根本就是错误的。这些文章只代表我个人的意见（但其中肯定有不少想法，来自MSDN以及其他人所撰写的博客和文档），同时我也希望它们能成为交流的一个平台。如果你对文章中的内容有意见和想法，欢迎留言。高质量、有价值的留言，通常都能让后来的阅读者受益良多。
任何软件项目的实施，都必须从实施团队开始。所以，首先要讲述的主题，是如何建立一个SharePoint实施团队。
从本质上来说，实施一个SharePoint项目，与其他类型的软件项目，诸如ASP.NET、PHP，都不会有根本的差别。所以一个SharePoint实施团队的组成，也基本上和一个标准的Web项目实施团队相同。在下面的角色描述中，我基本上只会描述和SharePoint相关的部分，而其他通用的内容则会尽量省略。
项目经理
项目经理是整个项目的管理者。他负责指派任务、记录和跟踪进度、向老板们汇报...总之，项目经理的工作就是要保证整个项目处于正常状态，并能顺利完成。在小型团队中，项目经理有可能同时兼任业务分析人员。
业务分析人员
业务分析人员应当与客户充分交流，弄清楚客户的业务需求、流程等等信息（越详细越好）。业务分析人员与架构师一起工作，撰写出应用系统的功能规格说明书（也可能叫其他名字），不管我们叫这份文档什么名字，它都应当至少包含有：
1、整个项目要解决的问题、目标
示例：“ABC公司是一家卖汽车的企业，它总共有300名销售人员，销售人员希望通过一个“客户管理系统”对他们各自的客户进行管理。在这个系统中，销售人员能够查看自己负责的客户、每个客户的详细信息、每个客户的订单历史记录等信息。同时，销售人员还需要通过这个“客户管理系统”提交季度销售预测报告...”
2、针对用户使用场景的User Cases
这里的User Cases信息，应当详尽的描述出用户使用系统的每个具体场景，它将作为整个团队的一个“基础文档”，架构师和开发人员根据这些信息，才能知道程序最终要实现的效果。每个User Case里面都要包含用户几乎每个操作的描述和说明，以及每个主要界面的图示（使用Visio或其他工具绘制），也就是说，它不能含糊，而应该清晰、明确、有针对性。
示例：“User Case 15 - 销售人员Dashboard”
“销售人员在“客户管理系统”主页上点击“Dashboard”按钮（参考User Case 5），就能够打开自己的Dashboard...Dashboard会自动校验当前浏览用户的身份和权限，如果的Dashboard以两栏的方式来展现信息（参考图15-3），其中左栏自上而下会包含5个链接，分别是...销售人员点击了左栏的“历史订单数据”链接之后，页面将转向到“历史订单数据”页面（参考User Case 26）...中间的向右箭头是一个可以允许销售人员将右栏折叠起来的图标，在点击它之后...销售人员可以点击右上角的“返回”图标，以返回到“客户管理系统”主页...”
功能规格说明书不涉及具体的技术细节，不包含如何实现每个场景的技术说明，不包含系统的设计内容。我们可以这样想象，假设团队中突然来了一个陌生人，他希望能了解这个团队到底在做一个什么项目，这个项目是干嘛的，实现了什么功能，我们可以将这份功能规格说明书给他，而他确实可以从这份文档中了解到他希望了解的这些信息。
这份文档不能由业务分析人员一个人独自写成，而一定要有技术人员（以架构师为主）的共同参与。一方面，架构师的参与可以保证规格说明书中的内容，在技术上是可行且合理的，另一方面，也有助于架构师从业务角度了解系统，明白客户的需求。
我个人对功能规格说明书的重要性非常推崇。在项目中，可能我们不会撰写详细的设计文档，可能我们不会撰写详细的部署文档，但一份详细的功能规格说明书确是不可缺少的。它的重要性体现在：
1、让团队中的所有人都明白我们要构建的是一个什么东西。如果没有这样的一份清晰的功能规格说明书，就不能保证团队的所有人都一致了解团队的目标。如果没有它，业务分析人员会根据客户的描述，在自己的大脑中想象出系统应该有的样子，然后口述给开发人员，并假设开发人员完全明白了自己大脑中的想法，而开发人员则会根据自己从业务分析人员那里听到的，在自己的大脑中又试图去想象系统做出来应该是什么样子的，并假设这就是业务分析人员想要的样子...总之，每个人都会根据自己的“想象”，去猜测别人的意图。而最后当开发人员把最好的东西给业务分析人员演示的时候，通常是业务分析人员大吃一惊：“我kao，怎么是这个样子？这根本和我告诉你的是完全不一样的东东...”而开发人员则会辩解：“胡说，这分明就是我根据你告诉我的要求做出来的...”
2、我们有了一个可以和客户讨论的东西。这份文档可以尽早的交给客户审阅，客户可以根据这份文档，了解到系统做出来会是什么样子，如果不满意，客户也可以及早的和开发团队进行沟通：“嗯，不对，在这个地方，其实我们更希望看到一个选择框，而不是用户自己填...”
3、它是业务分析人员与开发人员之间的一份“合同”。业务分析人员可以充分的假定，开发人员最后交付的，就是功能规格文档中所描述的样子，而开发人员也可以充分的假定，业务分析人员需要的，也是文档中所描述的样子。
值得一提的是，功能规格说明书并不会（也不应该）限制开发人员的“自由”。它仅仅包含对业务场景、系统功能的详细描述，但是不会写上应该如何实现。它肯定不会包含诸如“在这里，我们要创建XYZ类和ZYX类，前者用于从数据库中查询QWE表...”