快好知 kuaihz

探索技术管理与敏捷管理的一年:到底如何做技术管理和敏捷管理?

回想2016年初,至今还诚惶诚恐。在那时,Android应用开发团队还一团乱麻,时常有紧急问题发生,在那时,敏捷开发还在蹒跚学步。好在,一年过去了,我们也走出来了,没有原地踏步。

1.如何学做管理

其实,我很不想用“管理”二字,但是用一个新的词语,又未免增加了理解的成本。为什么不想用“管理”二字呢?因为,提到这个词语,我总是会很肤浅的联想到“流程”、“控制”、“绩效”、“计划”、”组织开会“这些工作。然而,我每天跟在团队后面,不断的督促他们完成任务就是管理了吗?这件事情有意义吗,我做这件事能产生多少价值?做这些事情有利于我个人的职业发展吗?这些问题,在开始之初时常在我脑海中荡漾,久久不能平静。

回到原点,公司把我安排在这个位置上,最现实的,也是最基本的,是保障这个领域能高质高效的配合产品项目的研发工作。那么,还管他管理的定义是什么,带领一帮人,达成这个目标,就是管理。是的,我就是这样一个现实主义者。于是乎,所有的管理工作,都将围绕着这个目标去探索,去开展。

在这项工作的开展过程中,有两个人的话影响着我,其中包括:“你自己写程序都能干得那么好,为什么人到你手下后,就不行了呢?“,”现在你们的管理知识,就和小学的数学水平一样。“,”管理是一门实践的艺术。“,在此,不得不感谢这两位导师,促进了我在这一领域的发展。个人的拙见,学做管理要重点关注以下三件事情:

1.培养你的团队成员,目标就是让他们和你一样强,甚至比你还强。

有时,我们会担心团队成员变得比我都还强,那我的位置不是会被他取代?公司还要我干嘛?个人的拙见,这是一个伪命题,这里仅仅是目标让他们变得更强,但是既然是你去培养他们,他们不可能全面超越你,你们各有所长。另外,作为一名管理者,应该有这样的自信和胸怀,我们自身也在不断学习,我们会走得更远。只有他们都变强了,团队才会变得更强,才能把事情做得更好,我们带领团队的价值才能有所体现。

2.加强管理知识的专业化学习,而不是闭门造车,自己摸索,多看书,看好书,多听有经验人士的讲座。

3.针对公司的特点,团队的特点,不断的尝试、总结、调整你所学到的方式方法,在实践中验证和改进它,变成你自身的经验,深入骨髓。

这种机会难得,很多人没有这样的机会去学习管理。

2.如何做Android应用团队管理

Android应用技术团队,专业知识强,技术细分领域多,人员技术能力参差不齐。面对市场上纷繁众多的机型,移动端让人操蛋的网络复杂性,以及让人恶心到爆的运营商,简直是苦不堪言。苦归苦,事情还得做,而且还得做好,于是今年一年经历了以下三个阶段:

第一阶段:全面重构以前那让人难以启齿的代码。

第二阶段:配合永不停歇的敏捷开发,人员迅速激增。

第三阶段:领域化划分,基本走上正轨。

我对Android应用团队的管理的观念,也随着这三个阶段,不断的演变和进化。在接手团队之初,团队人员仅有5人,那是程序代码格外凌乱,耦合严重,连最基本的代码合并都会经常出问题,线上问题也是时常发生,而且是越演越烈的趋势。由于我个人经验有限,当时也就只看到了这些问题,针对问题解决问题。并且当时有这样的观念,只要我把代码整体重构了,保障代码框架清晰易懂,解耦,Android应用团队就会在框架的引导下越来越好。可惜,我错了,我真的错了!虽然,这样做了后,在很大程度上改善了原有的问题,但是并不彻底。整个团队开始暴露新的问题:

框架约束力不够强,部分开发人员在执行过程中有其形,无其实。

部分开发人员基础知识不过关,框架可管不了这个。

svn管理,jenkins编译,gradle,maven等开发工具链问题不能得到较快、较好的解决。

团队对某些领域的技术研究深度不够,导致问题不能得到有效的解决。

敏捷迭代不断,团队成员忙于迭代,缺乏技术积累,人员工作分配不均,开发效率和质量得不到太好的控制。

人员不断增多,但是却不能较好的发挥他们的价值。

等等

