這篇文章是受漫談工程師的三觀 的啟發所寫。

常常聽到做業務的程式設計師抱怨自己現在做的業務沒有意思，學不到東西，用不到新技術，用的也都是翻來覆去的技術，得不到成長。很多程式設計師在經歷這個過程時，很多調整不了也就離職了，也許走向了一個新的技術興奮點，有些可能是換了個新的業務繼續迴圈。那我們程式設計師在遇到這種事情的時候應該怎麼調整，應該向哪個方向走。

業務開發最好的體驗就是從一個業務從起步-> 快速發展->業務穩定發展->…… 的過程，而在業務不同的過程中能夠清晰定位開發人員在業務中的角色，能夠從技術的角度支援業務。

1. 程式設計師的三觀

1.1 技術觀

技術是程式設計師的核心競爭立，什麼才是好的技術觀。

好的技術觀應該是不排斥新技術，不排斥自己未深入瞭解的技術。很多新人，甚至很多工作兩三年的開發者會陷入一種誤區，對一種語言極度熱愛，而對其他的一些語言極度鄙視，變成某種語言宗教成員；作為程式設計師很多時候像是在做學術一樣，需要不斷探索新的領域，一些技術需要深入掌握，很多技術需要大概知道原理是什麼，大概有哪些特性，相容幷包，在一項業務需要的時候能夠更好的技術選型。

不同的技術很多時候能夠開拓技術眼界，以程式語言為例，在併發實現的問題上：

• Java 使用執行緒和執行緒池的方式來實現
• Golang採用goroutine和channels的機制實現

不同的方式有著自己的優缺點，在實際應用中，我們可以以這些為借鑑解決我們的實際問題，如最近我們就在KTV 預訂流程中採用了Channel的模型來抽象並實現業務。

1.2 產品觀

技術人員在實現產品需求的時候，首先跳入腦海的是實現產品的技術成本，如實現這個產品會對現有的專案造成多大影響，開發起來有多麻煩等等。考慮這些成本是很有必要的，有了這些成本考慮才能更好的衡量這些需求值不值。但是如果僅僅止步於此，那還沒有形成很好的產品觀。

作為程式設計師不僅僅要理解產品的實現細節，我們還要知道產品的動機、定位和防線，知道產品為誰而做、為何而做。

例如在漫談工程師的三觀 文章中關於使用者登入的產品就是一個很好的例子：

比如說每個線上的系統都有密碼重置的功能 —— 我們看看，密碼重置的慣例是什麼？

• 使用者傳送密碼重置請求後，系統給請求的郵箱發一個重置郵件
• 重置郵件裡有個會在指定時間內過期的一次性連結，使用者點選後進入到密碼重置頁面
• 使用者設定密碼後，可以用新密碼登入

然而，這樣一個簡單的功能，有人會把它做成這樣：

• 使用者傳送密碼重置請求後，系統給請求的郵箱對應的賬號設定一個隨機密碼，併發一個郵件告知隨機密碼
• 使用者使用這個隨機密碼登入

1.3 資料觀

資料是真實世界在產品上的一個投影（projection）。好的工程師同樣也應該是對資料敏感的工程師。Learn startup 教給我們：build – measure – learn 的迴圈，這與其說是做產品的方法，不如說是我們學習萬事萬物的方法。

所以資料觀的第一步是知道測量什麼。想要知道測量什麼，需要知道某個產品最重要的 KPI 是什麼。 例如我們現在在做的KTV預訂，最重要的是預訂訂單數，其次是預訂成功率，再細化到預訂系統內部就是各預訂渠道的預訂成功率。

測量只是第一步，接下來是分析和解讀資料。分析和解讀資料的能力是工程師的資料觀的重要組成部分。

資料分析和解讀資料之後，需要形成相應的措施，如果業務中存在缺陷或者需要優化的地方，就需要形成產品需求，推動業務和產品的發展，這也許就是人人都是產品經理的一個意義吧。

2. 業務觀

業務觀是一個更高更廣的一種視角，無論是技術、產品還是資料分析都是為了業務更好的發展，如果讓業務更好的發展，這就需要更好的業務觀。正確的技術觀、產品觀及資料觀是支援業務的基礎，但是一個業務不僅僅擁有這三個方面。做一個業務需要知道業務的流程、必要的業務細節。

業務中需要有產品，這些產品大概如何推廣，銷售環節是如何的，每個環節技術如何提供幫助，以業務的視角來看，現在的產品和技術是否合理，能否提供更好的業務模式。

2.1 與業務人員的溝通

很多開發人員比較討厭與業務人員（銷售，地推人員，運營人員等）溝通，因為總覺得和這些人不再一個頻道上。其實很多時候業務人員是擋在真實使用者的最後一層，這一層更加理解真實使用者的需求，比真實使用者能夠進行一定的需求總結。傾聽業務人員說產品中不通的地方，往往能夠找到系統和產品中的缺陷。

2.2 技術的角度看業務

相比業務人員，技術人員有著技術優勢，能夠從技術角度更好的抽象業務需求。業務人員提出的大多數想法或需求，通常在很短的時間內，便可以基本判定技術實現方案的可行性。

References

打賞支援我寫出更多好文章，謝謝！

打賞作者

打賞支援我寫出更多好文章，謝謝！

任選一種支付方式