团队管理中的每日站立会思考

题外话:

我们为什么要做这件事(Why)?如何才能把这件事做好(How)?坚持高效的执行这件事(What)?是否审视评估这件事的成效(Review)?

Why:它能给我们带来什么益处?它有 带来哪些坏处?它要达到的目标效果是什么?
How:怎样做才能达到预期的目标?如何规避 存在的风险?
Waht:我们具体做的事项,坚持、高效、成效的执行,确保目标的达成。
Review:是不是达到预期的目标?哪些没有做到位?哪些需要添加?哪些需要删除?(下一个迭代启动)

Why让我们思考这件事的意义和目标以及标准;How让我们思考这件事如何更高效且有成效的达成;
What让我们具体执行的事项,坚持、高效、有成效的达成;Review让我们思考是否偏离方向,持续的改进优化提高。

来自西蒙-斯涅克《伟大的领袖如何激励行为》的思考。
[短期利益,让你吃上饭;长远利益,让你吃好饭。]
[人们买的不是你的产品,而是你的信仰;人们合作不是你的人,而是你的信仰。]
[相信你所相信的并带领大家相信你所相信的,并让大家看到阶段性可预见的成果,小步快跑。]

有段时间没写博客了,在深圳参加一些很棒的线下活动,认识了很多大牛,有时间一一整理,分享一下。
四月份写的博客《团队管理中的每日站立会》,是基于对站立会的最初认识,执行一段时间周期,最近又有对站立会的新思考:
每日站会,来自敏捷最佳实践,真的做好做到位,把站会的真正价值发挥出来还真的需要很多地方可改进的。

简单敏捷认识
不知道大家是怎么接触敏捷,说到自己最初的话,应该是博客园关注大牛周金根老师,然后就是第一家公司广联达的敏捷实践。
每个人接触敏捷的形态不一样,有的是进入公司的第一天就有接触,因为公司已把站会作为一种研发规范确定下来,你必须接受;
有的是接触身边朋友大家都在搞每日站会,似乎效果也不错,我们也搞一下试试,你尝试接受;
有的是公司学习大公司好的研发体系,发现普遍的大公司都在搞这个,我们不能丢我们必须同步,我们应该有,你强制自己接受。。。。
每个人的接受程度不一样,对最初的事物的认知度不同,以及接受尝试后,反思对事物的认识又是不同, 推翻最初的认知, 提高最初的认知。
一项新事物、新概念,不同的应用场景,不同人的执行,达到的预期的效果不一样。以至于我们对该事物的认知有所改变,而没有思考其根本。
我们公司推行了敏捷,敏捷中提倡的最佳实践,我们都有执行,可是预期的效果并不是如此的好,而且没有得到提高改进反而造成阻力,对团队、对项目无益处;
那就需要分析思考是不是哪里做的不到位,是不是哪些方式方法不当,是不是哪里不适合我们企业可以变通、调整下,不同的人执行达到的效果是不一样的。
敏捷不仅仅是提高效率的,而且还是降低成本的,当然项目管理不能仅依靠敏捷的一套思路去做,可以吸收百家所长,相辅相成,服务于项目。

每日站立会新思考,对这篇《团队管理中的每日站立会》博客的补充:
每日站会是否主持高效?
可能很多团队也同样纠结站立会如何主持,才更高效?在写的这篇《团队管理中的每日站立会》博客中,提到建议的一种方式就是团队成员的轮值主持,有利有弊。
对于不是太成熟的团队或是专业度很高的团队, 更多的选择的是由PM\SM\PO主持(控制不必要的风险或团队成员能力欠佳不能很好组织带来低效);
对于一般性的团队, 更多选择有团队成员轮值主持比较好,利弊分析过,不再冗余,不过这个还是极力推荐和推崇的。
其实敏捷期望达到的一种团队状态就是敏捷的自组织、团队成员的自组织,每个人都有很强的责任感和使命感,每个人都对团队赋有承诺,
每个人都对产品的成败负责,每个人都觉着每天的工作都是有意义的,大家在共同打造一款超级棒的产品。更多的强调团队成员的参与感、团队的主人翁精神,
团队的凝聚力,而每日站会就是一个很好的促成方式。当我们在为公司做事情的同时,也期待个人也有所成长和提高。
你不是在给老板打工,你是在给自己打工;你不是在打造一款公司的产品,你是打造一款你钟爱的产品。

