如何提反馈

引子

设想你是一位老师,正看到某人托着腮听课,心中会有怎样的解读?可能会有以下两种:一种是这个人不认真听讲,一种是这个人牙疼。这两种解读又分别产生不同的判断:前者是这个人不喜欢你的课,令你心生不悦;后者是这个人生病了,于是你对他的配合心存感激。

这两种判断会让你产生两种完全不同的行为模式,比如:你可能以后不想邀请他来参加你的课了;或者你会上前关切地询问他是不是生病了。

为什么会这样呢? 如果我们试着探寻背后的原因,会发现人们对事物的认知分为三个阶段:

  • 描述(Description):客观存在的事实,不包含任何个人猜测
  • 解读(Interpretation):根据场景进行的猜测,每个人的解读是不同的
  • 判断(Evaluation):带有个人感情色彩的解读

我们需要不断地提醒自己:不能因为自己的解读和判断曲解了客观事实。很多时候我们应该遵循确认、验证、沟通、反馈的过程,以此来核实解读是否正确,从而作出正确的判断。

什么是反馈?

在工作情景中,反馈是团队分享信息、了解工作表现或工作关系中某些环节的过程。在ThoughtWorks胜任力模型中提到:我们提出的反馈,应该是基于行为的、具体的、有帮助的反馈。在《伙伴教练》一书中有类似的定义:反馈着重在三个方面,行为、行为对人际关系的影响与行为对结果的影响。

莎士比亚说:“一千个读者眼中就会有一千个哈姆雷特”。必须承认我们对事物的认知是不同的,因为它与每个人的家庭、教育背景、工作经验、所处环境相关联。值得注意的是,尽管我们对于某个事件的描述不可避免地会有个人解读,但是具有感情色彩的判断是不建议的,尤其是带有负面感情的判断。因为它会使“反馈”的效果大打折扣,甚至出现负面效果。

这就要求提供反馈的人实事求是,反馈的内容是对方的行为,不要增加任何的主观判断。

如何提反馈呢?

征得对方同意

反馈不是一个单方面的活动,对方的接受程度会直接影响到反馈的效果。因此,征得对方同意是反馈开始的第一步。试想,当对方正在全身心投入的讨论需求、或者正在忙于解决线上问题时,会有耐心听取反馈吗?显然这些都不是给对方提供反馈的恰当时机。

一对一沟通

一对一沟通是比较推荐的提供反馈的方式。它会让提供和接受反馈的双方感到更加轻松和安全,在这种环境下,提出的反馈会更容易被接受。不仅如此,一对一沟通还能激发信任感,使双方进行更深层次的交流。

反馈的技巧

注意表达方式,就事论事,不要把自己的情绪带进去。有两个不错的反馈模板,分别是IIY模型(I See……I Feel……You Think)和SBIR模型(Situation在什么情况下……Behavior观察到的行为……Impact造成的影响……Reflection反思)。拿IIY模型举例,我们可以通过这样的三步为反馈提供合适的对话窗口:首先描述一个事实,这个事实是我们自己的观察(I See);再而基于共同的上下文对该事实进行解读,并提出自己的看法(I Feel);最后和对方确认是否接受这样一个事实和看法(You Think)。

我们来设想这个场景:有位同学连续几天项目站会都迟到。

项目经理:“你连续几天都迟到,是不是不想参加站会了?你的工作态度有问题。”
项目经理:“你连续几天都迟到,是不是遇到了什么困难?如果有困难,大家能提供什么帮助吗?”

对于以上两种情形,显而易见后者更容易被这位同学接受。如果从接受者的角度来看待反馈,我们可以引入一个防御模型来解释同样的问题。

反馈防御模型

反馈防御模型有外,中,内三层分别为:行为,态度和价值观/信仰,内层对反馈的防御大于外层。当对方在接受反馈时,如果内容仅仅包含行为的事实,那么这将是一个较为容易接受的反馈,若是包含对态度、乃至价值观的反馈,其效果可想而知。

写在后面

心理学中有个沟通小技巧,叫做“情绪三明治”,即“谈情、说爱、讲理”。在沟通的过程中,要遵循三个步骤:先谈自己的感受,再表达自己对对方的关心和爱,最后再讲自己的看法、道理或建议。

我们要留意的是“沟通的意义取决于对方的回应”。假如对方已经不悦了,说明我们需要即时调整方式和方法,对方的情绪和行为就是信号。沟通本身没有对与错,只有“有效”或者“无效”。因此,自己说得多么“正确”没有意义,对方接受你想表达的信息才有意义。

