项目何时进入维护或 TMA？
在其整个生命周期中，该网站经历了不同的阶段和参与者。设计涉及顾问、UX 和 UI 专家，开发涉及技术专家和开发人员，整体管理由职能项目经理负责。一旦在线实施和保证通过，这就是我作为TMA项目经理的角色发挥作用的地方 ：项目切换到阶段和维护合同。
将与我的同事职能项目经理进行交接，然后我将开始处理客户提出的更正和开发请求。
该请求是否是一个修 如何建立电话号码清单 正性的、不断发展的请求？
在Adimeo，我们实际上有两种类型的合约 ：修正型TMA和进化型TMA。我的首要任务是满足每个客户的要求……这是一种异常现象还是一种演变 ？
>纠正性 TMA仅涵盖异常情况的纠正。
但什么是“功能性”异常呢？ （异常，异常，这是有争议的……）。异常必须根据标称状态来定义，而SFD（详细功能规范）则确定了在设计期间定义的标称状态。
例如，如果客户告诉我“我发现这个页面有一个错误：文章的章节没有出现”。我正在深入研究神圣的 SFD，以检查是否是，计划在此页面上出现一章。如果“否”，任何矮子都不应该回到这个地方，这不是异常，而是一种演变。
当我们谈论异常时，我们基本上会检查功能的行为是否符合 SFD。
>可扩展的 TMA涵盖不需要设计阶段的开发请求
对于任何开发请求，我都会问自己：“请求是否足够精确，足以让开发人员直接参与？是否会冒与客户多次来回澄清需求的风险？”如果没有这一条黄金法则，当开发请求需要的开发时间少于 2 小时时，它将在 TMA 中处理。但由于有多少个代理机构就有多少个 TMA 合同，这只是一个例子。
TMA 是否涉及结构开发？
不，TMA 通常不用于处理需要设计阶段的大规模开发。作为项目经理，我还必须能够与我的团队一起确定必须经过设计阶段并因此超出 TMA 框架的开发。
TMA 如何计费？
TMA按花费的时间或按固定价格计费。如果我在需要设计阶段时处理 TMA 请求，则可能会导致处理请求的时间和成本加倍，更不用说由此带来的失望了。
例如，以复杂形式修改步骤可能看起来很快，但它们之间数据的依赖性可能会影响链人体工程学问题，并且可能需要 UX/UI 研讨会。
为什么网站一旦上线就需要新的干预措施？
原因很简单，网站是一种在不同环境、不同用户配置文件、不同时间使用的工具……用例越多，客户就越能识别出需要优化的功能。
TMA 的时间是 MOA（项目所有者）和服务提供商共同努力改进该工具的长期的一部分。
为了管理这些请求随着时间的推移不断流动，我依靠灵活但重要的方法框架。
网络研讨会
如何成功进行用户测试？
下载支持
我的日常生活：长期的优先顺序、食谱和客户关系
在设计站点时，TMA 项目经理的日常生活与职能项目经理的日常生活非常接近。
它包括：
20%的会议；
35%功能配方；
35% 团队简报；
10% 团队规划。
通常，项目经理处理的不是单个项目，而是多个项目，而他不了解这些项目背后的业务和功能。因此，依赖不同的工具和记录项目知识非常重要。
票务工具：限定请求并确定请求的优先级
为了监控请求，使用票务工具非常重要，它允许我跟踪请求处理周期。
在最著名的票务工具中，我们 TMA项目经理的经历 可以举出Redmine、Mantis。 Adimeo 选择在内部开发自己的票务工具 Adimeo Project Manager (APM)，以便使该工具最好地适应该机构的特定方法和流程。
举个例子，
客户创建一个请求，要求其网站符合“ CNIL GDPR ”要求；
我在票证中列出了要采取的行动以及功能影响；
客户向我表示同意 ；
我与其他开发人员一起规划开发；
开发完成后，我将执行已开发功能的配方（我的阅读建议Web 项目的配方：如何成功？）；
如果一切对我来说都是有效的，我会发表评论并将票发回给我的客户，以便他可以制作自己的食谱；
如果开发在客户端得到验证，则部署将在不同的环境中完成，并且工单中的来回继续，直到最终的 MEP（投入生产）；
一旦开发在生产中得到验证，我的客户就会关闭该票证。
我可以使用电子邮件与客户沟通，但我很快就会迷失在交流的流程中。因此，重要的是每个请求的交换都集中在单个工具中并“历史化”。
如何创建 TMA 票证？
为了确保快速有效地处理每个请求，我要求我的客户执行以下操作：
根据请求创建一张票证。
例如，如果请求涉及将 Facebook 和 Twitter 帖子上传到网站；我需要两张票，因为两个社交网络的开发和测试不同；
限定请求的严重性：Blocking、Major或Minor ；
这种重要性将使我能够确定团队工作的优先顺序和并行化，同时也知道是否必须紧急处理异常情况。一些维护合同定义了GTI（干预时间保证），它定义了根据故障单的重要性必须处理多长时间；
之后，票证的内容根据请求类型的不同而有所不同：
对于异常请求 ：
提及浏览器的版本和所使用的操作系统的版本。是的，此信息对于有关前端的异常非常有价值，因为例如从一个浏览器到另一个浏览器，显示可能会有所不同。
检查预期行为是否与初始 SFD 一致 ；
截取屏幕截图并标明相关页面的 URL；
（可选）指示哪个用户配置文件遇到异常。
对于开发请求 ：
在票证中准确详细说明需求；
如有必要，制作与请求相关的采购订单。
小提示：Browerstack 等工具可以让您在没有物理终端的情况下模拟不同屏幕和浏览器上的显示。
项目委员会：每天互相交谈并一起工作
TMA 项目委员会围绕客户的利益进行讨论
请求并非仅通过票务工具处理。我需要定期与客户进行口头沟通，以确保我们能够很好地理解对方。我们在项目委员会（每周或每月）期间举行会议，最多持续30 分钟。
这些委员会旨在务实并将项目的 加拿大电子邮件线索 运营人员聚集在一起（最多 3-4 人）。例如，如果我无法重现异常，我会要求我的客户重现它，一起导致异常的用户旅程。
项目委员会使得简化课题的进展成为可能。这种关系和由此产生的信任是宝贵的，因为 TMA 再次发生在很长一段时间内。这也许是我个人更喜欢的部分：倾听、理解业务问题并共同努力，即使一切并不一定总是顺利……我还必须知道如何接受客户的不满并尝试找到解决方案。知道如何做。当不可能时说不。但这种平衡行为对于所有项目管理来说都是常见的。
报告：定义行动计划
交谈和交流是一回事，但记住是另一回事…就我而言，我需要在项目委员会结束时写一份报告（CR），以便对每个请求都有一个清单和一个行动计划。就我个人而言，我以受声明信息决策行动启发的格式编写 。
