这个夏天,再一次coding with her

“毕竟我们只有这一次结对的机会,一个题目总要善始善终,所以不知不觉就写到了凌晨两点,和小伙伴用git协作,寝室只有我的电脑屏幕发出微弱的光,感觉夜晚如此静谧,而我们的大脑和手指都在激烈又高速运转着,我喜欢这样忘我的感觉。”

再遇见

在参加完第三季ThoughtWorks最佳编程体验之旅活动后,凯欣在自己的博客中写下了这样的回顾,这是她第二次参与最佳编程之旅。同样经过了为期四周的线上编程挑战,同样是从一千多名网申报名者中脱颖而出,最终与其他127名学生一起来到ThoughtWorks位于北京、武汉、西安、成都、深圳五城的根据地体验结对编程。

(第三季最佳编程体验——五城集结)

这次活动从开始报名到最终落幕共历时一个月,大家在其中学会的第一课可能就是——坚持。平心而论,今年的线上题目难度并不高,在题目截止之前,ThoughtWorks工程师还在线上分享过程中“无心插柳”的讲解了考题,并对同学们在这一过程中所遇到的问题进行解答。意在让大家遇到难题时能够选择直视问题、正面出击,毕竟在真实的工作场景中,“退缩”从来都不可取。

但即便如此,仍然有近90%的报名者在两轮线上答题赛中退出。最终,留到最后的128名同学在6月8号聚集在了一起。提到这次相聚,凯欣用了“久违”二字。这其中并不全是怀念,在去年的编程体验中,她算是抱憾而归。在侧重于“交付完整产品”的比赛中,由于纯粹追求设计思想与代码质量,忽视了内部研究,最终与第一名失之交臂,还错失了心心念念的“无人机”奖品。在朋友圈看到活动信息后,她第一时间报了名,想看看今年的玩法会有什么不同。

确认过眼神,遇上对的人

第三季最佳编程体验之旅的主题是“Coding with her”,作为全球最佳女性科技雇主,ThoughtWorks认为在科技领域男性和女性没有差别,在校招过程中也一直坚持男女比例1:1。在第一天的碰面中,同学们就见到了来自ThoughtWorks气场全开的几位小姐姐,她们都是公司内部非常厉害的程序媛,能文能武,可以利落的解决技术问题,也可以很好的兼顾工作与家庭,被内部同事称为“刀马旦”。

初遇“刀马旦”,倾听她们讲述ThoughtWorks的文化理念、职业经历与个人实践,学生们也在这个过程中“确认眼神、找到对的人”,定下后面两天结对编程的coach。凯欣选择了北京办公室的大姐大——禚娴静作为coach,因为“喜欢她的气场,感觉莫名亲切,喜欢投缘的人。”

紧张Coding,快速交付

作为第二次参加的“过来人”,凯欣对结对编程的概念及方法、TDD(TDD是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码)等实践方法都有所了解。在听完讲解、拿到需求后,就迫不及待的想要开始做整体设计。

这时大姐大却提醒她们,要着眼于当下需求,“我们就很听话地从实现第一个需求开始测试驱动开发,我写测试,小伙伴写实现,一路乒乒乓乓,极其尽兴,几乎忘了所有人的存在,沉浸在程序世界无法自拔,不知不觉就到了五点半截止时间,代码还有一点不太完美的地方,纠结要不要继续改,担心犯规什么的,我们俩最后一致决定要完成它,在最后完成所有基础需求的时候,我们给大姐大做审阅,大姐大咔咔咔指出n个不足,最有感触的一句话是:测试要从需求层面写,我当时好佩服啊,架构师就是不一样,一眼就能看出问题,给我们宏观的把握,接受完指点后感觉自己好幸运,那天晚上非常愉快地从大厦出来,和小伙伴一路商讨,回顾大姐大的点评,想到代码有哪些不完美,我们俩就哪哪都不舒服,也顾不上什么规则了,决定晚上回去继续做。”

在为期两天的编程和showcase过程中,大姐大一直守护在身后,对凯欣小组所遇到的问题进行引导。在这个过程中,回答问题并非主要目的,更重要的在于“授之以渔”,让她们拥有解决问题的思路。这不同于课堂上的直线教学,在真实项目中,问题是无法精确预见的,只有解题思路能够常存心中。这也是为什么ThoughtWorks要把最终脱颖而出的学生聚集到一起、让大家去体验真实的开发过程和工作场景。

(凯欣小组)