写到这里,突然意识到,最近一段时间,我与儿子的沟通似乎少了以往的平和和耐心。因为我自身在生活、工作中的压力,混杂了对他的期望与不满,让我对儿子”不听话”作了更多不理智的解读,我的反馈也更多地针对他的态度而不是行为本身,使得他对我越来越抵触。

现在,我应该思考如何给他更好地提出反馈了。


更多精彩洞见,请关注微信公众号:ThoughtWorks洞见

Share

在ThoughtWorks,我们如何做招聘

引子

知乎上有很多关于ThoughtWorks面试的讨论,主要集中在这样两个方面:

  • 该如何准备ThoughtWorks的面试?其面试流程是怎样的?
  • ThoughtWorks选择员工的标准是什么?

做OP(办公室负责人)一年了,我发现自己几乎30%以上的时间都在面试——招聘成为了我最重要的工作。于是想写一篇文章,讲讲我对面试的理解。

网上盛传ThoughtWorks面试严格,为什么会有这样的说法?说简单一些,与其说ThoughtWorks在选择员工,不如说ThoughtWorker在寻找同事。人与人之间是互相效仿的,很多人加入ThoughtWorks,就是为了和更多优秀的人共事。我们的中国区总经理曾经写过一篇名为《ThoughtWorks的同侪压力》的文章,文中提到:

对应到ThoughtWorks的上下文,这里汇集了一群追求卓越的人,于是这群人形成了一个追求卓越的环境,让每一个新进来的伙伴都压力山大,努力提升自己,寻求用正确的方法,做正确的事情。当对大家留在ThoughtWorks的原因进行调查时,很多人的回答是,因为有出色而努力的伙伴逼着我必须进步。

如何持续寻找我们的同事?

  • 将胜任力模型作为统一的面试框架,寻找有“学习型思维模式”的人才。
  • 多轮测评,以提高人才命中率。
  • 鼓励所有人为招聘出力,打造全员参与的招聘文化。

尽管组织的极速发展带来了巨大的人才需求压力,我们仍然不想在这方面有所妥协。为此,我们在内部建立了由同事进行评估的招聘体制,并成立招聘委员会——伯乐,招聘结果需要通过同事评估、由伯乐来定夺,以尽可能保证结果的合理性。

我们甄选人才的标准基于以下四个方面:

  • 知识:目标职位所需的技术和专业知识——候选人知道什么
  • 经验:目标职位所需的教育背景和工作成就——候选人做过什么
  • 能力:目标职位所需要的一系列行为表现——候选人能做什么
  • 个性特征/工作动力目标:与目标岗位的工作满足感和成败相关的特质——候选人是怎样的人

我们希望面试官在招聘时不要过于重视应聘者掌握了多少知识,而更应看重他们尚未开发出的潜力,也就是他们学习新知识的能力。亨利.福特说过:“不管你是20岁还是80岁,只要停止学习,就说明你老了。坚持学习的人则永远年轻。人生中最大的乐事,莫过于保持头脑青春永驻。” 拥有“学习型思维模式”的人是我们理想的应聘者,这些人不仅有处变不惊的智慧,也有乐于享受变化的心态。

以胜任力模型作为统一的面试框架

专业能力的发展一方面是知识、技能的持续更新;另一方面是通过刻意的锻炼和实践,持续提升专业所需的素养,在ThoughtWorks我们称之为胜任力。Competency Model (胜任力模型)是一个在HR领域非常成熟的、基于行为模式描述的人才管理模型。ThoughtWorks选取和我们的文化特点以及业务模型相匹配、重点强调员工发展的模型而不是单纯“考评”的工具,我们在自己的胜任力模型里定义了Craft Skill(使用某种特定工具解决某类特定问题的能力)和Amplifier(经过一段时间的学习和训练具备达到更高层次的能力),分别探寻个人在其方向上的发展方式。

举个例子,我们的“企业文化”也可以用胜任力模型来解释:

  • 360度反馈 => 自信
  • 培养型文化 => 发展他人
  • Tech@Core => 技术专长
  • Business Relevance => 客户成果交付

