竹磬网-邵珠庆の日记 生命只有一次,你可以用它来做些更多伟大的事情–Make the world a little better and easier


107月/180

【项目管理】敏捷项目管理流程-Scrum框架最全总结

发布在 邵珠庆

Scrum中的角色
Scrum Master——项目负责人、项目经理
保护团队不受外界干扰,是团队的领导和推进者,负责提升 Scrum 团队的工作效率,控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化,他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念。

Team——开发人员、测试人员、美工设计、DBA等全职能性团队
团队负责交付产品并对其质量负责,团队与所有提出产品需求的人一起工作,包括客户和最终用户,并共同创建 Product Backlog 。团队按照大家的共识来创建功能设计、测试 Backlog 条目交付产品。

Product Owner——产品负责人、产品经理、运营人员
从业务角度驱动项目,传播产品的明确愿景,并定义其主要特性。Product Owner 的主要职责是确保团队只开发对于组织最重要的 Backlog 条目,在 Sprint 中帮助团队完成自己的工作,不干扰团队成员,并迅速提供团队需要的所有信息。

User——最终用户、运营人员、系统使用人员
很多人都可能成为最终用户,比如市场部人员、真正的最终用户、最好的领域专家,也可能是因其专业知识而被雇佣的资讯顾问。最终用户会根据自己的业务知识定义产品,并告知团队自己的期望,提出请求。

Manager——管理层、投资人
管理层要为 Scrum 团队搭建良好的环境,以确保团队能够出色工作,必要的时候,他们也会与 Scrum Master 一起重新组织结构和指导原则。

Customer——客户、系统使用人员、运营人员

客户是为 Scrum 团队提出产品需求的人,她会与组织签订合同,以开发产品。一般来说,这些人是组织中的高级管理人员,负责从外部软件开发公司购买软件开发能力。在为内部产品的公司中,负责批准项目预算的人就是客户。

Scrum中的产出物
Product Backlog——Backlog 待开发项,积压的任务。
产品 Backlog 包括了所有需要交付的内容,其内容根据业务需求的价值顺序排列,每个 Backlog 的优先级是可以调整的,需求是可以增减的,因此产品 Backlog 将根据不断增长来持续驱动维护。

Sprint Backlog——Sprint 本意为“冲刺”,指迭代周期,长度通常是一至六周。
在 Sprint 开始前,定义本次 Sprint 要讨论的“Sprint Backlog”,从中产生本次 Sprint 要完成的 “已定 Product Backlog”。
已定 Product Backlog是 Sprint 计划会议的产物,它定义了团队所接受的工作量,在整个 Sprint 过程中它将保持不变。

User Story、Task——用户故事、任务
用 User Story 来描述 Sprint Backlog 里的项目,User Story 是从用户的角度对系统的某个功能模块所作的简短描述。一个 User Story 描述了项目中的一个小功能,以及这个功能完成之后将会产生什么效果,或者说能为客户创造什么价值。一个 User Story 的大小和复杂度应该以能在一个 Sprint 中完成为宜。如果 User Story 太大,可能会导致对它的开发横跨几个 Sprint,此时就应该将这个 User Story 分解。为了能够及时,高效地完成每个 Story,Scrum 团队会把每个 Story 分解成若干个 Task。每个Task 的时间最好不要超过8小时,保证在1个工作日内完成,如果 Task 的时间超过了8个小时,就说明Task的划分有问题,需要特别注意。

障碍 Backlog——问题列表,积压的待处理事务。
列举了所有团队内部和团队相关的和阻碍项目的进度的问题,Scrum Master 需要确保所有的障碍 Backlog 中的问题都已分配并可以得到解决。

通用会议规则
基本要求
•每次会议都要准时开始、准时结束。
•每次会议都采取开放形式,所有人都可以参加。

会前准备
•提前邀请所有必须参会的人,让他们有时间准备。
•发送带有会议目标和意图的会议纲要。
•预订会议所需的全部资源:房间、投影仪、挂图、主持设备,以及此会议需要的其他东西。
•会前24小时发送提醒。
•准备带有会议规则的挂图。

