公司在软件自主开发和外包业务方面组建了自己的专业队伍，引入海内外软件行业精英，成立了研发中心和项目开发部。项目中心在承担公司现有网站在日常开发及维护过程中所涉及到的技术更新工作的同时，还为物联网产业相关领域提供技术研发支持。

　　在满足自身技术研发需求同时，公司积极寻求外部合作，凭借技术研发优势，承揽各类软件开发外包业务，成为公司新的利润增长点。

　　公司专门组建一个网游产品销售团队，主要负责游戏产品市场推广和销售工作。公司已有的网络新媒体产业、传统媒体产业、手机电视新媒体产业、会展经济产业，科技产品销售中心为游戏产品销售渠道建设提供良好的基础。公司可以根据中心所在区域的实际市场情况，采用直接面向客户销售和与当地渠道伙伴合作两种方式开拓市场。对于直接面向客户销售的推广方式，销售团队应以具备丰富销售经验的业务人员组成，对客户群体按行业、所属地进行细化分类，进行分级管理，筛选潜在的客户群进行重点开发，同时积极开拓新的客户群，不断完善销售网络。当公司在社会上已拥有良好的品牌效应，开发的游戏产品在目标市场也有一定的知名度，可以恰当方式与当地渠道运营商结盟合作。借用渠道运营商的销售网络，加之公司品牌效应和客户对产品的认同度，即能节省公司时间、人力、运营等销售成本，又可以完善公司现有的销售渠道，支撑销售份额持续提升。为了能确保各个分销渠道能畅通运行，从总体把控上，有必要制定一套规范、严谨、科学的渠道销售政策，包括但不限于返点政策、区域价格保护、渠道价格等等。同时公司还要加强对各个渠道运营商的技术培训、销售培训等业务支持。对于销售业绩不太好的区域，可以鼓励合作运营商通过承包或买断区域代理权来独家垄断该区域的产品销售，以刺激其推广力度。

　　科技项目运营团队总监郭鹏，毕业于大连工业大学计算机科学与技术专业，目前已经开发出先进的企业办公管理系统，正在开发物联网应用项目，他写了一篇《科技项目研发团队建设》报告，引起了公司领导层的关注。他在报告中写道：

　　科技世界网已进入高速发展筹备阶段，公司拟定成立十大高端团队。作为十大团队中最具创新、设计高新产业的项目研发团队来讲，在本公司以及全国高新产业界都要力求做到高、精、新，团队组建尤为重要。

　　根据国家重大需求和学科发展前沿，现已确立主要研究内容和预期研究目标，即以软件开发为基础，以物联网方面为研究课题，并以此作为长期奋斗目标，最终在物联网领域取得卓越成就而不懈努力。

　　开发团队应具有良好的价值观和大局意识，并在沟通、反馈、勇气和谦逊等方面具备一定的素养。在沟通方面，无论需求分析、详细设计，还是编码、测试阶段，都能够促进你与团队内部人员及你的客户之间的沟通。在反馈方面，Kent Beck在Extreme Programming Explained中有句话讲得非常好：“乐观是编程的职业病，反馈则是其处方。”通过图表来交流你的想法，你可以快速获得反馈，并能够按照建议行事。在勇气方面，勇气非常重要，当你的决策证明是不合适的时候，你就需要做出重大的决策，放弃或重构(refactor)你的工作，修正你的方向。在谦逊方面，最优秀的开发人员都拥有谦逊的美德，他们总能认识到自己并不是无所不知的。事实上，无论是开发人员还是客户，甚至所有的 project stakeholder，都有他们自己的专业领域，都能够为项目做出贡献。一个有效的做法是假设参与项目的每一个人都有相同的价值，都应该被尊重。