最终,在最后一天三分钟的showcase过程中,凯欣和小伙伴赢得了在场coach的称赞,并成功拿下“小蜜蜂”奖品。更让她开心的是,这次奖品的设置是从多个角度进行衡量的,——“这和平时的单一评判标准(分数)决定学生好坏的片面评价不一样,衡量一件事就该多方面衡量,每个方面做的出色的同学都该得到鼓励和表扬,这一点就比第二期的活动做的更好, 很走心。”

尾声

6月10日下午,为期两天半的线下结对编程结束,走在回去的路上。凯欣在回味大姐大点评的同时或许也会想到大姐大的开场分享,“我不知道我50岁的时候会在做什么,但是,一想到很可能是在写代码,我就很开心。我也曾经无数次的想过要选择放弃,但是我站在这里就是最好的答案。”


更多精彩洞见,请关注微信公众号:思特沃克

Share

开发团队面临的三大安全挑战

应用安全不能只依靠防火墙,必须要在应用开发阶段采取适当的安全控制措施,使得应用在发布上线前就具备较好的安全性,避免人为失误造成安全隐患。

不少企业早就意识到了这一点,然而理想和现实之间还隔着几十个安全漏洞,尤其是那些采用敏捷或者精益开发模式的团队,在具体的实践过程中,几乎无可避免的会遭遇到下面几个挑战。

挑战1:一次性的安全检查无法匹配持续性的交付

为确保团队开发出来的应用具有足够的安全性,最常见的选择是对其进行全方位的安全渗透测试。无论这样的测试是由企业自己的安全团队执行,还是购买外部第三方服务,最终都会得到一份详细的安全报告,团队接下来需要做的就是基于这份报告所揭露的漏洞,对应用进行相应的调整,直到安全漏洞被修复为止。

持续交付是敏捷、精益开发团队的核心能力之一,这意味着团队可以做到每周甚至任意时刻发布产品,持续性的从真实环境中获取市场反馈,然后基于这些反馈对产品进行调整。一个可以参考的案例是,早在2014年的时候,亚马逊平均每秒有一次以上的产品部署,每天如此。

与此同时,安全渗透测试却没有这么高的“交付”速度。由于渗透测试的特殊性,虽然有大量的自动化漏洞扫描工具可以使用,但是一次全面、高质量的渗透测试依然需要人工参与,几天甚至一两周之后才能得到测试报告是普遍现象。

那么问题来了,一方面开发团队持续性的每周都有新功能上线和旧功能调整,另一方面渗透测试却没办法在这么短的时间里完成,它只能是阶段性、或者定期性的进行,例如每个季度测试一次。

这种情况下,开发团队该何去何从?如果要安全,那么就得等着做渗透测试,而且一旦发现安全漏洞还要花额外的时间去修复,产品发布必定会延期。如果要效率,那么就只能冒着风险发布,因为谁也不知道当前应用有没有安全漏洞,万一被黑客发现并且加以利用,后果不堪设想。

问题的关键在于,开发团队是在持续的发布应用到生产环境,然而渗透测试却是个相当耗时的一次性活动,它没办法跟上这么快的交付速度。

挑战2:缺乏自动化、自助化的支持,安全实践落地难

开发团队其实明白安全对于应用而言至关重要,也知道在开发过程中就应当通过运用各种安全最佳实践来主动消除安全问题,把安全风险降至最低。不过现状却是,不少安全实践要么无法落地实施,要么有流于形式的倾向。

一个真实的案例

一个开发团队在做完业务需求梳理后,立即进入了开发阶段。安全团队虽然在项目启动时提出过安全要求,例如要求团队采用威胁建模活动,识别出应用面临的安全威胁,并制定应对措施。然而由于该项目交付压力大,时间紧任务重,再加上团队成员对于威胁建模并不熟悉,最后这个活动被一拖再拖,直到应用开发完毕进行上线前的审批时,才发现没有做威胁建模,而此刻为了能让应用按时上线,只好回过头来临时补一份威胁建模的文档,仅用于应付安全部门的要求。这种情况下,安全威胁根本得不到全面的分析和应对,风险由此而生。

在项目前期的设计阶段是进行威胁识别的最佳时刻,开发团队只要在这时做一次威胁建模,就能识别出潜在的安全风险,并且在接下来的开发过程中采取适当的措施加以应对。但是开发团队却仿佛是懒癌晚期患者,硬是拖到上线前才把威胁建模补上,而此时它早已失去意义。

