深度优化项目总结

深度优化项目已处于尾声,我差不多从头到尾到参与进来.需求收集整理是先潮处理的.从先潮整理完成需求到生成产品原型, 我加入的时机是从整个界面原型的技术实现分析,数据库设计,代码架构设计,以及深度优化主要的订单模块内容开发.那么按照时间顺序,我回顾下在整个过程的处理情况.时间只能做个大体情况的描述.以及问题的整理,有值得继续发扬的地方,不足的地方,忍无可忍问题.

[问题1:我的问题,研发人员所说的内容和产品经理所说的内容有一定出路的,比如我和先潮之前的沟通,比如说订单列表排序,我问是不是当前界面的排序,他说是的,但是后来他又说使用当前字段去服务器查询后的结果,而不是当前界面上的数据排序,所以如果技术人员说的内容,尽可能使用精确的话来说明问题,不然的话,产品经理和研发人员的理解有偏差,虽然这个问题不大,目前只有几个小问题而已,但如果出现个大问题,那就是非常严重的.

处理方案是首先意识到有这个问题,然后研发人员和产品经理沟通,研发人员复述产品经理的内容,让产品经理来判断是不是产品经理描述的含义,否则会浪费比较多的时间.同理,研发人员和市场人员的沟通等等,都需要研发人员尽可能以对方的理解为基础去描述事情.当然很厉害的研发人员一定能以对方听的懂的语言去描述事情,因为他懂的换位思考,最起码我个人感觉我挺差的.]

开始我和先潮讨论问题的时候,虽然说订单深度优化,但是其实绝大部分过程都说的是商标注册内容,虽然有个自己找接口的嫌疑,但是我确认就认为是商标注册的优化,事实上绝大部分,90%的内容就是商标注册优化的内容.所以说没有任何问题的,我只处理商标注册业务的.最后2018年后期,做订单列表后来说全部订单列表,而不是商标注册业务.

[问题2:作为产品经理,做业务介绍的时候,务必确定明确当前产品原型设计的业务范围的,我认为产品经理每次做产品的时候,务必圈定业务修改范围,这个是大前提.所以我当初圈定的业务范围就是商标注册,其他的内容我就认为保持旧模式,旧的设计,根本没有做两者的业务交叉和杂糅,如果我知道是全部的订单,那么现在的设计应该会有部分调整,是大部分还是小部分,待定.如果我知道是全部订单的调整,给1个半月的时间,我会毫不犹豫地直接拒绝这个非常无理的要求]

[总结1:之前qds项目中,基本上有1/3的时间编写xml中的SQL脚本,如果不使用新技术,那么我实在都不敢想深度优化的工期会延迟多少的.同时虽然说,每次查询只查询需要的字段,但是深度优化中没有这么处理,因为做实体类映射的查询,此次编写的脚本基本1/10都不到,同时方便后期业务拓展,不需要改SQL,这样便于拓展和后期业务开发进行,利大于弊的决定.节省非常多的开发时间,能快速跟进业务的进行.使用新技术提高生产力,必要的培训都有有必要的,哪怕占用上班时间,我认为都可以提交非常多的生产力,也许这次看起来延期很多,但是不用新技术延期会更多]

之前和先潮确认过,设计的基础就是一标一类为基础,前期所有的设计都围绕这个开始的,但是后来到了tbd,进入开发阶段,居然管理层推翻这个设计,重新回到多标多类的场景.再次我表示极度极度的无奈和压抑.

[问题3: 深度优化的延期处理,个人认为至少1/2的原因是基础设计的推翻决定的.那么我实在不晓得,当初先潮和市场人员,管理层过了那么多遍,这个基础都没有质疑过吗?那么过了这么多遍,到底是怎么决定的,里里外外讨论那么多时间,到底都做了些什么,讨论了什么的.好比本来蓝图个东方明珠,最后要开建造的时候,要盖个别墅.来到云集中心后,设计基础的改变改变导致问题的变化,因为这个问题业务变化导致的,我更认为,以后产品经理和管理层或者市场讨论问题的时候,能不能思考业务需求的基础根本,立足点是什么.所以基础都错误了,其他的都是浮云,没有任何价值.这一点是从根本上出现的问题和失败.]