我们以“胜任力模型”作为统一的面试框架。对应胜任力模型,我认为有“学习型思维模式”的人具备这样的特点:

  • 自信:他们敢于挑战更高目标,迎着困难不停前进,而不是总想给自己留条后路。
  • 灵活机动:心态开放,对新事物有好奇心和主动钻研的热情,愿意对自己习惯的做事方式做出改变。对自己的强项和需要改善的地方有清晰的认知,而且能不断调整和突破固有思路和做法,适应新的岗位和要求。
  • 分析性思考:有逻辑、有条理地将问题逐条解决,能比其他人更快学习和领会新事物的特点。
  • 技术专长:在不断地实践中摸索最佳的答案,并持续不断地提高对技术的掌握水平,寻找更好的方法来解决问题。

设计这样的面试流程

很多公司在人才甄选方面非常粗放,随便看看简历,问几个问题就了事,这是非常不妥的。为了提高人才命中率,我们会采取多轮面试方式进行测评。

工作样本测试:针对候选人未来可能面临的实际工作场景、工作内容进行抽样和模拟,观察和评估候选人的表现。比如我们的Homework Review、Pair Interview和Role Play都属于工作样本测试。

行为事件面谈:这是结构化面谈的方式之一。它通过一系列对真实事件而不是假想事件的询问,了解应聘者是否具备职位所要求的能力。在准备面试前(Technical & Culture),面试官首先根据职位要求的关键能力准备相关的问题,并通过导入性问题和探索性问题开展面谈。

导入性问题:用于导入我们关心的一项能力,通常以“请举一个例子”开头。比如,当我们想评估求职者处理复杂问题的能力时,就可以问:“请举一个例子,当你遇到棘手的问题、或是需要作出一个重大决策的时候,你是怎么应对的?”

探索性问题:我们需要用STAR模型来还原当时的真实场景。

  • 情景:这件事情发生的时间、地点、人物等背景介绍。
  • 任务:这件事发生在什么样的场景下,你要完成什么任务?面对什么决策或者两难?
  • 行动:你扮演什么角色?你具体做了哪些事情?如何想到要那么做的?
  • 结果:事情结果如何?你收到了什么反馈?如何进一步改善?

情景问题面试成功的秘诀是对细节的深挖,像放电影一样还原当时最真实的场景。这样面试官就可以判断候选人提供的信息是否属实,是否具备需要考察的能力。

打造全员参与的招聘文化

在面试中,我们的职责是在有限的时间以及人为设置的环境中辩识出应聘者的优势。我们对招聘的要求越高,面试的过程就越重要,也就越富有挑战性。一个人的简历也许会告诉我们:他不仅成绩优异,还有很强的社交能力。但是通过面试我们可能会发现,这个人其实是一个几年都没有什么进步的平庸之辈。

同时,应聘者并不是唯一接受面试的人。一个能力过人的应聘者在接受我们评估的同时,也在对我们进行审视。我们不仅需要斟酌我们提出的问题,也要留意那些提出深刻问题的应聘者。在这个双向评估的过程中,我们需要不断地锻炼自己的分析力、洞察力、感知力和沟通能力。练习这样的面试技巧,不是很有意思的事情吗?

物色人才不只是招聘团队的事,招聘团队管理招聘流程,但人人都应该参与到招聘工作中来。招聘与整个组织的发展息息相关,这一理念需要渗透到组织深层。

对于小型企业而言,全员参与招聘非常自然。记得我在2014年刚加入ThoughtWorks武汉办公室的时候,无论是校招还是社招,几乎都是人人参与。然而,当组织扩大到一定规模的时候,我们经常谈论的是“人员如何分配”,而不是“如何寻找精英之才”。 而寻找TWer范的优秀人才应该是我们最重要的工作之一。

人才济济的组织很容易在人员规模上翻倍,每位员工只需引荐一位俊才,这个目标就可以实现了。这就是为什么在很多卓有成效的组织中内推很有效的原因——招聘周期短、且推荐的人才适配度更高。

写在最后

我们将胜任力模型作为面试的框架,帮助我们客观地收集信息、评定并识别候选人“冰山”以下的能力。

在武汉,招聘团队在持续推进面试官培养计划,挑选擅长面试的面试官给新人作培训。我们正在统计每位同事举荐的人数和来参加面试的应聘者人数,我们还会评估面试官填写面试反馈的效率,并可视化参与招聘活动的频率。我们鼓励所有人为招聘出力,以此来打造全员参与的招聘文化。

《变革的基因》这本书提到了“谨慎招聘”(Hire Slow)。文中提到:

