Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

01/2017: Monthly Toggl Retrospective #102

Open
EthanLin-TWer opened this issue Jan 19, 2017 · 2 comments
Open

01/2017: Monthly Toggl Retrospective #102

EthanLin-TWer opened this issue Jan 19, 2017 · 2 comments

Comments

@EthanLin-TWer
Copy link
Owner

EthanLin-TWer commented Jan 19, 2017

Overview

在看 Coursera 的 Learning How to Learn 课程 #99 时,里面提到大脑有两种不同的模式及其周期性。我开始想到采用静静🐵计时的方式来如实反映时间利用,为大脑模式周期提供 关于自己的 数据支持,于是走上了记录时间这条 不归 道路。从1月14日始我开始使用 toggl 计时,已经不知不觉成了生活的一部分,耳朵有时看我在用手机电脑计时的时候,还会戏耍地乱敲我的电脑~除夕前夜,就让我来做个心念已久的 retro,总结下这半月来的发现与结论。

image

image

13天以来一共计时大概271.5小时,实计大概12个完整的工作日,大概每天22.5个小时,94%的记录率。按照28原则,94%的记录率这里不需要再反省(不过按照绝对值来讲,剩下的6%依然是17个小时,相当于这半月来所有课余编程时间的总和还多…)。第一次 retro,原则是:

  • 对时间使用有一个稍微数据化的认识
  • 对时间记录这个事情本身更多思考
  • 遵循20-80原则,优先回顾大类上的时间,暂不过度深入、优化小细节

Dive into Analytics

image

下面会按时间花费多少来逐项分析。

B类-基本生活成本 Basic Life (139:03:46 / 51.2%)

所谓成本,也即是我认为价值不大但必须维持的事务,这个认识本身是有待商榷的,因为“成本”、“价值”这样的东西容易功利,希望自己也能更多感受日常生活的乐趣。这里的基本生活成本,包括睡觉、洗漱、一日三餐、买菜做饭、通勤等,竟然占去一半的时间不止!随着时间分析、计划制定,越发地发现自己浪费不起时间,需要更加努力,也更自然地承担起一些责任,这是在身上发生潜移默化的变化。

睡觉(69.24h / 271.5h = 25.5%, 69.24h / 11d = 6h 18min/day)。这个时间是夜间睡眠的时间,午睡和赖床都不算在其内。午睡为何要分开我没必然依据,赖床分开则有依据。6h18min 的夜间睡眠,我觉得还算是正常偏少的范围。睡眠目前不打算再深入计算,这个数据也可能是数据样本尚不够全面、准确得出的结果,后面再看。

一般生活事务(20:46:34)。这个 entry 是这两天新加的,准备用来容纳属于基本生活成本但更突发或短期性或不得不做的事情。这20个小时基本是昨天坐飞机回家及家里陪虎仔🐶的时间,属于正常事情。没什么好 retro。

吃饭🍚(12:26:51, 12.43h / 13 = 57 min)。这个看起来时间已经很少了。假定早餐几分钟不算的话,相当于午餐晚餐一顿只需要30分钟左右咯。需要注意的是,中间有一天的午饭时间是2个半小时,那天是去 TB 了。这么长时间,我更倾向于认为是社交活动。然而,作为社交活动,其价值基本是没有的,那天的话题基本就是娱乐性的电影、一如既往的房子、贴近地面而毫无营养的话题、各怀立场的人。产出一个 action。

image

通勤🚌(7:58:20, 7.97h / 8 = 1 h)。 合理。骑车上班从下楼到公司平均20分钟,总体消耗一天一小时。坐公交有时要更久。打滴滴的话,无论是从金钱上,还是从时间上,都不划算。更何况,内心并不想被这个下雨就单方面调价的贱人当成“选择抵抗力最小路径”的人群被营销。当然,打滴滴更多是出于迟到已久不好意思的心态,所以解决起来,与解决赖床与早起策略应是连带的。

image

做饭🔥(7:41:31, 7.69 / 12 = 38 min)

image