会议推进
•展开讨论时,会议的推进人必须在场。他不能参与到具体讨论中,但是他需要注意讨论进程,如果讨论参与者失去重点,他还要将讨论带回正规。
•推进人展示会议的目标和意图。
•有必要时,推进人可以商定由某个撰写会议记录。
•推进人可以记录团队的意见,或是教授团队如何自己记录文档;而且推进人可能会在挂图上进行记录,将对话可视化。
•推进人会对会议进行收尾,并进行非常简短的回顾。

会议输出
•使用手写或挂图说明来记录文档,给白板和挂图上的内容拍照。
•必须传达会议记录和大家对会议结果的明确共同认知。

让团队坐在一起!
•大家都懒的动,尽量让“产品负责人”和“全功能团队”都坐在一起!
•互相听到:所有人都可以彼此交谈,不必大声喊,不必离开座位。
•互相看到:所有人都可以看到彼此,都能看到任务板——不用非得近到可以看清楚内容,但至少可以看到个大概。
•隔离:如果你们整个团队突然站起来,自发形成一个激烈的设计讨论,团队外的任何人都不会被打扰到,反之亦然。

团队建设
•Scrum 团队最佳人数控制在“5~9”人。
•全职能性团队:开发组(后台开发、前端开发、测试人员——3~8人)、Scrum Master(项目经理)、产品负责人
•兼职团队成员:美工、DBA、运维

每日立会(Daily Standup Meeting)——建议下班前开始
会议目的
•团队在会议中作计划,协调其每日活动,还可以报告和讨论遇到的障碍。
•任务板能够帮助团队聚焦于每日活动之上,要在这个时候更新任务板和燃尽图。

构成部分
•任务板、即时贴、马克笔
•提示:ScrumMaster 不要站在团队前面或是任务板旁边,不要营造类似于师生教学的气氛。

基本要求
•成员:团队、Scrum Master
•无法出席的团队成员要由同伴代表。
•持续时间/举办地点:每天15分钟,同样时间,同样地点。
•提示:团队成员在聆听他人发言时,都应该想这个问题:“我该怎么帮他做得更快?”

会议输出
•团队彼此明确知道各自的工作,最新的工作进度图。
•得到最新的“障碍 Backlog”
•得到最新的“Sprint Backlog”

会议过程
•团队聚在故事板旁边,可以围成环形。
•从左边第一个开始,向团队伙伴说明他到现在完成的工作。
•然后该成员将任务板上的任务放到正确的列中。
•如果可以的话,该成员可以选取新的任务,交将其放入“进行中工作”列。
•如果该成员遇到问题或障碍,就要将其报告给 Scrum Master。
•每个团队成员重复步骤2到步骤5。

每个人三个问题:
•上次会议时的任务哪些已经完成?:把任务从“正在处理”状态转为“已完成”状态。——今天完成了什么?
•下次会议之前,你计划完成什么任务?:如果任务状态为“待处理”,转为“正在处理”状态。如果任务不在 Sprint Backlog 上,则添加这个任务。如果任务不能在一天成,把这任务细分成多个任务。如果任务可以在一天内完成,把任务状态设为“正在处理”。如果任务状态已经是“正在 处理”,询问是否存在阻碍任务完成得问题。——明天做什么?
•有什么问题阻碍了你的开发?:如果有阻碍你的开发进度的问题,把该障碍加入到障碍 Backlog中。——今天遇到了什么问题?

注意事项
•不要迟到
•不要超出限制时间
•不要讨论技术问题
•不要转变会议话题
•不要在没有准备的情况下参加
•Scrum Master 不要替团队成员移动任务卡片,不要替团队更新燃尽图。
•Scrum Master 不要提出问题,团队成员不要向 Scrum Master 或管理层人员报告。
•如果不能出席会议,需要通知团队,并找一名代表参加。

任务板
•任务板集合了选择好的 Product Backlog 和 Sprint Backlog,并以可视化方式展示。
•任务板只能由团队维护,使用不同颜色的“即时贴”来区分开发人员,或者在“即时贴”写上接受任务的姓名。
•尽量使用大白板,也可以使用软件。

任务板有4列:
•选择好的 Product Backlog:按照优先级,将团队在当前 Sprint 中要着手的 Product Backlog 条目或是故事放在该列中。

