hwtl工作指导书.doc

hwtl工作指导书 作为现场RF团队的Leader，RF TL还需对团队组织气氛、团队成员提高成长负责。 在项目组中，RF TL直接向项目经理汇报。 有的专业服务项目规模较小，且以RF类服务产品交付为主，此时，有可能由RF TL兼任整个交付项目组的PM。 要胜任RF TL的岗位，应具备以下能力1.规划优化技术基础扎实，熟悉规划优化业务流程2.具备良好的沟通协调能力3.有全局观，对风险敏感，能够分清问题的主次如下图所示第第2章交付流程规范2.1NTS专业服务项目交付流程规范2.1.1目的与范围NTS专业服务项目交付流程规范适用所有NTS交付项目。 通过规范NTS项目交付中的“12个交付活动”和“5个监控点”，同时细化经营和成本管理，以此来确保NTS项目交付和NTS业务的正常持续运作。 NTS RF TL工作指导书图2-1NTS专业服务交付流程图第第3章项目启动阶段项目启动阶段主要任务是完成项目的立项以及任命，同时，作为承上启下的阶段，在项目启动阶段需要从售前网规获取足够的投标信息，了解前因后果。 这些信息记录了投标阶段的过程以及客户的关注点、相互的争执点，将对后期的工作方式以及重心产生较大影响。 3.1配合PM完成项目立项和任命项目开始立项时，RF TL或许还没有正式加入项目组。 因此，项目立项和任命的工作可以由地区部PM或者RF TL完成。 项目立项和任命主要有以下工作?项目组关键岗位人员的任命(含NTS TL)?合同交底，投标经理将合同等相关信息传递给项目TL?客户特殊需求等信息收集第第4章项目准备阶段项目准备阶段可以说是项目执行过程中最重要的阶段，是高效、成功交付的基础。 在此阶段，主要完成项目实施计划、任务分解，资源计划制定和获取，交付和验收阶段的风险识别、解决等。 NTS RF TL工作指导书4.1制定项目实施计划NTS的实施计划是基于项目主计划制定的，在制定NTS项目实施计划前，先要对项目主计划进行评审、反馈或直接参与制定。 以避免引起由于项目主计划制定的不合理，导致NTS服务实施过程中出现重大风险。 对于项目主计划的内容有以下几点需要注意的 (1)预留给网络优化的时间是否合理。 如Network TuningService，一般需要4周的时间。 需要避免由于设备安装延迟，压缩优化时间的情况出现。 (2)工程安装计划是否符合NTS按照Cluster设定的安装顺序。 4.2分析项目验收风险，制定对策NTS项目常见风险类别包括?资源风险(人力和工具资源)?时间风险?市场及客户关系风险?技术风险其中资源风险在资源计划中考虑，时间风险在项目实施计划合理评估中进行分析，项目的验收风险分析主要是市场及客户关系风险、技术风险，具体的来说就是评估客户关系、合同质量和验收KPI的难度等。 1.市场及客户关系风险市场及客户关系在项目中主要体现在客户引导能力和客户需求管理方面。 在项目初期的评估，主要从周边了解以及市场预约客户高层情况等判断；项目执行过程中，主要从市场能否拒绝客户的额外、过度需求，市场能否有效引导客户进行收费服务等方面进行评估。 如果在客户关系方面存在风险，作为NTS来说只能尽量将运作和技术层面的工作做踏实，提升客户对NTS工作的满意度，避免成为客户投诉的焦点。 2.技术风险从最终验收角度看，技术风险主要是合同质量和验收KPI的难度，有以下内容?工作界面是否清晰、交付件是否明确?验收范围、方法和评判标准是否清晰?产品版本是否存在风险?是否存在过承诺(特别是突破公司销售禁止条款的承诺)NTS RF TL工作指导书如果合同中工作界面等不清晰，将会直接影响到任务的分解和后续资源计划，有可能导致大量的无效工作投入。 需要联合客户经理和行销产品经理，同客户尽快明确。 如果验收范围、方法和评判标准不清晰，就无法实现契约化交付。 这是一把双刃剑，在客户关系良好的背景下，可能会降低我们验收的难度，但多数情况下，模糊的验收范围、方法和评判标准，将导致我们为提高所谓的客户满意度不得不巨额投入。 因此，需要联合客户和行销产品经理尽快明确验收范围、方法和评判标准。 如果产品存在版本风险，比如首个商用局等，需要联合机关NTS PMO、技术支持一起推动研发维护部等成立定向工作组，组织专人到一线支持。 如果合同有过承诺的情况，过承诺问题需要及时反馈TL。 总而言之，项目验收风险分析和对策需要做到清晰、明确，避免工作和责任界面模糊化，建议使用风险管理表来明确风险责任人、完成时间等。 4.3项目开工会(内部)NTS内部的项目开工会是在TL的项目策划报告(包括前面提到的项目实施计划、资源计划、合作分包策略、项目验收风险分析等内容)的基础上进行讨论和评审。 项目开工会由一线NTS TL发起。 如果涉及的网络结构复杂、新技术应用较多，可单独组织技术方案的评审会。 技术方案的评审会也由NTS TL发起，TS作为技术方案的负责人主要讲解，必要时可邀请研发网规解决方案部和其他相关部门如性能部、解决方案测试部等。 会议必须形成会议纪要，明确在会议中发现的问题、解决方案等，必须明确问题的优先级、责任人、完成时间等。 问题的跟踪需要纳入项目的问题跟踪表，并作为下次项目分析会的输入材料之一。 4.4项目开工会(外部)在项目启动以后，PM会与客户一起组织召开项目开工会，主要目的是宣告项目正式开始，介绍项目组组织结构，双方参与人员及相互间的接口关系。 RF TL在参与项目开工会前，应根据开工会的议程，准备好相关材料，一般有1.自我介绍的材料2.RF team组织结构和关键成员介绍NTS RF TL工作指导书第第5章项目执行阶段5.1建立与客户的周例会制度在项目交付中，与客户之间建立一种互信合作的关系，对项目的顺利交付非常重要。 过往经验表明，绝大多数客户不满都是由于不了解、不信任而产生的。 为了避免沟通障碍，提高沟通效率，在项目交付阶段，与客户之间建立周例会制度是十分有必要的。 RF TL应在项目启动后的两周内，与客户对口部门约定周例会制度，将时间、参与人员等确定下来。 周例会制度要起到好的效果，需要注意以下几点 (1)制度化一周一次，双方都有固定参与人员 (2)规范性会前发会议通知；会后minutes和action list (3)Action list以action list作为会上所有结论的载体，做好持续跟踪 (4)主渠道引导客户将问题放到例会上讨论，减少事件性汇报交流下面就分这几方面展开说明。 5.1.1制度化1.时间例会一般以周为周期。 双方应约定好固定的会议时间，便于提前做好日程安排，避免时间冲突。 如果项目组还有更高级别的例会，RF的周例会最好安排在前一天，便于就项目组例会上将要讨论的议题提前达成一致的意见。 周例会制度一旦确定，就要一直坚持。 RF TL要为每周的例会做好充分准备，不能因为没有重要的问题需要讨论就随意取消，可以安排action listreview和进展汇报作为固定的例会议题。 2.与会人员固定与会人员?华为方RF TL和RF团队内各职能组的负责人?客户方网优部门主管和技术骨干、区域负责人可邀请参加的与会人员?华为方服务经理、PM?客户方客户网优部门的上级主管，一般是副总、CTO、GPM等NTS RF TL工作指导书5.1.2规范性TL应该在每次例会召开前一天，征求客户意见，确定并发送会议议程(meeting agenda)给所有与会人。 错误!未找到引用源。 给出了一个meeting agenda的样例。 在会议结束后，TL应该完成会议纪要(meeting minutes)，发送与会人确认，同时抄送项目组内相关人员(如PM、其他职能组TL、客户CTO等)。 错误!未找到引用源。 未找到引用源。 给出了一个meeting minutes的样例。 除了会议纪要，对于会上形成的决议和遗留问题，还应形成任务跟踪项(action item)的形式，放到任务跟踪表(action list)中跟踪落实。 关于action list的价值和使用，放在5.1.3中介绍。 5.1.3Action list前面讲到，每周的例会，除了meeting minutes，还应该将形成的决议和遗留问题更新到action list中进行跟踪落实。 虽然meeting minutes中也有会议结论和待跟踪事项，但实际项目中，不少事项需要比较长的时间才能落实，为了避免这些待跟踪事项丢失，把它们汇总到action list中是推荐的做法。 实际上，在双方接受这种形式以后，用action list取代例会的meeting minutes也是完全可行的。 在错误!未找到引用源。 中给出了action list的样例，可以看到，每一个action item都有编号，责任人和完成时间。 在整个项目执行的过程中，action list应该作为RF团队与客户之间任务跟踪的唯一依据，不仅仅是例会，其它形式的沟通产生的待跟踪事项，双方确认后，也都应加入这个action list。 在每次例会中，应将第一个议题固定设置为action list的review，最后一个议题固定设置为本次会议形成结论的summary和更新后action list的确认。 通过以上安排，明确了action list对双方的约束力，可以使客户养成按时完成各项配合工作，提高项目运作效率。 当然，action list中责任人为我方的项目，我们也应该高度重视，说到做到，按期完成。 5.1.4主渠道有的客户习惯事件触发地把TL拉过去要求汇报进展，或者抱怨、反映问题，这会占用TL大量宝贵时间。 TL应有意识地引导客户，把这些问题放到例会上讨论，这样做对客户来说也是有明显的好处的，因为主要的相关人都可以参加，问题能够得到澄清，形成的结论也能更好地得到跟踪落实。 客户形成了将周例会作为双方沟通的主渠道以后，可以大大提高双方沟通的效率和质量，对项目运作有很大的好处。 NTS RFTL工作指导书5.2内部周例会和周报制度5.2.1RF团队周例会制度RFTL是RF团队的leader，做好内部的沟通也同样重要，RFTL应在RF团队人员到位，组织结构明确后，建立内部的周例会制度。 RF团队的例会要坚持每周都开，传递从“项目组例会”以及“同客户的网规例会”中获取的有效信息，这里的有效信息主要包括网规网优目标新增或变更、进度要求等。 除此之外，还需要在RF团队内部完成个人计划制定、经验共享、问题答复等。 RF团队的周例会建议安排在“同客户的周例会”和“项目组例会”之后进行，以便重要信息(需求，意见，问题，解决方案等)及时传递。 在RF团队周例会中，对团队成员提出的问题要及时反馈，给与相应的帮助或者解释；在个人计划制定过程中，要让团队成员知晓自己近期的明确目标；任务不紧急的时候，可以在RF团队周例会上，组织大家进行问题讨论和技能传递，方便不同工作任务的同事之间的交流，以及加深团队成员对当前项目问题的了解程度。 在多数项目中有合作方的加入，需要注意信息安全问题，涉及公司产品和华为内部问题的讨论，可以放在周例会的后半段，合作方人员退场后进行。 5.2.2RF团队周报制度项目周报主要是描述当前工作进展情况、存在问题等，以及项目的历史记录。 是项目分析会以及前后方沟通的基础材料，项目周报的主送对象是项目组全体成员以及所在项目组的PD、TD等相关领导，抄送对象是NTS机关、系统部、产品行销、TSD、NRO等相关人员。 项目周报的发送对象并不是越多越好，在项目成立之前就应该规划好给哪些人员发送，否则可能会造成不必要的麻烦。 项目周报的发送绝对不应该只是将附件粘贴在邮件中，而需要将主要内容描述在邮件正文中，给与相关人员足够的提示，让读者能很快找到本次周报的重点所在。 在附录错误!未找到引用源。 中提供了一个项目周报的样例，可供参考。 5.3制定项目交付技术方案，组织评审TL是技术管理岗位，应对项目交付技术方案的制定负责。 作为TL，在制定项目技术方案前，应获取以下信息作为参考?工作范围(SoW:Scope ofWork)?责任矩阵(Responsible Matrix)?交付件(deliverables)NTS RFTL工作指导书?客户对本专业服务的期望5.4监控工程质量，推动问题整改对于与工程服务捆绑的RF专业服务，工程质量，特别是天馈安装质量，对RF交付至关重要。 工程质量环节的遗留问题，会给处于后端的RF交付带来时间、资源的大量消耗，交付质量也得不到保证，在这方面，前人有深刻的教训。 在工程质量监控管理方面，RFTL应主动出击，做到以下几点 (1)要在项目组内做好宣传教育工作在项目组内部强调工程安装，特别是天馈安装正确的重要性，RFTL应推动在项目组内PM、基站侧、合作方侧达成共识(比如专职QA、罚款措施等)，以会议纪要等书面形式保留记录。 (2)要想办法让交付团队中的各个team都来承诺各自工序的质量(如天馈接反率)，引导整个项目组对工程质量的重视度。 (3)关注工程质量保证的基本工作得到实施如工程安装的合作方入场前的上岗培训(重点关注是否会测量方位角和下倾角，是否规范了天馈色环使用标准等)。 每一种站型要做示范站安装，形成统一的标准。 督促项目组采用有一定资质的合作方。 (4)项目组的QA资源往往有限且主要关注走线的规范性、接地次数等纯工程问题，而不太关注天馈安装质量问题(方位角下倾角安装不准确、馈线接反、面板连线等)，RF团队在项目初期可以主动安排资源，对初期站点进行100的质量检查，发现典型问题，用数据说明，推动解决，通过这一过程实现质量可控。 工程质量受控之后，可以改为20%抽查。 (5)在工程实施阶段，要求项目组配置专用整改资源。 这样做可以避免工程实施抢占资源，导致整改工作迟迟无法开展。 (6)在项目组内部形成问题回溯、问责机制，由于工程安装质量问题(比例过高如超过20%)导致NTS重测或者额外投入的，需要相关部门作出内部罚款或赔偿。 (7)如果工程安装是在客户界面的，特别注意要在早期阶段向客户传递质量控制的流程方法、合作方的管理要求，对发现的质量问题要及时通报并要求整改。 5.5跟踪和解决项目执行过程中各类问题TL的工作头绪比较多，项目交付过程中各类问题都要跟踪和推动，维护一个完整的问题跟踪表，把项目中各类问题统一管理，是良好的工作习惯，可以避免问题丢失，降低风险。 NTS RFTL工作指导书项目中需跟踪处理的问题可以分为运作类问题和技术问题两大类 (1)运作类问题包括计划类问题、资源类问题、客户需求类问题等 (2)技术类问题包括产品类问题、工具类问题等在错误!未找到引用源。 中给出了一个项目问题跟踪表的样例。 一般要求TL作为项目问题跟踪表的更新责任人，以确保TL了解所有这些问题的进展。 在一些规模较大的项目中，可以将技术类问题分列出来，由TS负责状态的维护更新。 5.6加强合作方管理，提高过程质量引入合作方是可以有效降低交付成本，在近几年的RF项目中，交付资源合作比例有越来越高的趋势，合作方所承担的工作界面也从原来的路测、勘测低端分包，扩展到以站点、区域为单位的中高端分包。 合作方管理的好坏，直接影响到交付成本和质量，需要RFTL在项目执行阶段作为一项重点工作加以关注。 本节区分不同的分包方式，谈一谈合作方管理中TL的职责和工作要点。 5.6.1低端分包在一些RF项目中，将RF交付中路测、勘测等基本模块分包出去，合作方只对投入的资源数量、质量、完成的工作量、工作模块输出质量负责，而不对最终项目KPI是否达到验收标准负责。 这种分包方式我们一般称为低端分包。 在低端分包的项目中，合作方以路测队、勘测队的角色出现在项目中，他们的工作一般由TL或者Region-TL来安排。 也有的项目中，为了提高资源利用率，将这些队伍集中起来作为各个区域共享的资源池，专设一个合作方接口人1，所有需求汇总到这个接口人处统筹安排，制定计划。 对于低端分包的管理，有以下几点需要注意 (1)对投入资源的数量和质量进行检查低端分包中，合作方降低自身成本的最有效措施就是尽量减少投入资源数量，以及提供价格便宜的生手。 作为TL，在低端分包的合同中，应将资源数量、质量的最低标准明确说明，并附加罚则，以便执行阶段的管理。 合作方资源到位以后，可以通过面试、试用等方式，确认其人员质量是否达到标准要求。 (2)提供明确的交付件质量标准，严格把关低端分包的工作模块通常没有太高的技术含量，对于这些模块，我们应提供明确的交付件质量标准，并严格把关。 1这个接口人可以由合作方提供，称为coordinator。 NTS RFTL工作指导书 (3)提前到位，培训演练合作方人员在开展工作前，需要先熟悉华为的模块工序、交付件质量标准和工具，这个现场培训演练一般需要一到两周的时间。 在分包合同中应明确说明各类资源的到位时间，并附加罚则。 (4)制定效率基线，不断提升对于每一个队伍每天能够完成的工作量，TL应有准确的估计。 在项目的计划制定中，应从实际的效率基线出发。 项目初期，允许效率基线低于工时基线，但应制定提升计划，尽快达到并超过工时基线要求。 (5)控制人员流动有的项目中会出现合作方人员流动比例过大，导致产出效率和质量长期无法稳定的情况。 针对这一问题，建议在合同中对人员流动的规则增加说明替换人员应提前到位，通过交接期的试用，确认输出可以达到标准后方可完成替换等。 对于低端分包，最常见的问题是当项目超期时，合作方提出extra charge的要求，导致合作成本超出预算。 为了规避这一风险，CEG在进行合同招标时，会倾向于按站点报价的方式，但这也提高了合作方的报价(增加了风险因素)，对控制成本不利。 在华为的一些搬迁项目中，有按人天报价，或者明确限定单站平均测试次数，从而降低合作成本的成功案例。 不过，对于新建网项目，工程超期的几率很高，这样做需要十分谨慎。 大部份项目在进行低端分包时，会选择多于一家的合作对象，按报价高低划分不同份额。 应该在合同中增加条款，说明当所提供的资源数量、质量，或者交付件达不到标准时，华为有权调整份额甚至引入新的合作方。 这样可以加强合同条款的约束力，便于执行阶段的管理。 5.6.2中高端分包所谓中高端分包，是指可以直接对应到承诺给客户的交付件分包出去，合作方的验收与客户给华为的验收直接挂钩的分包方式。 在中高端分包中，合作方需要提供不同岗位的人员组成项目组来完成交付，通常还会配置管理人员。 华为在这类项目中投入会比较少，主要是TL和熟悉产品的SE，通过与合作方的manager来实施管理。 由于华为项目普遍存在的超标、超界面承诺，这一合作方式的成功运作高度依赖TL与合作方的沟通情况，相对低端分包来说难度要大不少。 对于采用中高端分包界面的项目，TL应注意以下几点 (1)熟悉合同，利用合同条款去管理TL应仔细研读分包合同，熟练掌握合同中可应用于合作方管理的条款。 如果TL从项目开始时参与了合作分包，应在合同中加入尽可能多对我们将来管理合作方有利的条款如项目执行过程中有权要求更换人员、交付件以华为审核通过为准等。 NTS RFTL工作指导书 (2)建立与合作方的周例会制度为了对合作方所分包工作内容的进展、质量、风险等进行监控，与合作方之间建立例行沟通制度是必不可少的。 (3)增加过程输出的质量要求为了对过程质量进行控制，除了最终给客户的交付件，还应该对交付基本过程和过程输出进行约定，并做好这些过程输出的把关，以及时发现问题和风险。 (4)对合作方的需求、投诉等通过正规途径(传真、会议纪要、信件等)发送为了保留对交付过程进行回溯的权利，对合作方的重要需求、投诉应以正规的途径发送。 (5)对投入资源的中高端部分，应坚持面试确认这一点在合同中也应提前做好约定，因为这些中高端资源，直接影响到最终的交付质量。 此外，面试的过程，与前面提到在合同中预留华为要求更换人员的权利一起，都有助于加强华为方TL对这些中高端资源的影响力。 当然，在项目交付过程中由于各种原因需要进行人员替换时，替换人员同样必须经过面试确认，并通过现场交接期考察后方可正式上岗。 (6)信息安全中高端合作方在项目中会接触到比较多的项目内部信息，需要将项目中的信息安全要求作为工作制度明确下来，制定相应罚则，避免敏感信息泄漏带来不必要的麻烦和损失。 第第6章项目收尾阶段6.1项目交付文档上传归档NTS RFTL依照项目总结报告模板，完成NTS项目总结，对项目质量、实施管理、技术问题、客户体验等各方面进行总结。 NTS项目交付过程中的所有文档要求在代表处的服务器存档，同时要求根据产品属性归档到机关相应服务器上。 1.项目总结报告模板RFTL在项目验收完成后(建议两周内)输出项目总结报告。 在项目总结时要关注实际交付过程与原计划的比较，要涵盖以下要素 (1)进度计划进度和实际进度的比较； (2)资源计划资源和实际投入资源的比较； (3)质量包括项目交付质量，输出件的规范性，交付动作规范性等方面； (4)满意度关注客户评估的满意度；NTS RFTL工作指导书 (5)风险以项目执行过程中产生的风险LOG为基础,对风险进行归类和对具体的关键风险本身进行分析； (6)人员培养总结在项目实施过程中对交付人员技能以及其他素质的提升有哪些有效途径； (7)经验和建议总结项目经验并对以后NTS项目交付提出合理化建议第第7章工作参考这部分内容以Q&A的形式，介绍项目运作过程中常见问题的对策、处理思路和一些技巧性的经验。 这些问题按PMP九大知识领域进行分类。 7.1整体管理7.1.1项目过程中TL变动，如何完成交接 (1)如果在项目中TL发生变动，新RFTL必须熟悉此项目的RF交付流程，一定要把各项与RF相关的工作内容传递给新TL (2)要把RF业务人员接口关系和责任矩阵给新TL传递清楚，最好要带新TL一一认识业务相关人员，如合作方的沟通和分工介绍；客户领导和与RF相关部门人员的介绍和沟通；与项目经理和项目组其他成员的沟通，与机关支持部门接口人的介绍与沟通等 (3)交接时长根据项目大小与重要性确定，一般要求不少于1个月，交接期间邮件同时抄送给原TL，工作开展以新TL为主，原TL协助 (4)原TL要负责写好工作交接报告，报告中要包括项目背景客户、项目组、RF团队组织结构的介绍工程进展验收标准已经完成的工作(包括完成的时间点)待完成的工作项目中存在的风险点 (5)项目文档的交接，包括NTS RFTL工作指导书项目计划项目周、日报项目交付文档问题跟踪表工程参数表各类报告案例工程里程碑以前的重要会议纪要以前的技术通知等 (6)工具、车辆管理的交接等其他事物7.1.2项目组成员离开，如何完成交接 (1)人员轮换或离开最好提前一个月做好计划，保证关键岗位1至2周的工作交接时间。 对于一些与客户存在接口关系的替换人员，需要提前告知和安抚相关客户；同时尽量避免大量人员在同一时间轮换，特别要避免中方员工的签证在相近时间到期而造成大量人员同时替换。 对于骨干人员，根据地区部预算，可沟通将关系下到地区部，保证项目组RF人员的稳定性； (2)离开项目组的成员要把自己当前承担的工作、进展、待跟踪事宜写成交接报告发送给工作交接人和项目组所有成员。 这样可以让项目组和交接人对该成员的工作情况一目了然，同时也方便交接人员了解到自己的工作任务，从而迅速的融入到项目组； (3)与交接人员的沟通。 离开项目组的成员最好有1-2天与交接人员面谈或电话沟通的时间，这样可以很好地帮助交接人员了解项目情况； (4)项目文件，特别是项目中自制的模版、小工具的共享。 在项目中往往有一些重复的工作，我们往往会制作些小工具来避免这种重复工作，这是项目中经验的积累结晶，共享这些模版和小工具可以提高不少工作效率； (5)项目文档的归档。 离开项目组的成员应该把自己负责的、未及时归档的文件进行归档，避免项目文档的缺失； (6)离开人员要及时完成项目总结报告与案例的写作与归档； (7)离开人员要及时归还工具给项目组。 NTS RFTL工作指导书7.1.3如何完成向维护团队的交接维护转移是由网络建设阶段向网络维护阶段转移的一个步骤，目的是把网络维护工作由工程人员平稳地转交给网络维护人员承担，一般而言网络验收或商用后，工程人员就要为维护转移作必要的准备，维护转移结束的时间点要依据合同要求。 进入运行维护阶段后，网络的维护方式有2种，即客户维护和代维维护2种。 由于在工程维护期结束后，将网络的维护工作移交给客户承担，这种情况比较简单，因此本节不做阐述。 一般向维护团队交接工作，需要包括以下内容 (1)现网信息(包括工程参数总表、网络参数配置表、网络性能数据、客户投诉、历史的工程优化文档、VIP区域信息等)，以便维护团队了解当前网络的规模和网络质量情况； (2)代维合同条款的理解交接双方都要通读代维项目服务合同信息，熟读网规网优部分内容，明确交付目标以及验收标准； (3)维护团队要依据合同要求确定项目组成员以及人员的技术要求，依据合同要求配置仪器设备。 依据合同要求制定项目目标、界面、责任矩阵、验收等内容； (4)日常优化工作的交接，包括日常KPI监控外部干扰监控与分析、告警分析、话统分析日常优化小区网络参数数据库分析、外部干扰清除记录、用户投诉信息分析、VIP及热点区域网络质量监控与分析、路测数据收集、路测分析、CQT测试、针对网络问题的优化调整执行记录、优化结果确认、站点定期勘查及信息确认； (5)文档的交接，包括日常网优计划、RF工程参数数据库维护、网络调整申请单、审核网络问题调整申请单、网络参数调整记录备案、网络调整操作备案、簇优化报告、KPI日报/周报/月报、维护优化日/周/月报、网络维护优化报告、网络可持续发展调整建议等； (6)客户接口人的介绍和沟通。 7.2范围管理7.2.1客户没有购买网优服务，以其他理由要求华为投入资源解决客户没有购买网优服务，但是以网络质量问题或产品问题为由要求华为投入资源解决，这种情况下如何处理？NTS RFTL工作指导书 (1)首先明确网优服务属于专业服务范畴，必须在有合同的基础上才能投入相应资源。 (2)对于这种没有购买网规网优服务的项目，在项目开始之初要识别出来，加强客户引导，明确工程网优的价值和交付内容（SOW）。 如果客户执意不购买，要明确我司契约化交付，降低客户期望值，从前端规避此问题 (3)如果客户以产品类的问题为由提出让华为投入网规网优资源解决的要求，客户应有足够的证据说明其怀疑的理由。 然后我们以此通过内部的费用结算来确定成本归属。 (4)如果代表处出于战略和客户关系方面的考虑，要求NTS提供网规网优服务，也应通过内部费用结算的方式确定NTS收入，以保障NTS的经营指标。 7.2.2如何处理工程实施团队和代维团队的工作界面问题在很多项目,工程实施和代维服务都是由华为交付,如何处理工程实施团队和代维团队的工作界面问题？ (1)站点移交由工程实施团队、代维团队、客户三方制定明确的站点移交清单，输出单站验证报告等。 对NTS而言，需要关注前期报告清单（规划报告、仿真报告、工参表、勘测报告、路测报告、优化报告等），硬件质量问题（驻波比、天馈安装质量、天线是否接反等）。 (2)人员复用工程实施组和代维组不少骨干和工程师都是复用。 在不影响客户满意度的情况下，是可以允许的，但要确保两个团队的各个模块有专职人员负责，避免责任不清晰。 如客户对人员复用表示明确反对，在客户机房人员尽量确保专职，只负责代维事宜。 (3)站点质量问题在站点移交初期，不少工程实施项目为了尽快的交站确认收入，不少有质量问题的站点也要移交给代维团队，这样站点质量问题经常会在两个团队之间纠缠。 可以让双方PM沟通达成一致，交站后的1-3月内质量问题由工程团队负责处理解决。 7.3质量管理7.3.1如何做好VIP区域和VIP用户的保障，提高客户满意度主要从VIP优化和投诉处理两方面着手去提高满意度。 1.VIP优化VIP区域要与客户一起确定。 对VIP区域要重点测试和优化，输出详细的分析报告，对于网络覆盖空洞以及可能引起的问题提前提出建议和预警。 NTS RFTL工作指导书对于VIP用户的常用路线和常去的场所，如上下班路线、常吃饭锻炼的场所，要定期摸底测试和优化。 如有覆盖缺陷、传输配置不足等客观因素，要主动提出建议。 2.投诉处理VIP投诉是个双刃剑，投诉处理的好，通过在投诉中与VIP客户的沟通树立威信和服务的品牌(平时可能很少有与VIP客户接触的机会)，对整个项目实施和验收都大有好处。 相反，处理的不好、不及时，会导致问题像滚雪球一样多起来。 因此，TL要积极面对VIP投诉，化被动为主动。 VIP投诉对客户RF主管也是压力很大，及时完美的处理了VIP投诉实际上就是帮助了客户RF主管，同样也对验收有利。 对于VIP投诉要成立专门的处理队伍，安排优势力量投入。 在客户允许的前提下，可以对VIP进行信令跟踪，方便分析；也可以通过PCHR的过滤出VIP客户的驻留小区信息，从而获得VIP经常活动的区域和推断出路线，对这些路线和区域进行保障。 投诉处理的重点包括两方面，处理结果和处理过程，很多时候处理过程更为重要。 过程关键点体现在?响应投诉的及时性；?对投诉处理的投入和重视程度；?及时向客户汇报进展；?处理投诉的态度。 投诉处理结果要与投诉人沟通、或者向客户解释，可以对每个VIP投诉处理完成后写分析报告提交给客户。 7.4人力资源管理7.4.1如何确定项目组组织结构，明确各岗位职责NTS项目组组织结构同PMP中的职能式组织结构、项目式组织结构和矩阵式结构不太相同。 在NTS项目操作过程中，一般可以分为三类1.区域划分的组织结构。 在各区域单独划分各类角色(如RF区域TL、区域SE等)，相当于成立若干个独立的小项目组。 这种组织结构对于资源的消耗较大，效率较低，区域之间的共性问题也无法得到及时共享和传递。 因此，在当前NTS的项目组织结构中已经基本不再采用了。 NTS RFTL工作指导书2.按功能划分的项目组织结构按功能划分的组织结构，是按照不同的岗位责任进行组织结构的划分。 采用功能型的组织结构一般是规模较小的项目，分布的区域也不大，可以比较容易的进行团队内的面对面沟通。 如下图所示是一种常见的功能性组织结构。 根据项目的实际情况如站点数量、地理分布位置、资源情况等，以下岗位可以考虑合并，如NTS RFTL兼顾客户接口的岗位。 图7-1按功能划分的项目组织结构?NTS RFTL对NTS项目的最终交付结果负责。 同时，负责项目范围定义(如定义活动、S-BOM向B-BOM的映射分解、子任务分解等)，负责项目的成本管理(如估算成本和制定预算等)；负责项目的资源计划制定，项目进度监控和问题反馈；负责项目的