　　开发团队不但要在团队精神中不断提高，形成凝聚力，在队伍建设和人才培养方面也至关重要。作为一个软件开发企业，人力资源是一个公司最重要的资源之一，如何组织项目团队，既要保证质量、又要提高效率，是项目管理者需要考虑的最重要的问题。我们需要将技术人员进行分类、尽量作到分工明确;由于公司同时进行的项目很多，应该保证各个项目能共享公司为数不多的“专家”级资源;在设计和开发过程中，尽量保证各个项目的技术、风格、质量基本一致，并且要将项目的质量提升到公司级别，而不仅仅是反映项目组的水平。

　　团队建设不单要将不同特点的开发人员凝聚在一起，形成一支强有力的开发队伍，而且还要最大程度的挖掘每个开发人员的优势，因地制宜，各司其职，这样才能保证项目在正常运行的情况，不断创新，达到超出预期的效果。

　　按照团队人员的特点和担当的责任，将团队人员进行分类，其基本法则主要是为了解决项目质量控制，项目组间资源共享等问题。其基本思路：

　　一是项目的入口同一起点，即：所有项目售前、需求分析阶段由“专家”团队承担。

　　二是系统的设计保证质量，即：系统的设计要汇聚公司的优秀资源，既要考虑系统的需求，又要考虑开发成本，还要结合公司现有的开发技术能力和已有的技术资源。

　　三是系统的开发并行实施，即：系统的开发和编码阶段，由开发部门进行全盘考虑和统一安排，根据项目的进度要求灵活组建开发团队。

　　四是系统的出口归并统一，即：系统测试必须严格把关，由测试部门承担，保证所有系统质量的一致性。系统的发布通过统一的出口，包括包装(如果需要)和各种附加文档(如：使用手册、系统说明书)。

　　传统方法是以项目组为单位，项目组人员基本上从开始到最后基本上是固定的，而该方法是以项目的不同阶段来组织不同的团队，其人员的数量和成员本身随着项目的进程不停的调整。

　　有效的项目团队由担当各种角色的人员所组成。每位成员扮演一个或多个角色，常见的一些项目角色包括：项目经理，是项目管理人员，要求具有良好的沟通能力和管理能力;客户经理，属于市场人员，负责与客户的沟通;技术经理，是开发过程中负责技术管理的人员;

　　售前工程师，需要知识全面。表达能力优秀;需求分析师，需要是业务专家;系统架构师，需要技术能力突出，有丰富的项目经验;界面设计师，需具有一定的业务知识，能快速设计用户界面;系统设计师，属于设计人员;数据库设计师，是数据库设计人员;数据库管理员，也就是我们常说的DBA;技术支持工程师，主要负责硬件、网络支撑;程序员，包括界面开发工程师、业务逻辑开发工程师、数据库开发工程师等。质量保证工程师，是负责质量管理和质量控制的人员;测试人员，需对业务非常熟悉，能从功能和性能方面测试系统;产品包装师，需懂得包装产品，包括各种交付的文档。以上每个角色都应该有清晰的工作定位。并要求具有相应的技能，能在项目的各个阶段出色完成任务，这些称为人力资源，是保证项目成功的最基本的条件。根据项目规模做有效的调配，角色划分上也要做到具体情况具体分析。

　　项目前期主要指的是项目业务需求调研、包括配合用户制定项目建设方案、技术规范书、配合市场人员进行售前技术交流等环节，此阶段应该组织由售前工程师、需求分析师(业务专家)以及系统构架师等组成一个临时小组，负责跟踪项目。这个小组根据项目的大小和客户的要求确定小组成员，一般由3—5名成员组成。

　　项目前期小组的工作是项目的开始，这个小组工作成绩的优劣、工作质量的高低，将直接影响项目的成败。因此，从管理层的角度，一定要重视这个环节。项目前期小组需要完成的工作包括以下方面：

　　一是客户的各种项目前期要求，如：方案介绍、业务需求编写等

　　二是提交项目可行性分析报告，包括成本、效益分析

　　三是提交项目建议方案

　　四是提交业务需求说明书或需求分析说明书