从五月左右,我开始思考深度优化原型的问题,整理了四个版本的问题,和先潮讨论后的答案.整理差不多两个月,这次版本迭代实在非常非常大的,我个人认为我已经相对比较熟悉业务,但是每次打开原型都会有新的问题和新的界面内容.我不敢说彻彻底底整理完业务,但是大体的脉络熟悉完成.

[问题4: 从给app写接口耗时2-3个月,到两个中心开发耗时2-5个月,然后深度优化耗时2-5个月,我们做了太多的大版本迭代,给我们研发人员带来太多的痛苦,真想拿一把斧头砍死几个人的冲动,砍死谁,想想是不是自己,并且都是过年的时候开发,入职两年的春节,没有哪一年过个好年的!]

以后拒绝大版本迭代,不要说有什么不能推迟处理的,遵守下互联网产品迭代的规则.开始说深度优化中退款,增减商品项不能砍,需要一起迭代的.但是事情确实无法完成,那么不推迟完成的啊.我知道产品经理没啥决策权,那么管理层要参与产品设计的话,那么最起码遵循下互联网小步快跑的产品迭代策略.两个中心,新版个人中心,深度优化,都是企业级开发模式.

虽说公司花钱雇佣我们,给工资了,要干活,这无话可说.但是我个人认为公司要考虑工作给员工的痛苦指数,每次大版本迭代都表示你要加班加班长时间加班,加班时间长,压力非常大.每次都是要过年了,给大家不断地增加痛苦,已经发生两次了,希望管理层有些远见,不要不断给大家增加不必要的痛苦,管理领导的不善.如果公司再来一次这样大版本迭代,就直接不用考虑我了,让别人接手我的事情好了,我一直接受的准则就是事不过三.]

熟悉业务的时候,Java由我负责了解业务处理业务内容,个人认为我对业务的掌握程度,我个人满意的.我认为我这个评价对自己名副其实的.深度优化的商标注册业务,除了先潮,就我最熟悉.我得到我预期的目标.订单业务由小组负责,小组掌握业务,目前来说分产品线是对的.

[问题5:大版本迭代就是船大不好掉头,两个中心,深度优化,只有某个关键支撑内容发生改变,在进行调整的代价是非常大的,尤其项目从需求收集,需求分析,数据库设计,架构设计,代码开发,测试,上线部署;如果业务出现问题,那么数据库设计,架构设计,代码开发都会被波及的,调整的越晚,代价越大.所以说从一月调整,那么数据库设计,架构设计,代码调整,都会波及非常广的.所以我个人认为,深度优化的延期等问题就是管理层的远见不善导致的.]

[问题6:事后诸葛了,深度优化在我看来当初一个半月做不完,这话也许很欠揍.但是管理层直接下来任务说一个半月完成,和两个中心类似,说了也没有任何用途,那就去做吧,尽力去做,做不完也无愧于心的.当然我没有认真落实到每个点上,据理力争这是是我的问题,不能推卸的责任.

但是我认为最根本的问题是管理层管理没有远见,不知李嘉诚还是谁说,我看到的是半年或者一年后的事情和发展,我个人感觉公司看不到半个月后的发展,看不到所有安排不明白具体的事务进展,如果说深度优化重要,那么技术参与处理两个月后,就应该七,八月开始进行深度优化开发,给个三四个月开发,而不是一个半月的时间.如果合伙人重要,当初说招人去开发,然后又不了了之,给这么点时间去开发.种种迹象表情,要处理事情的时候,管理层的处理和大学考试类似,都是临阵抱佛脚的处理.入职两年,管理层的决策给我的感觉从来就没有从容不迫,有条不紊的时候,每次都着急忙慌地进行,最后的结果都是产品经理和研发人员的无能导致的.

我们回顾下公司的产品设计和发展,商标交易,从三楼刘真一个2016版本,开发完成,然后在线上沉睡;然后一楼2017版本开发处理,然后代码在线上沉睡,浪费多少人力时间的.公司的产品敲定都很匆忙,搞的都很着急似的,慌慌张张的,至少浪费2-3人/月吧,然后不了了之的.这样的问题,可能只是管理层的几句话,做什么什么,过了几个月,之前的不行,我们再做什么什么,尽可能善用人力,虽然决策过程不是这样的,但是最终的结果对于我们来说就是如此.]

