软件项目管理

软件项目管理2011/11/7目录基本概念软件项目需求管理软件项目进度管理软件项目质量管理软件项目成本管理软件项目配置管理软件项目风险管理软件项目沟通管理软件项目团队管理王海舰的就业指导课基本概念软件项目管理软件企业商业模式业务模式软件定制软件外包软件产品（嵌入式软件）软件服务（SaaS）软件运营代表公司中软、浪潮大连华信用友、华为百度盈利模式项目收入－项目成本（单位工作量收入－单位工作量成本）×工作量产品收入－产品投入（研发、市场）－升级成本服务费用－系统投入（研发、市场）－维护成本服务费用－系统投入（研发、市场）－维护成本客户群政府或企业软件、集成公司政府、企业或个人企业或个人企业或个人客户数量极少少多多众多收入稳定性差一般好好极好利润率低低高高高市场投入大小极大小极小研发投入极大极大大小小维护投入大小大小小风险极大小大小极小需求来源单一较单一众多众多众多“管”、“理”和“管理”“管”是“管控”、“监督”，“理”是“梳理”、“理顺”“管”是执行规章制度，“理”是制订规章制度“管理”就是制定，执行，检查和改进。制定就是制定计划（或规定、规范、标准、法规等）；执行就是按照计划去做，即实施；检查就是将执行的过程或结果与计划进行对比，总结出经验，找出差距；改进首先是推广通过检查总结出的经验，将经验转变为长效机制或新的规定；再次是针对检查发现的问题进行纠正，制定纠正、预防措施，以持续改进。“管理”是“管”和“理”的统一，是科学与艺术的统一，是例行与例外的统一，是运营与项目的统一。“项目”“项目”是一个组织为实现自己既定的目标，在一定的时间、人员和资源约束条件下，所开展的一种具有一定独特性的一次性工作。“项目”是为创造特定产品或服务的一项有时限的任务。项目的特性：目的性：任何一个项目都是为实现特定的组织目标服务的独特性：项目所生成的产品或服务与其他产品或服务都有一定的独特之处一次性/时限性：每一个项目都有自己明确的时间起点和终点，都是有始有终的，而不是不断重复、周而复始的制约性：每个项目都在一定程度上受客观条件的制约，最主要的制约是资源的制约其它特性：包括：不确定性、风险性、过程的渐进性、成果的不可挽回性、组织的临时性和开放性等项目与运营的区别与联系区别：工作性质与内容的不同：“运营”中存在着大量的常规性、不断重复的工作或劳动，而“项目”中则存在较多创新性的一次性工作或劳动。工作环境与方式的不同：“运营”工作的环境是相对封闭和相对确定的，而“项目”的环境是相对开放和相对不确定的。组织与管理上的不同：一般运营工作的组织是相对不变的和相对持久的，运营的组织形式基本上是分部门成体系的。项目的组织是相对变化的和相对临时性的，项目的组织形式多数是团队性的。联系：项目的循环往复是运营，运营的单个片段是项目“谈恋爱”是项目，“过日子”是运营“吃饭”是运营，“吃某一顿饭”是项目“项目管理”项目管理就是为了满足甚至超越项目涉及人员对项目的需求和期望而将理论知识、技能、工具和技巧应用到项目的活动中去。为满足或超越项目涉及人员的需求和期望，需要在下面这些相互冲突的要求中寻求平衡：明确表示出来的要求（需求）和未明确表达的要求（期望）有不同需求和期望的项目涉及人员范围、时间、成本和质量质量成本时间范围美国项目状况项目平均预算超出90%，进度超出120%项目总数33%既超出预算又进度推迟52.7%的项目费用是原估算的189%以上只有16.2%项目按预算和进度完成平均时间超出量是原估算的222%。在大公司，只有9%的项目按预算，按进度完成“软件项目”软件项目是指以软件开发为主要工作内容的项目；软件项目特点：项目干系人的复杂性--甲方、乙方、第三方以及每一方内部错综复杂的组织结构；项目目标的不确定性--干系人的利益冲突导致项目目标的飘忽不定；项目范围的易变性--也就是软件需求的易变性，有诸多成因；项目质量的不可控性--也就是软件质量的不可控性；项目人力资源的稀缺性--每一个环节都需要一批专家；高风险性--经常发生意想不到的突发事件。软件项目容易失控的原因特别的需求管理模糊和不精确的交流脆弱的架构过度复杂未检测出需求，设计和实现中的不一致测试不足对项目状况的估计过于乐观未解决存在的风险无法控制变化的传播自动化程度不足出自美国IBM公司Rational产品首席科学家

