09:05 到公司 09:06-09:08 整理桌面卫生 09:09-09:20 思考今日任务安排 09:21-09:51 组织Java早会,分派当日任务 09:52-10:01 休息 10:02-10:26 处理订单查询者的问题 10:27-10:32 休息 10:33-10:58 处理临时杂事的安排处理 10:59-11:54 处理注册中心的代码拆分 11:55-13:38 午休 13:39-15:13 处理完成注册中心的代码 15:14-18:06 处理杂事内容
今日任务安排: 1.文龙,继续处理crm事情(熟悉原型,熟悉技术框架等内容) 2.利阳,接手发票模块,准备金蝶发票对接,文龙彻底放手 3.栋栋,接手文龙的那块申请人业务,处理订单流程状态的问题和bug 4.斌斌,沈哥联调,同时邮寄模块的单元测试,开发编写. 5.微服务第一讲文档,看看栋栋和云飞整理没有. 6.昨天周例会上,很多模块已经业务划分完成,现在的很多内容其实要改变的
1.处理完成穆哥指派的crm的订单查询者业务内容 2.处理完成注册中心的代码
技术管理: 1.很多时候任务分配不到位,比如crm,看昨天例会情况就应该是文龙一个人处理的,而昨天我确认斌斌和云飞也查看原型,浪费这么多人力时间,到底什么原因导致的呢?就是以后要做什么事情,我根本都不知道,组织架构没有定型,我分派的事情其实根本没有什么价值的,甚至很多分配因为很多前提信息不存在,不知晓,导致出现非常多的无用功. 2.要控制早会时间的长短,今天开半小时早会,比较耽误时间.分享的时候,分享完的内容,让其他人整理,查看他们对分享内容的掌握程度,同时锻炼这些人的文档编写能力,同时分享的时候大家踊跃发言,锻炼自己的表达能力,这样对于每个人都有的发展都有非常好的帮助,值得大力发展. 3.这次其实就是一次大版本的迭代,因此修改的逻辑层层相扣,a改的订单a模块的,b改的订单b模块的,c改的订单ab模块的,一次上线的内容差不多10多个问题,并且跨度非常大的,非常麻烦的.小版本积累非常大的后,那就是大版本迭代,事实上这个非常不可控的,之前为了避免这个问题发生,所以修改了一版本,其实这个上线后,那么就没有太多问题,然后第一个版本没有上,紧跟着第二个迭代版本,在第一个版本上的修改,第三个版本在第二个版本上处理,非常大的版本迭代.本来周二周四上线就尽可能小版本迭代,最后认为搞成个大版本迭代,管理本身就是有问题的,最可怕最可悲的就是认识不到有病.应该如何去做,a版本处理完线上几个问题,处理没有问题了,上线;然后在a后面的版本去修改b版本,b版本没有问题,那么上b版本,然后b版本后继续处理c版本,每次都是小迭代,并且开发人员毫无压力处理,现在搞的好似一大波僵尸突然来袭,搞的又是大版本迭代.管理是一门技术活,是工艺,是艺术品,因为恰到好处可以让人变得舒服愉快,简单可控. 4.既然乱七八糟的没有规则,那么我就去制定规则好了,不然的话,得类似我们研发人员,我制定的规则,我来遵守,其他人的种种问题,在我这被集中拦截.
反思总结: 1.首先第一点,不能靠人的自觉去做某事,因为人的素质是不一样的,问题在于什么呢,投机取巧,多一事不如少一事,实际上能负责的人不多.比如提测前代码审核,根本原则就是直接拦截掉,查看不通过的代码,直接退回去.靠人的自觉是对制度建设的缺失. 2.如何每天都可以没有意外的没有大问题的版本迭代呢?而不是周二周四去上线的,因为人为因素实在不可控的,导致非常多的问题.很多我打算上线的内容,未必可以及时上线的.
网友评论