在創(chuàng)業(yè)公司搞技術開發(fā)的心酸往事（已倒閉）

長話短說，就是在2022年6月的時候加入了一家很小創(chuàng)業(yè)公司。老板不太懂技術，也不太懂管理，靠著一腔熱血加上對實體運輸行業(yè)的了解，加上盲目的自信，貿(mào)然開始創(chuàng)業(yè)，后期經(jīng)營困難，最終散伙。

自己當時也是不察，貿(mào)然加入，后邊公司經(jīng)營困難，連最后幾個月的工資都沒給發(fā)。

當時老板的要求就是盡力降低人力成本，盡快的開發(fā)出來App(Android+IOS)，老板需要盡快的運營起來。

當時就自己加上一個剛畢業(yè)的純前端開發(fā)以及一個前面招聘的ui，連個人事、測試都沒有。

結合公司的需求與自己的技術經(jīng)驗(主要是前端和nodejs的經(jīng)驗)，選擇使用如下的方案：

1. 使用uni-app進行App的開發(fā)，兼容多端，也可以為以后開發(fā)小程序什么的做方案預留，主要考慮到的點是比較快，先要解決有和無的問題；
2. 使用egg.js + MySQL來開發(fā)后端，開發(fā)速度會快一點，行業(yè)比較小眾，不太可能會遇到一些較大的性能問題，暫時看也是夠用了的，后期過渡到midway.js也方便；
3. 使用antd-vue開發(fā)運營后臺，主要考慮到與uni-app技術棧的統(tǒng)一，節(jié)省轉(zhuǎn)換成本；

也就是初期選擇使用egg.js + MySQL + uni-app + antd-vue，來開發(fā)兩個App和一個運營后臺，快速解決0到1的問題。

App的開發(fā)方案有很多，比如純原生、flutter、uniapp、react-native/taro等，這里就當是的情況做一下選擇。

1. IOS與Android純原生開發(fā)方案，需要新招人，兩端同時開發(fā)，兩端分別測試，這個資金及時間成本老板是不能接受的；
2. flutter，這個要么自己從頭開始學習，要么招人，相對于純原生的方案好一點，但是也不是最好的選擇；
3. react-native/taro與uni-app是比較類似的選擇，不過考慮到熟練程度、難易程度以及開發(fā)效率，最終還是選擇了uni-app。

很多時候方案的選擇并不能只從技術方面考慮，當是只能選擇成本最低的，當時的情況是egg.js完全能滿足。

1. 使用一些成熟的后端開發(fā)方案，如Java、、php、go之類的應該是比較好的技術方案，但對于老板來說不是好的經(jīng)濟方案；
2. egg.js開發(fā)比較簡單、快捷，個人也比較熟悉，對于新成員的學習成本也很低，對于JS有一定水平的也能很快掌握egg.js后端的開發(fā)。

前期開發(fā)還算順利，在規(guī)定的時間內(nèi)，完成了開發(fā)、測試、上線。但是，老板并沒有如前面說的，很快運營，很快就盈利，運營的開展非常緩慢。中間還經(jīng)歷了各種折騰的事情。

1. 老板運營遇到困難，就到處找一些專家（基本跟我們這事情沒半毛錢關系的專家），不斷的提一些業(yè)務和ui上的意見，不斷的修改；
2. 期間新來的產(chǎn)品還要全部推翻原有設計，重新開發(fā)；
3. 還有個兼職的領導非要說要招聘原生開發(fā)和Java開發(fā)重新進行開發(fā)，問為什么，也說不出什么所以然，也是道聽途說。

反正就是不斷提出要修改產(chǎn)品、設計、和代碼。中間經(jīng)過不斷的討論，擺出自己的意見，好在最終技術方案沒修改，前期的工作成果還在。后邊加了一些新的需求：系統(tǒng)升級1.1、ui升級2.0、開發(fā)小程序版本、開發(fā)新的配套系統(tǒng)(小程序版本)以及開發(fā)相關的后臺、添加即時通信服務、以及各種小的功能開發(fā)與升級；

中間老板要加快進度了就讓招人，然后又無緣無故的要開人，就讓人很無奈。最大的運營問題，始終沒什么進展，明顯的問題并不在產(chǎn)品這塊，但是在這里不斷的折騰這群開發(fā)，也真是難受。

明明你已經(jīng)很努力的協(xié)調(diào)各種事情、站在公司的角度考慮、努力寫代碼，卻仍然無濟于事。

1. 后期調(diào)整了App的打包方案；
2. 在新的配套系統(tǒng)中，使用midway.js來開發(fā)新的業(yè)務，這都是基于前面的egg.js的團隊掌握程度，為了后續(xù)的開發(fā)規(guī)范，做此升級；
3. 內(nèi)網(wǎng)管理公用npm包，開發(fā)業(yè)務組件庫；
4. 規(guī)范代碼、規(guī)范開發(fā)流程；

如下是對于當時的人員招聘的一些感受：

1. 小公司的人員招聘是相對比較難的，特別是還給不了多少錢的；
2. 好在我們選擇的技術方案，只要對于JS掌握的比較好就可以了，前后端都要開發(fā)一點，也方便人員工作調(diào)整，避免開發(fā)資源的浪費。

對于小團隊的管理的一些個人理解：

1. 小公司剛起步，就應該實事求是，以業(yè)務為導向；

2. 小公司最好采取全棧的開發(fā)方式，避免任務的不協(xié)調(diào)，造成開發(fā)資源的浪費；

3. 設置推薦的代碼規(guī)范，參照大家日常的代碼習慣來制定，目標就是讓大家的代碼相對規(guī)范；

4. 要求按照規(guī)范的流程設計與開發(fā)、避免一些流程的問題造成管理的混亂和公司的損失；

5. 
   
• 如按照常規(guī)的業(yè)務開發(fā)流程，產(chǎn)品評估 => 任務分配 => 技術評估 => 開發(fā) => 測試 => cr => 上線 => 線上問題跟蹤處理；

6. 行之有效可量化的考核規(guī)范，如開發(fā)任務的截止日期完成、核心流程開發(fā)文檔的書寫、是否有線上bug、嚴謹手動修改數(shù)據(jù)庫等；

7. 鼓勵分享，相互學習，一段工作經(jīng)歷總要有所提升，有所收獲才是有意義的；

8. 及時溝通反饋、團隊成員的個人想法、掌握開發(fā)進度、工作難點等；

1. 選擇創(chuàng)業(yè)公司，一定要確認老板是一個靠譜的人，別是一個總是畫餅的油膩老司機，或者一個優(yōu)柔寡斷，沒有主見的人，這樣的情況下，大概率事情是干不成的；
2. 老板靠譜，即使當前的項目搞不成，也可能未來在別的地方做出一番事情；
3. 初了上邊這個，最核心的就是，怎么樣賺錢，現(xiàn)在這種融資環(huán)境，如果自己不能賺錢，大概率是活不下去的@自己；
4. 抓住核心矛盾，解決主要問題，業(yè)務永遠是最重要的。至于說選擇的開發(fā)技術、代碼規(guī)范等等這些都可以往后放；
5. 對上要及時反饋自己的工作進度，保持好溝通，老板總是站在更高一層考慮問題，肯定會有一些不一樣的想法，別總自以為什么什么的；
6. 每段經(jīng)歷最好都能有所收獲，人生的每一步都有意義。