年中总结

前言

有两个月没写总结了，无论缘由如何，总要把欠了的补上。这个周末抽出时间，好好整理一下前两个月的工做内容以及感想，内容涉及：

1. Github
2. Flutter
3. 产品思惟与用户意识
4. 新的技术观
5. 新的团队观
6. 自我承认

Github

具体技术点，已写在文章中：🤖自动化的Github Workflow

自作开源组件以来，文档、预览、构建、发布这几个环节，一直都是很繁琐，手工操做多，易出错，十分不得要领。

因而参考vue/nuxt/element, 一点一点地摸索，反复地尝试，终于找到了适合咱们的github wokflow。

因而咱们就对全部组件进行升级改造，相关脑图以下：

Flutter

滴雀APP(意为滴普语雀)下载地址

这个星期，咱们由Flutter开发的APP终于登陆App Store了。这是咱们第一款由Flutter开发的应用，我也经历了第一次从0到1完整的上架的过程。

我在语雀官方论坛上发布相关信息，也得到了官方人员的承认。

我感触比较深的是两点：

1. 增加了信心
2. 实践才是王道

信心

年初的时候，与某团队进行技术交流，据说他们不但作了小程序，还作了APP，甚至他们已经完成了从RN到Flutter的转型。咱们当时只涉及H5，并无过APP方面的积累，所以虽然表面不动声色，其实内心大吃一惊，难免有些没底气。

时至今日，咱们开发的APP已被当初那个团队的人使用着，我内心已不虚。

实践

现在不少社区、论坛、公众号，都在报道Flutter的相关信息，各类比较Flutter与其余技术的优缺点; 身边不少人也早就跃跃欲试，却一直说没时间而停滞不前，或由于作不出最佳选择而犹豫不决。

而咱们已经在实践，而且上生产了。要想真正了解一件事，惟有经过亲身实践。因此，若是真的想尝试，赶忙行动起来吧，不用再犹豫了，也不须要把没时间当借口。

产品思惟与用户意识

经过实践，我认为作产品有两点很重要：

1. 搞清楚用户最想要解决的是什么问题
2. 本身用起来

MVP

第1点也就是mvp，但这点理论上提及来简单，作起来却难。

首先，用户的声音不必定能听到，就算听到了，也可能由于沟通表达的问题，理解有误差。

其次，不少时候产品规划都是很宏大的，功能都是很齐全的，从0到1的过程当中，很容易在这种规划中迷失。

同时，优先解决核心问题，先实现最小功能闭环，思路是没错，但这样的产物可能过于简陋，所以有人可能会以为这不像是产品，而持否认意见。

吃本身的狗粮

因此，第2点就很重要。本身作的产品，本身用起来，也即“吃本身的狗粮”。

本身去动手前，想想，这个东西作出来本身会不会用？若是答案是否认的，那就先别动手，从新再想想。

本身做为用户，才能真正地培养用户意识。

最后还要注意的是，产品越早投入使用越好，这样能够根据用户反馈，快速调整与完善。

新的技术观

对于技术，我新增了如下方面来观察与思考：

1. 全局
2. 金钱
3. 用户
4. 开源

全局

全局意味着要有总体思惟，从团队、从整条生产链路来思考。

如今市面上不少媒体，过度强调我的或单个环节，致使人们广泛过度关注局部，而忽略了总体。

好比有不少开发技术方面的“练级攻略”，给人一种错觉，彷佛掌握了这些技术，就能横扫江湖，走向巅峰。但其实开发只是软件工程的一个环节罢了，若是不能掌握总体，在局部再登峰造极，也会有捉襟见肘的时候。

再好比某些教程，说是“教你从0到1开发一个APP”，但其实也只是聚焦在开发领域，也只是能在本身的机器上构建一个APP，安装在本身手机里而已。真正要上线到生产，让别人也能安装使用，同时保持后续的更新迭代，前先后后还有不少内容要涉及，并非学了教程，开发好了，就完事了。

使用全局的思惟来看待这些事情，这样才能看得更清楚、更透彻。

金钱