　　系统设计是决定项目或软件系统“怎样做”的过程，这个过程回答了系统应该如何实现的问题。从软件工程的角度，设计阶段大约是整个项目开发成本的25%，所以，设计团队以及该团队的工作成绩对于整个系统来说至关重要。

　　设计团队一般由3—8名设计人员组成，从这个阶段起，项目需要一名项目经理，行使项目组的各种管理职能。设计团队的成员具体包括：1名项目经理; 1—2名项目前期成员;1名系统构架师;2—4名设计人员;1名数据库设计人员;1名用户界面设计人员组成

　　设计团队需要完成的工作包括：项目开发计划;确定系统软硬件配置最佳方案;确定系统开发平台以及开发工具;确定系统软件结构;确定系统功能模块以及各个模块之间的关系;确定系统测试方案;提交系统数据库设计方案;提交系统概要设计文档。由于应用软件需求经常变化，因此设计需要考虑系统可扩展性，并需要在设计过程中对于重要的环节和用户进行及时沟通。

　　将用户的需求变成真正可用的软件系统，是通过编码和系统实现阶段来完成的。虽然软件的质量主要取决于系统设计的质量，但是编码的途径和实现的具体方法对程序的可靠性、可读性、可测试性和可维护性产生深远的影响。这个阶段要根据用户对项目进度的要求灵活组织开发团队，一般5—15左右。为了工作的连贯性，同时也为了解决在开发过程中用户需求有可能变化的因素，开发团队因该保留1—3名设计团队的成员。

　　开发过程中，项目经理的角色非常重要，项目经理负责项目组开发人员的日常管理，控制项目的进度，负责和设计部门、市场部门以及客户之间进行必要的沟通。这个阶段通常是多个部门的人员共同组成一个项目组，因此，项目管理的一定要保证统一管理，理想状态是项目经理全权负责项目组人员的人员工作安排、业绩考核、 工资奖金等，因为项目经理最了解项目组成员的工作态度和工作业绩。

　　一般在大型项目开发团队中，应该设立专门的技术经理岗位，负责对项目组的技术方案进行管控，技术经理最好是由设计团队中抽调出来。技术经理在项目开发过程中需要注意程序风格、编码规范等问题，并必须进行有效的代码管理(版本管理)。

　　开发过程还应该进行系统的单元测试工作，确保各个独立模块功能的正确性和性能满足需求说明书的要求。开发团队应该完成的工作包括：系统的实现代码编写;单元测试;提交源代码清单;提交单元测试报告。

　　在系统测试、软件打包阶段，系统测试阶段在整个软件生存周期中是占据总工作量最大的一个环节，统计资料表明在40%左右，有的时候还可能是其他过程的几倍，因此，必须高度重视软件的测试工作。软件的测试本身是发现软件中的错误，但是发现错误是为了使开发的系统完全满足用户的需求，因此测试工作还伴随着诊断、改正错误、调试等复杂过程，测试也是软件开发最困难的工作。测试这个环节，参与人员除了测试人员以外，还应该包括几乎所有的开发人员，同时我们经常可以把这个环节看作是编码工作的延续，直到完成集成测试、通过测试验收，形成最后的发布版本。经过测试、稳定的软件版本包括相关的文档可以进行打包，作为软件开发的出口。

　　这个阶段，必须严格把关，确保各个开发组完成的软件都是高质量的、同一个水平层次的软件系统。这个阶段完成的工作包括：更改情况说明;集成测试报告;软件发布版本;系统使用说明书;系统安装配置说明书。

　　在工程施工及软件安装阶段，由于从事的应用软件的开发，因此，在开发完成之后经常会有系统集成、软件的安装等工作。这个阶段还经常伴随着新的业务需求和本地化需求的产生，因此将会有一部分的开发工作需要在这个阶段完成。工程实施阶段需要的人员包括：1名项目经理;多名技术支持工程师(硬件、网络支撑);2—4名软件开发人员