•待完成的任务:要完成一个故事,你得完成一些任务。在 Sprint 规划会议中,或是在进行当前 Sprint 中,收集所有特定 Backlog 条目需要完成的新任务,并将它们放入该列。
•进行中的工作:当团队成员开始某个任务后,他会将该任务对应的卡片放到“进行中的工作”列中。从上个每日 Scrum 例会开始,没有完成的任务都会放在该列中,并在上面做标记(通常是个红点)。如果某个任务在“待完成任务”列中所处时间超过一天,就尽量将该任务分为更小 的部分,然后把新任务放到那一列,移除其所属大任务卡片。如果一个新任务因为某个障碍无法完成,就会得到一个红点标记,Scrum Master 就会记下一个障碍。
•完成:当一个任务卡完成后,完成此任务的成员将其放入“完成”列,并开始选取下一张任务卡
燃尽图
•跟踪进度要由团队来完成,燃尽图的横轴表示整个Sprint 的总时间,纵轴表示 Sprint 中所有的任务,其单位可以是小时,人天等。一般来说,燃尽图有”Sprint燃尽图”和”Release燃尽图”之分。
•团队每天更新燃尽图。
•如果燃尽图一直是上升状态,或当 Sprint 进行一段时间之后,Sprint 燃尽图上的Y值仍然与 Sprint 刚开始时相差无几,就说明这个 Sprint 中的 Story 过多,要拿掉一些 Story 以保证这个 Sprint 能顺利完成。 如果Sprint 燃尽图下降得很快,例如 Sprint 刚过半时Y值已经接近0了,则说明这个 Sprint 分配的任务太少,还要多加一些任务进来。在 Sprint 计划会议上,如果团队对即将要做的任务理解和认识不充分,就很可能导致这两种情况的出现。(锻炼团队人员的自我估算时间)
•燃尽图要便于团队更新,没必要让它看起来很炫,也不要过于复杂,难以维护。

Release 燃尽图:记录整个Scurm项目的进度,它的横轴表示这个项目的所有Sprint, 纵轴表示各个Sprint开始前,尚未完成的工作,它的单位可以是个(Story 的数量),人天等。

Sprint规划会议——第一部分(上午)
会议目的
•该会议的工作以分析为主,目的是要详细理解最终用户到底要什么,产品开发团队可以从该会议中详细了解最终用户的真实需要。在会议的结束,团队将会决定他们能够交付哪些东西。
•产品负责人在会前准备:条目化的需求(用户故事),优先级排序,最近1~2个迭代最希望看到的功能。会前准备至关重要,可帮助产品负责人理清头绪,不至于在迭代期内频繁提出变更、增加或删除故事。

基本要求
•迭代计划会在每个迭代第一天召开,目的是选择和估算本次迭代的工作项。
•只有团队成员才能决定团队在当前 Sprint 中能够领取多少个 Backlog 条目的工作。

构成部分:
•经过估算和排序的 Product Backlog。
•挂图、马克笔、剪刀、胶水、即时贴、白板、铅笔和蜡笔。
•假期计划表、重要人员的详细联系信息。
•参会成员:团队成员、Scrum Master、产品负责人

持续时间:在 Sprint 中,每周该会议占用时间为 60 分钟,在早上召开该会议,这样还有可能在同一天召开 Sprint 规划会议的第二部分。

会议输出
•选择好的 Product Backlog 条目。
•各个 Backlog 条目的需求。
•各个 Backlog 条目的用户验收测试。

会议过程
•从第一个 Product Backlog 条目(故事)开始。
•讨论该 Product Backlog 条目,以深入理解。
•分析、明确用户验收测试。
•找到非功能性需求(性能、稳定性...)
•找到验收条件。
•弄清楚需要“完成”到何种水平。
•获得 Backlog 条目各个方面的清晰了解。
•绘制出所需交付物的相关图表,包括流程图、UML图、手绘草图、屏幕 UI 设计等。
•回到步骤1,选取下一个 Backlog 条目。

流程检查:询问团队能否快速回答下列问题,只需要简要回答即可:“我们能在这个 Sprint 中完成第一个 Backlog 条目吗?”如果能得到肯定的回答,那么继续询问下一个 Backlog 条目,一直到已经分析完的最后一个 Backlog 条目。——接下来,休息一下。在休息后,对下一个 Backlog 条目展开上述流程。