为何开发团队一边认同安全的重要性,一边却又对安全实践如此怠慢呢?本质原因在于,某些安全实践需要大量人工参与,或者对人员安全技能有很高的要求,与此同时又缺乏自动化、自助化的支持,因此在开发团队看来,这些实践的采纳成本太高,在面临交付压力的情况下选择性的忽略,或者认认真真的走个形式,就成了再正常不过的结果。

挑战3:高耸的部门墙让开发和安全团队难以进行高效的协作

随着敏捷、精益开发模式的普及,再加上DevOps转型的助推,不少企业已经开始组建全功能开发团队,团队中各个角色有着共同的目标,相互协作以更高的效率交付应用。但是安全团队却依然隶属于一墙之隔的安全部门。

别小看了这堵墙,说它是万恶之源有点太夸张,但它的存在确确实实阻碍了企业实现其业务价值最大化。墙的这边,开发团队竭尽所能的以最快的速度完成应用开发,以求尽快上线获取反馈;墙的另一边,安全团队只关心应用是否安全,至于是否急着上线,那不是他们关心的问题。但是他们都忽略了一个事实,那就是企业的成功需要两者共同高效的协作。

小结

敏捷、精益团队一方面要保持快速的交付速度,一方面还要提高应用的安全质量,看上去这是鱼和熊掌不可兼得的事情,然而事实上我们依然有办法解决这些挑战。

开发团队可以通过自动化,显著降低安全实践的实施难度和成本,把一次性的安全检查转变为持续性的安全质量反馈。对于安全团队,也应当向着开发团队迈进一步,打通开发和安全部门之间的隔离,以更加紧密和高效协作的方式,共同确保应用具备更高的安全质量。


更多精彩洞见,请关注微信公众号:思特沃克

Share

团队敏捷转型的三个阶段

在国内做咨询的这段时间里,前后帮助三个客户,在数十个团队做敏捷转型。在这个过程中,见到了不同思想的团队Leader,也遇到了能力参差不齐的团队成员,他们都面临着共同的问题:一方面有着自上而下的压力,却缺乏视野和自学能力,不知道自己究竟应该做什么;另一方面,敏捷的定义模糊且众说纷纭,自己又缺乏自主的独立思考能力,对怎么才算敏捷转型成功充满疑惑。

在被客户无数次的问及以上问题后,我自己也感到疑惑,因为即使在ThoughtWorks内部,这也没有标准答案,甚至我在面对不同客户时,会根据当前的目标产生不同的答案。因此我一直在不断思考一个问题:当下一个客户再问我类似问题的时候,我能不能有一个更明确,更体系化的答案。在和工作在各业务的同事交流后,我得到了一些答案,在此先做一些整理,分享给大家,期望引发后续的讨论。

团队敏捷转型的三个阶段

我们假设,敏捷转型的开始是瀑布式开发,我把这个阶段定义为Agile 0,根据我们的敏捷成熟度模型(AMM)里提及的最终形态定义为Agile 5,期间会经历三个阶段。

阶段一(Agile 0 – 1):建立敏捷流程,缩短交付周期

这个阶段,引入迭代或者建立看板是重点,类似于下图:

(Scrum运作全景图)

这个阶段的主要目标,就是将需求的反馈、开发质量的反馈、以及改进周期缩短在一个迭代内(通常2-4周)。 为达到目的,Coach主要会做以下一些事(Actions):

  • 培训 – 给团队培训敏捷流程、各角色的职责,以及各种工具的使用(比如Jira)。
  • 现场指导 – 先带领团队走完整的敏捷流程,通常会有几个迭代;然后观察团队自己执行流程,并帮助团队改进;最后不再参与这类活动。
  • 需求梳理 – 指导PO和BA建立需求全景图(比如Story Map)、拆分Story、排优先级、和团队其他成员协作等;制定Story编写规范,Story价值流和建立Story看板。

这个阶段主要培养的目标,是Scrum Master或者类似的角色,让他们能了解敏捷流程的运作方式,并能带领团队在Coach不在场的情况下,依然按敏捷流程运作。

要走过这个阶段,有一些关键指标:

  • 交付周期 <= 3周:如果是迭代开发,则应该每个迭代小于3周,并且每个迭代都Release;如果是用Kanban,则Story的Lead Time应该小于3周。
  • 上线的已知缺陷数 = 0:有些企业会给缺陷分级,只要求把高优先级的修复,但是我们推动敏捷,要求质量不可妥协,因此需要转变客户的想法,让客户把缺陷修复放到高优先级。
  • Finish Rate / WIP:如果是迭代开发,为了改变瀑布式开发硬塞需求的习惯,一定要控制Finish Rate大于80%。如果是看板,那就要控制到WIP,让每个人专注于一件事的完成。

