突破自我设限

前言

今天聊「突破自我设限」,经过前面 20 几天,多数概念已经建构得差不多,是该来总览与整合。有时个人与团队只差一哩路,大家可能都看见了什麽,但却止步在自己想像中的限制,还没开始就觉得会失败,在一片负面的思维中徘徊,迟迟无法突除它。

今天一样是经验谈,希望透过一些整理,关联铁人赛过去的文章,再次刺激思考。

看待「导入」这回事

团队转型、导入敏捷、导入 Scrum,这背後累积的甘苦谈可曾少过,原因可能有很多种,这里点出其中一种可能:僵固,不知变通的思维。

团队可能会执着(或误解),认为导入敏捷或 Scrum 就一定会如何,这可能是正常的,例如把它当成万灵丹;或反向认为导入 Scrum 肯定会为自己带来麻烦,为什麽我要改变习以为常的工作方法?我们当然可以质疑,更可以挑战,但不是停留在表像上面打转,以呼口号似的支持或反对。

当我们挑战敏捷时,更应该思考敏捷坏在哪?我们如何让它更好?

当我们挑战 Scrum 时,更应该思考 Scrum 不足在哪?我们如何改善它?

延伸阅读:Day 10「自然而然的敏捷导入」与 Day 11「Scrum 也自然吗」。

看待「传统」工作模式

疫情不会是促成远距工作的唯一推力,我们更应该思考它的积极性。在这一系列文章当中,我用了三天的篇幅来说明远距工作,正是希望大家能有机会尝试一下。

而远距工作也只是冰山一角,它现在略展光芒,在未来很可能成为显学。远距工作象徵着团队已经有足够好的沟通与协作能力,并可以展现自主性,不需要有人推着跑,展现时刻检视与修正的能力,以一种更自由、更平衡的方式工作着。

延伸阅读:Day20「管制与自我管理」、Day 26「远距工作停看听:好处篇」、Day 27「远距工作停看听:挑战篇」与 Day 28「远距 Scrum」。

看待「角色」定义

角色(Role) 固然重要,也是团队初期一个抓得到的点,成员各司其职,也界定了基本的底线,约束我们至少要做什麽、不能做什麽,但它不应该阻碍我们的发展。

强大的自我管理团队,每个人都是管理员。我希望你我都能从自己出发,若还需要别人来管理自己,都算晚了。我们同时在影响(或牵制)着着他人,只是我们可能没有自觉,如同象棋的将帅兵卒、企业与客户、国家与人民一般。静下心来,看清楚整体关系,避免陷入纠结。

角色总是变化与叠加的,《经理人之道》在描述成为 Tech Lead (技术负责人,p.35) 时,有这麽一段精妙的说明 (部份截录):

从这个阶段开始,无论你将走向何种职涯路径,其中一个核心挑战就是在事物之间取得平衡。最糟糕的情况是,你经常需要在擅长且喜欢的工作(如写 Code)与不擅长的工作之间取得平衡。

这个描述对我而言很有共鸣,虽然它晚了许久才出现在我的视野当中。当我身为前端 Tech Lead 之时,我不再有连续的时间沉尽在开发当中,随时都有插断,无论是技术上的还是行政事务上的,会议量也增加了不少,是个很多工的工作场景。

我们都有可能成为书中的 Tech Lead,也可能被赋予特定程度的管理权责。届时我们要打破的是「先前的工作内容」,同时也不要被新的工作给框住。作为实例,至今我仍然是跨越两边,我有管理的任务在身,也同时在撰写程序,後者是让自己持续保持对技术的敏锐、为技术教练做准备、为协助团队排除技术障碍、为了成为团队的人力备援。

职位也只是最低标准,只要还有心力,跨向其他领域也是很好的,以企业为单位还有太多的领域等着大家探索,不要让眼前的职位限制了眼界。

同样的道理,《经理人之道》一书虽以「经理人」为名,但值得让每位软件人一读。对於新手,这本身为您指出了未来;老手,这本身为您回顾了过去;现在,这本书也可以作为您的指南。是的,连这点小观念也请大家突破它。

看待「需求」定义

需求是会变的,客户与市场也在不断变动,坚守固定需求并无意义,随时接纳变化的可能。

延伸阅读 Day 21「陨石很可能砸下来」。

看待「突破」本身

当我们要敏捷、要转型,本身就是一种突破传统的思维,或许我们还没意识到真正要「突破」什麽,只是单纯觉得再这样下去不行。

团队不该为了突破而突破,不需要为了特别想做出点什麽、想出点风头,或是求新求变来突破。一个具体的时机是,当团队正在面临瓶颈,就是一个突破的好机会。

再更进一步谈,什麽是突破「突破」本身?意思就是,当我们真的要突破什麽时,同时不要被突破限制住,一直坚守「我一定要突破」,反而又被「突破」给困住了。混乱了吗?思考一下。

若能够轻松在这些观念上转换,相信在团队经历「守破离」的阶段会是自在的,背後的道理也通「见山是山、见山不是山、见山还是山」,当我们转了好一大圈,最後回到的反而是最基础,正如敏捷走到最後,剩下的只有精神

提醒

这并不是在否定敏捷转型,以及导入 Scrum 过程中的各种挑战,只是在心态的层面提醒,避免在充满变化的过程中加入更多误会。已经有太多的宝贵经验在各管道中分享,我也尽浅薄之力在铁人赛分享了一些自己的经验与观点,但这都不是「一定」非得要怎样。

能够有这样的认知,自然可以超然看待每个过程伴随的对抗。

身为变革者,保持开放心态是很重要的,因为正在领导变革,本身就是跳出框架的行为,这个过程中如果又找了一个新框架来框住自己,那就太可惜了。

身为不平凡的团队成员,发现变革即将被引发时,一样是保持开放的心态,因为正在共创变革,这时又把自己框住,往往变成四不像,更是可惜。

小结

流程是活的、规则是活的、人也是活的,知道精神,不要死守名词与方法。

喔,对了,上面这句话也是活的。

当我们超越成见,自然就正向了,这不是许多个人与团队正在追求的吗?

明天「我们与敏捷团队的成长」系列大整合!


<<:  魔法实作 - todolist

>>:  Day-26 事件机制(2)

用React刻自己的投资Dashboard Day23 - 非同步呼叫API,完成首页资料串接

tags: 2021铁人赛 React 上一篇确认过API内容之後,剩下的部份就是串接API,并将资...

TypeScript 能手养成之旅 Day 16 类别(Class)

前言 在 ES6 中新增了 Class(类别),可以视为建构函式的语法糖,究竟是裹上怎样的糖衣呢?让...

Day11:今天我们来聊一下Parrot Security上的Enum4linux

当我们环境有Windows及Samba主机时,可以使用Parrot Security上的Enum4l...

Day-18 Excel手把手作图表(三)

今日练习档 ԅ( ¯་། ¯ԅ) 大家好,今天进到了图表主题的第四天,如果您还没看过前三天的可以先回...

数字证书(Digital Certificate)

证书申请和回应 证书签名请求(Certificate Signing Request) 在公钥基础结...