结束流程:
•在 Sprint 规划会议第一部分结束前留出 20 分钟。
•再次提问——这次要更加严肃、正式:“你们能否完成第一个 Backlog 条目,...第二个,...?”
•如果团队认为他们不能再接受更多的 Backlog 条目,那就停下来。
•现在是非常重要的一步:送走 Product Owner,除了团队和 Scrum Master 之外的所有人,都得离开。
•当其他人都离开后,再询问团队:“说真的——你们相信自己可以完成这个列表?”
•希望团队现在能短暂讨论一下,看看他们到底认为自己能完成多少工作。
•将结果与 Product Owner 和最终用户沟通。

注意事项:不要改变 Backlog 条目大小,不要估算任务。

Sprint规划会议——第二部分(下午)
会议目的
•该会议的工作以设计为主,产品开发团队可以为他们要实现的解决方案完成设计工作,在会议结束后,团队知道如何构建他们在当前 Sprint 中要开发的功能。

基本要求
•只有产品开发团队才能制定解决方案,架构师或其他团队之外的人只是受邀帮助团队。

构成部分:
•能够帮助团队在该 Sprint 中构建解决方案的人,比如厂商或是来自其他团队的人员。
•选择好的 Product Backlog 条目。
•挂图......

注意事项:不要估算任务,不要分配任务。

会议输出
•应用设计、架构设计图、相关图表
•确保团队知道应该如何完成任务!

会议过程
•从第一个 Backlog 条目开始。
•查看挂图,确定对于客户的需求理解正确。
•围绕该 Backlog 条目进行设计,并基于下列类似问题: •我们需要编写什么样的接口?
•我们需要创建什么样的架构?
•我们需要更新哪些表?
•我们需要更新或是编写哪些组件?
•......

当团队明确知道自己应该如何开发该功能后,就可以转向下一个 Backlog 条目了。在会议的最后 10 分钟,团队成员使用即时贴写出初步的任务。这能帮助团队成员知道接下来的工作从哪里开展,将这些任务放在任务板上。

持续时间:在 Sprint 规划会议第一部分完成后,召开该会议。可以将午餐作为两次会议的一个更长久的休息。但是要在同一天完成 Sprint 规划第一部分,在 Sprint 中,每周该会议占用时间为 60 分钟。

估算会议——根据项目情况合并到Sprint第二部分会议
会议目的
•要做好战略规划,你需要知道 Backlog 中各项的大小,这是版本规划的必要输入;如果想知道团队在一个 Sprint 中能够完成多少工作,这个数据也是必须的。
•团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。

基本要求
•只有团队才能作估算,Product Owner(产品负责人)需要在场,以帮助判定某些用户故事能否拆分为更小的故事。

构成部分:
•Product Owner 根据业务价值排定 Product Backlog 各项顺序。
•需要参加的人员:Team、Product Owner、User、Scrum Master

注意事项:
•不要估算工作量大小——只有团队能这么做。
•Product Owner 不参与估算。

会议过程
•Prodcut Owner 展示她希望得到估算的 Product Backlog 条目。
•团队使用规划扑克来估算 Backlog 条目。
•如果某个 Backlog 条目过大,需要放到下一个或是后续的 Sprint 中,团队就会将该大 Backlog 条目划分为较小的几个 Backlog 条目,并对新的 Backlog 条目使用规划扑克进行估算。
•重新估算 Backlog 中当前没有完成、但是可能会在接下来三个 Sprint 中要完成的条目。

持续时间:该会议时间限制为不超过90分钟。如果 Sprint 持续时间长于一周,那么每个 Sprint 举行两次估算会议比较合适。

会议输出
•经过估算的 Product Backlog。
•更小的 Backlog 条目。

扑克牌估算
具体步骤:
•每个人各自估算后独立出暗牌,听口令一起开牌。
•数值最大者与最小者PK,其他人旁听也可参考。
•讨论结束后重新出牌和开牌。
•重复上述过程,直到结果比较接近。

常见问题

1、为什么任务要分给组而不是个人?
答:因为怕出错了牌又说不出所以然,这样即使日后他不做这个功能,也对这个功能很了解。

2、为什么不让最后领任务的人自己估算?
答:因为他很可能因为不知道某代码可用、不知道某软件不行....而选择了错误的实现方法。

3、为什么不让师傅估算大家采纳,他不是最厉害吗?
答:师傅的想法常常是徒弟们理解不了的,比如为什么不留在女儿国而偏偏去西天取经之类的,共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程。

