年中總結

前言

有兩個月沒寫總結了，無論緣由如何，總要把欠了的補上。這個週末抽出時間，好好整理一下前兩個月的工做內容以及感想，內容涉及：

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就行了。說到底，分享的意願不夠罷了。

若是咱們實踐了想分享，必定會開源，不搞虛的。

新的團隊觀

去年，個人團隊理念是，基於團隊現有成員，把每一個人打造出我想象中的樣子。

當時，我看人主要仍是看技術能力; 對於一些技術能力並不符合預期，但態度好的人，我也願意招聘進來，由於能夠培養。

今年，我更強調的是適者生存，也即，團隊是有淘汰的，跟不上步伐的人，只能離開。

我如今招聘更願意招已經技術能力過關，不太須要進行技術培養的人，也即寧缺勿濫，縱然這樣極可能一個月也招不到一我的。

另外，我還會注重對軟實力的考察，好比熱情、目標規劃、自我定位、思惟方式等，我但願團隊成員是自我驅動的，最終能成爲本身想要的樣子。

一句話總結：去年我想讓團隊的全部人變得合適; 如今我只想要合適的人留在團隊裏。

自我承認

在去年北京的項目實戰以後，我隱約以爲，我已經得到了足夠的外界承認。

回來廣州的大半年，我愈發肯定，接下來我尋求的，是自我承認。

這是一套本身給本身的評判標準以及打分機制：

• 也許外界以爲這樣差很少了，但我以爲不夠
• 也許外界以爲這樣作不對，但我相信本身

最後，來點雞湯：願你不受外界環境擺佈，堅決本身的意志，堅持作你最初想作的事。