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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

對于小團隊的管理的一些個(gè)人理解：

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

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

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

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

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

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

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

8. 及時(shí)溝通反饋、團隊成員的個(gè)人想法、掌握開(kāi)發(fā)進(jìn)度、工作難點(diǎn)等；

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