保存成功
保存失败,请重试
提交成功

从康威定律和技术债看研发之痛

作者/分享人:右军
蚂蚁金服高级技术专家、支付核算技术部负责人、成都研发中心技术团队创建者之一,先后负责或参与资金运营平台、类营销类支付工具等数个平台建设;之前有数年电信业务研发经验,涉及BSS|OSS|针对性营销等平台。个人感兴趣的方向:高并发、稳定性模式;内建质量、技术型管理。

软件研发没有银弹,但无数人又在麻醉自己寻找银弹。我们总是心怀理想,现实骨感。理想是产品靠谱,老板靠谱,研发在好的办公环境按时下班; 现实是产品改来改去,业务变来变去,加班加成狗。理想是胸怀大志打造一流系统,现实却是撸着业务代码,感叹如何成长? 理想是一个强大的工具平台,我可以专注自己的业务研发,现实却是一连串的沟通和协同,到处都是坑。那些不得不说的技术债,那些逃不开的康威定律,架构该演进,还是该依托稳定平台架构,且看老司机解读一二。

实录提要:

  • 怎么说服不是很懂技术的领导给予时间支持重构这件事?
  • 作为基础平台部门,如何更好平衡平台升级与业务线产品交付的压力?
  • 消除技术债务比较好的手段有哪些?
  • 如何向产品团队的人解释偿还技术债的重要性及相关的工作量?
  • 详细介绍一个系统或业务做得比较好的组织的沟通方式和组织结构?
  • 怎么将非一流个体打造成一流团队?
  • 在保证质量和进度的前提下,怎样减少团队的加班时间?
  • 产品经理有好的产品需求规划会更有利于技术债务的减少吗?
  • 有技术团队与市场脱节的情况,怎么防范?
已有656人预订
预订达标
文章出炉
交流日期
     
17.01.08
17.01.13
17.01.16 20:30
查看文章评论/提问
zhenxing1 年前
图片全部都看不到了,作者能修正一下嘛,多谢
光辉岁月3 年前
写的非常好,要反复研读,并运用到实际业务中!
dongquan3 年前
学习了,谢谢老师分享
Michael3 年前
老师好,提个问题,减少团队数量来提高沟通成本,但这个是和康威定律是矛盾的。康威定律不是说大系统倾向于拆分。那就是说总有一种组织形态是最佳临界点,是最适合当前架构的?或者说是最适合设计当前系统?再或者说是提供满足客户价值的系统。客户的需求是变化无常的,那组织的重构也必然是一种常态。不知道这么理解对不对?谢谢
武可3 年前
技术债和真实债务的最大区别在于,技术债确实很有可能不用偿还。 而且这是个自实现的预言:不偿还 → 短期快,长期慢 → 无法适应需求变化被淘汰 → 不偿还是经济的 → 投入到又快又糙的新产品中… 另外,不要在雨天修屋顶的原则,和抓住项目痛点推进结构改造,其实是有些相悖的。一般来说觉得痛了多少都是在下雨的时候,真等到晴天了,时机也过去了。 说到底,还是要靠决策者对度的把握
你可能还喜欢
Redis 知识点整理
JavaTimo
1925·青年必读书——民国名流开具的书单
李烨
Java 集合底层原理剖析(List、Set、Map、Queue)
老牛
基于 Spring Boot 的线程池最佳实践
古拉里
Vue 一步一步搭建企业级后台管理系统
一只帅帅的猿
Spring Boot 面试指南(50 题)
axiya
微信扫描登录
关注提示×
扫码关注公众号,获得 Chat 最新进展通知!
入群与作者交流×
扫码后回复关键字 入群
Chat·作者交流群
入群码
该二维码永久有效