就这样,带着这些问题,我走过了前两个阶段,直到到达第三阶段,才有了质的改变。

总结以上问题,核心还是在于团队能力线问题,所以提高团队能力线,才是以上问题的正解。到这里,正如“如何学做管理”中所说,这个问题要通过培养团队成员来解决,那么问题来了,怎么样培养团队成员呢?我们的Android应用开发团队是一个年轻的团队,一些知识体系都还有待完善和建设,作为团队负责人,我有责任和义务给团队成员指明未来的方向。因此,作为培养的第一步,先明确我们团队需要些什么,他们要做些什么,现在能做些什么?我们先来第一步,组织构建:

组织构建

控制组织大小,4到6人为一个小组织。

我们团队有20人,一个20人的团队,任何思想的传达效率都会比较低,协作成本高,根据我个人的开发经验,4到6人的团队沟通成本低(随便找个空地就能开聊),利于互帮互助。

明确各个小组织的领域范畴和责任。

这个点需要一定的技术背景才能操作,我将Android应用领域拆分为8个领域,包括数据与系统对接、网络与性能、界面与国际化、H5与工具链,每个小组织负责2两个领域的持续跟进研究,以及沉淀。

人员责任包括领域研究和产品开发。

对于人员的要求,所有应用开发人员同样需要负责模块功能的开发,同时要兼顾领域研究,让所有人员既有产品观,全局观(了解应用开发需要的所有技术),同时又有自己的核心领域,做到广而精。

这样才划分带来了很多的好处,各个领域的独立,降低了团队成员的心智负担(操心的事情多),每个人都能一门心思的研究自己的领域,遇到非自己领域问题搞不定时,团队里总能找到能提供帮助的人(有所依靠,哈哈)。一个小组织的成立,我们还可以做弱结对编程、代码审查。因为他们的领域相同,知识体系一样,很容易做到这件事,沟通交流更顺心。

另外,附加的收益,由于领域的独立,紧接着领域的沉淀也逐步加强,各种设计文档也很自然的产生(开发人员不是天生都不喜欢写文档,而是不愿意写没有意义的文档),未来新成员培训也是很有希望做到的。这些好像和团队成员培养没关系?嗯,是的,没有直接关系,但是他们是我进行团队培养的基础,是成员成长必不可少的环境,没有这样的设定,团队培养很难落地执行,接下来开始团队培养:

团队培养

识别团队中的核心成员,给他们合适的权力和责任。

想想,一个班里面,除了老师还有班委。为什么呢?层级太多不是也不怎么好么?如果我能同时兼顾20人的所有细节工作,自然不想再构建新的层级。当我们的关注的事务细化到一个层面后,那么精力就不够了,作为领域团队层面,我们的关注点要细化到代码设计甚至编码级别,一个人能搞定吗?至少我搞不定!那么这和培养有什么关系呢?我对培养的定义不仅仅是指导,还包括培养环境的构建。所以这里做的目的主要有两个。第一,给他们更大的发挥空间,发挥更多的价值(构建带领一个小领域开发的学习环境,现在的开发已经很少能单兵作战了),第二,让他们带我传递我的思想和理念,小团队传递效率更高,深度更深。

各领域持续指导和跟进。

各领域成立后,我的精力主要放在和他们沟通上,让他们明白程序应该怎么设计,这个领域需要做哪些事情,应该怎么做,成员如何组织等,反复不断的沟通、总结、改善,持续的做下去,直到我觉得我们大家的思想是一致的,方式方法没有问题(当然,如果我错了,那么问题就大了,我得保证我没有搞错,或者错了及时改正),这样他们才能有效的指导他们领域的成员,带领他们前进。

领域拉通,成员能力挖掘,查漏补缺。

各小领域成立后,并不代表我就可以做甩手掌柜,除了各领域的培养以外,我还需要拉通各个小领域,促使他们有效的协作,降低他们之间的耦合,减少跨领域的成本。同时,还需要持续不断的关注团队成员的学习进展,给与他们合适的建议,以及符合他当前能力的工作,针对有潜力的成员重点指导,针对有问题的成员及时告诉他的问题,促使他改善。

关注新技术,加强自身对技术的学习,带着团队向前走。

细节有很多,这里谈到了主要方面,个人总结能力还是有限啊,主要只想说一点:核心是为了产品的研发,开展基于培养提升团队成员能力,形成自组织,流程、规范、考核均是辅助措施,能无就无,谨慎对待。