有些人说为什么不从技术实践开始?设想一下在瀑布式开发中,开发团队几周甚至一个月才交一次版本给测试团队,在这种情况下,开发怎么会有动力写自动化测试?运维怎么会有动力做自动部署?需求没有妥协的空间,设计没有妥协的空间,导致团队的痛点永远是按时交付,质量一定会被牺牲掉的。因此只有先强制缩短交付周期,让团队痛点转移,才能改变开发人员对质量的观念。至于这个过程中导致的交付速率降低,我们会说:

  • 在敏捷转型前期一定是有所付出的,然而你投入越多,进展就会越快,收益就会来的越早。
  • 没有质量的交付不能称为完成,只能叫半成品或者次品。

由此我们来讨论第二阶段

阶段二(Agile 1 – 3):引入技术实践,质量内建,减少返工

这个阶段的主要目标,是提升开发人员的质量意识,从而提升开发阶段产出的质量水平,减少后续环节的返工。用质量内建的话来说,在缺陷时就立刻修复。这样做的好处就是同时提高了质量和团队整体效率。 其实在软件开发中,生产过程随着开发结束而结束,随之而来的都是检查和传递,因此产品的质量实际是由开发阶段就确定的,如下图:

(Story的生命周期)

只有提升生产过程的质量,才能减少返工,提高效率,因此我们在这个阶段会引入技术实践,缩短质量验证的反馈周期,主要包括:

  • 单元测试:单元测试的反馈周期最快,也在测试金字塔的最底层。要求开发人员编写单元测试,一方面可以提升开发人员的代码设计能力,提升代码质量,另一方面可以提升开发人员的质量主人翁意识,让开发阶段的交付物质量有所提高。
  • 集成测试:包括API测试和组建测试、契约测试等。这依然是要求开发人员来编写,提高开发人员的能力和意识。
  • UI自动化测试:如果是带页面的项目,这个阶段通常都会引入UI测试,一般会要求测试人员编写,这个阶段的主要作用是帮助团队提高回归测试的效率。
  • CI:通过CI服务器,将以上测试定期运行,并可视化报告,让所有团队看到。同时要求团队第一时间修复CI。
  • CD Pipeline:建立自动部署流水线到生产环境,并集成冒烟测试,E2E测试等自动化测试,同时实现回滚。
  • Git:建立使用Git的规范,建立分支策略或者指导客户做纯主干开发,培训客户使用GIT高级功能,同时解决一些疑难杂症。
  • Operation相关技术:指导客户实践蓝绿部署、云和容器、金丝雀发布等。帮助客户设计更好的部署架构和技术架构,同时帮助客户架构师做更好的决策。

这个阶段培养的主要目标就是开发,建立开发的质量意识,帮助开发写出更好的开发,培养开发处理复杂问题的能力。同时开阔团队视野,让团队成员了解更多的技术,学习如何利用新技术提升自己效率。

除了第一阶段的指标继续改进外,这个阶段我们会重点关注的一些指标:

CI相关指标:做CI的背后其实是为了培养团队能力

  • CI触发频率 > 开发人员个数:确保开发人员每天每人有提交。
  • CI通过率 > 80%:确保开发人员在提交代码前做了本地自检。
  • 最近一周内的CI修复时长 < 8h:确定团队对CI有足够的关注,没有CI红过夜。

质量相关指标:

  • 一次通过率 > 80%(或者迭代手动Test的缺陷数接近于0):Story开发完成后,会对完成的功能做一轮手动测试。这时得到的缺陷数,代表了开发阶段的质量,缺陷数越少,说明开发人员的自动化测试和CI做的越好。一次通过率可以作为更高的要求,因为包括了后续的测试环境和生产环境中,产生问题的返工。
  • 单元测试覆盖率 > 80%(大家不要纠结为啥是80%,你也可以改成79%,或者100%):首先要确保单元测试的数量在持续增加,同时要有Code Review的机制来保证单元测试的质量。另外,如果覆盖率造假,那一次通过率一定不会得到改善。
  • 测试金字塔:收集各层测试的数据,并关注是否是一个良好的金字塔,给个参考比例1:2:7。这里需要特别关注的一点,如果发现顶层测试数量太多,通常说明开发人员对自动化测试的关注不足,需要加大对单元测试和集成测试的推广力度。