“优秀的人才通常没耐心等待,为什么还要谨慎招聘?这是因为招聘决策非常重要,如果仓促做了招聘决策,就很可能要在低效的培训、无休止的反馈和痛苦的提升计划中耗费时间。为什么不尽力一次做对呢?”

我们设计相应的招聘流程,就是为了更好的提高人才命中率。我们也建立了招聘反馈机制,在持续关注每一位入职新人成长的同时,验证招聘的有效性,并持续改善我们的招聘流程。这或许能回答我们在文章开头提出的问题。

谢谢阅读!

PS:如果你也想成为一名ThoughtWorker,请查看这里:https://www.lagou.com/gongsi/j67300.html


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

Share

项目管理中的敏捷实践

作为项目经理,我们经历了不同的项目,却总是受限于相似的困局。比如以下三个典型难题:

  • 团队目标不一致
  • 团队成员不熟悉
  • 信息发布不流畅

倘若我们任由问题存在,而不在每次项目中进行总结和提炼,就会反复的徘徊于丰满理想与骨感现实当中。

敏捷思想和实践能够为我们提供一种可能性,帮助我们解决在项目交付过程中遇到的具体难题。

敏捷的项目管理——追求最大价值的成功

当我们提到敏捷的项目管理,就得先说说瀑布式开发和迭代式开发的区别。

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

大家都知道瀑布式开发的特点是大批次、缓慢流动、在每一阶段追求工作完整,但因其缺乏并行迭代的概念,对变化的响应必然很慢。而迭代式开发则恰恰弥补了这个弱点。在迭代式开发过程中,整个开发工作被组织为一系列短小的、固定长度(在ThoughtWorks通常是2周)的小项目,我们将其称为一系列的“迭代”。每一次迭代都包括了需求定义、需求分析、设计、代码实现与测试。

采用这种方法,开发工作可以在需求被完整地确定前启动,并在每次迭代中完成系统的一部分功能开发工作,再通过客户的反馈来细化需求,并开始新一轮的迭代。

ThoughtWorks的敏捷开发通过逐步细化、迭代前进的方式,分阶段地将需求予以实现。比如说,我们先从整体功能规划中定位出一小部分核心功能,打造能基本运转、对用户有价值的最小可用产品(Minimum Viable Product,MVP),然后迅速迭代开发,听取用户反馈,及时调整功能规划。

我曾在一次培训中听到同事谈到敏捷团队与西游团队的相似性,他认为唐僧师徒可以被看作敏捷中的全功能团队:团队有共同的目标——取到真经;他们历经了九九八十一难,好比九九八十一个迭代,每次打怪成功都是完成了一次交付;在不断迭代的过程中,这个团队不断地收集反馈、持续改进,一步步地完成了最后的目标。取到了真经,意味着完成了项目的交付,同时使得团队能力得到质的提升。这是一个美妙的结果。

项目成果的交付和团队能力的提升,这是项目经理在项目管理中最希望达成的目标。 传统项目管理的定义是:“在有限资源限定的条件下,实现或超过设定的需求和期望”。一句话概括了传统项目管理的铁三角:需求是范围,资源包括时间和成本。

那么这个定义是正确的吗?

大家都看过电影《泰坦尼克号》,如果我们套用上面这个“范围、时间和成本”定义的框架,《泰坦尼克号》会被判断为一个失败的项目。为什么呢?这部电影在拍摄过程中多次延期,预算也超出很多,无论从成本还是时间来看,这都是一个失败的项目。可是我们都知道,《泰坦尼克号》直到现在仍然是一个难以超越的票房神话。

由此可知,左图的“传统项目管理铁三角”概念忽略了“价值”这一重要因素。右图的“敏捷项目管理铁三角”强调,团队应得到来自市场的真实反馈,以此来帮助敏捷团队持续不断地、尽早地交付有价值的软件。

在追求价值交付过程中,我们越来越多地发现敏捷项目管理中有着至关重要的一环——人,也就是我们的团队。价值是人创造的,是为人服务的,很多敏捷实践都围绕人展开。我们试图找到一种通用的方法来最大限度地发挥人的能量。未来社会最有价值的人,是以创造力、洞察力、对客户的感知力为核心特征的,我们相信这样的团队能创造最大的价值。

下文将以我在ThoughtWorks的项目经历为例,讲述ThoughtWorks日常交付项目中主要使用的敏捷实践是如何帮助团队实现最大价值的。