3.如何做敏捷项目管理

敏捷团队是一个全功能团队,里面包含了各个领域的成员,由于公司原本组织架构的一些特点,我们并没有像标准敏捷项目团队那样,有产品经理、敏捷教练等职务,与之对应的是规划与交互,项目负责人。虽然“形”对不上,但是如果能对上“神”,也是不错的。

在敏捷之初,我们并没有理解什么叫迭代,我们傻乎乎的定迭代周期为一周,而且还觉得自己在走敏捷的迭代。可惜我们那不是迭代,我们只是每周计划一下需要开发的工作而已,仅此而已。因而带来了很多问题,前端需求人员不知道功能的开发预期和进展,项目负责人也就是协调协调资源,面对纷繁复杂的功能项开发,也不太情况每个功能的开发进展,当前是否正常(除非非常不正常才能发现)。整个项目组感觉都忙忙碌碌,但是却不知道大家都做了些什么?每天晨会大家说的事情都有点不知所云,感觉晨会都快没有实际意义了。问题太多,以至于我们有点迷失方向。

敏捷,宣称要拥抱变化,我们却粗浅的理解为不需要计划,是不是很白痴。我个人现在对拥抱变化的理解为:“及时交付可体验的产品,随时做好调整的准备,日常的工作任务安排,如果发现不合符预期,需要及时调整,重新评估新的任务,而不是掩耳盗铃,觉得不列一个新任务就会快一点”。好了,临近年底,对于敏捷总算有所顿悟,多亏了《敏捷估算和规划》这本书,给予了我很多启发。接下来,谈谈具体的一些实施细节。

由于我们为了保障版本的按时发布,我们采用了版本火车的形式,所以,我们每个发布版本并没有很强的计划(目前还在纠结改善的地方),而常规的敏捷一般包括三个维度的计划工作,最高维度为版本计划,其次而迭代计划,再次为工作任务。所以,针对我们现有的特点,本文仅讨论到迭代计划及其以下维度层面。那么如何做迭代计划呢?我个人觉得一定要遵循以下原则:

迭代的目标是交付可体验的产品,不是完成任务。

所以,迭代计划里面只能是用户故事及需求,而不是某某人的任务,另外迭代并不是完成开发,还包括视觉、测试的工作。

迭代的周期要合理。

针对不同的产品特点,迭代周期一般为2到4周,如果周期过短,就需要把用户故事的粒度拆分到足够小(不是任何产品都能拆到如此小的粒度),因为我们要在一个迭代周期完成开发、视觉、测试的工作,针对我们的产品特性,我们最终改为3周一次迭代。此外,过短的迭代周期,会议也会增加不少呢,还有一些别的非研发工作损耗。

评估故事点。

从长远考虑,评估故事点有利于团队知道自己的速度,如果哪天上版本计划,有了这项基本数据,能更好,更快,更准确的评估版本开发时间。

故事点是对规模的评估,不是时间的评估。

评估故事点需要一定的技巧,我选择10个用户故事,里面包含各种难度的需求,然后给0.1、1、2、3、5、8、13、20、40、100,然后让他们根据这些用户故事的工作量(包含开发、时间、测试的工作量),然后给这些故事分配对应的值,值得重点说明的是0.1和100,在《敏捷估算和规划》一书中采用了0,代表那些基本可以忽略工作量的故事,避免因个别故事太小导致影响后面的相对值,里面重点说到10个0不等于0,因此我干脆改为0.1,更容易体现出10个0.1是有工作量的,至于100嘛,仅仅是为了标记当前故事无法评估,其实目前我们20和40也没有用到,过大的用户故事不利于跟进。

有了这些以后,还有一些问题会困扰我们,一个迭代安排多少用户故事,每日晨会如何开展?迭代发布会,迭代计划会,故事点评审会这些会议怎么组织,在什么时候组织?我们怎么能准确评估一个迭代的工作量,某个领域任务过多怎么办?啊呀,问题实在是太多了,真是人越多问题越多,我们的敏捷团队有20人,20真的和我有缘啊,同时管理两种类型,两个20人的团队也是一种挑战!目前潜意识认为20人的敏捷团队过大,还没有想到太好的拆分计划,还需要不断的总结分析想办法。

