分析项目成员管理场景的活动。在添加或移除团队成员时，需要通过OA系统发送通知。通知的发送不在目标系统范围内，也不是由某个参与者发起，而是在添加或移除了团队成员之后进行，属于业务服务的执行步骤，不需要列入图20-15所示的业务服务图。
项目计划管理也分成了两个阶段，合并为一个业务服务图，如图20-16所示。
问题管理业务场景的业务服务图如图20-17所示。
“问题”（issue）概念的获得并非一蹴而就。一开始，我倾向于使用任务（task）来表达这一概念，然而，在需求管理体系中，任务与用户故事（user story）、史诗故事（epic）、缺陷（defect）属于同一等级的概念，我需要寻找到一个抽象概念来同时涵盖这几个概念，由此就得到了“问题”概念。在Jira和GitHub的需求管理工具中，都使用了这一领域概念。
项目管理者在创建问题时，会指定问题的基本属性，如问题的标题、描述、问题类型等。那么，问题所属的迭代、承担人（owner）、报告人（reporter）是否也属于问题的属性呢？在确定问题管理业务场景的业务服务图时，我确实困惑不已。例如“分配问题给迭代”与“分配问题给项目成员”都可以认为是在编辑问题的属性。既然业务服务为角色提供了服务价值，很明显，无论是将一个创建好的问题分配给迭代，还是将其分配给项目成员使其成为问题的承担人，都具有项目管理价值，是由项目管理者向目标系统发起的一次独立而完整的功能交互，应该分别识别为两个业务服务。
在确定项目管理的业务服务时，统一语言再一次发挥了价值。最初在确定项目管理的业务流程时，项目管理者要查看问题的完成情况以了解迭代进度，故而将该流程中的一个活动命名为“查看问题完成情况”。在识别业务服务时，我认为该名称没有清晰地体现该业务服务的服务价值，经过与业务分析人员沟通，认为该业务服务需要清晰地表达问题在迭代周期内的过程，准确的术语是“进度”（progress），将其命名为“跟踪问题进度”（trackingissue progress）更加符合该领域的统一语言。
（3）培训
培训的目的是提高员工的技能水平，需要根据员工的职业规划与企业发展制订培训计划，开展培训。培训的整个管理由人力资源部的培训专员负责。培训流程除了牵涉到培训专员，还牵涉到部门协调者、员工主管和员工本人。系统将分配给员工的培训机会称为票（ticket），这实际上是领域概念的一种隐喻。培训专员发起培训的过程，实际上就是分配票的过程，整个流程如图20-18所示。
培训专员在分配票之前，会设定过滤器。过滤器主要用于过滤员工名单，获得一个与该培训相匹配的提名候选名单（candidate）。培训专员将票分配给部门协调者，部门协调者再将票分配给属于提名候选名单中的部门员工。员工在收到培训邮件后，可以选择“确认”或“拒绝”，若员工拒绝，票会退回给部门协调者，由部门协调者进行再分配，最终会形成一个提名名单（nomination）。
培训期间，每个参与培训的员工都需要通过培训专员出示的二维码签到，包括培训开始签到和培训结束签到。培训结束后，培训专员可以获得出勤名单。比较出勤与提名名单，可以获得缺席名单。培训专员确认了缺席名单后，系统会根据黑名单规则将缺席人员加入黑名单。员工若被列入黑名单中，将来就不会再出现在提名候选名单中，除非又被移出了黑名单。培训流程如图20-19所示。
图20-19 培训的服务蓝图
培训专员在确定培训计划并分配票时，还可以事先设置有效日期，用于判断票的有效期限。从发起培训开始，到培训结束，一共有4个重要的截止时间（deadline）：
q提名截止时间；
q缺席截止时间；
q培训开始前；
q培训结束前。
在不同的截止时间，员工取消票的流程都不一样，票的处理规则也不相同，如图20-20所示。