用户故事

用户故事(User Story)是敏捷开发的基础,它从用户的角度来对需求进行描述。软件开发是为了实现产品的商业价值,满足用户需求。只要需求足够明确,所有人都了解其具体内容,团队就能简单有效地把需求转化成可实现、可测试、能够发布的代码。为了实现这个目标, 需要找到一种方法来描述需求,让所有人都能对任务的范围有一个共同的认知。这样团队对任务完成会有一个共同的定义,不会出现“你做的不是我所要求的”、 “我忘了告诉你这个需求”等类似的问题。

用户故事体现了用户需求以及产品的商业价值,同时定义了一系列Acceptance Criteria(AC)。只有团队完成的工作符合这一系列的AC时, 才算真正完成了这个用户故事。一个用户故事通常包括三个要素:

  • 角色:谁要使用这个功能;
  • 活动:需要完成什么样的功能;
  • 商业价值:为什么需要这个功能,这个功能带来什么价值。

用户故事可以有不同的展现形式,以下是其中一种:作为一个<某种类型的用户角色>,我要<达成某些目的>,只有这样我才能够获取<商业价值>。

所以用户故事一旦被确定,那么它所要实现的功能、需求范围、所需工作量也就随之确认了。之后开发人员所要做的就是根据这个用户故事的内容进行开发,只有当所有AC被覆盖到,测试人员完成测试,发现所有功能是可测试的、可运行的,这个用户故事才算完成了。

估算和迭代计划

估算(Estimation):团队在动手开发一个用户故事功能之前,应当对实现这个用户故事所需要的工作量有清晰的认识。如Martin Fowler所说,”Estimation is valuable when helps you make a significant decision”。只有当团队对达成一个目标的工作量以及完成它之后的“收益”有明确的认知, 才能做出明智的决定。

当团队在为工作排定优先级、制定迭代计划时,业务分析师需要知道每个用户故事的成本,团队成员需要知道每个用户故事的价值。有很多种估算用户故事工作量的方法,其中一种就是把完成这个用户故事所需要的点数(根据用户故事的复杂度估算)写到对应的故事卡上。估算可以帮助团队以不同的方式,对实现即将开始的用户故事、未来的架构方向和代码库的设计,有更好的理解。一个迭代能完成多少个点数是能估算出来的。也可以使用一些工具统计出过去每个迭代所完成的点数,比如燃尽图。

只要整个团队共同协作,估算本身也可以变成一种很有意义的活动。它有助于团队增进理解,并保证团队每个人都对要交付的需求范围和价值达成共识。让评估变得更有趣的是,通常不采用简单连续的数列,比如1,2,3,4,5等——而是采用一种近似菲波拉契数列的形式,像1,2,3,5,8,13等(正如《达芬奇密码》里面看到的),这样当数字越大、相邻数之间的间隔就越大,使得团队更容易区分哪个故事更小、哪个更大。

在做迭代计划(Iteration Planning)时,团队需要从客户价值维度和技术风险的角度来排定优先级。下图中是常用的工具之一——需求优先级矩阵。

迭代会议和功能演示

敏捷宣言里面有一条:客户协作优于合同谈判。在敏捷团队中有一个角色叫做业务分析师(BA),其核心职责是确保业务需求的清晰和透明,保证开发团队对业务有足够的理解,并将这些待完成的用户故事按照优先级排列出来,以任务卡的形式来驱动团队的开发。

迭代会议(IPM)通常发生在每个迭代的第一天,团队成员一起制定迭代计划。这个会议由BA主持,大家一起同步几个方面的内容:

  • 下一个迭代的用户故事;
  • 对下一个迭代的期望和计划;
  • 风险的评估和总结。

不同的人对需求有着不同的理解,所有团队成员都要对用户故事所有相关内容、所要实现的功能、满足哪些条件用户故事才算完成达成一致。迭代会议的主要产出是下一个迭代中需要完成的用户故事,这些用户故事即为下一个迭代所要完成的主要目标。

功能演示(Showcase)是敏捷开发流程中的又一个实践,通常发生在每个迭代的最后一天,目的是演示可工作的软件。团队把一个迭代中开发好的功能给相关人员演示,并收集反馈,以便在下一个迭代中可以对变化作出快速响应。

站会和用户故事开卡

