来到可兰达以后，和大家一起做了很多有趣的事情，其中有些产生了很好的效果，有些以失败告终，有些还在摸索和验证当中，有些显得有点鸡肋，食之无味弃之可惜，还在纠结的阶段。在后面逐个介绍这些项目的起因，经过和结果以及产生的一些反思。
管理方面：职级体系建设，OKR目标管理工具的落地，绩效评价体系，研发招聘评价体系，组织结构调整
职级体系目前从第一个版本以来稳定改进中，每次开会讨论都会有新的收获，也请教了很多其他行业其他公司的朋友。目前的进展算不上非常满意，也反复讨论了很多次了，这是我觉得比较鸡肋的一部分产出，因为在大厂，我理解职级也是一种管理工具，在绩效和目标管理还没有做得特别成熟的情况下，我们厂的规模需要这么多管理工具吗？我不太确定，可能目标管理和绩效管理是我目前更认可的应该着重强化的部分。
OKR和绩效评价体系是我刚来可兰达，吐槽得比较多的，一个是我们非目标导向的做事方式，一个是最初形同虚设的绩效，目前和综合部也会定期开会讨论相关流程和制度，不断完善中，但总的来讲，这块并不是我擅长的，也看了不少资料，请教了很多人，目前的形态，也没有达到一个我自己觉得很舒服的形态，我觉得也许是因为管理大部分工作其实本来就是反人性的，要不自己不舒服，要不下属不舒服，总是没有办法达到一个比较理想的状态，这个结果主要来自人性的复杂。未来在目标管理和绩效管理这块，其实应该是要投入非常多精力的，即使可能目前做得磕磕碰碰或者短期看不到效果，但我始终认为，这两个是管理最重要的两个部分。
研发招聘评价体系做了一段时间规划，有点虎头蛇尾，后来停了，主要原因是接近年尾招聘需求下降，频次降低，准备来年招聘量上来的时候，再逐步把这块做得更规范，提高这部分工作的价值。
组织结构调整做得比较多，自认为效果还行，虽然目前短期还看不出来实际产生的影响和产出，但清晰合理的组织结构和战略目标的配合，是公司管理的基石。不合理的组织结构会影响员工的产出和绩效，包括工作积极性，工作效率，未来工作规划，成长与挑战。根据万年历维稳的战略目标，主要的调整有，成立最美社区项目组，成立聚乐直播项目组，成立技术中台组，成立智能数据组，减小万年历项目组团队规模，测试组合并。
业务：最美社区项目，万年历，聚乐直播预告项目，心动日常项目
我个人并不喜欢做“纯管理”工作的人，脱离了业务的管理工作，我感觉更像某种行政职能，很难发挥真正的作用，纯技术管理，在我们公司目前这个阶段，作用是非常有限的，一是因为人员规模还不够，二是业务规模也还没到一定量级，强调太多技术专业上的重要性，其实会弱化业务的成长，所以只会在万年历这样的成熟项目上去尝试，新项目方面，更多的是业务的摸索，这方面来说，我个人也还是在摸索阶段，并不是我特别擅长的领域。但经过之前创业的摸索和来公司以后的实践，逐步也有了更多的理解，看的视野更广阔，有更多心得，虽然最美社区和聚乐直播这两个项目都失败了，但在里面也摸索出来一些门道，应证了科学管理的作用在“做业务”这件事情上有它的价值存在，做业务一定需要灵光一现的灵感和某个行业敏锐的洞察力吗，我觉得未必，灵感之后的市场调研和逻辑分析也许比灵感本身更重要。
聚乐直播我个人感觉更多输在没有对这块技术难度有一个合理的预估，产品验证阶段的失败，也和团队本身的组成有关系，运营成本太高，实习生也确实不给力。即便这样，我现在其实也还是有对聚合直播的需求，主要原因可能是我作为直播用户，已经完全摒弃电视，习惯在手机上观看直播节目，但在一个平台上的体验，其实并不是特别好。相比来说，最美社区项目更是倒在一个很突然的原因，我和团队本身还没有完全放弃。
万年历项目组，目前主要是在用户体验和收入上做文章，这块我花的精力并不算多，还是在新项目组和日常管理工作时间投入比重比较大。核心的想法是，通过技术手段，从客户端，后端，前端入手，解决一些以前没有关注到的用户体验，让大盘上更多用户在使用万年历产品的时候，得到一个更优的使用体验，提升品牌和产品的质量。大厂在这块投入都是相当大的，但我其实到可兰达以后，才开始反思，我们以前花时间花精力去做这些技术改造优化体验的事情，到底是由于到了一定程度，技术人自己为了提高自己的产出和重要性，去找的事情做，还是实际上会给用户带来统计意义上的不一样的体验，这个核心的诉求，是没有问题的，实际的效果，还需要验证。
心动日常项目，基于偶然开始做，然后调研了这个市场中的竞争对手，发现一些可能打得过现有产品的方法论，这个方法论也是从优启还有九吨一些相关负责人这里取经，加上自己的理解再升华了一下，也是待验证的一个业务场景，目前我是比较乐观的态度，但具体效果，也和我们在产品设计和打法上的很多细节把控关系很大，因为这块会是一个很重体验的产品，好坏的区别可能和每一个技术方案，每一行代码每一次交互设计息息相关。
技术：中台建设(推送，AB测试)，后端技术栈扩展，服务稳定性(EM系统，后端性能监控，前段性能监控，慢请求优化)，
机器学习在商业变现中的应用，CI/CD，后端容器化改造，数据中台建设，程序员节活动
技术方面的尝试也非常多，目前看起来，有一定成效的，是机器学习的应用和后端技术栈拓展，在测算产品推荐这件事情上，我们用日卡文字链作为试验田，粗略验证了使用时间+地域两个大方面的特征，可以做到大体上5%左右的点击率提升，在最终测算产品收入上的影响也有一个大体同比的提升，后续的计划是把粗粒度的特征更细化，做到个性化推荐，并把其他位置都通过主机器学习辅人工的方式进行管理，虽然看起来是一个循序渐进的过程，但这其中对数据质量等基础设施的建设，连接打通原有配置，是完全不在一个量级的难度，未来会逐步推进。后端技术栈，从纯C#，扩展到现在大部分新项目用GO，从纯windows，扩展到部分linux。纯语言的区别我觉得倒不是特别重要，操作系统的变化反而影响更大一点，可能带来的是完全工作模式的变化，思维方式和视野的转变，技术面太窄，只知道计算机语言层面的东西，是对程序员这个职业最大的误解，计算机语言其实只是露出的一点冰山，海面下庞杂的计算机基础知识体系才是一名计算机工程师更大的提升和挑战，目前有些团队也开始尝试一些其他方面的新技术，当然，总体上，我也会把控，不会让太宽泛的技术选型成为一个包袱。
服务稳定性相关，目前由于人力原因，进展比较缓慢，在来年会通过在OKR中拟定目标逐步去推进，主要在万年历项目，逐步积累经验，公司的同事经常说，万年历的用户体验和商业收入，是反比，挂广告多了，用户体验就差了，广告少了，用户体验就好了。这种说法有道理，但太有局限性，把用户体验和收入完全看作一个零和博弈。这么看起来，通过技术手段对用户体验的提升，反而是工程师更大的价值，不仅提升用户体验，反而对商业收入也有正向影响。启动更快了，包更小了，打开一个h5更快了，很少出现打不开h5的情况，崩溃率更低了，等等等等。
中台建设相关的产出目前收效甚微，影响力还不够大，不管是技术中台还是数据中台，直白地说我甚至感觉有点鸡肋，未来的规划还需要和相关同事多探讨一下，相比稳定性提升，目前我个人也没有特别笃定的路径和方向，需要大家一起摸索，这样一种形式的组织和技术输出，在当前规模下的公司，是否能发挥出真正的价值。
程序员活动，很小的一个活动，但感觉很有意思，明年1024节还想继续搞，难得全公司的工程师可以就一个大家都参与的项目一起探讨交流的机会，相比平时的非常细分领域的分享，我个人感觉效果更好。
以上。