fei33423的专栏

CTOKPI 包含了架构师应有的技能,能够辅导架构师 规划: 推演,规划未来,提前布局招人. 收集问题抱怨,整理问题(维度化,数字化),发现问题,解决问题: 1. 各个技术系统之间冲突导致的问题 2. 各个系统之间共有的问题 3. 制定流程和目标,简介. 设计评审, 2/5/15 支持: ...

问题: 跨部门解决线上问题. 如果优先级不高,容易出问题.机制 这种首先要有机制,有个跨部门的人来管控这个事情,定制标准和惩罚机制. ali ddcto很机制,指定了一个早值班体系. 协调系统有如下能力 1.总项目(空间)2.关联项目(空间)妙用: 虽然早值班本来是让各团队解决自己的问题. 但是利用团队协作系统....

会向业务“砍需求”的技术同学，该具备哪6点能力？我的另外两篇,待整理:关于需求评审和设计需求评审和分析为什么要需求评审? 很多创业公司,都没有需求评审,一句话带过.很多细节都是开发后期,验收后期才发现. 或者是开发和产品共同沟通的结果.这个时候没有需求评审,好处在于开发即产品,一句话后有自己的理解,同时不需要协作返工成本低. 更重要的是创业开城阶段,主方向对就可以了,细节...

1.CI做到90%的行覆盖率，真能发现BUG吗？如何评估测试用例的有效性2. 基于traceId的单测覆盖率. 可以将线上流量清晰归类. 开源产品类似3. 配置规则，怎么测？内网文章,超级厉害.通过脑图,类似产品的思维方式. 职能图. 角色(内部运营配置,员工,产品,依赖方)以服务端分配码为例,第一个层级: 角色 (员工,访客,管理员,内部预配置)第二...............

1. 自学入门. 现在书很多,视频很多. 网络培训班很多,一两千投入是至少的.2. 低工资,实习三个月 因为纸上得来终觉浅,先去一家门槛很低的公司实习,免费打工. 因为是工作,大家都想要结果,遇到不懂得会指导你.自学的话效率很低,一卡就卡半天3. 有了实战经验之后,跳槽,找更好的平台,难度更高的平台. 这个时候就需要多沟通,牛人是如何学习的,他们平时关注...

泛学:目的:增加大家的广度. 每个人都可以听,了解. 形式: 一人一组 时间: 每周分享,占用周会时间. 素材来源: 阿里云上各种产品,开源各种产品,公司内各种产品,各种流程.标准:能介绍就行,对技术细节不要求完全理解,可以半知半解. 讲明白历史和背景,技术或者框架的来龙去脉,背后的故事. 跑通过demo. 内容结构:...

避免散点问题:   1. 都是散点的问题,没有分类,金字塔.   2. 散点的问题 ,也可以,但要够难,行业解决不掉,行业对比.  复盘时间轴, 并且后续有没有方法论如何长期避免这些问题的action,述职重点讲  1. 做事情的意义  2. 行业对比  3. 有没有多个方案  4. 为什么采用这个方案.  5. 整体架构图, 分类, 核心方法论. 过5年之后系统剩下...

需要积累与平时的总结.平时工作是点状的,主要是周报的时候解决? 归类,汇总,效果.点状bug如何变成总结: 影响目标是什么? 1. 原来受影响的人是多少,现在受影响的人是多少. 2. 解决完bug,性能提升了多少.工作分两块: 1. 点状的,case by case的解决问题. 工作时间,只是说明你在做什么. 或者一个重点case,难点....

管理,项目,进度,协作沟通.一定要让对方给出时间点. 团队口号：快乐工作，快乐学习，快乐分享，注重贡献1、 团队规模：目前团队主要成员6人 2、 管理难度：A：项目多而且还来源于不同产品，每个产品都觉得自己的项目优先级最高B：全职做营销系统开发的比较少，只有4人，实习生,外部支援者C：团队成员职业规划不清晰，甚至有些人完全没考虑自己长远的规划，做事积极性不是

管理,项目,进度,协作沟通.一定要让对方给出时间点.大数据-监控系统-BI一、管理说明：1.团队规模 大数据智能平台部实时监控组，目前有6名同学参与到实时监控项目（包括实习生）。另外，由于实时监控系统依赖外部系统、服务较多，虚线团队还包括：公共技术部 3人（ dba baidu-dbproxy）；基础平台部 3人（）；原大数据架构团队 6人（）；2.管理难度

容易陷入的坑:1. 早会只抛问题,抛风险,感觉抛出来老板知道后就可以了. 抛出后, 具体对风险的action是什么, owner不管了, 需要老板定下来, 要么改时间,要么加人.2. 只关注action,没有数据支持,可衡量具体化.3. action执行者不把自己当owner, 依赖方需要管理,时间点,和过程风险暴露和解决. (自己经常遇到的坑)4. 不要对别人有要求...

另外一篇自己总结的文章:大项目设计和管理复盘 - 需求评审如何评审.核心原则对自己:对他人:做好表率和育人: 工作方式,向前一步的关键是(这也是靠谱的核心,信任度,放心把事情交给你,个人执行力和owner一件事情的执行力和作为领导带领团队的执行力) 1.一个问题,自己先分析. 2.如果发现不是自己的原因 3.可以变成组织者(自己先定时间,这样自...

当跨部门业务项目和技术项目很多时, 还在做手头项目,还未进入提测阶段,又要被拉去评审了,反响很大.1. 如果你不反馈,组员压力就会很大,就会很不爽. 最终老大又会怪到你.2. 另外你帮他们去计划时间,他们也会很不爽. ( 别忘记掉通知组员去设计和排期了.那就是你的不专业了)     和主题无关的ps:        组员成长最好是另外结合业务的成长,变成ow

331原则:三个角色. 领导: 定目标,发现问题和指定解决task,拆需求,思想碰撞沟通,按需分配. 了解: 职场互相了解,定位. 可以搞团建,自我定位,介绍. 生活了解. (兵熊熊一个, 将熊熊一窝) 教练: 做事,怎么做要有一定广度. 但后面可能只需要定目标,预估时间,关注流程中问题. 跨部门追过程, 直接过去让他约定完成时间.

人基于感性认识进行决策: 影响力,预期管理,情绪管理,沟通管理,预期管理.客户: 同事,上级,夸组同事,跨部门同事,需求方.积极处理方式: 管理好自己的事务. 1. 主动对客户进行情绪管理. 进度主动反馈. 2. 主动展现成果. 3. 以点带面. (一个对账n个对账,一个分润n各分润)对于我自己: 要低调,要沉住气,不要得瑟.提出成

系统都是进化出来的,不要过度设计.一开始设计支付表. 有代金券id,代金券抵扣金额.业务进化后后面有多种优惠,业务水平拆分为两种业务.支付业务.优惠维护业务.一个订单: 表1:乘客支付金额和乘客抵扣金额表. 表2: 订单id, 优惠类型,优惠金额,优惠id.落地方案1: 代码需要兼容老版本: 查询代金券id,需要先查新表,后查原表