简单地说,站会(Standup)是团队在一起快速地开一个会(通常在物理墙前),成员逐个更新自己的状态。更新包含以下几个方面:

  • 昨天完成的工作;
  • 今天计划做的工作;
  • 面临什么阻碍,需要什么帮助;
  • 自己手头用户故事的进展,是否存在技术风险。

既然是快速的会议,站会的时间就不宜过长,10分钟左右为佳。建议团队成员站着开会,因为研究表明,当人们坐着开会的时候,会议的时间会被无形中拉长。

这里有一些实践原则:

  • 团队成员都要参加站会,轮流主持,谁迟到了都不等——仪式感很重要。
  • 站会的时候,每位团队成员围绕故事卡进行更新。介绍一种有意思的实践——使用Token(也就是使用一个实物作为”令牌”,准备发言的人首先取得”令牌”,发言完成后将“令牌”传给下一个人。令牌要醒目,可以是毛绒玩具,也可以是一顶帽子)。

用户故事开卡(Story kick-off):在每个用户故事开发之前,要确保BA、DEV和QA对用户故事理解一致。这个沟通活动通常表现为由DEV讲解这个用户故事要完成的功能及AC,一旦发现任何疏漏,BA及时补充。DEV有任何疑惑也需及时提出来,当场确认,使这些功能得以正确实现。在后续开发中如果碰到任何疑惑,也应及时找BA了解清楚。QA会严格按照AC来验收用户故事。

代码审查和回顾

代码审查(Code Review) 开发团队在完成每天代码之后,会聚在一起评审当天的代码,这样做有几个好处:

  • 团队经过一天高强度的思考与编码,适当地停下来,看看其他人写的代码,同时将自己的代码讲解出来,往往能获得一些意外的灵感,或许能解决自己面临的阻碍;
  • 互相了解设计思路,获得更好的建议和进行思路重构,提高代码质量;
  • 及早发现潜在缺陷,降低事故成本:如果这个时候发现代码的坏味道和一些需要改进的地方,代码审查结束后可以花少量时间作出更改;
  • 促进团队内部的知识共享。

回顾(Retrospective):回顾会议的目的是通过新的沟通形式唤起大家对团队的集体意识,指出团队或个人在一段时间内的不足并列出对应行动。持续而有效的回顾和反馈,可以保证团队关心生产力和效率,了解自身的不足,这将成为团队持续改进的起点。

回顾的关注点也多种多样,除了“项目开发”之外,还可以关注“敏捷成熟度”、“团队角色和职责”、“人员技能提升”等。在坚持回顾的同时,需要做的还有保证回顾的有效性。应根据团队建设目标的发展变化,不断调整回顾的关注点和形式,确保回顾能够有针对性地发现团队的缺陷并转化为实践。长期有效的回顾和正确的回顾产出,还能够不断提升团队内部的安全感和信任度。

回顾的形式和方法非常多,最常见的是“Well & Less Well”。

最大程度的可视化

看板源于精益生产实践,敏捷将其背后的可视化管理理念借鉴过来,形成了具有自己独特风格的可视化管理工具。

在敏捷项目里,挂在墙上的“人人可见的大图表”是一种普遍的实践,它被用来共享项目的状态并将之可视化。比如表示项目状态的物理墙,这样的物理墙通常包括三个元素:时间、任务和团队。

除了表示项目状态,项目团队还会可视化其他的元素,比如团队应坚持的规则、项目上的经验分享以及项目的里程碑。

一般来说,通过有关联的团队和个人之间相互协商,可以识别出未来一段时间里各自的活动,以及相应的、对成功的衡量方式,然后将其可视化出来,每段时间再回顾和调整一次。有了这样的可视化,团队会更加容易对齐目标,并不断培养和加深责任感。

可视化带来的好处是:

  • 日常工作透明,将迭代过程中所有的故事卡可视化出来,团队成员可以随时知道当前需要完成的工作以及将要完成的工作。由于人对视觉反应更灵敏,可视化的故事墙能立刻聚焦团队的注意力。
  • 将迭代过程中遇到的问题暴露出来,可以促进团队成员在工作中一起积极讨论解决方案。
  • 团队也可以根据现在的进度以及遇到的问题,了解需要哪些帮助,更好的分配资源,减少开发进度被滞后的风险。

沟通计划

敏捷里面的自组织团队其实是敏捷的结果,而不是先决条件。实施敏捷的过程也是打造自组织团队的过程。每个团队成员在面对“做什么、怎么做”的问题时,也会以自组织的方式去解决。每一天,团队中的每一个人都要其他成员保持协调。为了保持同步,我们会创造基于敏捷实践的沟通机会,这个也是实施敏捷的过程之一。

