為什么寫代碼是一件很爽的事情?
為什么寫代碼是一件很爽的事情?
我的看法是：
- 及時反饋 —— 超級無敵的及時反饋
- 確定性強 —— 與代碼打交道，確定性強
- 有成就感 —— 解決問題，或克服困難的成就感
- 被需要感 —— 如果自己的創(chuàng)作，還能服務(wù)于他人，爽上加爽(被需要感)
因為這些感覺/感受，寫代碼成為了一件很爽，甚至?xí)习a的事情。其實會上癮的事情，通常也有這些特質(zhì)。
軟件交付的上下游
寫代碼是整個軟件交付過程的一環(huán)，當(dāng)然軟件交付是整個產(chǎn)品的一環(huán)，產(chǎn)品又可能是公司戰(zhàn)略的一環(huán)。我們就只把上下文限界在軟件交付的過程中。稍作抽象，軟件交付是在解決問題，用某些技術(shù)(代碼)來解決某些人的某些問題。
從定義問題，到找出解決方案，再到實現(xiàn)，那大約會就出現(xiàn)了”上下游“的概念。
順流而下
從問題，到解決方案，再到實現(xiàn)，如果我們從以下幾個維度來觀察：
- 不確定性
- 反饋周期
- 無形/有形
- 人的問題/程序的問題
就會發(fā)現(xiàn)趨勢：
(1) 不確定性 - 從高到低：
不確定性是因為變化導(dǎo)致的，而且是不規(guī)律的變化(如果變化是規(guī)律的，那就是可預(yù)測的，不確定性也就大大降低了。)
我們經(jīng)常說市場在變化，需求在變化，甚至是人在變化，這些變化導(dǎo)致了大量的不確定性。從找到/定義問題，到制定解決方案，再到實現(xiàn)，不確定性的趨勢，是由高到低的。
(2) 反饋周期 - 從長到短：
在問題階段，客戶/用戶提出一個問題/請求，到這個問題得到合理驗證性的回答，這個中間是需要一段時間的;而且，很多這個階段的問題，都只能給出假設(shè)性的回答，或者沒有回答，只能等到產(chǎn)品上線之后才能知道其中一些。
等到了最后的實現(xiàn)階段，不斷拆解Release -> Feature -> Story -> AC -> Task -> TDD, TDD的反饋環(huán)就不言而喻了吧。
(3) 從無形到趨近于有形：
在物理世界里，當(dāng)然軟件也是無形的;不過在數(shù)字化的世界里，可以工作和運行的軟件就是有形的了。
某個問題，某些想法和感受，通過文字或者圖片表達出來，以此來找到解決方案，再通過計算機程序語言來實現(xiàn)變成可工作的軟件，這個過程是無形到有形的轉(zhuǎn)化。
(4) 從人的問題轉(zhuǎn)為了程序的問題：
Ta有什么期望?現(xiàn)在的體驗是什么樣的?有什么其他的沒有說出來的訴求?會不會受到什么影響而改變決策?這些都是典型的人的問題，不一定有確切的答案，有時候甚至是Ta自己也不知道。
程序的問題則不一樣，這個地方出錯了，一定是有原因的，某個地方的邏輯一定出了問題，我會找到原因的。
所以，從問題到實現(xiàn)，我們一開始偏重人的問題，到最后逐漸轉(zhuǎn)化為解決程序的問題。
上游的蝴蝶
上游對下游的影響是顯著，而又數(shù)量級遞增的，就像“蝴蝶效應(yīng)”一樣。上游的蝴蝶扇動了翅膀，可能會對下游產(chǎn)生劇烈影響。不過，倒也不用太擔(dān)心，因為軟件交付的下游影響比蝴蝶效應(yīng)要可控一些，預(yù)測性比較強。
(1) 上游的Problem：
- 通常涉及到的人數(shù)比較少;
- 通常是在各種會議或者一對一的對話中，來識別，分析和定義的。
- 需要一定程度地定義問題：問題是什么(期望是什么?現(xiàn)在的體驗是什么)，是誰的問題?
(2) 中游的Solution：
- 通常涉及到的人也不多(會遠低于下游的Implementation)
- 是在給定問題或上下文的基礎(chǔ)之上;如果給定的問題或上下文有誤，那Solution就出問題;Solution階段也會做問題/上下文的確認。
- 通常是線下工作，但是需要在各種會議或者一對一的對話中，來反復(fù)修正(技術(shù)實現(xiàn)角度，安全角度，一致性約束等)
- 比較多”紙上談兵“，經(jīng)驗主義
(3) 下游的Implementation：
- 交付團隊都上了
- 多數(shù)團隊成員直接面對的是各種Feature/Story卡
- 日常交付工作(Release/Sprint/Story,Tech,Bug)
- ”沙場秋點兵“ - 安排合適的人解決合適的問題
- 有些工作會追溯回上游的Solution, Problem階段
(4) 上游的"蝴蝶"，很重要
通過上面的分析，可以看到，上游的”蝴蝶"很重要，扇動翅膀的威力很大。
我們自然是希望更有經(jīng)驗的人來做上游的”蝴蝶”：
- 可以和客戶在各種會議上，"談笑風(fēng)生"
- 需要(扯皮)的時候，能為團隊Fight客戶
- 可以給下游的信息，簡約而不簡單
項目里誰適合呢?有經(jīng)驗的PM, BA, TL被選中了!
如果客戶方有技術(shù)/架構(gòu)師參與到項目交付中的時候，TL就跑不脫了。
為什么不寫代碼是件”不爽”的事
非彼無我，非我無所取。
那不寫代碼很會失去哪些寫代碼的能獲得的快樂呢：
- 及時反饋 —— 超級無敵的及時反饋(刪掉
- 確定性強 —— 與代碼打交道，確定性強
- 有成就感 —— 解決問題，或克服困難的成就感
- 被需要感 —— 如果自己的創(chuàng)作，還能服務(wù)于他人，爽上加爽(被需要感)
及時反饋 &確定性強，這兩個肯定是沒有(或者大幅降低)了。
那成就感，和被需要感呢?
既然加了一個“感”字，那就說明這個東西，就是“主觀的”，我說有就有~
如果感受不到成就感和被需要感，那就去尋找，創(chuàng)造，記得向外看(可以參看之前的博客: "拼命的工作有人教 快樂的工作沒人教")
那我不寫代碼，得到的啥?
是會議、PPT與扯皮嗎?就這?
【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】