交付相关指标:

  • CD Pipeline的Cycle time < 1h:这个一定要严格控制,假设一个团队有8个开发,每人每天提交一次,那一天至少提交8次,如果Pipeline跑的太慢,就会影响到大家的代码提交。当然,你也可以把这个时间要求减少,只是我的经验里,有些部署环境复杂、UI测试写的有点多的团队中,1h完成已经是一件非常难的事了。
  • 一个月内 Product Incident <= 1:差不多就是1年小于10个的标准,这个数字可以根据不同行业有不同要求,银行业通常会更严格,而创新互联网企业对线上事故的容忍度会更高。
  • 其他SLA指标:比如服务可用率、响应速度、负载等,这些指标关系到的是部署架构和技术架构的设计和实现。

这个阶段会耗时比较长,因此会有两阶的跨度,第一阶是起步,往往会有教练带着团队做重构,写自动化测试Demo,定规范和总结最佳实践。到第二阶后,这些能力就由团队自己去传播了,教练只会偶尔参加一下Code Review来看看团队是否走在正确的路上。

小结:

总的来看,以上两阶段就是帮助客户建立流程,定义参与角色并找到适合的工具,然后通过度量追踪整个转型过程,并逐步引入敏捷实践来提升相关指标。

(敏捷转型内容示意图)

阶段三(Agile 3 – 5):提升价值交付效率和响应力

到Agile 3为止,我们一直在告诉客户你要做什么,通过改变客户团队成员的行为,来改变他们的思想,特别是开发人员的质量意识和团队成员的能力。基于已有的成果,这个阶段的目标,就是培养成员的自我提升意识,团队的自我改善能力,并帮助团队建立自我改进的习惯。

因为团队专注于自我改进,因此大家会有自己的改进线路,不过无论如何,都会专注于以下几个方面:

  • 更高级的能力建设:能进入这个阶段的团队说明已经具备了支撑快速变化业务的基本能力,因此可以推动更高级的能力建设,比如引入微服务、代码共享、特性团队等(这些能力也能在阶段三之前引入,但是只有在有了阶段二的基础后,才能真正做好)。
  • 以Coaching为主:我们Teaching的内容会变少,Coaching的内容会变多,会让客户自己组织更多的分享,鼓励客户自学,并建立学习型文化。我们会和一些关键人物定期的做交流沟通,来帮助他们解决他们所面临的问题。
  • 与业务走的更近:团队可以更好的理解业务,同时能给业务提供更有价值的建议,因此很多业务在决策早期就会引入技术团队的成员。另外团队也能更好的做出业务想要的东西。 在这个过程中,文化贯穿始末。因为团队能力变强,所以更容易建立业务和技术团队的信任,形成信任文化;因为团队养成了自我改善的习惯,所以更容易形成学习型文化;因为大家有信任、有能力,所以会打破原来的控制型文化,培育出创新型文化。这些文化的建立,能更好的帮助企业在未来保持良好增长。

这个阶段度量的内容会关注在响应力、创新上,这里给些参考:

  • 交付周期 < 5d:这是响应力的象征。
  • 假设验证率:这个指标可以用来考核PO,理论上学到的知识越多,这个数字就会越高。
  • 其他业务指标:这时团队关注的是如何帮业务走向胜利,因此在软件开发时就会大量埋点用于业务分析。

总结

整个转型的过程,其实是行为改变思想,再通过思想影响行为的过程,当团队中的人员能力慢慢提升,思想也在随之改变,所有人都能对什么是正确的事作出更好的判断,继而走向持续改进的道路。所以如果定义团队转型成功,我认为就是帮助团队建立起了一群能自己做持续改进的自组织特性团队。 团队要经历这三个阶段必然是一个漫长的过程,很多钱多气粗的企业一定想知道有没有什么捷径,我的答案是有:敏捷转型的过程就是培养大家能力的过程,既然终点是所有人都拥有很强的能力,那为什么不在一开始就找这样的人来工作呢?

PS:

2005年,作为敏捷方法实践领头羊的ThoughtWorks走入中国,并将敏捷方法论首次引进中国。今天,我们想对中国企业敏捷实施情况做个总结报告,让更多人关注并加入敏捷实施的行列。本调查针对已经实施敏捷的中国企业,了解哪些实践比较普遍,在实施过程中有哪些困难。

我们将在2017年北京TID大会(7月18日)分享第一轮结果,参与填写本调查并留下邮箱的朋友,将会优于业界其他人收到最终报告。