[问题7:是否想过为什么下面的反馈慢慢不多,或者没有呢?从我的角度看,既然是决定的事情,反馈的事情没有用,我们说了没有任何作用,还说这些做什么呢.如果不需要太多的讨论,那么就需要比较高明睿智的管理和领导.或者也只是个流程讨论而已.我感觉这样不好,从公司长远角度来说,熟悉业务的人因为对公司的种种不满积攒的负能量,哪一天爆发,当然公司少了谁都照样运转的.我也见过几波人入职离职的,其实我总结深度优化的事情,也不指望公司能看进去听进去的,只是感觉应该去做吧.最起码对我有提升吧.次贷危机中,美国雷曼公司,很多公司中低层员工都知道公司要完蛋,可能只有管理层不知道,因为他们根本收不到底层一线的反馈,同时可能底层一线反馈也是什么用都没有的.]

最初深度优化的版本数据库设计讨论完成,最初的架构是spring boot处理.处于技术实践和未来技术的使用定型,使用spring cloud来使用微服务,同时搭建好框架内容,减少未来技术的债务.未来5-10年,技术框架应该不会有太多问题.算是自己对公司的贡献,然后在此基础上不断添砖加瓦.技术框架选择和搭建上自己趟过很多坑坑洼洼的.

[总结2:使用spring cloud作为技术架构的选项没有任何问题,目前来说运行也还算良好,同时公司技术架构和主流一致,有利于招来积极的人,技术框架框架这块试错,其实时间很短的,但是知道这块没有问题,如何保证及时处理问题,这块需要做的比较多,整体在技术架构这块,应该差不多半个月的处理,个人感觉时间很短,做到这个地步,还算个人还算满意.]

[问题7:技术架构搭建好,其实没有进行一定时间的讲解,以会议的形式讲解,这个是个很大的不足,以后搭建好的内容,以会议形式讲解,让大家都明白如何使用这个是搭建技术后需要处理的,这个没有处理好.增加了其他人的摸索时间.但是我做微服务分享的时候,也没有谁来听啊,最后以文档形式发给大家,那么就落实到我的管理的问题,或者组员的素质问题]

我想我应该在实践spring boot框架编写业务的时候,用了差不多一个半月时间把下单,订单列表,修改尼斯分类的时候,测试开发,然后给穆哥错误,误以为差不多一个半月就可以开发完.这块的开发完是因为之前的一标一类的基础.但是之后数据库的修改,spring cloud框架的调用形式,导致了不可能一个半月完成,是不是穆哥根据我这个做出来的判断呢,还是因为管理层要求一个半月要求完成导致的呢.

[总结3:目前的框架,在我的思考总结下,处理很多之前qds框架中的问题,虽然有新的问题,但是机会成本来说,非常小的.这个必须感谢穆哥的支持的.总的来说避免掉qds的大部门已知的问题,会看qds,感觉自己之前的代码烂的要命的要命.在spring cloud下,大部分人的技术,不说代码基本素质,技术都有比较大的提升,个人认为的会有的]

[问题8:当初a要离职的时候,说n月内没有问题,不会离职的,但是我没有大用他,结果证明我的结论正确,同时后续查看处理深度优化的乱七八糟的代码,全部重写推翻掉,写的代码和qds的结构一样,可读性可拓展性都是非常差,不能大用,只能小用而已,判断很完美,这个认知非常好; b两次提离职,这样的人我跟不会委派重要的任务谁知道下次啥时候离职呢, c.代码问题重复提出n多遍,每次都是重复的问题,进行不做处理,哈哈,当然不能说就我可以,我知道我的管理有问题,一定有问题,尽管我不断总结反思的.深度优化中管理思考方面提升很多,算是进步许多,些许内心的安慰.]