Sprint评审会议(Review Meeting)
会议目的
•Scrum 团队在会议中向最终用户展示工作成果,团队成员希望得到反馈,并以之创建或变更 Backlog 条目。

基本要求
•Sprint 复审会议允许所有的参与者尝试由团队展示的新功能。

构成部分
•有可能发布的产品增量,由团队展示。

会议输出
•来自最终用户的反馈。
•障碍 Backlog 的输入。
•团队 Backlog 的输入。
•来自团队的反馈为 Product Backlog 产生输入。

持续时间:90分钟,在 Sprint 结束时进行。

会议过程
•Product Owner 欢迎大家来参加 Sprint 复审会议。
•Product Owner 提醒大家关于本次 Sprint 的目的:Sprint 目标、Scrum 团队在本次 Sprint 中选定要开发的故事。
•产品开发团队展示新功能,并让最终用户尝试新功能。
•Scrum Master 推进会议进程。
•最终用户的反馈将会由 Product Owner 和/或 Scrum Master 记录在案。

注意事项:
•不要展示不可能发布的产品增量。
•Scrum Master 不要负责展示结果。
•团队不要针对 Product Owner 展示。

Sprint反思会议(Retrospective Meeting)
会议目的
•该会议的对应隐喻:医疗诊断!其目的不是为了找到治愈方案,而是要发现哪些方面需要改进。

构成部分
•参与人员:团队成员、Scrum Master

基本要求
•从过去中学习,指导将来。
•改进团队的生产力。

注意事项
•不要让管理层人员参与会议。
•不要在团队之外讨论找到的东西。

会议输出
•障碍 Backlog 的输入。
•团队 Backlog 的输入。

持续时间:90分钟,在 Sprint 评审会议结束后几分钟开始。

会议过程
•准备一个写着“过去哪些做的不错?”的挂图。
•准备一个写着“哪些应该改进?”的挂图。
•绘制一条带有开始和结束日期的时间线。
•给每个团队成员发放一叠即时贴。
•开始回顾。
•做一个安全练习。
•收集事实:发放即时贴,用之构成一条时间线。每个团队成员(包括 Scrum Master)在每张即时贴上写上一个重要的事件。
•“过去哪些做的不错?”:采取收集事实同样的过程,不过这次要把即时贴放在准备好的挂图上。
•做一个分隔,以区分“过去哪些做的不错”和接下来要产出的东西。
•“哪些应该改进?”:像“过去哪些做的不错”那样进行。
•现在将即时贴分组:
•我们能做什么》团队 Backlog 的输入。
•哪些不在我们掌控之内?》障碍 Backlog 的输入。
•根据团队成员的意见对两个列表排序。
•将这两个列表作为下个 Sprint 的 Sprint 规划会议第一部分和 Sprint 规划会议第二部分的输入,并决定到时候要如何处理这些发现的信息。

144月/170

浅谈围绕业务和资源的成熟度,设计团队和项目管理模型

发布在 邵珠庆

房如华: 从五人到五十人:浅谈围绕业务和资源的成熟度,设计团队和项目管理模型

 

如何度量研发和项目管理模型是否良好的支持了业务发展?

互联网的产品植根于高度充分竞争的土壤中,对外界环境的变化是非常敏感的,我们不能保证时刻都做正确的事,因为正确是相对的。在传统软件行业里,通常软件会被交付给明确的客户群体,那么软件的品质只与是否满足了客户需求,以及与同类产品的相对优势有关。而一款互联网产品,在出生之日起,就面临着用户的不确定性,用户需求迁移的不确定及复杂性,竞品可能来自多个领域等因素,我们唯一能够确定的就是变化本身。

研发和项目的管理模型,实际上就是团队的能力成熟度模型。我们既不能在缺人的时候才开始招人、培养人,也不能在业务尚未成熟时招到无法施展拳脚的专家,同时还要确认团队中的大多数同学的潜力能够跟随业务一起成长,否则团队在早期的波动会严重影响甚至毁灭整个业务的进程。因此,业务的成熟度与团队的能力成熟度是呈双螺旋不断迭代的,两者不能产生较大的偏差。

评估两者是否匹配的标准,我认为主要有以下两点:

  1. 敏捷性:能够控制从“决定做某种修改”到“该修改结果正式上线”的这段时间,也叫做周期时间(cycle time)
  2. 灵活性:只有当能够控制每一次从引入变更到发布的整个过程时,你才能开始优化和改进软件交付的速度和质量。