更多精彩洞见,请关注微信公众号:思特沃克

Share

团队的精进之道

之前写过一篇文章《编程的精进之法》,这篇文章主要侧重于个人精进之法。然而现在已经不是个人英雄的年代了,我们需要再深想一步,一个团队应该怎么办?

当我们带领一个团队的时候,我们想的总是,如何做好任务分配、平衡团队战斗能力、交付最好的结果。于是做的时候就会下意识的去简单、被动的因材分工,那么随着项目的进展、人员的流动、各种意外的发生,我们在项目后期会感到处处掣肘,于是只能加班以示诚意。

我刚入行的时候,经历的各个项目都是如此,一直觉得这种事情就是天经地义的,直到认识了一个项目经理。该项目经理是个高人,他在项目开始的时候,问清楚每个人擅长的部分,然后让每个人去做自己不擅长的部分,不会?去找擅长的人帮忙。

(图片来自:cargocollective.com/)

比如,张三以前做过用户权限管理,李四以前做过单据管理,王五以前做过工作流。(交代一下例子的上下文,当时那家公司主要就做一个大的领域,不像现在前后端分这么清楚,项目经理有时候还要身兼Tech Lead)他就会说,好,张三去做工作流,王五去做单据管理,李四去做用户权限管理,遇到不会的,谁擅长什么你们都知道了啊,去问。

虽然看起来有点乱来,但是他负责的项目从来没出过问题。后来我加入了ThoughtWorks才知道,这是“把项目成功交付看作能力建设的副产品”口号的一种朴素实现。

很多团队能力不强,团队的领导者就总是在向外寻找方法和帮助。这个行为本身没错,但是做这件事的人往往无法摆正心态,很多人的潜意识是假设团队成员能力不变的,期待在此前提下通过一种魔法般的方法改变团队的绩效,这种思路在真实世界里是走不远的。

在ThoughtWorks,我们认为,软件开发中的一切问题,根本上都是人的能力问题。如何发展每个成员才是问题的关键。如果成员没有进步,始终是治标不治本的。所以我们采用的一切实践,不管是以前曾采用的还是以后会采用的,核心目的都只有一个:发展人的能力。因此才有了那个听起来很耸动的口号:“把项目成功交付当成能力建设副产品”。

如何发展人的能力?讲东西吗?不太靠谱,信息仅靠分享是没用的,我经常把刚讲过一遍的知识,让人复述;把结对时刚写完的代码全删掉让同伴重写一遍,能做到的人不多。记也记不住,做也做不到。

就像我之前在《然而培训并没有什么用》里说的,做练习?没时间,项目太忙了。而且,就算你有时间,我们拿出时间来做练习,你能保证到了跟练习不一样的场景下,团队成员们都能用好吗?把学会的知识在新场景下用好这件事,还是挺看天赋的。

讲东西不靠谱,做练习没时间,那难怪大家不考虑能力建设了。不过,如果我们反过来想,这个问题就变得没那么难办了,既然没有时间做能力建设,那么也许一切活动都可以看作是能力建设。所以那个项目经理的招数虽然看起来比较乱来,却恰恰是这个思路,我在项目开始的时候,不是着急去以最快的速度交付结果,而是通过任务分配,发展团队成员的能力。在一个较长的时期里平均来看,我们就是在以最快的速度交付结果。

(图片来自:cargocollective.com/)

所以,回到我们的主题,团队的精进之道就是把交付过程中的一切活动都看作能力建设,把整个团队构造成促进每个成员成长的生态系统。

说起来好像挺简单,我只要换个角度看就好了,然而想要做到却没有那么简单。这里面差异微妙而关键。

比如以上一篇文章《编程的精进之法》中讲到的方法为例。一个人要划任务、估时间、在做的时候计时、根据实际结果进行反思。我们可以把这个方法做成非常邪恶的、仿佛流水线上工人的强制要求。我不关心你为什么超时,就通过这种方法来控制程序员,要求每个人都严格按照一个死板而僵化的步骤做一些简单重复的机械动作。也可以用这个方法来锻炼一个人的自我认知和发现知识漏洞等能力,促使他以最快的速度成长,等他成长起来马上给他更重要的任务,比如评估技术、评估项目、带新人、做架构等等。这两种结果的差异,背后就是领导者认识的差异、团队成员认识的差异。这其中的不同早在很多年前,就被一些大牛们观察到,作为敏捷宣言里的一句话表达了出来:“个体与交互 胜过 流程和工具”。