数据库设计,架构设计过程中,我出现的问题没有那么多,基本很少.数据库设计和穆哥,其他人讨论若干,原则性问题不存在的.可能会有很多业务上的瑕疵问题.数据库设计从开始,到评审,以及后期来到云集中心处理,基本稳定没有什么问题.虽然从一表一类,变成n表n类,但是整体稳定性和拓展性都得到及时处理.后期记得沈哥讨论过另外的设计,当时其实我打算放弃数据库的维护处理,移交给别人处理.类似这种企业级开发,业务整理完,推翻重新处理;数据库设计完,打算推倒重新设计,然后着急忙慌地去开发,实在没有太多信心能完美地处理完成任务.就以当前的红色标注说明,项目能进展到现在的程度,我感觉非常不容易,同时这是一个非常完美的项目管理开发的典型失败案例.

[问题8:所有的问题都得考虑现在的资源,人力,技术和素质,以这个为前提去思考的;或者未来新增的人员思考,是不是有可能.考虑问题就是这个为前提.临时想到的什么事情忘记了]

[问题9:我低估了项目安排的难易程度,所以项目排期其实出现很大的问题.如果不是这么处理,那么项目排期可能就得三四个月,现在回过头看,当初安排的拆分的任务需要两三天才能完成的任务,排期一天,本身就有问题的.回头看排期有问题,有没有问题其实都不是问题,因为那些时间就是不够用的.给我的教训就是自己认为合理的安排和处理,就必须据理力争,不然做不完事情,就得我背锅.任务拆分排期,这个给我很大的启发,就是开发前花费两三天好好思考任务排期,是非常有必要的,凡事预则立不预则废的代价]

[问题10,我要打造个新的订单团队处理,之前的种种问题,属于历史问题,和穆哥说过的,失去信任再重新建立信任,这个过程还不如开始个新的团队,扔掉旧的一批人重新培养的好,如果打造新人的团队,那就是我的问题.那么和旧的团队成员的关系就属于要舍弃无法舍弃,还得忍受的情况.团队的秘密一书中说的一点很重要,那就是信任关系,深度优化中很多事情之所以不分派出去,就是因为不信任,宁愿我自己处理,我的事情比较多,导致部分事情的进展延误,这个责任不能推脱.]

[问题11,我管理团队的问题,这个之前总结过,应该尽可能利用现有资源去处理问题,不能指望其他人处理完任务后积极主动去处理事情,这个,目前来说,入职这么多年没有多见几个人有这种积极主动的品质,大部分人就是干完自己的事情,就做其他的私事,所以当初管理陷入个问题就是希望能找积极主动的人.给我的启发就是尽可能合理安排事情给不同的人,跟踪进度,发现事情做完,干别的事情,那我就尽可能继续分派事情.不能寄希望于其他人的积极主动,一切需要自己去掌控]

事实证明,订单内容的事情,分派出去的事情,差不多有1/3的事情,我重写一遍代码.同时也证明我当初的担心是正确的.很多代码,在我查看后,直接删除掉,我自己重写的.对于屡教不改的人,自己实在没有耐心去培养一个人,屡教不改的人.

[总结4,虽然管理层,或者市场其他人对深度优化结果很多意见,但是从结果角度看,做纵向对比,和当初入职给app写接口,两个中心项目比较,深度优化中以及解决掉我反思两个中心和给app写接口中绝大部分的问题,大部分问题我给予全面的处理和部分处理,当然引入部分问题,但是从机会成本上看,处理掉之前大部分问题,引入目前评估出来的少量问题,利远远大于弊.

从代码的拓展性和将来的业务拓展性上,减少大量的xml中的sql编写;使用框架的功能比较多,减少大量人为添加的困难,降低非常多的开发难度;从结果看,我个人人为深度优化的结果,半个月测试处理,然后上线,要比两个中心的处理要完美的多,如果两个中心处理的结果打10-20分,从技术处理的角度我给深度优化打分80以上的,可能其他人对业务结果不满意,但是我个人对技术和业务处理相对之前的代码开发,我非常满意.]