其实不少技术是能够用金钱来买的。这个交易的本质是：用金钱来买时间。

下面举些例子：

1. 咱们没有相关新技术的知识，咱们能够本身去预研、去实践，而后本身再写一份教程，也能够直接买付费的教程，让你们快速进入系统的学习
2. 咱们要想一个功能，目前没有，能够本身去实现，也能够买第三方服务
3. 咱们缺乏具有某些经验的人员，能够内部花时间培养，也能够直接从外部招聘有相关经验的人员

上面的例子都是常见的待决策的状况，前者都是本身亲力亲为，花费的是时间; 后者则是作资源整合，付出的是金钱。值得一提的是，时间也是金钱，也是成本，由于员工是要发工资的，这一点千万不要忽略了。

遇到上述状况如何决策，须要具体状况具体分析。

只不过，在筛选简历时，往往遇到一些人描述本身“全栈工程师”，但其实只是泛泛而谈时，我都在想，我为什么不直接招一个专职的前端、一个专职的后端？这对于企业而言，一个月增长的成本，微不足道。这种相似的思想，池建强在《Flutter 要全平台制霸？我看悬》一文也提到了。

用户

没有愚蠢的用户

产品上线后，就会收到用户的反馈。有可能产品的第一个界面，就让用户困惑了。此时技术人员常见的反应是：这都不懂，真笨！

请尽早把用户愚蠢的想法抛弃掉。用户遇到了任何问题，首先应该想一想，是否是产品有须要优化的地方。技术是用来解决问题，提高效率的，不是用来彰显本身高端、不同凡响的，作技术的千万不能曲高和寡。

用户第一

不少时候技术人员评估的事情的优先级，是按照技术难易程度、有趣程度而排列的，但其实上线后，最重要的，是倾向用户的声音，根据反馈进行开发调整。

也许你以为作个炫酷的动画是颇有挑战性、颇有趣的事情，但用户也许更关心产品首页的错别字。这种状况下，请优先改正错别字。

开源

总有一些技术团队在讲本身是设计这个系统的，怎么实现的，讲了一大堆，即没有附上代码地址，说什么与内部业务联系太紧密，不方便开源。

我也写过一些文章，因此我清楚，不少时候文字并不能完整地表达意图，更别说一个大型系统的设计。也许文章做者以为本身写出关键点了，但读者的知识背景良莠不齐，难保文章没写出来的，才是读者更须要的。所以，软件设计没有附上相关的可执行产物，我认为作的就是不到位。

不少时候，你们重复造轮子，就是由于资源不共享，前人的成果无法复用。

vue、k8s都开源了，把咱们的实践成果开个源，其实也什么大不了的。若是涉及商业机密，把相关内容替换成demo就行了。说到底，分享的意愿不够罢了。

若是咱们实践了想分享，必定会开源，不搞虚的。

新的团队观

去年，个人团队理念是，基于团队现有成员，把每一个人打造出我想象中的样子。

当时，我看人主要仍是看技术能力; 对于一些技术能力并不符合预期，但态度好的人，我也愿意招聘进来，由于能够培养。

今年，我更强调的是适者生存，也即，团队是有淘汰的，跟不上步伐的人，只能离开。

我如今招聘更愿意招已经技术能力过关，不太须要进行技术培养的人，也即宁缺勿滥，纵然这样极可能一个月也招不到一我的。

另外，我还会注重对软实力的考察，好比热情、目标规划、自我定位、思惟方式等，我但愿团队成员是自我驱动的，最终能成为本身想要的样子。

一句话总结：去年我想让团队的全部人变得合适; 如今我只想要合适的人留在团队里。

自我承认

在去年北京的项目实战以后，我隐约以为，我已经得到了足够的外界承认。

回来广州的大半年，我愈发肯定，接下来我寻求的，是自我承认。

这是一套本身给本身的评判标准以及打分机制：

• 也许外界以为这样差很少了，但我以为不够
• 也许外界以为这样作不对，但我相信本身

最后，来点鸡汤：愿你不受外界环境摆布，坚决本身的意志，坚持作你最初想作的事。