　　为提高项目质量，达到创新开发的预期，技术部门未来将在以下几个方面进行再提高。过去项目团队组织模式通常是按照项目组为单位，由项目组从头到尾负责整个项目的需求、设计、开发、实施过程。根据以上讨论，由于应用软件开发的特点，这样 的组织模式已经不能满足高效率、高质量的要求。但是如果完全实行设计和开发完全分开，又几乎不可能达到设计出完美的设计文档、开发只埋头写代码的理想状 态。根据实际情况，一般公司的技术人员主要集中在系统分析部、软件开发部、系统集成部、测试部。系统分析部应该主抓项目前期、系统设计两个环节。开发部应该主抓系统实现和编码、工程实施等环节。

　　在开发阶段，系统分析部以设计人员派出方式参与具体开发过程，同时，在开发过程中，系统分析部应该设立对一个非常设技术机构(包括开发部的项目经理)，负责对项目的关键开发过程进行评审、并对项目的开发过程进行技术把关。另一种开发模式：敏捷开发。简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集 成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。并在开发过程中把握核心原则：

　　一是主张简单：当从事开发工作时，你应当主张最简单的解决方案就是最好的解决方案。不要过分构建(overbuild)你的软件。如果你现在并不需要这项额外功能，那就不要在模型中增加它。要有这样的勇气：你现在不必要对这个系统进行过分的建模(over-model)，只要基于现有的需求进行建模，日后需求有变更时，再来重构这个系统。尽可能的保持模型的简单。

　　二是拥抱变化需求时刻在变，人们对于需求的理解也时刻在变。项目进行中，Project stakeholder可能变化，会有新人加入，也会有旧人离开。Project stakeholder的观点也可能变化，你努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实。

　　三是开发第二个目标是可持续性即便你的团队已经把一个能够运转的系统交付给用户，你的项目也还可能是失败的--实现Project stakeholder的需求，其中就包括你的系统应该要有足够的鲁棒性(robust)，能够适应日后的扩展。就像Alistair Cockburn常说的，当你在进行软件开发的竞赛时，你的第二个目标就是准备下一场比赛。可持续性可能指的是系统的下一个主要发布版，或是你正在构建的系统的运转和支持。要做到这一点，你不仅仅要构建高质量的软件，还要创建足够的文档和支持材料，保证下一场比赛能有效的进行。你要考虑很多的因素，包括你现有的团队是不是还能够参加下一场的比赛，下一场比赛的环境，下一场比赛对你的组织的重要程度。简单的说，你在开发的时候，你要能想象到未来。

　　四是递增的变化和建模相关的一个重要概念是你不用在一开始就准备好一切。实际上，你就算想这么做也不太可能。而且，你不用在模型中包容所有的细节，你只要足够的细节就够了。没有必要试图在一开始就建立一个囊括一切的模型，你只要开发一个小的模型，或是概要模型，打下一个基础，然后慢慢的改进模型，或是在不在需要的时候丢 弃这个模型。这就是递增的思想。

　　五是令Stakeholder投资最大化你的project stakeholder为了开发出满足自己需要的软件，需要投入时间、金钱、设备等各种资源。stakeholder应该可以选取最好的方式投资，也可以要求你的团队不浪费资源。并且，他们还有最后的发言权，决定要投入多少的资源。如果是这些资源是你自己的，你希望你的资源被误用吗。

　　六是有目的的建模：对于自己的artifact，例如模型、源代码、文档，很多开发人员不是担心它们是否够详细，就是担心它们是否太过详细，或担心它们是否足够正确。你不应该毫无意义的建模，应该先问问，为什么要建立这个artifact，为谁建立它。和建模有关，也许你应该更多的了解软件的某个方面，也许为了保证项目的顺利进行，你需要和高级经理交流你的方法，也许你需要创建描述系统的文档，使其他人能够操作、维护、改进系统。如果你连为什么建模，为谁建模都不清楚，你又何必继续烦恼下去呢?首先，你要确定建模的目的以及模型的受众，在此基础上，再保证模型足够正确和足够详细。一旦一个模型实现了目标，你就可以结束目前的工作，把精力转移到其它的工作上去，例如编写代码以检验模型的运作。该项原则也可适用于改变现有模型：如果你要做一些改变，也许是一个熟知的模式，你应该有做出变化的正确理由(可能是为了支持一项新的需求，或是为了重构以保证简洁)。关于该项原则的一个重要暗示是你应该要了解你的受众，即便受众是你自己也一样。例如，如果你是为维护人员建立模型，他们到底需要些什么?是厚达500页的详细文档才够呢，还是10页的工作总览就够了?你不清楚?去和他们谈谈，找出你想要的。