每日站会是否是工作汇报?
可能很多团队同样也纠结站立会怎么变成工作汇报了?在写的这篇《团队管理中的每日站立会》博客中,提到每日站立会中的三段论,在做工作情况陈述。
才开始的执行确实是这样切入比较好,但是执行一段时间后,你会发现大家都只管自己的那一块任务的陈述,或是任务陈述过于浮于形式。
其实,采用什么形式或许并不是最重要的,确定工作陈述主要目的是什么:
<1>.项目进度反馈。对项目经理、对团队成员反馈你任务执行的进度,确保我们的项目在一个可控的安全时间内运转;
<2>.项目风险把控。对项目中 存在进度的偏离,技术风险,需求风险,沟通风险,都能及时的暴露,风险前置;
<3>.团队监督承诺。每次工作陈述都是对自己已做工作和将做工作的一个承诺,大家一起监督,你也迫使自己去达成自己设定的目标。
<4>.团队沟通透明化。大家彼此沟通无障碍,谁的任务,有需要谁来协助,各个环节沟通顺畅,工作事项透明化。
只要可以达到这个四个或许采用三段论也不妨,但是如果团队出现疲态或是背离我们的初衷,那就需要及时的调整,采用一些有趣好玩的形式,让我们的工作陈述更有意义。

每日站会是否要做会议记录?
可能很多团队同样也纠结站立会要不要做会议记录? 大家认识中敏捷是无文档、无加班,提倡更多是必要重要的文档和每天高效工作的保持。
在《团队管理中的每日站立会》博客中,提到会议的产出。其实,更多需要一些重要的纪要性的文档产出,例如:
针对今天站立会,突然发现团队某种不良现象,要加以约束和调整,团队成员达成共识的一个团队执行标准,这个是需要记录的,为我们更大的团队执行制度添枝加叶;
针对今天站立会,可能引发的沟通上的不协调问题,团队达成共识的一个决议,这个需要记录的,让大家以后都采用这种方式来沟通;
针对今天站立会,一些需要的重大的调整、决议、设计、改进等等,也需要简单记录,方便查找和事后的跟踪。
会议记录作为会议的一个产出,既是对以后工作的一个监督跟踪也是形成了一份组织资产,可能很多公司都不关注公司组织资产的建设,认为是费时费力有没成效的事情。
近期看组织资产确实不能给你带来当前的利益,长远看组织资产将是一大笔财富,不需要太花费大量的人力、物力投入去做,只需平时工作中多做那么一点点就可以了,水滴积河流。

每日站会是否助长懒人歪风?
可能你的团队来自一个矩阵组织,业务分析员、测试工程师、不同部门的开发工程师、UI设计师组织在一起,同时为了项目组织在一起。可能在工作会出现项目责任的推诿,每日站会的时候,告知PM和大家这个模块做不了,交给其他人来做。大家来自不同的职能部门,有各自的职能经理,对于成立的项目组的归属感不大,也不认为是大家的项目,只管把自己那一块的工作做好就好了。其实有时候不是跨职能组织的团队,自己一个部门也会有类似的问题。可能就想到敏捷执行确实需要一定的基础建设,团队、公司是否适合推行敏捷。
作为PM临时的处理办法就是命令指派的领导,但这不是长久的方法,这明显的是一个团队的不成熟,需要多花心思去让团队更加成熟些,增加大家的归属感,一起短暂的奋斗合作的事业更有意义。
在发现这种不良状况时,PM就要反思了,要让大家看到我们的前面路很美好,让大家看到彼此的付出,让大家彼此信任,他做了那么多,我也不能拖团队的后腿,我要要做点什么。让团队正向能量运转,首先PM要相信,然后让大家去相信。相信你所相信的,带领大家相信我们所相信的,并看到可预见的成果。

时间: 2024-08-26 06:21:05

团队管理中的每日站立会思考的相关文章

团队管理中的代码评审

代码评审在软件项目管理中是经常组织的活动,通过代码评审的工作也确实给我们的团队带来很多的益处,简单谈谈代码评审的感受,你们的团队是否也在进行代码评审(Code Review)的相关工作呢? 1.为什么要组织代码评审 组织代码评审其主要目的是保障我们的代码质量和软件产品质量,其次是团队的学习提高,共同的成长.可以是两个方面的驱动,外在现实中的工作痛点和团队内在战斗力提高的驱动. (1).实际工作中的痛点:<1>.团队开发的软件质量越来越差,Bug居高不下,问题层出不穷:<2>.团队的

转:几个软件研发团队管理的小问题

几个软件研发团队管理的小问题 最近在与一位总经理交流的时候,他谈到他们公司的软件研发管理,说:"我们公司最大的问题是项目不能按时完成,总要一拖再拖."他问我有什么办法能改变这个境况.从这样一个问题开始,在随后的交谈中,又引出他一连串在软件研发管理中的遇到的问题,包括: . 现有代码质量不高,新来的开发人员接手时宁愿重写,也不愿意看别人留下的"烂"代码,怎么办? . 重构会造成回退,怎样避免? . 有些开发人员水平相对不高,如何保证他们的代码质量? . 软件研发到底需

几个软件研发团队管理的小问题

