IT工程師數位筆記本

第一個關鍵詞：復盤

在商業戰略上復盤有兩個好處。第一個是找到亮點，對于可行的一些試點項目投入更多資源擴大規模。第二個是我們犯過什么錯，犯過的錯誤能不能寫下來不再犯。今天就來盤點一下去年我們范下的那些嚴重錯誤：

1. 低估問題的難度

如果去看上一篇文章大概還可以看到我對于能從一堆亂麻中找到所有問題，排好優先級一個一個來理順解決這件事情是抱著癡迷的態度的。

但是由于認知的問題，包括對于個人本身能力的認知以及對于問題的認知都決定了“外來人員” 是很難在短期內從根本上解決問題的。舉個栗子:

由于我本人是技術管理出身，又都是偏大公司的背景。所以自然而然，我最先看到的都是關于技術和流程的問題，并且我過去解決這兩類問題所用的思路、資源跟現在都不一樣，所以我過去的經驗就未必那么有用了。沒有正確客觀的分析自己的優勢與所處環境, 以及與原來同事的溝通不充份。這是一開始就埋下的一個坑。

問題總比想象的要復雜的多

資源的能力以及可控的范圍遠比想象的要小

2. 錯誤地跟隨

和大家一起參與重構是我踩下的另一個坑。當時我們由原來的網站模式開發向純前后端分離的開發模式。而原先的前端負責人在完成一個小項目之后離職了，留下了一個重度的react框架和一個我們剛剛從后端轉過去跟他學習的前端。

在選擇react去留的問題上，我發揮了一個“優秀”技術人員的特性。喜歡新技術，相信自己能搞定這一切。于是我們花了一個月才把原來留下來一個沒有重構完成的項目拖上線。

千萬不要用不熟悉的技術

你可能沒有時間學習

3. 錯誤地評估/加碼 

過程雖然艱辛，但是最后完成了，我們歡欣鼓舞，準備大干一場！

大家都很期待， 我們找了系統中的一個重要模塊決定開始服務化。前端還用react！  投入2個后端，1個前端。后端api在2周左右基本完成，但前端花了1個多月功能還是不能正常運行。后端api也因為缺少設計和框架層面的支持有一些缺陷。最后全盤放棄，時間從我加入已經過去5個月了。

第2和第3個坑可以說是有連續性的，之前那個前端負責人走的時候，我們已經有一部份線上項目用react實現，并且也有一個后端一起參與。為了不讓這些變成沉沒成本，我們選擇繼續投入。

中間那個項目上線之后，其實我們依舊沒有對react+redux等這套框架掌握的非常熟練，包括對于那個模塊的業務，也不是特別的了解，可以說是技術與業務與人員3重危險的基礎上做重構，勝算非常的低。

學會堅決放棄

4. 帶著團隊沖向了炮火

在以上的5個月的時間里，雖然沒有在技術和產品上取得進展，但是卻在團隊和開發流程上取得了一些小成績。那時候前端團隊擴充到3個，后端擴充到6個，并增加了一位測試，技術團隊擴充到14個。 正好到了11月底，大家想著要在年底做點真正對用戶有意義的事情！

于是我們開展了一個叫“磨刀”的行動。

在一個月之內，前端3個人+后端4個人+測試1人。修復所有現有UI、數據上的bug。新開發了5個模塊。發版7次。

有人說，這怎么也算坑了？

你們想想，如果一個公司開始出現瘋狂加功能的時候，基本離死掉也不遠了。

事實也證明，除了bug以外，到現在為止還沒有證明我們做的事情從增長、營收以及留存上有特別大的價值。這可能是最致命的，因為你最不忍心看到的就是那些滿腔熱血、艱辛付出的人最終不能贏得榮耀。

敏捷開發的軟脅是：工程師愿意根據不斷改變的業務要求調試產品，但是對這些商業決策的質量不負責

第二個關鍵字：反思

所有的坑，都只能坑踩一次。

以上所踩的坑可以說是具體的現象，相信所有的創業公司都會遇到，只是以另一種現象展現出來而且。由于篇符的原因，以上幾個問題我將結合我們去年一年的實踐分為下面的5個主題在接下來的一一分享 

1. 人才引進與培養——找對人才，幫助其發揮

2. 產品開發流程實踐 ——優化效率，指導方向

3. 我們的架構演進實踐  —— 什么時候該做升級，如何來升級

4. 解決問題之道 —— 識別與迭代改進 

5. 企業發展戰略如何實踐 —— 戰略是打出來的，團隊如何跟進 

生意專家是一家專注于實體店鋪開店管理的saas軟件服務商，目前服務于全國40W家b端商戶且在繼續快速增長。想和我們一起見證從1到100000嗎？

你也可以在我的公眾號上看到這篇文章。（我會在公眾號上直播這段創業的經歷，包括我們技術架構以及團隊的升級）