　　七是多种模型：开发软件需要使用多种模型，因为每种模型只能描述软件的单个方面，“要开发现今的商业应用，我们该需要什么样的模型?”考虑到现今的软件的复杂性，你的建模工具箱应该要包容大量有用的技术(关于artifact的清单，可以参阅AM的建模artifact)。有一点很重要，你没有必要为一个系统开发所有的模型，而应该针对系统的具体情况，挑选一部分的模型。不同的系统使用不同部分的模型。比如，和家里的修理工作一样，每种工作不是要求你用遍工具箱里的每一个工具，而是一次使用某一件工具。又比如，你可能会比较喜欢某些工具，同样，你可会偏爱某一种模型。有多少的建模artifact可供使用呢，如果你想要了解这方面的更多细节，我在Be Realistic About the UML中列出了UML的相关部分，如果你希望做进一步的了解，可以参阅白皮书The Object Primer -- An Introduction to Techniques for Agile Modeling。

　　八是高质量的工作：没有人喜欢烂糟糟的工作。做这项工作的人不喜欢，是因为没有成就感;日后负责重构这项工作(因为某些原因)的人不喜欢，是因为它难以理解，难以更新;最终用户不喜欢，是因为它太脆弱，容易出错，也不符合他们的期望。

　　九是快速反馈：从开始采取行动，到获得行动的反馈，二者之间的时间至关紧要。和其他人一共开发模型，你的想法可以立刻获得反馈，特别是你的工作采用了共享建模技术的时 候，例如白板、CRC卡片或即时贴之类的基本建模材料。和你的客户紧密工作，去了解他们的的需求，去分析这些需求，或是去开发满足他们需求的用户界面，这 样，你就提供了快速反馈的机会。 软件是你的主要目标：软件开发的主要目标是以有效的方式，制造出满足project stakeholder需要的软件，而不是制造无关的文档，无关的用于管理的artifact，甚至无关的模型。任何一项活动(activity )，如果不符合这项原则，不能有助于目标实现的，都应该受到审核，甚至取消。

　　十是轻装前进：你建立一个artifact，然后决定要保留它，随着时间的流逝，这些artifact都需要维护。如果你决定保留7个模型，不论何时，一旦有变化发生 (新需求的提出，原需求的更新，团队接受了一种新方法，采纳了一项新技术...)，你就需要考虑变化对这7个模型产生的影响并采取相应的措施。而如果你想 要保留的仅是3个模型，很明显，你实现同样的改变要花费的功夫就少多了，你的灵活性就增强了，因为你是在轻装前进。类似的，你的模型越复杂，越详细，发生 的改变极可能就越难实现(每个模型都更“沉重”了些，因此维护的负担也就大了)。每次你要决定保留一个模型时，你就要权衡模型载有的信息对团队有多大的好处(所以才需要加强团队之间，团队和project stakeholder之间的沟通)。千万不要小看权衡的严重性。一个人要想过沙漠，他一定会携带地图，帽子，质地优良的鞋子，水壶。如果他带了几百加仑 的水，能够想象的到的所有求生工具，一大堆有关沙漠的书籍，他还能过得去沙漠吗?同样的道理，一个开发团队决定要开发并维护一份详细的需求文档，一组详细 的分析模型，再加上一组详细的架构模型，以及一组详细的设计模型，那他们很快就会发现，他们大部分的时间不是花在写源代码上，而是花在了更新文档上。

