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

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

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

实录提要:

  • 怎么说服不是很懂技术的领导给予时间支持重构这件事?
  • 作为基础平台部门,如何更好平衡平台升级与业务线产品交付的压力?
  • 消除技术债务比较好的手段有哪些?
  • 如何向产品团队的人解释偿还技术债的重要性及相关的工作量?
  • 详细介绍一个系统或业务做得比较好的组织的沟通方式和组织结构?
  • 怎么将非一流个体打造成一流团队?
  • 在保证质量和进度的前提下,怎样减少团队的加班时间?
  • 产品经理有好的产品需求规划会更有利于技术债务的减少吗?
  • 有技术团队与市场脱节的情况,怎么防范?
已有203人预订
预订达标
文章出炉
交流日期
     
01月08日
01月13日
01月16日 20:30
查看文章评论/提问
Michael
就像下棋一样,走一步,看三步。 什么是远见,这就是。
雨品
技术债,迟早要还。
郑泽安
关于技术债务,我认为无法避免,但可以减少其带来的负面影响,让团队持续良性的发展。在初期,做好基础技术架构和研发规范要求,在项目进行过程中及时发现问题并处理,对团队成员做一些技术提升帮助或者改正其不良习惯。总体来说我觉得项目的行进应该是小步快跑,对于问题不拖沓及时处理,消除债务,减少债务累积带来的重大问题。
右军
明晚付费用户群答疑,关键范围: 组织架构,技术架构,技术债务,协同涉及一点考核范围。以上主题欢迎留言或者联系明天下午的小助手提问。非以上话题,可以加好友到日常群解答。
军哥
请教老师一个问题,作为基础平台部门,如何更好平衡平台升级与业务线产品交付的压力?是不是组建一个平台加业务的综合团队在一定时期比较有用
乐夕
产品模糊,架构懈怠,业务追赶,研发低能,体制僵硬,一大堆垃圾产品倾囊而出。
右军: 这是一个复杂命题,任何一个因子最好一些,结果也有少许改变
马金凯
比较赞同引入考核方式,把重心放在考核上,背负考核时成果质量就会提升,当不同组织的关注点一致时,事情就好做了
风行天下
TeamLeader的远见性,基本上能够决定了整个团队的技术远见性,至少在实际工作中会有这样的情况,一线码农如何引导呢?
曹磊
如果产品团队与技术团队不在同一个team,如何向产品团队的人解释偿还技术债的重要性以及相关的工作量?说服他们在产品迭代的周期安排中考虑这一部分的时间要求?
三旬老汉
学到很多东西,谢谢
江伟
请教老师两个小问题。 请问组织架构上是否有必要单独成立一个技术能力较强的小团队,把控架构方向引导整合技术团队? 怎么说服不是很懂技术的领导给予时间支持重构这件事?
郑泽安
消除技术债务的比较好的手段有哪些,对于债台高筑的项目是否直接废弃重新开发了。
庄表伟
对缩减团队的案例很感兴趣,从8个团队减到3个团队,他们怎么肯同意的呢?或者再推广一下,如果让一个团队承认他们是冗余的,并不重要呢?
王超Charles
老师好,如果已经积压了技术债务,还有很多的业务需求的压力,而且已经工作负荷很大了,是否有办法向上管理,说服老板把业务需求延期一下,去清理技术债务呢?
ZzZzzz...
创业公司初期各种原因会有很多技术债务,中期又会面临快速发展,人员不足,这期间如何更好的组织管理偿还债务?
李志刚
请问能详细介绍一个 系统或业务做的比较好的组织的沟通方式和组织结构吗?比如支付宝 在不避免谈“责任”的前提下,由于 减少沟通环节 而造成的后果,有没有好的处理办法 增加组织凝聚力 保持上下同欲有没有实践经验,技术团队建设又有什么特点?
李晓时
所谓“强将手下无弱兵”,可往往是“强将手下尽弱兵”。怎么将非一流个体打造成一流团队?
李晓时
在保证质量和进度的前提下,怎样减少团队的加班时间?
武可
技术债和真实债务的最大区别在于,技术债确实很有可能不用偿还。 而且这是个自实现的预言:不偿还 → 短期快,长期慢 → 无法适应需求变化被淘汰 → 不偿还是经济的 → 投入到又快又糙的新产品中… 另外,不要在雨天修屋顶的原则,和抓住项目痛点推进结构改造,其实是有些相悖的。一般来说觉得痛了多少都是在下雨的时候,真等到晴天了,时机也过去了。 说到底,还是要靠决策者对度的把握
Michael
老师好,提个问题,减少团队数量来提高沟通成本,但这个是和康威定律是矛盾的。康威定律不是说大系统倾向于拆分。那就是说总有一种组织形态是最佳临界点,是最适合当前架构的?或者说是最适合设计当前系统?再或者说是提供满足客户价值的系统。客户的需求是变化无常的,那组织的重构也必然是一种常态。不知道这么理解对不对?谢谢
你可能还喜欢
Service Mesh 在华为公有云的实践
田晓亮
从零开始,搭建 AI 音箱 Alexa 语音服务
Mike
Web 安全恩仇录:再谈逻辑漏洞
肖志华
编程和数学基础不佳如何入门人工智能?
赵宁|Neal
如何用 Vue 实现前端权限控制(路由权限 + 视图权限 + 请求权限)
雅X共赏
智能增长:如何用大数据和人工智能实现业务体量的增长
蒋凡
微信扫描登录