[问题: 关于士气,开始整理业务,数据库设计,架构设计,其实历时很长时间了,我再次感受深刻的是,士气,一鼓作气,再而衰,三而竭.从六月到十二月业务变化调整,然后变化调整,其实到开发的时候,我已经没太多心思去处理这些事情.古代行军打仗将领还知道军士疲敝不堪,需要修整呢.前进的过程中,过程如果都不稍稍美好一点,其实不必期待会有个好的结果,对人对事皆是如此.给研发人员有多少修整的时间呢.从深度优化后.

[这块是我的感悟收获内容,灵光乍现]突然感觉古代事情和现在的关于人的判断,其实都差不多的.管理确实是比较有价值的学问啊,突然的感受和领悟.选择创业公司,最关键的是创始人,创始人的言行举止传递的信息,才是最关键的.创始人平时都比较大气,那么手下感觉有希望,平时都比较好,将来不好的可能性不大;如果平时都感觉没有多少美好的事情,将来自然不必有任何期待.]

[问题11,关于加班和关于人性化,我认为相互体谅是基础,但是现在根本的地方根本谈不上什么相互体谅.我认为加班和休息应该是波浪形的,比如1234四周,1加班135,2加班24,然后135,而不是现在这样的加班方式.我非常不认同深度优化的加班方式,虽然去创业公司,是开启hard模式,还是地狱模式,这个取决于公司管理层,但是尽可能妥善合理的管理,降低工作劳累程度,这个需要管理层好好想一想.高强度的加班,不会增加什么产出的,如果世界上什么事情都可以加班处理,那就不会有那么多伟大的互联网公司.

[每个人都有自己的思考利益出发点,我想我作为公司管理层,我希望员工都精力充沛,每天给我工作25小时;看看百度阿里腾讯,那么晚还在加班还在工作,我们为什么不能这样呢?如果我是员工,我就想看看人家百度腾讯给的福利待遇.拿着白面的工资总是希望做出来白粉的价值,又想马儿跑的快,又不给马吃草.

那么需要退一步,我给你的答案,如果公司对员工的关怀到位,平时工作很顺心,其实大部分人对薪资的要求并没有那么苛刻的.会出现上面的情景的最重要的原因就是平时一方对另一方斤斤计较,马云说了,离职的原因有2,不顺心,钱不够,处理这两个问题,绝大部分问题都没了.

涉及到另外的话题.招人,留人,开人.我认为这都是正常的公司事务,如果认为人员不行,那就开除掉就是了.设置规则,规则公平,招人,留人,开人很正常的.我个人认为公司不需要对某些人满意不满意,不符合公司利益不能推进公司业务发展,那就开掉无可厚非,招来合适的人就是.(可能只代表我的意见,也许还有一部分人的心思而已),哪天有一天我被开了,我都一点不意外的. 我们可以严格执行KPI考核就好,满足要求的留下,不行的开除掉,规则之下人人平等就好,其实个人感觉不必有太多不满,这个不满或那个不满的]

关于深度优化接口这块的bug问题其实并那么多,当然自己可能比较乐观.主要是和两个中心做比较,bug数量其实Java部分并没有那么多的.当初以为处理完上线,需要两三个月去适应消化深度优化带来的问题和影响呢,结果看现在差不多半个月全部消化处理完成,这一点穆哥的领导和管理做的非常好啊.这一点很佩服.

[问题12,深度优化和合伙人产品设计问题,我个人认为的问题,那就是合伙人的设计和深度优化的订单设计存在出路,会有很多不是共性的地方,有差异化的地方,导致订单接口无法通用的.无形之中增加不少工作,但这不是问题,可能设计就是如此的.希望的是尽可能相同的业务有尽可能的设计,尽可能不要有太多的差异化内容处理,处理给合伙人的内容差不多花费工作日5-8天的时间,专门处理差异化的部分]

整理的内容,乱七八糟的,可能对可能不对,都是我思考和我的认知内容吧,说的不对的,不是那么一回事的,请见谅.