下面,为了简化表述,我们把业务和团队的成熟度分为四个阶段,每个阶段有其自身的特点和面临的挑战,接受并克服了这些挑战,团队将变得更为强大。

0-5人:挖下成功的第一锹泥土

当你想办法向你的老板或者投资人讲完一个美妙的故事之后,你就拥有资源了,这时你需要的是招募(确切的说是说服)一个能够把事情做起来的初始团队,也许一开始只有5个人,但不要紧,明确好从0到1的目标,马上开始工作吧。

这一步通常是用最小的抛弃成本来验证目标、团队的可行性。你要想办法在团队没有产生自我怀疑之前,把事情尽快做成。此时,应遵循INVEST原则,即独立的(Independent)、可协商的(Negotiable)、有价值的(Valuable)、可估计的(Estimable)、小的(Small)并且可测试的(Testable)。

对于这5个人,角色分工很简单,你是项目经理,其他成员都是研发人员,一切资源面向把事情做成。沟通方式是次要的,大家坐在一起,早期不会有太大的沟通障碍。此时人员的单点不是最大的风险,没人测试也不是最大的风险,因为很多项目没等第一个Demo做出来就已经失败了。

但不关心沟通不代表工具是次要的。好的工具可以极大的提高工作的效率,例如代码控制、Wiki这些基本的工具还是要使用的,而且等团队成型之后,容易成为团队文化基因的一部分。

这个阶段对团队的技能和经验也提出了一些必要的挑战:

  1. 需要有解决问题能力很强的人,在项目因各种原因停滞的时候需要有人站出来解决;
  2. 需要有较强项目过程管理能力的人,在优先级、项目品质等方面受资源影响需要调整计划时,要能基于不全面的信息做出合理的决定。
  3. 要从一开始就让团队养成持续交付的习惯。持续交付就是要形成需求、开发、测试、部署的流水线。对于早期团队来说,就要想办法让部署的工作流水线化。首先,版本控制是必要的,它能够保证随时checkout一个版本用于上线,并且随时回滚;其次,配置管理也是必要的,方便我们基于部署环境编写不同的配置文件;最后,部署的变更管理也是重要的,而且需要尽可能的自动化,为什么要自动化?因为早期你的产品很显然会出现大量的缺陷,你唯一能做到的就是把缺陷在代码里修复之后,以秒级的速度发布到线上。目前国内有很多初始成本低廉的公有云产品可以使用,通过写一些简单的脚本,可以把程序和配置快速发布到一个高可用的环境中。
5-20人:踌躇满志,更快的奔跑

初始的业务模式得到验证,团队活下来了,可以沿着预计的大方向前进了,这时候,终于可以把之前的Demo细化了,因为Demo只是跑通了流程,但此时产品可能连可用性还谈不上呢。

你招来了一名产品经理,他开始兴致勃勃的编制未来半年,甚至一年的路线图。假设能够完成这些需求,并保证品质,那么前途是一片光明,并有望领先大部分竞争对手。

这时,作为项目负责人的你,欣慰的发现产品经理在大多数方面和你的业务见解是一致的,因为都提出了大量不得不做的需求,我们确实辜负了用户太多的期待,但你突然意识到一个更关键的问题,完成这些的资源远远不够!

要开始做取舍了,你知道在这个冗长的列表里,永远存在“更有价值“的需求。

好的,列一个Excel,我们开始排个序。

判断优先级的标准是什么?很简单,做两个极端的假设,一个是:哪个需求不做会死人?另一个是:哪个需求带来的预期收益更大?

可能有的需求需要加三个月的班才能完成呢,浪费了时间,贻误战机怎么办?其实不用担心,先把可用性做好,再找你的目标用户群体不晚,在此之前,患得患失是无意义的。

与其患得患失,不如多花点开发量,做点更“精益”的事吧。比如通过小范围的用户测试、灰度发布等方法,快速验证产品的可用性,使用尽可能多的用户行为分析软件来评估你的用户按照你的预期使用了功能并且留存下来。这样万一你先前的决定是错误的,你也可以用较小的抛弃成本来调整方向,少留些遗憾给未来。