GradyBooch

“软件项目管理”软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员（People）、产品（Product）、过程（Process）和项目(Project)进行分析和管理的活动。软件项目管理和其他的项目管理相比有相当的特殊性。首先，软件是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保证。其次，软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。Windows这样的操作系统有1500万行以上的代码，同时有数千个程序员在进行开发，项目经理都有上百个。这样庞大的系统如果没有很好的管理，其软件质量是难以想象的。再次，软件项目管理最主要的是对人员的管理，尤其是相关人员基本都是高学历、高素质的年轻人。软件项目需求管理软件需求的相关概念需求获取需求分析需求验证需求跟踪需求变更控制需求需求：需求是指人们对于某种事务的需要，体现为意向、愿望和兴趣，是促成行动的直接原因。有显性的，也有隐性的。显性需求来源于用户的“客观需要”，这些“需要”被分析、确认后形成完整的文档，详细说明项目“必须或应当”做什么。隐性需求来源于客户的“主观需要”，无法被量化，但必须被重视。软件需求的类别需求类型软件需求设计约束功能性需求非功能性需求可靠性性能适用性软件需求工程所有与需求直接相关的活动通称为需求工程。软件需求工程是应用工程化的方法、技术和规范来开发和管理软件的需求。软件需求工程是科学与艺术的结合。科学主要用来保证显性需求，艺术主要用来保证隐性需求软件需求管理的主要困难软件需求的主要来源直接和间接使用软件系统的用户；市场调查和用户问卷调查；已开发出的和待开发的同类软件系统的描述和文档；对人工系统的存在问题的报告和增强要求；观察正在工作的用户；对用户工作内容的分析。软件需求收集技巧1—面谈用户面谈是一种十分重要而直接的需求获取方法，是一种在任何情况下都可以使用的简单、直接的方法。需要注意的是要确保面谈者的偏见或易于动摇不会妨碍到信息的自由交换。只要面谈者脑子里把握住目标，话题偏题一点没有关系。软件需求收集技巧2—问卷调查问卷调查可用来确认假设和收集统计倾向数据。在完成初次面谈和分析后，问卷调查作为一项辅助技术可以收到良好的效果。如果系统应用有大量现成的或潜在的用户，目标是获得关于客户或用户在有限选择项中的倾向性统计数据时，问卷调查可以在短时间内高效的收集大量数据。问卷调查不能取代面谈中人与人的接触、友好关系的建立和不拘形式的交互。其他技巧也不能。问卷调查压制了许多获取需求的好技术，通常不推荐只用它进行需求获取。软件需求收集技巧3—需求专题讨论会需求专题讨论会是被设计来在较短的时间内促成与会者在需求上达成共识，对操作过程尽快取得同一意见。它将项目的主要风险承担人在短暂而紧凑的时间段内集中在一起，一般1到2天，集中对系统所要提交的高级特征进行创建和审阅。它也许是启发需求的最有力技术。结果是，一个在特征级别上的初步系统定义很快被产生。充分的准备和使用有需求管理经验的联络员是需求专题讨论会成功的关键。软件需求收集技巧4—角色扮演开发团队从用户的角度体验用户的世界。很多用户不能清晰的表达出他们所遵循的过程以及必须解决的问题；许多用户没有承认他们不遵循所规定过程的自由。任何开发人员都无法预见到所有必须问的问题，任何用户也不可能预见到开发人员需要的所有问题。开发团队的每一个成员简单的扮演用户的角色，执行客户的工作。适用于功能密集而不是算法密集型的项目。很多情况下，角色扮演并不实际。软件需求收集技巧5—原型开发为了启发需求，我们通常选择构建一个舍弃型的、水平的、基于用户接口的需求原型，而不是演化的、垂直的、基于技术可行性的体系结构原型。需求原型是软件系统的部分实现，构建该原型帮助开发人员、用户以及客户更好的理解系统的需求。要针对模糊的用户需求部分开发需求原型。开发舍弃型的原型要求采用实现示例最快、最便宜的方法。开发演化原型必须选择最终系统的实现语言和开发环境，要花大力气为系统设计软件结构，而且要遵循编码标准和过程规范。否则将引入重大的缺陷。原型建成后，应该让尽可能多的用户在尽可能接近最终系统运行环境的环境中使用。 非功能性需求非功能需求是衡量软件能良好运行的定性指标。由于缺乏定量指标，因此很难根据这些需求来评价软件系统，这也是开发出来的软件系统与用户所满足的软件系统之间存在差异的主要原因。用户所关心的非功能需求主要有：可靠性；在给定的时间和规定的条件下，系统能完成所要求的功能的概率，常用平均无故障时间和平均修复时间表示可扩充性；系统能方便和容易的增加新功能，常用增加新功能时所需工作量的大小表示安全性；防非法访问、防数据丢失、防病毒入侵等互操作性；与其他系统交换数据和服务的难易程度健壮性；系统遇到非法输入数据以及在异常情况和非法操作下，能继续运行的程度易使用性；用户学习和使用系统功能的简易程度，以及系统输出结果易于理解的程度可维护性：发现并纠正一个故障或进行一次修改的简易程度可移植性：把系统从一种运行环境移植到另一种运行环境所花费的工作量可重用性：系统中的某个构件可以在其他应用系统中使用的程度确定软件需求的优先级确定优先级的意义帮助项目相关人员判断系统的核心需求，并有助于项目相关人员集中于重点问题的交流和协商；形成需求基线；根据需求的优先级权衡合理的项目范围和进度安排、预算、人力资源以及质量目标的要求。在确定了所有需求的优先级后，必须把每个需求优先级记录入需求规格说明中，并可通过设置相应的字段给予标识。软件需求确认的内容和方法内容正确性一致性完备性可实现性可验证性无二义性必要性方法自查走读评审软件需求跟踪需求跟踪需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。需求跟踪有两种方式：正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。软件需求变更控制需求变更通常会带来一系列的问题，如需求间的影响（即当一个需求更改后对其它需求的影响），需求更改对设计和实现的影响等。为了有效地管理需求变更，应该考虑以下几方面的工作：控制项目范围的扩展；变更控制策略；变更控制的步骤变更几乎是不可避免的通过合同控制《用户需求说明书》通过《用户需求说明书》控制后续变更提前和客户沟通，确定阈值，超过部分坚决抵制，或者交换软件需求变更控制流程软件项目进度管理项目策划项目跟踪与监控软件项目策划WBS分解项目估算制定其他计划制订进度计划项目分工进度安排编写项目计划评审项目计划项目跟踪控制开始结束WBS分解WBS（WorkBreakdownStructure）是识别项目所应完成的各项工作的工具WBS是项目管理工作的基础，是项目工作量估算、编制进度计划、费用计划、人力资源计划的前提，也是项目跟踪的必要条件项目范围内工作的细分，归纳和定义形成项目的《工作任务分解表》WBS分解的要求分解后的任务应该是：可管理的、可定量检查的、可分配任务的、独立的复杂工作至少应分解成二项任务每项工作的持续时间不能太长不体现工期和任务的先后顺序要包括管理活动：项目管理、质量保证、配置管理、项目总结等任务分解是大家商讨出的，不是项目经理自己定的。软件项目估算规模估算工作量估算进度估算人员估算成本估算项目经理选择具有应用领域内的经验、敢于承担责任、有声望的估算人员3-5人组成估算小组,并确认组长；项目经理准备与估算相关的材料；估算组长召开会议,确认待估算的条目(Item),并和将使用的《Delphi个人估算表》分发给估算小组成员；估算小组成员进行独立估算,并填写《Delphi个人估算表》；估算组长汇总并分析个人估算表；估算组长召开会议组织讨论和汇总,对于估算相对偏差大于30%的条目评估小组成员讨论差异；（最大偏差=最大估值-最小估值；平均值=估值总和/估算人数；相对偏差=最大偏差/平均值)重复4～6步骤直至达成一致意见DELPHI估算法规模、工作量和工期估算规模：项目（系统）大小的度量。工作量：完成一（多）项任务花费的人时（天、月）数量。工期：完成一（多）项任务花费的时长（小时、天、月）。三者关系理论上：工作量＝规模/生产效率理论上：工期＝工作量/人数实际上：？进度安排及任务分工进度安排根据规模估算，推算出各种类型工作的工作量根据工作量估算和工作任务分解表安排进度计划某项任务的子任务工作量之和应在该项任务的工作量估算范围内任务分工项目经理根据项目组人员数量和每个人的技能情况进行合理分工分工应充分争取有经验人员及当事人意见制定进度计划甘特图计划制订的依据估算结果进度要求（计划倒排）资源限制计划优化工期优化、资源优化软件项目跟踪和监控会议周例会专题会协调会报告个人周报项目周报专题报告总结报告项目跟踪表跟踪甘特图.......时间管理—时间矩阵紧急不紧急重要不重要讨论：可以举例说明哪些事情各属于哪个象限吗？虚假的必要的领导的浪费的马上做尽早做委托别人做不做紧急不紧急重要不重要考试上课火灾锻炼身体孝敬父母防患于未然打牌三缺一聊天电话看欧洲杯决赛无关紧要的邮件部分琐碎的工作抽烟普通人的时间安排25-30%15%50-60%2-3%紧急不紧急重要不重要成功人士的时间安排20-25%65-80%15%<1%紧急不紧急重要不重要软件项目质量管理质量保证：针对过程评审：针对文档软件测试：针对代码质量保证的概念软件质量保证的目的是保证软件开发过程按照一定的规范执行。好的过程质量并不等于好的产品质量，但是糟糕的过程很难带来好的产品质量。为了较好地开展软件质量保证工作，软件质量保证人员应该是独立的，与项目经理没有任何行政隶属关系，对他的考核与评价也不应由项目经理做出，同时他也不能承担本项目中除软件质量保证外的其他任何工作，以确保其独立性。质量保证的内涵SQA的责任是检查软件项目的活动并鉴别活动中出现的与公司规范不一致的偏差。软件质量保证的主要工作包括以下三个方面：通过监控软件的开发过程来保证产品的质量；保证生产出的软件和软件开发过程符合相应的标准与规程；保证软件产品、软件过程中存在的不符合问题得到处理，必要时将问题反映给高级管理者。质量保证的主要工作公司标准培训指导审核评审评审评审不符合问题处理流程发现不符合项项目经理同意并解决将项目经理不同意解决的不符合项提交事业部分管经理SQA将事业部分管经理、SQA经理和管理者代表的处理意见传达有关人员,由项目经理安排人员处理问题被豁免SQA跟踪检查、确认NoNo是否当时解决YesNo解决SQA将事业部分管经理不同意解决的不符合项提交SQA经理协商处理解决YesYesYesNoNoSQA经理将自己无法协商处理的不符合项提交管理者代表裁决解决不符合项关闭Yes将不符合项录入TD文档评审评审类别主要的评审内容评审方式评审负责人参与角色备注技术评审需求文档单人/小组概要设计详细设计数据库设计用户界面设计文档测试用例测试分析报告用户手册维护手册管理评审软件项目开发计划配置管理计划质量保证计划测试计划验收计划安装实施计划里程碑报告项目总结报告软件需求评审步骤软件测试V模型需求分析概要设计详细设计编码集成测试系统测试单元测试代码审查基本概念项目预算费用控制软件项目成本管理项目利润=项目收入-项目成本-项目费用项目成本/费用的构成采购成本代理成本人员费用车船费市内交通费住宿费业务费办公费不可预见费用软件项目成本管理的基本概念请看《费用预算表》软件项目预算费用跟踪和分析费用月报费用分析+解决措施降低费用的常用方法尽量用合适的人千万不能人浮于事制订费用标准，统一执行进行费用考核，让成员自己主动节约费用软件项目费用控制软件配置管理配置管理的意义配置管理的相关概念配置管理的功能配置管理的概念软件配置管理是一门技术、管理和监督相结合的学科，通过标识和文档来记录配置项的功能和物理特性，控制这些特性的变更，记录和报告变更的过程和状态，并验证它们与需求是否一致。配置管理的主要概念配置项基线SCCB版本并行开发和分支系统建立SCM主要概念－配置项配置项定义：是一个硬件，软件或硬、软件的集合，配置项是为了配置管理而指定的，并在配置管理过程被当作单一实体。配置项包括：项目计划；SCM计划；需求定义文档；分析、设计、编码和审核标准；系统分析文档；系统设计文档；原型；高层设计文档；低层设计文档；系统测试规格说明书；系统测试计划；源代码；目标码和可执行文件；单元测试说明；单元测试计划；数据库设计文档；测试数据；用户手册等。SCM主要概念－基线基线定义：已经经过正式评审或批准的，作为以后进一步开发的基础，只有通过正式的更改控制流程才能进行更改的配置项。在配置项的生命周期中，在特定时间经过正式认定的一个或一组配置标识文档。基线加上经过审批的基线变更，共同组成了当前的配置标识。基线是SCM的一个重要概念，它帮助实现对变更的控制SCM主要概念－SCCBSCCB(SoftwareConfigurationControlBoard)－软件配置控制委员会SCCB的作用：审定软件基线的建立和配置项/单元的标识。代表项目经理和所有可能受到软件基线更改影响的组的利益。评审和审定对软件基线的更改。审定由软件基线库制造的产品的生成。配置管理的功能配置标识配置控制配置审核状态统计SCM配置标识变更控制状态统计配置审核与复审配置标识配置标识的过程由三部分组成：选择、命名、描述。配置项的取舍并没有硬性规定，主要取决于经验和良好的判断力。不恰当的配置项选择将会导致花费增加、时间延长，甚至在软件开发期间和维护期间导致增加额外的管理和技术负担。一个系统配置项的数量是由负责SCM系统设计的人来决定的。配置项的选择要做到“不多也不少”。每个软件部件都必须具有独一无二的标识。标识方法包括命名约定，版本排序和文字标签。变更控制变更是软件开发过程中最基本的特性。开发过程的所有阶段从需求分析到产品再到维护都围绕着变更来进行。对软件实施变更是容易的，但管理这些变更却不容易。状态统计在软件开发过程中为了收集数据应尽早开始跟踪CI的状态。配置管理系统应能够有效的记录SCM活动并能在数据库中自动更新活动的状态。配置项状态报告配置审计实施配置审计以维护配置基线的完整性。配置审计确认最终的基线和文件有遵照特定标准或需求，并适当记录审计结果。何时开始审计工作？通常是在开发生命周期中每个阶段的末尾开始审计工作。审计工作都干什么？为了保证所有人员（包括项目成员、配置管理员和CCB）都遵守配置管理规范，要定期审计配置管理工作。配置审计是一种“过程质量检查”活动。由谁执行审核工作？通常由管理者、QA部门或客户执行审核工作。配置管理总结配置评审配置标识配置状态发布配置控制开发库测试库基线库产品库通过单元测试的代码评审通过的基线文档需变更的文档和代码发布的最终版本其他工作产品通过系统测试的代码软件项目风险管理风险定义风险识别风险度量风险控制软件项目风险定义项目风险的定义项目风险是指由于不能准确预见或控制的因素，而引发的使项目受到损害的事件。项目风险产生的原因人们的认识能力所限信息本身的滞后特性项目的各种不确定性项目风险的主要特性随机性渐进性相对可预测性潜在损失特性软件项目风险的识别项目风险识别的概念识别和确定项目究竟有哪些风险，这些项目风险究竟有哪些基本的特性，这些项目风险可能会影响项目的哪些方面。项目风险识别的主要内容包括：识别并确定项目有哪些潜在的风险识别引起这些风险的主要因素识别项目风险可能引起的后果经验数据法通过分析以往同类项目经常出现的风险，来识别本项目可能的风险头脑风暴法运用创造性思维和专家经验，通过会议的形式去分析和识别项目风险经验数据+头脑风暴软件项目风险识别的方法软件项目风险度量项目风险度量的内容项目风险发生概率P项目风险后果严重程度H项目风险的重要性I（I=