最近在与一位总经理交流的时候,他谈到他们公司的软件研发管理,说:"我们公司最大的问题是项目不能按时完成,总要一拖再拖."他问我有什么办法能改变这个境况.从这样一个问题开始,在随后的交谈中,又引出他一连串在软件研发管理中的遇到的问题,包括: . 现有代码质量不高,新来的开发人员接手时宁愿重写,也不愿意看别人留下的"烂"代码,怎么办? . 重构会造成回退,怎样避免? . 有些开发人员水平相对不高,如何保证他们的代码质量? . 软件研发到底需不需要文档? . 要求提交代码

每日站立会议——敏捷流程scrum实践

每日站立会议是敏捷流程scrum中的很重要的一个制度之一. 功能: 1.快速同步进展,让项目组内部的员工互相了解彼此的进展,从而了解本项目的整体进展. 2.给每个人一种精神压力,信守承诺.这是一种面对面的精神压力,直面项目进展. 3.培养团队的文化,让每个人意识到:我不是一个人在战斗,我们是一个团队. 站立会议的目的: 1.让所有人了解其他人在做什么,当前项目计划进展如何 2.帮助大家解决那些阻碍做事情的问题,以及共享承诺这些都非常有利于提高团队合作精神的. 注意要点: 1.主题明确,不能掺杂其

敏捷开发之每日站立会议

1) 在  Scrum  方法中,Scrum  会议非常重要,整个会议可能会比较混乱粗略,但推进进度的目标却非常清晰明确,并促使团队齐心协力朝共同目标迈进.  2) 团队应召开每日  Scrum  会议,以便确定下一天所需执行的工作,以最大可能地履行其承诺.   团队的每个成员都应该描述自上次会议以来所做的工作.  3)他们计划在当天完成的工作,以及可能对其他团队成员产生影响或需要获得其他团队成员帮助的任何问题或障碍. 4)Scrum  主管严格控制会议结构,确保会议准时开始并在  15  分钟

各级主管在绩效管理中的责任

各级主管要明确自己在绩效管理中的责任,首先就得明确绩效管理是什么. 笔者对绩效管理的定义是绩效目标设立.达成.评价.运用.改善的循环管理.其中的绩效评价就是令主管们头疼的绩效考核.绩效管理失败的企业众多,主要原因就是只知其一,不知有二,只知绩效考核,不知绩效管理.因此,要搞好绩效管理,就必须明确自己在绩效管理循环过程中每一环的责任,才能避免偏离管理方向.落入失败陷阱. 一.组织目标设立 绩效目标就是我们平时订的工作计划.只不过以前订计划没有量化要求,没有奖惩约定:只有简单的要做什么,没有具体的做

团队管理的简单总结:少即是多,体力透支,负能量管理,自我进化团队,沟通

今天读了三篇关于管理的文章,做了些简单的总结. 读<腾讯资深产品经理:团队管理的心得> 1)考核同时看最终业绩与个人提升.不同阶段有不同比重.--还要在实践中思考. 2)在新员工培训上,目前还是统一培训投入大,到项目组内部是,缺少一个很好的计划与跟踪.真正的做事情是提升最快的方式.在这一方面要建立一个计划.跟踪考核机制才对. 3)作为leader,要提升自己的能力.严于律己,宽以待人. 4)团队的流程建设,不是简单的设计一下做一件事情的流程,搞一个OA软件.更有效的部分其实是寻找人力,利用现有

团队管理:新业务团队如何结合绩效来度量开发目标

之前有人给我blog留言问过绩效的事情,本篇主要与大家分享一下如何在新业务项目组中结合绩效来度量目标的一些思考,我们先从对绩效.产品开发的认识开始,最后会列出绩效细则.本篇更多从量化角度去看,不考虑绩效分数的激励制度. 敏捷个人和敏捷团队 就像我在使用Scrum来敏捷自己所说的,在我们要求团队以人为本进行管理时,我们不能单方面要求团队把员工当人看,更重要的是员工要把自己当敏捷个人来看,做到在最基本的主动.自律的完成工作基础之上再去发挥你的卓越.我也一直都是这么要求自己的,并且也在把这些想法积极地

负能量程序员杂谈(2)- 管理中的情和义

本系列文章仅从个人有限的对事物的认知出发,如有不同意见,请温和提出态度,毕竟都是成年人,别那么幼稚. 情和义,值千金. 今天和很久没见的朋友L喝酒,L目前是一家不错公司的开发管理,手下10几号开发.中途他给我聊了一个很有意思的话题:公司正在转型,那么由于成本压缩控制会裁掉一些人,由于担心裁人会引发和公司矛盾,所以这种事交于开发小组的小组长负责沟通,有的小组长碍于情面,觉得不好意思落下脸面,他就出马负责和即将被裁掉的程序员沟通.我问他为什么不是HR去搞定这个事呢?他告诉我,之前发生过因为HR去沟通