HWTL工作指导书.doc

HWTL工作指导书

NTS RF TL 工作指导书

目 录
第1章 NTS RF TL 岗位职责 4
第2章 交付流程规范 4
2.1 NTS 专业服务项目交付流程规范 4
2.1.1 目的与范围 4
第3章 项目启动阶段 5
3.1 配合 PM完成项目立项和任命 5
第4章 项目准备阶段 5
4.1 制定项目实施计划 6
4.2 分析项目验收风险，制定对策 6
4.3 项目开工会 (内部) 7
4.4 项目开工会 (外部) 8
第5章 项目执行阶段 8
5.1 建立与客户的周例会制度 8
5.1.1 制度化 8
5.1.2 规范性 9
5.1.3 Action list 9
5.1.4 主渠道 10
5.2 内部周例会和周报制度 10
5.2.1 RF 团队周例会制度 10
5.2.2 RF 团队周报制度 10
5.3 制定项目交付技术方案，组织评审 11
5.4 监控工程质量，推动问题整改 11
5.5 跟踪和解决项目执行过程中各类问题 12
5.6 加强合作方管理，提高过程质量 12
5.6.1 低端分包 12
5.6.2 中高端分包 13
第6章 项目收尾阶段 14
6.1 项目交付文档上传归档 14
第7章 工作参考 15
7.1 整体管理 15
7.1.1 项目过程中 TL 变动，如何完成交接 15
7.1.2 项目组成员离开，如何完成交接 16
7.1.3 如何完成向维护团队的交接 17
7.2 范围管理 18
7.2.1 客户没有购买网优服务，以其他理由要求华为免费投入资源解决 18
7.2.2 如何处理工程实施团队和代维团队的工作界面问题 18
7.3 质量管理 19
7.3.1 如何做好 VIP 区域和 VIP 用户的保障，提高客户满意度 19
7.4 人力资源管理 20
7.4.1 如何确定项目组组织结构，明确各岗位职责 20
7.5 沟通管理 22
7.5.1 如何推动客户在验收报告上签字 22
7.6 风险管理 23
7.6.1 如何安排测试计划，降低验收风险 23

22 / 22
第1章 NTS RF TL 岗位职责
RL TL 对服务交付实施的计划、资源、风险等各方面进行管理，保证交付质量和内外部客户的满意度。作为现场 RF 团队的 Leader，RF TL 还需对团队组织气氛、团队成员提高成长负责。
在项目组中，RF TL 直接向项目经理汇报。有的专业服务项目规模较小，且以 RF 类服务产品交付为主，此时，有可能由 RF TL 兼任整个交付项目组的 PM。
要胜任 RF TL 的岗位，应具备以下能力：
1. 规划优化技术基础扎实，熟悉规划优化业务流程
2. 具备良好的沟通协调能力
3. 有全局观，对风险敏感，能够分清问题的主次
如下图所示：

第2章 交付流程规范
2.1 NTS 专业服务项目交付流程规范
2.1.1 目的与范围
NTS 专业服务项目交付流程规范适用所有NTS交付项目。通过规范NTS项目交付中的“12个交付活动”和“5个监控点”，同时细化经营和成本管理，以此来确保NTS项目交付和NTS业务的正常持续运作。

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

图7-1 按功能划分的项目组织结构
l NTS RF TL
对NTS项目的最终交付结果负责。同时，负责项目范围定义 (如定义活动、S-BOM向B-BOM的映射分解、子任务分解等) ，负责项目的成本管理 (如估算成本和制定预算等) ；负责项目的资源计划制定，项目进度监控和问题反馈；负责项目的沟通管理 (如协调各功能团队之间的工作流和相互配合等) ；负责项目中合作策略的制定、合作分包招标以及合作资源的管理。
l 客户接口
负责同客户的日常沟通，接收客户的信息反馈，管理客户期望值等。
l 技术支持组
负责项目中的技术规范制定
负责技术类(特别是产品相关) 问题收集、跟踪和解决。
l 路测组
按照项目经理制定的计划，进行路测，按照规范提交路测记录。
l RF分析组
对路测数据进行分析，解决各类 RF 问题。
l 性能监控组
收集和分析话统数据，输出性能监控报告，发出性能问题预警，解决常见的性能问题。
功能型组织结构的优势：
(1) 小团队的工作目标与任务比较明确，有专人负责，交付质量容易控制。
(2) 同区域性组织结构相比，提高了工作效率与反应速度，如共性问题可得到迅速共享和传递。
(3) 资源调配相对合理，可以按照人的特点分配到不同的团队，充分发挥人的积极性和特长。
功能型组织结构的缺点：
(1) 小团队之间联系较弱，