管理多地点项目

管理多地点项目

• 一个问题的成本是多少

  • 团队坐在一起成本低，尽可能让团队坐在一起

• 识别项目的文化差异

  • 体现在人们认为他们可以讨论哪些话题，给予哪些奖励，人们对待彼此的方式
  • 整个项目不一定使用同样的生命周期模型，开发手段和具体实践，但整个项目团队必须使用互补的

• 在团队间培养信任

  • 帮每个团队制订承诺目标，定义可交付物
  • 确保每个地点都有完整的项目可交付物
    • 不要创建单一功能团队，也不要创建过于零散的团队
    • 要保证每个地点都有一个完整的团队，交付相对完整的功能，通过测试，可以顺利运行的功能
    • 如果无法在一个地点召集完整的团队，想办法保证每个人跟团队其他人能够紧密接触：线上即时通讯等，摄像头
  • 确保团队可以彼此相互合作
    • 互相依存的管队之间不能存在竞争关系，特别是有失业风险的时候
    • 确保多地点的团队有同样的目标：以项目或工程为重
  • 帮忙人们相互接触
    • 全体成员到同一工作的地点共组一段时间，还可以组织一些社交活动，比如一起进餐，让不同地点的人相互增加了解（ 并非强制娱乐活动）
    • 团队难以聚在一起，就让项目经理和技术带头人聚到一起。每个地点派几个人来， 也可以组织各地点之前定期的相互访问
    • 多地点的项目经理应该定期访问各个地点，可以在每个地点待上一段时间
    • 即时工具让沟通更有效率

• 在团队中互补实践

  • 项目经理有权要求每个团队使用特定的工作方式，如果无法做到就要求结果
  • 使用互补生命周期
    • 多地点项目不要使用顺序式生命周期
    • 2周XP迭代团队，4周Scrum迭代团队以及使用按阶段交付生命周期
    • 多站点项目开发和测试更需要尽快得到反馈
  • 详细说明每个团队的里程碑和交付物
    • 详细说明每个词汇的含义：比如修复（包括验证吗），功能冻结（第一次还是最后一次），编码完成等的理解是否相同
    • 详细说明里程碑的含义
      • 比如功能冻结:是更为详细的设计还是对概要设计有了了解。因为不同的团队立场，目标不同，面对的问题不同。了解面对的问题，将重点放到临时结果上（每个组到底在何时需要什么样的东西），共同定义出主要的里程碑
      • 通过想要的结果定义里程碑
    • 详细说明团队了解自己工作进度的方法
      • 不要强制规定每个团队取得可交付物的工作方式，说明你想要的结果； 以结果为导向， 而不是方式方法或具体实践， 多地点团队尤甚
      • 可以要求每个团队提供图标开使得进度可视化
      • 时间差可以让团队带头人和你商定一个统一的时间来召开电话会议
      • 管理最后的结果，而不是人们已完成的工作，可以让团队带头人定期解释测试进展状况
  • 详细说明团队如何评审工作产品
    • 多地点项目，技术评审可以提供额外的沟通框架和上下文比如需求和框架评审，还有其他文档比如设计和功能规范 ，特别是代码
    • 可以在项目初期评审项目章程，规划和日程表，在整个工程团队范围内评审工程的发布条件，且如何从工程的发布条件转化为自己负责的项目的发布条件
    • 鼓励团队成员评审自己的工作，相互评审
    • 多地点项目需要更为正式的需求和框架评审，正式的评审有助于降低沟通问题产生的风险；可以确保每个人了解项目目标，至少每个团队出一名技术代表参加正式评审并就需求的正确性，可实施性达成一致
    • 敏捷周期项目，只讨论当前迭代的需求和框架；增量式讨论仅限于当前阶段的可交付物；重点评审接口而不是具体实现
    • 评审和考虑其他地方的文档并非易事，邮件评审会遇到一些问题，还是需要真正的谈话甚至面对面讨论
      • 阅读工作成果的人会主导讨论，害羞的人不会积极提意见
      • 有人开始提出意见，别人就默认有人会处理这些问题
      • 形成同样的沟通风格很难

• 寻找潜在的多地点项目和不同文化导致的问题

  • 不同地点团队对里程碑和交接物的定义可能不同，可能源于对用词的理解；有时对于承诺的含义理解不同； 都可以通过开发实践解决，比如项目规划，项目日程安排和技术评审
  • 形目进度的沟通和报告出现不一致，经常在项目初期。
  • 不同母语的项目团队可能很难理解对方说什么. 确保团队在书面和口头沟通中使用的语言适用于每一个人。哪种语言作为通用语言，存在哪些二义性？所有参与者是否能流利使用？ 是否有文化习俗的差异
  • 节假日，假期和加班都有可能产生沟通问题。明确说明假期的含义，每个团队成员所在国家的法定假期对项目日程的影响
  • 要确认每个人正确理解当天结束或者其他某个时间对于可交付物的含义，尤其是有时差的时候
  • 使用一些通用工具的水平不同，比如代码管理，缺陷跟踪等

• 外包时要避免的错误/应注意的问题：如果必须使用外包团队

  • 训练外包相关负责人员: 负责外包的人要了解产品的工作方式，包括产品内部，客户希望解决的问题这两个角度
  • 挑选厂商：是否有相关领域的知识，财务是否可靠，合同中是否有包含知识产权相关的保护条款
  • 选取好的项目经理作为外包项目公司内部的醒目经理，接包方也有项目经理，需要和本公司的人沟通，以便确保他们团队正确理解项目相关的可交付物和交接物
  • 与接包方的管理层或项目经理建立信任关系，可帮助了解项目的真实情况
  • 规划，调整内部员工的工作时间，包括外包人员时间，找出相关沟通的时间
  • 用文档记录需求
  • 制订适当的变更流程：清晰的变更流程，确保只允许发生希望的变更
  • 选择需求相对稳定的项目进行外包
  • 为每个项目规划更长的时间，更多的资金预算，特别是外包关系建立初期。 第一个项目增加30%的估算时间
  • 在整个项目的开发过程中，坚持解包方不变更团队
  • 确保接包团队有合适的工具，信息系统和流程，最好和内部团队用到的项目工具一样
  • 要验证确实是声称自己负责项目工作的人们在做项目的工作，而不是转手给其他没有经验的人完成，成为试验田

铭记：
如果团队没有分布在同一楼层10米之内，就是一个多地点团队
相对于管理坐在一起的团队，管理多地点团队要花费更多时间，需要跟多推进项目的技能
如果项目经理无法建立与远程团队的信任关系，项目就很难成功