　　在达到以上核心原则的基础上，我们还要做到在内容、工具、开发精神与合作意识上的提升，要明确内容比表示更重要：一个模型有很多种的表示方法。例如，可以通过在一张纸上放置即时贴的方法来建立一个用户界面规格(基本/低精度原型)。它的表现方式可以是纸上或白板上的 草图，可以是使用原型工具或编程工具建立和传统的原型，也可以是包括可视界面和文本描述的正式文档。有一点很有意思，一个模型并不一定就是文档。它们通常 作为其它artifact的输入，例如源代码，但不必把它们处理为正式的文档，即使是使用CASE工具建立的复杂的图表，也是一样。要认识到一点，要利用 建模的优点，而不要把精力花费在创建和维护文档上。

　　了解三人行必有我师：你不可能完全精通某项技术，你总是有机会学习新的知识，拓展知识领域。把握住这个机会，和他人一同工作，向他人学习，试试做事的新方式，思考什么该做，什么不该做。技术的变化非常的快，现有的技术(例如Java)以难以置信的速度在改进，新的技术(例如C#和.NET) 也在有规律的产生。现存开发技术的改进相对会慢一些，但也在持续的改进中--计算机产业属于工业，我们已经掌握了其中的试验基本原理，但我们还在不断的研 究，不断的实践，不断的改进我们对它的了解。我们工作在一个变化是家常便饭的产业中，我们必须通过训练、教育、思考、阅读、以及和他人合作，抓住每一个机 会学习新的处事之道。

　　同时需要开发人员了解你的模型：因为你要使用多种模型，你需要了解它们的优缺点，这样才能够有效的使用它们。 了解你的工具：软件(例如作图工具、建模工具)有各种各样的特点。如果你打算使用一种建模工具，你就应当了解什么时候适合用它，什么时候不适合用它。

　　必要时，开发人员需进行局部调整。你的软件开发方法要 能够反映你的环境，这个环境包括组织特征，project stakeholder的特征，项目自身的特征。有可能受其影响的问题包括：你使用的建模技术(也许你的用户坚持要看到一个细节的用户界面，而不是初始草 图或基本原型);你使用的工具(可能你没有数字照相机的预算，或是你已经拥有某个CASE工具的license);你遵循的软件过程(你的组织采用XP的开发过程，或是RUP，或是自己的过程)。因此你会调整你的方法，这种调整可能是针对项目的，也可能是针对个人的。例如，有些开发人员倾向于使用某一类工具，有些则不用。有些人在编码上花大力气，基本不做建模，有些则宁可在建模上多投入一些时间。

　　在团队合作上，开发团队应进行开放诚实的沟通。人们需要能够自由的提出建议，而且人们还应该能够感受到他们是自由的。建议可能是和模型有关的想法：也许是某些人提出某部分新的设计方法，或是某个需求的 新的理解;建议还可能是一些坏消息，例如进度延误;或仅仅是简单的工作状况报告。开放诚实的沟通是人们能够更好的决策，因为作为决策基础的信息会更加准确。利用好人的直觉：有时你会感觉到有什么地方出问题了，或是感觉什么地方有不一致的情况，或是某些东西感觉不是很对。其实，这种感觉很有可能就是事实。随着你的软件开发的经验的增加，你的直觉也会变得更敏锐，你的直觉下意识之间告诉你的，很可能就是你工作的关键之处。如果你的直觉告诉你一项需求是没有意义的，那你就不用投入大量的精力和用户讨论这方面的问题了。如果你的直觉告诉你有部分的架构不能满足你的需要，那就需要建立一个快速技术原型来验证你的理论。如果你的直觉告诉设计方法A要比设计方法B好，而且并没有强有力的理由支持你选择某一个方法，那就尽管选择方法A。勇气的价值就已经告诉你，如果未来证实你的直觉是错的，你也有能力来挽救这种情况。你应该有这种自信，这很重要。