在ThoughtWorks有一个非常有名的活动叫Inception。Inception是启动软件设计和交付项目的方法,通过集中式、互动式的设计工作坊,帮助客户在最短时间内对项目范围达成一致,快速进入项目交付。而Inception的一个产出就是沟通计划(Communication Plan)。比如在这个沟通计划中会讨论:以什么频率、什么形式作项目的更新,比如说每周五以周报的形式作一些主要信息的更新;站会和迭代会议什么时候召开,需要邀请哪些人,比如说业务负责人,技术负责人等等。

以下内容都会在沟通计划中定义清楚:

写在最后

回到文章开头的部分,我认为可以将敏捷实践和解决方案做如下对应:

团队目标不一致

  • 用电子墙和物理墙展示用户故事、需求全景图、项目进度燃尽图;
  • 通过迭代会议和功能演示会议对齐迭代计划,项目进度、识别项目风险。

团队成员不熟悉

  • 基于敏捷实践,创造更多的沟通机会,比如回顾会议、代码审查和站立会议。通过不断地创造这样的沟通机会让团队成员更加默契。

信息发布不顺畅

  • 共享信息,制定沟通计划;
  • 最大程度的可视化。

文中提到了很多类型的敏捷实践,这些实践需要贯穿到团队的日常活动中去,持续的实施和改进。行为心理学研究认为:21天以上的重复就会形成习惯。任何一个动作,重复21天就会变成习惯性的动作;任何一种想法,重复21天、或者重复验证21次,就会变成习惯性的思维方式;任何一种信念或者有益的实践,经过团队持续验证,它一定会成为团队的信念和实践。

剑道中有这样一个心诀:守、破、离。

  • 守:最初阶段须遵从老师教诲,认真练习基础,达到熟练的境界
  • 破:基础熟练后,试着突破原有规范让自己得到更高层次的进化
  • 离:在更高层次得到新的认识并总结,自创新招数、另辟新境界

项目管理者中的大多数人都处于“守”的阶段:他们学习、吸收了前人的项目管理经验,带领自己的团队有序地开展项目交付工作;但是他们经常困惑于某些在管理中反复出现的问题,苦于找不到有效的解决方法,不得不在新的项目中重复之前的困惑;

有的项目管理者已经达到了“破”的层次:他们能够以全局优化的角度去总结自身项目管理的经验,并通过学习、分享及各种交流平台去开阔眼界、拓宽思路,借鉴或改良项目管理的方式方法,使之更适用于团队;

而所有项目管理者的最高目标则是“离”:随着项目经验的不断积累、对管理的思考日渐加深,对项目管理有了新的、更高层次的、属于自己的独特认知,并将其应用在实践中,独辟蹊径,使整个项目管理思路焕然一新。

希望越来越多的项目管理者能够达到更高的阶段。这是我们在项目管理中不变的追求。


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

Share

敏捷团队的办公室设计

ThoughtWorks武汉办公室的装修花了三个月时间,整个办公室的装修设计体现了很多敏捷的特点,环境布置的目标就是为开展敏捷实践提供最大的方便。

ThoughtWorks旨在打造世界领先的办公环境,通过营造环境最大限度的激发人的潜能,人们可以在此获得自然光,新鲜空气,这有益于成功营造高效的工作环境。办公室内部应该实现色彩、光影、纹理、对比度,以及自然元素(如植物)的均衡,最大限度让人感到舒适——既能满足人们协同合作、专注工作的需求,同时也能让紧张的大脑得到放松。

武汉办公室的前台包括两部分,前台办公区和前台背后的接待区。

进门右手边的地方放了两组沙发,用来招待临时的客人,比如来面试的候选人,访客。

我们会有意识地培养社区,并专门开辟这样的物理空间,以方便人们进行更多面对面的互动。从前台走进去之后就可以到达社区活动区。从这里也可以看到办公室整体的装修风格是简洁明快的。办公室的社区活动区离前台很近。这样的好处是访客来的时候直接就能到这个区域。同时这个区域也是与主办公区隔离开的,安全性特别好。在社区活动室的站立式办公区,大家可以选择站着办公,也可以选择坐高椅子。