上面的问题我就不都解答了,只是想说明敏捷并不是几项简单的流程,它是一个系统化的解决方案,里面有很多细节,就像我们写软件,设计交互一样。现在回想以前自己做软件时,对项目管理人的哪些肤浅的认识真是惭愧。接下来我要重点说明一下在迭代计划下的任务拆分,当我们计划好本次迭代需要完成的用户故事时,下一步任务就是需要将用户故事拆分成实际领域的工作任务,这种任务我们简直是太熟悉了,例如:完成界面编码。那么在做任务拆分时,有哪些需要遵循的原则呢?

任务需要拆分到1到16小时的工作量。

控制任务的粒度,有利于更快的得到任务的进展和反馈。

告诉团队成员,尽量评估准确任务工作量,但是我们允许任务评估不准确,并且我们也认为任务不可能评估那么准确。

拆分任务的目的不是为了评估某个人的工作量和效率,主要目的是基于任务得到反馈,团队事务透明,以及便于拉通各个领域协作。

当发现任务评估不准确时,及时调整任务时间,或者将原有的任务重新拆分为新的任务,或者新的几个任务。

我们要客观的承认任务的难度,这样有利于团队成员更积极的拆解任务,更真实的评估任务时间,让整个团队得到最真实的反馈。

根据任务计算各领域工时,发现迭代瓶颈。

当所有的故事都拆解成各个领域的任务时,我们可以很轻易的发现瓶颈出下哪个领域,并及时作出对应的调整。

根据剩余的总工时量,绘制迭代耗散图。

每日晨会根据看板的任务流动情况,更新迭代耗散图,让团队成员了解到迭代进展和速度。

不要量化团队成员的个人速度,更多的基于团队去考核和引导。

不要通过量化团队成员的速度来对团队成员进行考核,这样很容易引起团队成员各自为政,并且各种评估不合理,我们需要通过其他手段进行成员评估,引导大家基于团队目标进行行动,共同承担责任。

当我们任务拆解已经完成后,接下来就是每日晨会了,开晨会一般是聊昨天做了什么,遇到什么问题,今天要干什么。在没有做这些计划之前,我觉得早上说这三件事很无趣,很无意义。但是,当我们的迭代这样进行后,说这三件事就很自然了。

昨天做了什么?

用于驱动看板上在doing中的任务,是否要挪动到done中。

遇到什么问题?

根据对应任务遇到的具体问题,促使团队成员了解具体的情况,进行交流。

今天要做什么?

用于驱动看板上在todo中的任务,是否要挪动到doing中。

有了这些细粒度的工作任务,晨会就这样开就可以了,由于晨会流程的标准化,我们可以任意安排团队成员主持晨会,好开心!我可以从这件事中解脱出来,在晨会中更专注的关注项目的进展。在任务安排中,同一个人尽量要控制doing中的任务不超过2项,否则不太好及时得到反馈和跟进。这样的晨会,我能很及时的发现项目中的异常点,及时评估和协调,当我告诉测试你们资源不够时,再也不是那么苍白无力,测试也会很悻然的接受我的建议。

4.总结

本年度参加部门的例会,部长的三句话目前印象深刻。

三角形最稳定。

刚开始听到这句话基本上是左耳朵进,右耳朵出,没有太多的感触。直到我将Android应用开发团队划分为四个小领域团队后,才有所领悟。是的,多方关联的组织相对于一家独大的情况确实更加的稳定可靠,也许物极必反也是这个道理。

提升团队能力线。

这句话给了我信心,让我确信当前做的事方向是正确的,作为一个团队管理者,这一点一定要做到。

我们谈原则。

这句话给了我信心以及指导,渐渐我的也潜移默化的给团队成员谈原则,谈思想,谈未来。让我们的思想在同一战线上,路才不会走偏,才能放心的把一些事情彻底的交手出去。

很感谢部门对我的信任,对于我这样一个管理的新人,授权我去尝试这么多的事情,给我成长的环境。2017年且行且珍惜,尽量少挖坑,带领团队走得更远。

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:技术管理  技术管理词条  敏捷  敏捷词条  管理  管理词条  探索  探索词条  到底  到底词条  
产品

 数据产品经理技能必备:MySQL...

作为一枚数据产品经理,需要掌握基本的SQL查询语句技能,之后才能进一步了解与搭建数据仓库、元数据、指标字典体系。本文首先介绍MySQL基本知识。一、了解数据库模...(展开)