努力奔跑的日子总是充满期待的,但你也经常会从资深的员工嘴里听到些许纠结:“我是不是该重构了?”先重构后开发总是没坏处的,这正是素养优秀的表现。然而此时你仍需要帮助他们进行取舍,合理的留下一些技术负债。

如何判断要留下哪些负债呢?

负债产生利息吗?也就是未来团队和业务复杂度不断增加的情况下,是否会让技术问题的影响范围扩大,或是优化成本不断升高直至失控?如果负债会产生短期的利息,那么把精力花在减少利息和让业务加速奔跑相比,哪个更合算?

当前的负债,能够通过后期招募一名专业、资深的成员,用更少的时间、更好的经验或者更成熟的组件来一次性解决它吗?

如果某个业务模块的需求变化本身是频繁的,那么此处产生的负债也是不确定的,刻舟求剑的优化之后,发现需求已经变化了,也是一种浪费。

在这个阶段,因为引入了制定需求和跟踪缺陷的角色—产品经理,所以需要使用工具来对需求和确信进行追踪,一个类似Bugzilla的开源缺陷跟踪软件就能满足你大部分的需求了。

20-35人:总体产出随人数增加减缓,团队能力出现瓶颈

你的团队成型了,80%的成员都是工程师,他们努力的实现着一个一个小的目标,照此速度运转下去,似乎你脑海中的那个路线图就要实现了!

“继续招人吧!多一倍的资源投入就能换来多一倍的回报,因为他们负责的业务模块是不同的,不会产生沟通上的麻烦。”

观点听起来很有道理,但实际是错误的,你的团队毕竟不是流水线上的组装工人,更何况,随着事情越来越复杂,沟通的交集是不可避免的。这就好比一片森林,地表以上的树干都是笔直挺拔,互不影响,但地表以下的树根已不可避免的盘根错节在一起,更可怕的是,没人能完整的掌握这种交集的状态,更不要提如何改进了。于是,一辆战车抛锚了,而看起来任何人都没做错什么。

瓶颈到来了。

我们知道在早期的网络通信技术里有一个名词叫做“广播风暴”,指的是在集线器组成的共享网络下,所有用户的实际可用带宽,随用户数的增加而递减,并且在争抢信道的时候产生用户的等待。

这是不是很像目前你的未被治理的早期团队遇到的情况?为了确保每个人都得到足够的信息,全员会议在增加,人数越多,会议议程越复杂导致沟通成本的进一步增加,这还不包括团队成员随时被打断、叫到某个会议中的情况。

集线器最终被交换机和路由器彻底的取代了。随着团队增长,也需要主动革新现有的成员之间的沟通协作方式。

沟通的本质是解决信息传递问题,让信息的生产者能够尽快抵达必要的受众。但自发的信息传递并不保证效率,也不保证可达,所以需要一个协调员来优化沟通的效率,当然协调员就不能总是组织全体会议了。

  1. 必要的信息,还是要广播出去,提到Dashboard的概念,Dashboard是团队成员需要得到的信息的最小子集,通过这些信息,团队成员能够基于自身角色和目标的考量,迅速开展后续行动。如何让Dashboard的变更成本最小化?就必须协作了,一开始这种协作是痛苦的,因为并没有流程来保证不同角色间信息传递是一致的,所以只好让团队中的每个角色的关键成员都来更新Dashboard,刚开始会出现大量的信息不完善、不一致甚至自相矛盾的情况,但不要怕,频繁的去做,坚持两三周,情况一定会好转,管理就是不断重复,把主观上想做好变为真正有能力做好的过程。
  2. 局部的信息传递给团队中局部的群体,该如何来操作呢?如果你的团队中有几个人具备项目经验和较强的责任心,还是可以通过定期的会议和不定期的沟通来解决的,但你一定觉得在这个阶段投入专职的项目管理或流程优化的人员还是过于奢侈了,那么不要紧,充分利用好工作流这个IT界的伟大发明吧。工作流能够让你的团队根据一系列预先设定好的过程规则,将文档、信息、任务在不同的执行者之间进行传递与执行,避免人工的方式造成的低效、等待和错误。可以考虑购买Atlassian的Jira软件,这可能是你的第一笔软件投资了,或许觉得有些昂贵,但这一定比你招募一个专职的员工便宜多了。
  3. 加强团队不同角色对信息中“一致”的部分的约定,例如版本,版本用于识别一篇文档、一份代码的各个时间点的历史快照,不同角色的成员基于对版本的一致命名,可以有效的识别需求、实现、部署工作之间的对应关系。
