07 | 解决了很多技术问题,为什么你依然在“坑”里?
郑晔
该思维导图由 AI 生成,仅供参考
你好,我是郑晔。
在前面的内容中,我给你介绍了几个体现“以终为始”原则的实践,包括怎样界定工作是否完成的 DoD、怎样判定需求是否完成的验收标准、还有怎样验证产品经理给出的产品特性是否合理的精益创业理念。
了解了这些内容,可能你会想:我为什么要关心这些啊?我是程序员啊!难道我不应该安安静静地写程序吗?为什么要操心其他人的工作做得好坏?如果我管了那么多事,我还是不是一个程序员,到底哪里才是我的“终”呢?
今天这一讲,我们就来聊聊这个让许多人困惑的问题。因为只有要跳出程序员的角色看问题,工作才会变得更加高效。
“独善其身”不是好事
在需要与人协作的今天,独善其身可不一定是好的做法。我先给你讲一个发生在我身边的故事。
有一次,我的团队要开发一个数据服务层,准备作为一个基础设施提供给核心业务系统。开发没多久,一个团队成员和我说,他的工作进展不顺利,卡在了一个重要问题上,他想不明白该如何在多个实例之间分配 ID。
我听完之后,有些疑惑,为什么要考虑这个和功能无关的问题呢?他解释说,因为我们的系统需要保证消息的连续性,所以他设计了消息 ID,这样下游系统就可以通过消息 ID 识别出是否有消息丢失。
这是没错的,但我奇怪的是,他为什么要在多个实例之间协调呢?他给出的理由是,这么做,是出于考虑应对将来有多实例并发场景的出现。然而事实是,我们当下的需求应对的是单实例的情况。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
在技术领域中,仅仅解决技术问题并不足以让你脱离“坑”。本文通过分享一个团队开发数据服务层的故事,强调了“以终为始”原则的重要性。作者指出,在需要与他人协作的环境中,独善其身并不是明智之举。他强调了不同角色在工作上的上下文差异,以及如何跳出程序员的角色思维,扩大工作的上下文,从而更全面地理解问题并提出更有效的解决方案。文章强调了技术能力并非解决所有问题的唯一途径,而是需要从更广泛的角度思考问题,以提高工作效率。通过扩大工作上下文,读者可以获得更多发展机会,提高工作效率,解决更多问题。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《10x 程序员工作法》,新⼈⾸单¥68
《10x 程序员工作法》,新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(58)
- 最新
- 精选
- SA我在项目中也多次遇到过通过扩大上下文而解决问题的情况,比如有一次客户提了一个定期从我方系统提取数据同步给某外围系统的需求,开发过程中我们发现提数逻辑涉及关联一张上亿多数据的大表,查询性能很差,技术层面无论如何是无法解决的,最后我们从需求层面出发,着手绕过这个坎,经过分析,发现关联这张大表的作用主要就是为了过滤掉一些脏数据,再结合客户最终的使用场景分析,发现其实由外围系统进行此项过滤会更容易,最后我们说服了客户和友商,不仅很好的绕过了这个坎,也成功实现了该需求;类似的案例还有很多,技术解决不了的问题就通过非技术手段解决,这个案例中开发人员搞了几天一直没能解决,后来报了进度风险,最后版本经理想到从需求层面绕过去,这或许就是他们两个角色的上下文不同的区别吧
作者回复: 赞!
2019-01-0975 - Vackine听了这么多第一次留言。还是研究生,马上毕业,听了之后,感觉对自己以后职业的发展有了更清楚的想法认识和计划。事物发展的过程都是由点到面不断往外扩充的,要想成长也是如此,从最开始看到的点,前后上下文的联系,以及思维的转变,才是成长更近一步的表现。老师讲的非常棒,跟下去之后对自己之后毕业入职一定会有很大的帮助!🤗
作者回复: 真羡慕你在没开始工作之前就了解了这些!
2019-01-0956 - 大彬我很喜欢上下不同这个描述。我曾经以为,具有主管的能力就够了,后来发现这还不够,缺少主管这个位置的视野和背景,就是上下文这个词。我们组的主管,是上级主管兼任的,我想,我是不是能够成为组的主管?有次主管有事没来,让我按他说的,给其他同事安排工作,等他回来后,跟他汇报,发现是有差距的,并且有些工作还得他出面协调。为什么我做的不够好,为什么我现在做不了这个组的主管。一个星期的时间,我认识到,能力是一方面,上下文也是一方面,我缺少他知道到的信息,这也会影响决策的方方面面,从此,开始不断拓展自己的能力圈。
作者回复: 你已经具备了向前一步的基础,赞!
2019-01-0937 - Gojustforfun还没满足当前需求,就以可扩展性之名考虑后需求,纠结着想要一次性写出完美的代码,没错就是我本人了! 老师的那位同事真是幸运能遇到您! 我一直在纠结着,实现一个功能可能有ABC三中方式,当量级上来后C更容易扩展成D满足后续需求,AB较难或需推倒 有两个纠结点: 可能只有AB,根本没C自己在那里瞎转空耗 意识到了有ABC,但纠结着无法做出选择,因为抱着那位同事的心态想一次搞定完美解决,可惜能力不够不知道C能扩展成D 希望听听老师的建议,谢谢
作者回复: 别纠结,先实现,等问题真的出现了,再说怎么去优化,很有可能的情况是,你想多了。多了解一些上下文,你才有能力判断自己是否想多了。
2019-01-10320 - ZackZzzzzz之前一个项目,需要调用三方的API拿到客户购买历史,通过和上下游服务交涉,明白购买历史只对于会计计算有用,而会计允许一定范围误差,确认不调用三方API的结果在误差范围之内,结果就是节约了大概4s的API延迟
作者回复: 赞!
2019-01-0919 - 新博之前自己是一个打杂的程序员。有次负责一个项目的人离职走啦,部门经理让我负责,最后也完成了工作,不仅让自己的技术得到了提升。更重要的自己也学会了与客户的更好的沟通,及时完成项目任务,获得了领导和客户的信任。扩大自己工作的上下文,别把自己局限在一个“程序员”的角色上。
作者回复: 越走路越宽
2019-02-2412 - 春之绿野我在做ab两个组的事情,前两天a组的组长跟我说因为他们这边缺人,让我全部做a组的事情,因为没有心理准备,而且我想这边这么缺人,我肯定也没有选择权,问我可能就是个形式,于是我就答应了,其实我不想专做a组的事情。后来还是我领导找的我,我跟他确认我能不能自己选择,还有a组这么缺人怎么办,我领导说这个是可以自由选择的,缺人的话他会让另外一个同事加入或者想其他办法加人。其实在领导的上下文里,这个问题是有很多解决办法的,我还操那么多心,连和更大点的上下文寻求帮助,反馈沟通的意识都没有。而且我发现我做的选择是下意识的根据好多预设的条件做出的,因为是无意识的,也没有去反馈和确认这些预设条件的意识。如果不是领导主动找我,我可能又暗自憋屈去了。沟通好难啊!
作者回复: 进步就是一点点发生的。
2019-05-129 - 印哥爱学习很多公司内部系统,研发团队建制并没有那么全面,很多研发团队都不配备产品经理及测试,全靠研发自己往前往后多抗事情,这种情况下,公司更想要不光会闷头写代码的程序员,所以还是多了解一些,尤其是业务主导的公司。
作者回复: 是啊,但是,人少不代表需要的角色少,没有人是也得做。最糟糕的结果就是,用户成为了你的测试,发现了更多的问题。
2021-01-168 - arronK由于自己的爱好吧,之前也经常学习一些产品经理相关的东西,在做写程序的时候呢,也会经常和产品经理去沟通他们的一些产品需求。我就是经常这样扩大自己的上下文的。 也应而在和产品对接需求的时候。有很多不必要开发的需求能及早的避免掉,有很多可以更好更优的解决方案的需求能够更早的被提出来。也正是因为如此,我的开发效率也提升很多。
作者回复: 你已经走在正确的路上了。
2019-11-268 - 蓝士钦技术团队在bug反馈群里排查线上用户问题。有些不一定是代码有bug而是产品设计缺陷导致的逻辑问题导致的,程序员的思维通常是马上蒙头查日志 找出代码中的逻辑bug,火速修复。 扩大上下文:跳出程序员思维,站在处理问题的角度思考如何才能快速解决用户当前的问题,有没有途径让用户先通过其他操作绕过这个问题,先让用户能正常继续使用系统。bug让测试人员先验证确定问题点 最后才修复。 而不是在等bug修复僵持很长时间。 通常群里的开发组长会让用户通过其他途径先正常使用系统,普通开发人员依旧埋头查日志。 这件事可以看到不同上下文的人处理不同的事,但普通程序员依旧在自己的范围内处理问题。有全局思维却难以跨越
作者回复: 线上的Bug先修为妙,不影响用户为主。下来再想怎么更好地解决。
2020-06-076
收起评论