(图片来自:http://t.cn/RXYXkek)

团队里的流程和工具,是为了成就个体,促进交互?还是为了抹杀个体,消除交互?这个微小而关键的差异,是一切的本质。有多少团队学了ThoughtWorks的一些实践,搞了看板、开放工作空间、TDD、CI,团队氛围依然压抑,成员之间交流不畅,个体成长不受尊重,领导与员工玩“猫和老鼠”。在上一篇文章《编程的精进之法》的开篇曾经简单的提到,新时代的管理者比起老板,更像老师。师者,传道,授业,解惑。各位老师,团队的未来就靠你们了。


更多精彩洞见,请关注微信公众号:思特沃克

Share

从自我驱动到带领10人团队

新的机会

有一天,你的老板找到你,他说你这段时间的表现都非常不错,我很欣赏你,正好呢,另外一个团队需要一个头,于是他决定把你提拔为那个团队的项目经理。这时的你可能会这么想,我将屌丝逆袭迎娶白富美。

如果你,正在经历这种转变,从自我驱动到带领团队这么一个过渡阶段,那么恭喜你已经成功的,走过了《领导梯队》的第一个层次,并且迈向了更高的层次,这也是职业生涯的第一次晋级。 不过咱们也别高兴的太早,因为,也有不少人没有成功转型,没有屌丝逆袭,也没有迎娶白富美。

想想以下几个问题:

  1. 为什么老板看上我?而不是其他人?
  2. 新的职位需要什么技能?工作内容是什么?
  3. 我要胜任新角色需要做出那些努力?那些我能搞定,那些需要别人帮助?

这些问题不是打击你的信心,而是帮助你更好,更快的适应新角色。不过转头一想这些问题的答案好像也简单。

  1. 我的技术过硬,踏实,肯干,能解决别人搞不定的事情
  2. 没吃过猪肉,还没见过猪跑。我看我们的项目经理,比我清闲,也就是,催催我们的进度,跟客户开会,管理项目进度,控制风险,制定应对措施,向上汇报。至于技能嘛,差不多就是,协调沟通,资源整合,计划能力,识别风险。
  3. 看样子大部分我都是知道的,如果再找找其他项目经理学习学习经验,应该是错不了了。

以上的答案还是不错的,已经说明你有很不错的观察能力和总结能力,不过团队负责人的职责可不仅仅是这些。我们先来看一下这个阶段的团队负责人,是什么样子了。一般来说,他将负责以下四个部分。

01

  • 交付管理。说白了就是要保证项目的按时交付,为了达到这样的目的,作为项目负责人需要关注交付范围,预算,人员计划,发布计划,并且需要实时监控项目进展,评估是否有潜在风险以及应对措施。
  • 客户管理。有些团队可能没有我们平常意义上的客户,但是每一个客户都有一个广义上的客户。你可以认为你是boss,就是你的客户,或者是说甲方就是一个客户。作为团队的管理者,客户的所有沟通,合作,都是你的职责。
  • 人员管理。重点是人员成长,如何帮助组员快速成长,并且在项目中承担更重要的角色。这是一个双向活动,就团队本身而言,需要组员成长一边提升交付能力;另一方面,作为组员提升自己的能力当仁不让。
  • 过程管理。主要是日常项目活动的章程,比如说新人如何更快的上项目,软件开发过程中的各种实践:站会,迭代计划会议,结对编程,代码检视,持续集成,当然也包括一些开发之外的活动,比如请假,Team Building等。

看到这儿是不是突然觉得,其实白富美,还真不容易取,屌丝的逆袭,也不是说说而已的。其实事实也是如此,这是一个非常关键的过渡时期,之所以重要,因为工作内容的转变是一方面,但更重要的是你的思维方式工作方式都发生了巨大的变化,同时,你也需要为此对领导力的成长付出巨大的努力。

思维方式的转变

事必躬亲到委派任务。

你不可能完成所有的工作,帮助团队成员成长,并使其承担职责更加重要。比如,你手头上有两件事情。一件事是为下一个90天计划做准备。另外一件事情是,和客户的,技术带头人,讨论某一个系统的未来架构。作为从技术出身的人,并且现在还在做着技术相关类工作的你,对于后者,是,更有把握的。以当前的团队领导阶梯储备情况,你必须亲力亲为这两件事情。渐渐的你会发现这样的事情越来越多,你从开始的逐渐适应变成了陀螺,忙得不可开交。其中一个非常明显的信号时,你的会变的很多,一些会在刚开始的时候对你来说是有价值的,有挑战的,但到了后面,就是失去的原来的价值。因此你要做的是讲自己的工作或者职责一一列举,进而考虑那些事情必须自己来完成,哪些事情可以委派给别人完成。这样做的好处显而易见,集中精力做应该做的事情,给别人以成长的机会。

我有一个同事,他是某一个项目的负责人。有一次我们在聊天的过程中,他向我吐了一肚子苦水,主要是他多么多么的忙,甚至很多时候都不敢请假,即便生病也得扛着去上班。我请他列举了一下他所忙的一部分事情:

  • 所有跟客户的沟通都由他进行
  • 每周跟客户开一次项目状态更新会,他需要找多人收集信息
  • 主持没填的各种实践:站会,代码检视
  • 每人每月的谈心
  • 考虑如何做人员培养
  • 组织Team Building
  • 督促大家按时填写Time Sheet(简化版的工作日志)

看到这样的工作列表,的确是没法请假。但是稍加分析一下,我们很快就能得出“不必事必躬亲”的结论,假如把其中划线的部分去掉,他的工作量将大大减少。《专业服务公司的管理》一书中专门就提供专业服务的公司的共性问题——授权不足展开了论述,它的危害主要有:降低项目的利润,影响职业发展,降低士气,缺乏对未来的投入等,如果有兴趣也可以看看这本书。

培养自己的领导梯队。

说白了就是培养自己的得意助手。在某一方面可以成为的你备份,可以让你委以重任的人。如果我们拿交付管理举例子的话,你的成长轨迹应该是这样的:积累知识,从实践中学习;总结,形成理论观点;培养,构建自己的接班人。之后你的接班人再做同样的事情,生生不息。如果这样的事情持续进行的话,我们将会看到一个领导梯队不断的团队,就像是一个梯子一样,而你再梯子的中间,既为整个梯队培养人才,有成为别人的培养对象,这是一个健康的团队的表现。在ThoughtWorks我们有一条不成名的规定,如果你想从某一个项目roll off,请找到你的接班人。大多数的情况是,这样的接班人需要你自己来培养,这也是作为高级咨询师的职责和技能的一部分。

工作方式的转变

从关注局部的关注整体

这个阶段对可能出现的问题就是只见树木不见森林。你必须从只关注一些开发细节转变为能够关注项目的宏观层面,比如项目的交付进度,日期,潜在的风险以及相应的处理。举个例子,原来的你有可能只关注特性的开发,但是现在的你需要关注开发的整个生命周期=需求分析+开发+测试+部署+上线,每一个阶段无需深入细节,但必须在你的视野之内。从另外一个角度出发,也只有当你成功的培养了组员,并适当分配任务,才能在不陷入所有细节的情况下,对全局有所把握。反之,则需要你自己来发现所有细节,以便对整体有所把握。

我和客户会定期的开会,来更新项目的整体情况,由于同时管理了多个小项目,但我仅仅工作在其中一个,所以无法得到所有详细信息,当然我也无需了解所有。每次开会之前我的准备工作就是,找到其他小项目负责人,了解一下信息:

  • 项目的整体进度
  • 是不是按计划进行,如果不是,是由那些因素导致的?
  • 有没有风险,如果有是什么?相应的对策是什么?
  • 有没有人员变动?
  • 。。。

从追随者到领导者

所谓屁股决定脑袋,作为一个普通组员,我所关心的事情无非是写好代码,配合项目负责人,其他一概不管。很多情况下,我的工作内容是别人指定,更多的是扮演追随者的角色,但是作为团队负责人,则大大不同,你需要完成一个被决定者到做决定者的转变。这种角色的转变是不容易的,因为它所涉及决定的方方面面,不仅如此你还需要为结果负责。所谓事不关己高高挂起,当事关己时,则纠结不已。

小气鬼

在对外时,如资源的协调,一定要有鲜明的立场——团队的利益是首要的。如果你的观察够仔细,你身边的项目负责人也够优秀,你就不难看到这样的场景——一个为了找到最佳人员的项目负责人和另外一个项目负责人争的面红耳赤,争执结束后他们又继续是好朋友。

总结

虽然仅仅是10人团队的管理,但是其中所蕴含的基本道理却是与管理100人1000人有共通之处。而从自我管理到管理他人的转变却是质的飞越,这个过渡中的思维和工作方式转换对该阶段的人来说,至关重要,希望各位能够好好把握个中关键成功转型。

Share