35-50人:重装上阵,提高整体交付品质和团队成熟度

你拖着沉重的身躯,靠一己之力把团队带到了一个执行力和结果都还不错的状态,终于可以停下来歇一歇了。

这是大多数业务负责人梦寐以求的状态,但要想从同行中杀出血路,保持进一步的竞争优势,这还不够完美。

你望着窗外鳞次栉比的建筑物,发现大多数二三十层的楼房并没有什么不同,但鹤立鸡群的几幢摩天大楼,让你意识到,一定有一些工作是只有某些人才能完成的,而当你的进取心激发你要建造摩天大楼的时候,你也需要他们。这就是专家的价值。

如果你想停止修修补补的民工游击队的日子,就在这个时候引入专家团队,来让团队变得更加高大上吧。

专家能扮演怎样的角色,取决于你需要他们发挥怎样的作用,每位专家都有自己擅长的工作模式,你需要了解他们的工作偏好,以帮助你改善团队的能力基因。

  1. 架构师:具备一定的理论高度,并在相当规模的环境下,成功的完成过研发或管理能力的升级。他倾向于了解到具体情况后去务实的推进解决问题,并怀着积极和包容的沟通心态获取团队的支持。这种工作模式的优势是目标明确,执行有力;劣势是可能过程中需要调用较多的资源,会与业务线的资源调配产生优先级上的冲突。
  2. 咨询师:他不是最主动或者最敏感解决问题的人,也许平常他只是收到各个项目组抄送给他的邮件,但遇到紧急情况时,能够快速亲自解决,或者叫上其他同学一起会诊,对于可能会重复出现的问题,或者重复产生的工作量,会设法通过优化流程来降低内部消耗。这种工作模式的优势是面向问题持续迭代团队,确保短期的成果总是可被衡量的;劣势是受团队现有成员的视野的限制较大,总是踩过坑后才能促使团队意识到问题并统一思想。

此外,还要使用IT管理的思想来提高团队的流程成熟度和专业度,从而提高整体交付品质。

互联网的商业化只经历了短短的不到二十年的时间,但在此之前,IT的信息化就已经在国外很多企业中普及开来了,企业中的大部分员工是使用IT设备作为生产力工具和协作沟通的渠道,那么如何支持好IT基础设施就变成了很重要的工作,并由此催生了IT服务管理的概念,在20世纪80年代末期,还由英国政府部门发起制订了一个信息技术基础架构库即ITIL,到目前已修订至第3版,从流程的规范制订,发展为面向全生命周期的服务管理。

虽然前面反复提到:互联网与IT企业对于需求的管理存在相当大的差异,但这只会促使我们思考如何吸取面向交付品质的ITIL的理念,并在此基础上让一切环节运转在一条流水线上,并想方设法让流水线变得更快。

让流水线变的更快,可以从两个角度进行优化,一个是提高效率,一个是减少损耗。工具的高度自动化,把尽可能多的事情交给机器去做是提高效率的最显而易见的方法。那么减少损耗呢?通常因为测试资源、环境复杂性等问题,导致原本在测试环境运转正常的软件,在服务器或者用户的手机上出现了问题,你几乎没有办法在生产运行环境下远程调试和修改程序,但这些问题又无法复现,所以捕获现场就变成了非常重要的事。日志和监控是经无数团队和项目证明的最重要的两种捕获现场、衡量线上交付品质的方式,所以在你的团队有允许的资源时,一定要有专人面向其进行持续的分析、优化和质量评价。

总结
  1. 在业务还比较小的时候,要面向成功率最大化进行团队资源配置,随着业务的逐步发展,资源配置的原则要逐步倾斜至执行效率、交付品质,直至从理论的高度设计相应的流程和角色来固化你的团队,使之变得优质、高效、稳定、可控。
  2. 充分利用工具,尽可能将一切工作自动化。
  3. 重复、频繁的做一件事,尤其是你发现这件事情既重要又困难的时候。
  4. 在你的团队没有强大到能够筑巢引凤的时候,不用花精力弥补技能的短板,因为成功率低,回报也有限,反而对团队的项目管理要亲力亲为,识别损耗并推动改进。