P×H）项目风险影响范围项目风险发生时间项目风险的优先级根据I的大小进行排序关注重要性最高的前6~8个风险风险预防措施—尽量让其不发生风险容忍：不管它—不采取任何措施风险规避：设法完全避免—搞清原因，彻底解决风险延迟：尽量推迟风险发生的时间—情感、待遇、前景留人，留不下就拖风险消减：逐步降低风险发生的概率和影响—培养接班人风险转移：用一个破坏性小一些的风险代替—赶走他讨厌的人风险处理措施—尽量减少已发生风险的破坏性风险消减：减少风险带来的影响—做好工作交接风险分担：利用团队的力量应对风险—安排两个人接替他的工作风险转化：转危为机—向老板要一个更厉害的人过来软件项目风险应对措施举例：项目的一名骨干人员有离职的风险需要进行哪些沟通怎样进行这些沟通软件项目沟通管理软件项目干系人之间的关系软件项目主要沟通方式沟通方式参与人周期目的技术文档沟通项目组内部、客户阶段性传递工作成果一对一口头沟通有关系的干系人不定期各种目的个人周报项目组成员撰写，项目经理沈阳一周汇报进度、解决问题项目周报项目经理撰写，客户及公司领导审阅每周一次汇报进度、协调资源、解决问题项目周例会项目组核心人员、有关客户每周一次汇报进度、协调资源、解决问题月度项目分析会公司领导、各项目经理、职能部门每月一次汇报进度、协调资源、解决问题问题协调会项目经理、客户、公司领导根据需要解决重大问题项目技术评审文档作者、项目经理、评审专家阶段性确定技术文档是否合格项目管理评审文档作者、项目经理、客户、公司领导阶段性确定管理文档是否合格集体活动（运动、吃饭、旅游等）项目组成员、客户阶段性沟通情感、强化关系项目总结报告项目经理撰写，客户及公司领导审阅一次性汇报成果，总结经验和教训高效的会议明确会议目的找到合适的参会人员做好通知做好准备工作不但规定开始时间，同时提前规定结束时间把控会议方向和进度形成结论，做好记录落实并检查实在不行站着开会沟通的两个重要原则知识的诅咒游戏1：在同伴身上用手拍一段歌曲的旋律，让他猜是哪首歌换位思考游戏2：手指自上而下旋转，观察顺时针变为逆时针沟通管理四象限别人知道别人不知道自己知道自己不知道公开象限隐私象限盲点象限潜能象限名字性别大部分日常工作不良嗜好痛苦经历默默奉献暗恋牙齿上粘了根韭菜自以为是领导、同时对你的看法明天你会怎么样20年后你会成为一个什么样的人自我揭示寻求反馈D.D.S不好意思说忘了说，或者以为没有必要说尊重与信任要想获得成功，尽可能扩大公开象限反馈的艺术反馈分为正反馈（表扬）和负反馈（批评）正反馈的艺术：及时说其不常被人说的优点负反馈的艺术：B：事实（而非评价）I：影响C：结果软件项目团队管理团队特征和要求团队发展阶段团队精神项目经理的职责团队的基本特征共同认可的明确的目标合理的分工与协作积极的参与互相信任良好的信息沟通高度的凝聚力与民主气氛学习是一种经常化的活动软件项目团队成员的基本要求具备项目工作所需要的技能成员自身的需要可以通过参与项目而实现应具有与其他成员相融的个性不反对项目工作的各种约束………形成阶段震荡阶段规范阶段辉煌阶段项目团队的发展阶段解体工作绩效团队精神形成阶段是项目团队的初创和组建阶段。在这个阶段中，团队成员由个体而归属于一个团队，总体上有一种积极向上的愿望，团队成员的情绪特点包括：激动、希望、怀疑、焦急和犹豫，在心理上处于一种极不稳定的阶段。在这一阶段，项目经理需要为整个团队明确方向、目标和任务，为每个人确定职责和角色，以创建一个良好的项目团队。项目团队的形成阶段这是项目团队发展的第二阶段。这一阶段，团队成员按照分工开始了初步的合作，有些成员会发现项目的工作与个人当初的设想不一致，有些会发现项目团队成员之间的关系与自己期望的不