早晨洗漱🍼(5:15:02, 5.25 / 11 = 28 min)。这个28分钟似乎有点小多了,尽管除去前后的成本还是多了。可以是下次 retro 重点关注的项目,并且,尽管回到了家,还是要早睡早起、按时洗漱、吃饭。产出一个 action。

image

晚上洗漱🛀(4:38:43, 4.63 / 11 = 25 min)。洗个澡加洗衣服、洗厕所(1min…)、刷牙什么的,觉得不算瓶颈。

image

午睡😴(4:13:51, 4.23 / 7 = 36 min)。平均起来,不多,正常。不过有1天中午没有午休,有2天睡了接近1个小时。我的经验是,午睡的时候就午睡,不要戴耳机,能感受到大脑还要处理歌词旋律输入,会分神。

image

洗碗(1:44:18)

A1-工作 Work (39:32:55(39.55h) / 14.6%)

image

考虑收集下面这些数据:

  • 每日除去日常会议实际工作时间
  • 每日实际高效工作时间(解决了核心问题,或非常专注的时候)
  • 工作中实际的 velocity: 工作中每个卡的估点和实际占用时间比较
  • 每个卡中 tasks 的估算与实际完成时间比,但这需要 toggl 集成到工作环境中去
项目 item 实际用时 比例 percentage
实际核心工作 BlackOps + DART 29:02:56(29.04h) 73.43%
敏捷日常会议 Standup + IPM + Retro 5:05:27(5.09h) 12.87%
额外会议 Other Meetings 2:42:02(2.7h) 6.8%
Sessions | Workshops 2:13:14(2.22h) 5.61%

日常会议 Regular Meetings(5:05:27)。每周5个小时日常会议,应该说是一个标准值了,BlackOps 真是一个示范项目组。站会一周2.5小时,IPM 1个小时,Retro 1个小时,半个小时 extended,我觉得是很健康的一个时间。然而这里其实也有一个问题,可能我忘记准备,就是 IPM&Retro 之前其实也是有时间来准备会议的,这个迭代体现还不是很明显,下个迭代可以看下收集下数据。

image

其他会议 Other Meetings&Events(2:42:02)。一次 production issue 的会,一次 portfolio update,正常,仅供记录用。

Workshops&Sessions(2:42:30)。1次英语试讲,2次咨询团队大会。后者其实没留下什么东西,只是在心里种个草;英语试讲还是挺好的。不足的是 机器学习、微信小程序 、AR&VR(觉得暂时排除) 的 workshop 我都去不了,要么 DART 有事要么 BlackOps 有事。今年可能会列入我的技能清单,so 这些也是重要的。产出一个 action。

DART-GFI。DART 这边的工作已经没什么好说,离开是带着留恋的心情啦。SSO 那一块看起来也很有意思,实际代码上似乎也有一个 service 还要设计,自己全新起。不过来到 BlackOps 的技术栈变成 CI/CD 及基础设施,以后则可能会接触前端。这才是与自己职业目标相结合的正确姿势,作为一名 dev,虽然沟通学习也很有价值,不过当前我更倾向于核心代码能力和问题解决能力的培养

BlackOps

Story Card Tasks Total
换组工作交接 看项目 backlog 37:08
查看邮件 23:01
整理(checklist/TW group emails/alias) 1:36:32
2h 36min 41s
550 整理相关问题 + 和 K*a 打电话了解确认 2h 54min 13s
了解项目代码 29min 0s
了解 Node 版本升级 43min 40s
了解 AWS 增加 slave 容量的原理与配置 4h 15min 58s
读书,了解 Linux 上内存模型及 SSH 1h 15min 13s
Debug 部署不成功的问题 45min 5s
走查现有 slave 硬盘使用情况 24min 49s
升级 Nodejs 版本到 6.9.4 4h 16min 20s
15h 4min 18s
临时のdynatrace issue 建卡,了解解决方案 40min
修复 Dynatrace 部署过程遇到的问题 1h 23min 15s
确认其他 region 正常部署、写 comment 体力活 1h 41min 6s
问下 ZW Dynatrace 的情况 5min 21s
3h 49min 42s
其他 53min
总计 Total 22h 23min 41s