进门是一整面的黑板墙这次的主题是回到童年还有类似拼车的生活信息。除了八卦杂志,“我想听/我想分享的海报也放在了这里供大家交流。在社区活动室也专门放置了乒乓球台和foosball,方便大家在放松的时候增进彼此之间的感情。

在进门的地方和社区活动室都会有超大显示器,展示公司最新会发生的重大事件,比如社区活动的日历、公告等。整个办公室也有几台悬挂的大电视,用于公司宣传片的播放和一些重要通知的推送。

ThoughtWorks,只要有人登高一呼就可以启动一个虚拟团队。在ThoughtWorks其实有很多虚拟团队这个大屏幕上展示的就是这个虚拟团队利用业余时间自发做的系统。团队的名字很有意思17High。大家觉得有必要做一个内部的广告系统广告什么呢比如谁有意愿分享session的时候就会在这个系统中登记登记成功后会在办公室的几个大屏幕上滚动播放这样大家就能随时知道在哪、什么时候、有什么样的session

在公司办公区的墙面上分别装饰了技术雷达和商业洞见。

ThoughtWorks在每年都会出品两期技术雷达,这是一份关于技术趋势的报告,它比起一些我们能在市面上见到的其他各种技术行情和预测报告,更加具体、更具可操作性,因为它不仅涉及到新技术大趋势,比如人工智能和大数据,更有细致到类库和工具的推介和评论。ThoughtWorks最近发布了自己的技术战略2.0(3年前我们发布了技术战略1.0),经过三年的发展,通过我们对业界,学术界和行业的发展,我们认为现在是时候展望更长远的未来。

ThoughtWorks在践行「科技即商业」的过程中,也一直在思考、研究、学习和总结,期望把最新的思考和最有价值的案例汇集起来分享给业界。由此萌发了一个想法:搭建一个平台,能分享我们的经验,并为这一领域的实践者、作者和读者提供一个交流的纽带。这是《ThoughtWorks商业洞见》的由来。

整个办公区域是完全开放式的,方便进行可视化管理,我们设计足够长、足够大、没有挡板和隔断的办公桌,有利于每天的结对编程和code review。

敏捷团队需要很多的沟通,办公区提供随处可见的白板,很多墙壁也是玻璃的,大家有足够的空间进行每日站立会议和进行各种各样的讨论。每个项目组都会配备专用的大屏幕电视或专用显示器,来可视化持续发布和自动化的流程。

我们也会设置由电视、Mac Mini和Skype组成的无间断视频(Always On Video),不仅方便与异地的同事通过视频的形式召开每日站立式会议,而且即使大家相隔千里,也能随时就问题展开讨论。

我们并不希望大家整整八个小时都被束缚在办公桌前。因此,适当地采用分区策略(例如茶水间和放松区这样具有文化敏感性的区域),将有助于人们在需要时补充能量和恢复精力。

类似这样的公共区域,都是开放性的,比如休息区、茶水间、打印机等,没有任何物理边界,一方面是方便各个区域的人的到达,另外是形成汇聚点,成为人们的交流场所,这样大家路过的时候就能够随时打个招呼聊上几句。

会议室相对团队空间来说,私密性会强一些,因此我们特地预留了一些小的quite room。敏捷团队的会议室的白板的面积应该尽量的大,画不下要擦掉会影响思路,我们将整面墙都做成白板。

整个会议室的命名采用:区域+星系。我们之所以要给会议室起不同的名字,不是为了fancy,而是为了让我们所有人在一起工作的过程中有值得记忆的事情!当多年以后,我们依然记得在某个会议室的点滴瞬间:比如为了某段代码的争论,为了某个上线的开心,为了生日的庆祝,或者为了一些事情的伤感。

会议室的门和墙做成了透明的,同时为了兼顾隐私,在玻璃中间贴一层磨砂纸,同时保障私密和透明。很多项目也利用这块空间做成物理看板,每天的站会就在这里进行。

整个工作区域设有2个people room,以舒适沙发取代会议桌椅,大家可以在里面更加随意的聊天或者休息。另外有一个专用的母婴室,方便怀孕期和哺乳期的女性员工,武汉办公室的女性员工比例超过40%。值得一提的是ThoughtWorks凭借在全球范围利用软件技术推动社会和经济公正的多年实践,和包括Google、Facebook在内的其他24家美国组织荣登2016年最佳女性科技人员雇主领导力指数榜单,并力压群雄最终摘得“2016最佳女性科技人员雇主”桂冠。

武汉办公室欢迎大家!


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

Share