现在这个公司主要经营亲子门户网站，致力于育儿资讯、电子商务、社区交流等多元化网络服务。目前，公司项目主要由“内容区(资讯)”和“SNS(社区)”组成，我主要负责内容区的功能分析和架构设计，以及后台的开发工作。
本系列文章主要是想和大家分享一下发生在技术部门的那些事儿，以及自己在实践过程中，所学知识的总结。
声明：本系列文章总结只代表人个观点，请误对号入坐！
1.1 团队介绍
1.1.1 产品部
接收：完成网站产品所有功能的设计，接收运营部和所有人员提出的有效建议。
交付文档：《产品原型说明文档》、相关需求说明书
岗位职能：网站的每个功能都是由他们设计（原型）出来的，并根据运营部（或策划）的需求设计产品，最终把产品需求转化为原型图和配套的原型说明文档。每个需要交付的产品原型文档都要通过需求评审会议才能发布，需求评审会议需要技术小组的相关负责人参加，评审会议结束后《产品原型说明文档》需要发布到技术部各技术小组的负责人手中。
1.1.2 美工组（设计）
接收：《产品原型说明文档》
交付：产品效果图、产品所需的各种设计图（标志、ICON等）
岗位职能：凭借艺术细胞把产品原型文档转化为领导能欣赏的网页图片...
1.1.3 前端组
接收：《产品原型说明文档》、效果图（美工）
交付程序：静态页面、资源文件（图片/样式表/脚本）、API 调用示例和前端架构说明文档、第三方插件资料等。
交付文档：《内容区前端资源处理标准化(SOP)流程文档》
内部文档：《html&css前端开发规范》、《javascript前端开发规范》
岗位职能：根据美工提供的效果图并参考产品部的原型说明文档进行布局，分析页面结构、提取公共模块、设计并开发样式及脚本框架。在分析和开发过程中，为了能达到更科学的效果（重用、交互体验等），有时需要和美工及产品经理沟通并修改部分效果图的布局和交互效果。在实现某些需求和服务器交互的脚本时，需要和开发人员约定相关接收和返回值的接口。
1.1.4 开发组
接收：《产品原型说明文档》、前端组交付的程序
交付程序：各个产品可运行的网站程序、特定业务自动作业处理程序、公共模块的测试程序、统一架构的代码生成模板、程序相关配置说明文档。
交付文档：《内容区技术架构》、《内容区开发规格说明书》、《内容区全文检索解决方案》、《内容区安全测试标准化(SOP)流程文档》、《内容区各产品配置部署标准化(SOP)流程文档》
内部文档：《编码规范（C#版）》
岗位职能：接收产品部提供的产品原型文档，并编写《内容区技术架构》和《内容区开发规格说明书》，根据特定功能分析并编写解决方案，比如《内容区全文检 索解决方案》。把前端组所提供的静态文件，转换成动态网页，在功能分析和开发的过程中，同样也避免不了需求变更，这时需要大家共同协商并解决问题。在网站 程序开发完成并通过测试后，需要编写相关标准化流程文档，有关开发组的具体细节会在后几章为大家分享！
1.1.5 数据库组
接收：《产品原型说明文档》、参考开发组的交付文档
交付文档：《内容区数据库结构说明书》、《内容区数据库配置部署标准化(SOP)流程文档》
交付程序：内容区相关数据库脚本
内部文档：《数据库管理规范》
岗位职能：分析产品部提供的原型文档，和开发人员共同协商数据库的设计，指导开发人员编写高性能的SQL语句和存储过程，设计数据库访问权限和数据库物理架构设计，以及数据库运维工作（部署、备份、安全等）。
1.1.6 测试组
接收：《产品原型说明文档》、静态效果图、网站所有产品的发布程序、前端组和开发组交付的开发说明书和相关配置文档。
交付程序：经过测试的网站程序
交付文档：《内容区后台使用说明文档》、《测试流程管理标准化(SOP)流程文档》等
内部文档：《Bug流程管理》、《Bug管理工具说明》、《测试申请单》等
岗位职能：根据产品部提供的产品说明文档编写测试用例，并依据以上小组提供的文档对网站产品进行测试，并按照《Bug流程管理》处理Bug。网站产品测试结束后需要依据《产品发布作业标准化(SOP)流程文档》进行产品发布，并编写相关测试总结文档。
1.1.7 运维组
接收：经过测试的网站程序和相关部署配置文档。
交付文档：《托管机房IDC部署文档》、《IDC机房网站内容区运维标准化(SOP)流程文档》
岗位职能：公司内部和IDC机房的硬件及网络运维工作（硬件采购、账户分配、网络维护、硬件及系统环境搭建等），包括服务器系统及相关环境的搭建，按照《产品发布作业标准化(SOP)流程文档》对网站程序进行部署。
注：以上只是简单介绍了技术部内部各小组的工作内容，在实际工作环境中还要和产品部门、运营部门、编辑部门进行协作沟通。
1.2 团队协作
在团队介绍中已经简单描述了每个小组的工作内容，从每个小组的“接收”和“交付”内容中可以看出一些工作流程，我根据以上内容简单地画了一张“团队协作流程图”。
在团队协作的过程中，有很多环节需要注意，如果前期不进行良好的沟通，各种问题就会越来越多，就如雪球会越滚越大，等到问题暴露出来，甚至会造成项目重头再来的局面。接下来我会列出项目中几个比较典型的问题和大家分享。
1.2.1 产品文档评审会议
首先产品经理需要在《产品原型说明文档》中，把产品的所有功能描述清楚，因为美工会按照产品原型文档去设计效果图。在会议上产品经理需要依据 《产品原型说明文档》来讲解产品所包含的功能，此时参加的组员都可以发表自己的建议。这个环节很重要，开发人员（开发组长或项目经理）必须要理解清楚产品 所包含的每一个功能，因为要依据这些功能来设计产品的技术架构，如果开发人员误解了需求，有可能会导致阶段性工作重来。同样，测试人员（测试组长或测试经 理）也需要理解每个功能在页面中的表现，并且，确定《产品原型说明文档》对功能的解释足够详细，因为后期测试组需要拿着这个文档来对项目进行功能性测试， 如果前期不确定清楚，在测试时会和开发人员、产品经理发生争论。总之，每个技术小组的负责人都要理解《产品原型说明文档》，这样才能设计和开发出产品经理想要的产品。
1.2.2 需求变更
在这个公司，需求变更可以分为两种，一种是如果我们犯了上面的错误，也就是说，开发人员根本没有弄清楚需求，这样就会导致项目在开发过程或内部 测试时，各小组意见不一致，此时，就会请产品经理确认需求，修改相关文档和程序。另一种则是产品经理在设计时没有考虑周全，在内部测试时，客户代表（编辑 人员或负责人）发现不是当初想要的，这时产品经理不得不重新设计需要修改的功能，然后按照流程执行修改。需求变更在传统瀑布开发模型中是不允许的，而在敏 捷开发方法中，需求变更是常见的事情，所以，在竞争激烈的互联网行业中，拥抱变化，才能快速迭代发布产品来抢占市场。
1.2.3 架构统一
当网站产品原型和开发文档都完成后，就进入了实现阶段，美工会按照原型来设计网页效果图，而前端会根据效果图来编写前端代码，后台也是同样。这些看似简单的流程，想要做到持续简单的同时，还要保障团队成员在今后有个良好的合作平台，就需要提前定义架构，统一架构。比如，各技术小组都是由多个成员组成的，而公司的发展还会有新成员加入，为了确保新员工加入团队后，能够快速适应项目的开发，或者是当老成员离职后，其他团队成员能够更快地接手他的任务。在第二章，我会介绍各小组必需要建立的一些内部文档，但是除了这些文档，在开始编写代码前，还需要各小组分析产品功能、编写统一的架构设计和案例代码，并要求整个开发团队都按照这个流程和代码结构来编写代码，这样团队中的每个成员都能有效地阅读其他人的代码，同时也方便开发组长（项目经理）进行代码审查。如果没有按照以上方法来执行，那么很多开发人员都有过这样的经历，在修改团队其他人，或者在修改离职员工编写的功能模块时，宁愿自己再重新编写，也不愿审阅他人的代码。关于架构统一，应该由公司的架构师和团队中资深开发人员进行具体实现，这样也可以达到提高团队成员技术水平的效果。
1.2.4 有效沟通
在团队协作过程中，建立一个良好的沟通环境很重要，但是很多时候大家是为了沟通而沟通，这样就会浪费大量的项目时间。前两天，在看《软件架构师应该知道的97件事》时，收集了一些关于有效沟通方面的建议：
- 不要把对话当成对抗
- 不要带着情绪与人沟通
- 尝试通过沟通设定共同目标
- 以沟通为中心，坚持简明清晰的表达方式和开明的领导风格。
- 让沟通事半功倍，起立发言是简单、有效的方法！
- 必须和执行该决策及会直接或间接受其影响的人进行过沟通，达成共识。
本系列目录：2011 年终项目总结