每天可做卡时间:3h 43min ( = 22h 23min / 6 )

Task Spent Story Points Days working
Onboarding 2h 37min 2 0.7d
Frontend Slave Enhancement 15h 4min 3 4.1d
Dynatrace bug 3h 49min 2 1d
  • 似乎对于非代码类的任务估时偏高,而对于代码类的任务估时偏低
  • IM 对于留 comment 以做文档用很有偏好。这对于项目来说是好的,对于 dev 来说平均每天则需要多占15min 左右时间,似乎也是好的
  • Ansible 的反馈周期较长是一个问题,一天假设工作 3 小时,平均反馈一次半个小时,即是说每天只可能验证个5、6次。这不是好的方式,必须改进之
  • 技能熟练度也有很大关系,要学学这边的技术栈

C1-跟宝贝 o(////▽////)q

image

本日志仅宝贝可见。

D-浪费(20:14:26, 20.23h / 271.5h = 7.5%, 20.23h / 12 = 101min = 1h 41min)

image

天啦噜,仔细计算一下,平均每天居然浪费了1个小时不止的时间。按照28原则,如果能有非常简单的方式 cut 掉80%的浪费,也就是每天可以凭空多出接近一个半小时! 这20多个小时的浪费中,赖床占去了14个小时,平均每天1个小时不止,也即是说,每天大部分的时间都是赖床时间。按照28原则,本次 retro 只分析赖床的时间和原因。

之所以把赖床的时间放在浪费,而非睡眠,是因为这样的浪费是有原因的。有意留意了自己在赖床时的情绪,多是因为前一天有情绪没有处理完,或自卑或逃避或消极,觉得不想上班,或者前一天浪费了太多时间直接自暴自弃觉得还早起干嘛,因而赖床。但其实上,赖床并没有什么意义,解决不了问题,只是白白浪费时间。还是需要了解身体,了解大脑产生反应的过程,众生平等啊,没什么好比较自卑的。加油即可。可以产出一个 action。

A5-Rest(14:45:52)

Foosball (8:00:53)。8个工作日,平均每天要打一个小时,感觉是多了。看了下描述,用时较多的几天都是因为打得比较 high,要么是彼此都较有状态,要么是刚赢一盘就又被打下来,总有一种不服想要连胜几把的期待感。哈哈哈。产出一个 action,要把这项的时间降低到2/3,也即平均每天最多打40分钟。提高时间成本的方式就是一直打不要下减少等待时间呗,不过打得久也累,每次本来是想出去放松一下的,结果回来的时候比出去的时候还累成🐶。。。

image

A2-技术/编程 Tech-Programming (14:12:58, 14.2 / 271.5 * 2 = 10%)

说明了啥?在除去基本生活成本以外的业余时间里只有10%——也就是1成——的时间用于了实际编程,这踏马要谈个屁的技术卓越?我真是很失望。这10%的时间里,大约有70%的时间是在撸 Chrome 插件,有30%的时间是在重构项目代码,而后者刻意练习的比例则更少…我只想静静。

开发 Chrome Extension: PEAK (10:01:41, 10 / 14.2 = 70.4%)。这里每个 issue 都有计时来 track,可以产出一个 action,记录分析这些 issue/task 的用时。

image

重构项目代码(3:49:42, 3.83 / 14.2 = 36.9%)。这里主要就是在重构 U*A 那块代码,一直想把现有真实起 Spring context 的单元测试拆掉,以最简单最快的 JUnit assertion+Mockito 代替之,因为现有测试一个类要 680ms,相对 10ms 一个的单元测试慢了68倍。每次以 0.5s 简算,30min 的时间可能运行30次单元测试,每次就是15s… 好吧,虽然看起来不是很多,不过每次按下保存同时跑测试的同时,680ms 加上 Intellij 的 Run view 启动绝壁要2s+,对于开发者体验就很差,人脑明显要停下来等大脑。

image

A3-阅读-方法论-知识管理 Reading-Knowledge-Methodology (10:44:04, 10.73 / 271.5 = 4%)

啊,这个 retro 我做得好累。

之所以把方法论与技术赌气地分了一栏出来,是因为 annual review 的时候大家给的评价就是说我对方法论(比如 TDD、时间管理等)很热情,但是技术方面好像 average,感觉似乎没什么卵用。这听起来就好像是说,恐惧对技术要求很高,力求卓越,然而最后并没有求成,于是感觉追求这个事情好像没什么卵用似的。向结果论致敬,并且产出一个 action:向外界展示,永远结果导向;自己学习过程,则追求更优的方法、更快更好的路径。成果不对个体分享,对小组分享。

行了,下面的 entry 加起来不超过25小时了,主要是陪家人。终于完成这第一次半个月的 Fornightly Retrospective,可喜可贺。累死我了,感谢从羽,结束撒花。总耗时 9h 15min。

image

Well

  • 开始计时,战胜拖延症的第一步啊!
  • 通过计时,使自己对时间和自己在做的事情本身有了观看和审视,某种程度对拖延、逃避的心有所意识与觉察

Less Well

  • 还没把计时用于 estimation 和 planning
  • 刻意练习的比例太少了
  • 用于 IT 和妹子以外的时间也太少了,应有第三生活啊
  • 用于 IT 的时间里,实际编程的时间也太少了
  • 用在 IM 上的时间基本没有,不知是好是坏…
  • 似乎没有与人交流的时间
  • Toggl Retro 的时间太长,费心费力,最后只能被抛弃

Actions

General Idea Retroed from ... Description Acceptance Criteria
细化 Toggl Project 的分类 - 用于支撑下面的量化,针对性地优化提高。Project 是分析的大类,可谓元数据
    细化 Toggl Project 的 Description 模板 - 比如三餐各自的时间分配等。但目前看来没有太过细化的理由,属于 nice to have
      产出 Toggl Retro 的模板 - 这次 retro 花去太多的时间,比如数据计算,模板整理等,模板能使下次更快更直接
        将 Toggl 应用于个人 planning/estimation - 及时反馈学习进度、根据速度调整计划数量、缩短计划与执行的反馈周期等
          • 建立 milestone 并以此规划日常事务
          将 retro 所得 action&thoughts 产出成 ticktick/issues - GTD 原则。执行 action 也需要时间;thoughts 可能是日后的种子
            • 将 retro 所得 action&thoughts 产出成 ticktick/issues
            减少1/3打 foosball 的时间 A5-Rest 平均每天1个小时,真是白 billable 了,打多了也很累,按照28原则,先 cut 掉1/3的时间
              • 每天打 foosball 的时间不超过40分钟
              加快做事速度 B-Basiclife 生活成本的总量是不会变的,那么做的更快,是从速度上节省时间,对人的精神面貌也是积极影响
                • morning cleanup 的日平均时间比这次 retro(28 min) 减少了
                早起 B-Basiclife 诸多好处,一是不用堵车,二是不用打滴滴且被加价,三是不用迟到,四是晚上的代码练习可以提到早上做,五是早上更安静更能专注,六是对习惯养成有正激励
                  • 每周至少3天8点20前到公司
                  先减少一半赖床时间 D-Waste 赖床多是因为心情不好,然而赖床不能解决问题。不如起来看电影或怎么样,利用习惯的原理改变之
                    • 下个月最多只赖14小时,即每周最多赖3.5小时,平均一天半小时
                    参加 capability 方向相关 workshop A1-Work-Workshops -
                      • 参加至少2个小时 workshops/session

                      Thoughts 💡

                      💡有些事情其总量确实是没有太大变动的(比如生活成本),那么这种情况下,要提高效率,可以:

                      💡retro 的重要性。GTD(同时也是正确的做事方式)中重要的一步便是回顾(也有更专门的复盘一说),不管是对工作的 retro,还是对方法论本身的 retro,都是重要的。

                      💡retro 产生的 action 又是我们日常需要安排进来的事了,它们同样遵循 GTD 原则,有两个可能流向:

                      • 变成可执行的事件安排到 Ticktick 中
                      • 变成更长期事件或规划安排到 Github issue 中

                      💡晚上睡觉或午睡的时候要放松,清空大脑,不要想东西。

                      💡番茄的要义有二:专注与休息,其组合便是节奏。专注是刻意练习的基石,休息适应大脑的运作机率,同样很重要。番茄不要用于记录。

                      💡番茄时间到了就停止休息。

                      💡习惯。改变的方法:动机、奖励。寡人发现,7点半起床并没有什么卵用,梳洗做饭要半个到一个小时,半个小时在交通上,到公司依然9点,甚至还迟到。这样“早起”(7点半起)这个事情其实是没有奖励,没有愉悦感的,还有迟到的不快感。因此如果不改变这个结果,这样的习惯不可能形成,也没有形成的意义。所以,我想的是,更早去公司,把下班后的半小时重构学习的时间抽到早上来,这样可以提前进入工作状态,下了班早走,更重要的是早上没人,安安静静几乎是效率最好的时候了。不过也要注意,晚上回来就要好好陪陪妹子啊~经过实践,发现不需要8点到,因为8点15分会有送早餐的来敲门,刚好就在要进入状态的时候打断了,这样这半个小时撸代码的幸福感和专注度都大大降低了。不如8点20到,吃个早饭,打个水,梳理一下,然后8点30开始撸一下代码,缺点是人开始多了,看我早到都要震惊一下……😂

                      💡通过刻意练习,我提高了洗碗的速度😂左三圈右三圈碗就干净了,以前由于处女座心理一直觉得不干净就会一直刷…哈哈哈哈哈。

                      💡很多时候,赖床都是两个原因:没有目标有所逃避。前者时不时会被弱化,后者有时白天工作生活中会出现,尽管没有表现,但是对身体的影响是诚实的,就会赖床或逃避面对。

                      💡对我来说,一次详尽的 toggl retro 需要占用很多时间。如果很多时间,那么事情通常只有两个趋势:少做,或者减少做的成本。目前结论是,少做+优化模板工作;每月一次,一些模板性的计算写代码自动化。

                      • 少做,比如1个月才做一次,平时就想到一些 well/less well/actions 就及时放进去即可
                      • 减少做的成本,比如更早的 retro(一周或两周一次)、只回顾重点、使用模板替代每次计算数据等

                      💡更好地规划 inbox,不是今天必须做的就别放 #today。

                      💡尽量保持规律的生活作息,按时早起、刷牙、吃饭。

                      💡让跟宝贝相处的时间更有意思。

                      💡需要找到在 Toggl 中度量刻意练习的方式。

                      💡这些想法板需要被回顾,只是作为想法记录下来,或一时无法采取 action,或暂时无法衡量其价值,或暂时不在优先级上,但以后可能需要用上,需要被存取和回顾 -> Ticktick

                      💡慎重挑选 TB 对象。

                      💡向外界展示,永远结果导向;自己学习过程,则追求更优的方法、更快更好的路径。成果对小组分享,对个体则要更懂是否适合分享。

                      References

                      @EthanLin-TWer EthanLin-TWer self-assigned this Jan 19, 2017
                      @EthanLin-TWer EthanLin-TWer changed the title 01/2017: Monthly Retrospective 01/2017: Monthly Toggl Retrospective Jan 20, 2017
                      @EthanLin-TWer EthanLin-TWer added this to the Iteration 1: PEAK milestone Jan 27, 2017
                      @JimmyLv
                      Copy link

                      JimmyLv commented Jan 27, 2017

                      TheMachine 对 Finch 说:如果你删掉我的记忆,我要怎么从错误里学习,怎么成长,怎么记得你?

                      @JimmyLv
                      Copy link

                      JimmyLv commented Jan 27, 2017

                      哈哈哈哈 豆豆加入了保龄球俱乐部,John 说宁愿拿头撞保龄球也不愿意社交。

                      Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
                      Projects
                      None yet
                      Development

                      No branches or pull requests

                      2 participants