為什么寫代碼是一件很爽的事情?

我的看法是：

• 及時(shí)反饋 —— 超級(jí)無敵的及時(shí)反饋
• 確定性強(qiáng) —— 與代碼打交道，確定性強(qiáng)
• 有成就感 —— 解決問題，或克服困難的成就感
• 被需要感 —— 如果自己的創(chuàng)作，還能服務(wù)于他人，爽上加爽(被需要感)

因?yàn)檫@些感覺/感受，寫代碼成為了一件很爽，甚至?xí)习a的事情。其實(shí)會(huì)上癮的事情，通常也有這些特質(zhì)。

軟件交付的上下游

寫代碼是整個(gè)軟件交付過程的一環(huán)，當(dāng)然軟件交付是整個(gè)產(chǎn)品的一環(huán)，產(chǎn)品又可能是公司戰(zhàn)略的一環(huán)。我們就只把上下文限界在軟件交付的過程中。稍作抽象，軟件交付是在解決問題，用某些技術(shù)(代碼)來解決某些人的某些問題。

從定義問題，到找出解決方案，再到實(shí)現(xiàn)，那大約會(huì)就出現(xiàn)了”上下游“的概念。

順流而下

從問題，到解決方案，再到實(shí)現(xiàn)，如果我們從以下幾個(gè)維度來觀察：

• 不確定性
• 反饋周期
• 無形/有形
• 人的問題/程序的問題

就會(huì)發(fā)現(xiàn)趨勢：

(1) 不確定性 - 從高到低：

不確定性是因?yàn)樽兓瘜?dǎo)致的，而且是不規(guī)律的變化(如果變化是規(guī)律的，那就是可預(yù)測的，不確定性也就大大降低了。)

我們經(jīng)常說市場在變化，需求在變化，甚至是人在變化，這些變化導(dǎo)致了大量的不確定性。從找到/定義問題，到制定解決方案，再到實(shí)現(xiàn)，不確定性的趨勢，是由高到低的。

(2) 反饋周期 - 從長到短：

在問題階段，客戶/用戶提出一個(gè)問題/請求，到這個(gè)問題得到合理驗(yàn)證性的回答，這個(gè)中間是需要一段時(shí)間的;而且，很多這個(gè)階段的問題，都只能給出假設(shè)性的回答，或者沒有回答，只能等到產(chǎn)品上線之后才能知道其中一些。

等到了最后的實(shí)現(xiàn)階段，不斷拆解Release -> Feature -> Story -> AC -> Task -> TDD, TDD的反饋環(huán)就不言而喻了吧。

(3) 從無形到趨近于有形：

在物理世界里，當(dāng)然軟件也是無形的;不過在數(shù)字化的世界里，可以工作和運(yùn)行的軟件就是有形的了。

某個(gè)問題，某些想法和感受，通過文字或者圖片表達(dá)出來，以此來找到解決方案，再通過計(jì)算機(jī)程序語言來實(shí)現(xiàn)變成可工作的軟件，這個(gè)過程是無形到有形的轉(zhuǎn)化。

(4) 從人的問題轉(zhuǎn)為了程序的問題：

Ta有什么期望?現(xiàn)在的體驗(yàn)是什么樣的?有什么其他的沒有說出來的訴求?會(huì)不會(huì)受到什么影響而改變決策?這些都是典型的人的問題，不一定有確切的答案，有時(shí)候甚至是Ta自己也不知道。

程序的問題則不一樣，這個(gè)地方出錯(cuò)了，一定是有原因的，某個(gè)地方的邏輯一定出了問題，我會(huì)找到原因的。

所以，從問題到實(shí)現(xiàn)，我們一開始偏重人的問題，到最后逐漸轉(zhuǎn)化為解決程序的問題。

上游的蝴蝶

上游對(duì)下游的影響是顯著，而又?jǐn)?shù)量級(jí)遞增的，就像“蝴蝶效應(yīng)”一樣。上游的蝴蝶扇動(dòng)了翅膀，可能會(huì)對(duì)下游產(chǎn)生劇烈影響。不過，倒也不用太擔(dān)心，因?yàn)檐浖桓兜南掠斡绊懕群?yīng)要可控一些，預(yù)測性比較強(qiáng)。

(1) 上游的Problem：

• 通常涉及到的人數(shù)比較少;
• 通常是在各種會(huì)議或者一對(duì)一的對(duì)話中，來識(shí)別，分析和定義的。
• 需要一定程度地定義問題：問題是什么(期望是什么?現(xiàn)在的體驗(yàn)是什么)，是誰的問題?

(2) 中游的Solution：

• 通常涉及到的人也不多(會(huì)遠(yuǎn)低于下游的Implementation)
• 是在給定問題或上下文的基礎(chǔ)之上;如果給定的問題或上下文有誤，那Solution就出問題;Solution階段也會(huì)做問題/上下文的確認(rèn)。
• 通常是線下工作，但是需要在各種會(huì)議或者一對(duì)一的對(duì)話中，來反復(fù)修正(技術(shù)實(shí)現(xiàn)角度，安全角度，一致性約束等)
• 比較多”紙上談兵“，經(jīng)驗(yàn)主義

(3) 下游的Implementation：

• 交付團(tuán)隊(duì)都上了
• 多數(shù)團(tuán)隊(duì)成員直接面對(duì)的是各種Feature/Story卡
• 日常交付工作(Release/Sprint/Story,Tech,Bug)
• ”沙場秋點(diǎn)兵“ - 安排合適的人解決合適的問題
• 有些工作會(huì)追溯回上游的Solution, Problem階段

(4) 上游的"蝴蝶"，很重要

通過上面的分析，可以看到，上游的”蝴蝶"很重要，扇動(dòng)翅膀的威力很大。

我們自然是希望更有經(jīng)驗(yàn)的人來做上游的”蝴蝶”：

• 可以和客戶在各種會(huì)議上，"談笑風(fēng)生"
• 需要(扯皮)的時(shí)候，能為團(tuán)隊(duì)Fight客戶
• 可以給下游的信息，簡約而不簡單

項(xiàng)目里誰適合呢?有經(jīng)驗(yàn)的PM, BA, TL被選中了!

如果客戶方有技術(shù)/架構(gòu)師參與到項(xiàng)目交付中的時(shí)候，TL就跑不脫了。

為什么不寫代碼是件”不爽”的事

非彼無我，非我無所取。

那不寫代碼很會(huì)失去哪些寫代碼的能獲得的快樂呢：

• 及時(shí)反饋 —— 超級(jí)無敵的及時(shí)反饋(刪掉
• 確定性強(qiáng) —— 與代碼打交道，確定性強(qiáng)
• 有成就感 —— 解決問題，或克服困難的成就感
• 被需要感 —— 如果自己的創(chuàng)作，還能服務(wù)于他人，爽上加爽(被需要感)

及時(shí)反饋 &確定性強(qiáng)，這兩個(gè)肯定是沒有(或者大幅降低)了。

那成就感，和被需要感呢?

既然加了一個(gè)“感”字，那就說明這個(gè)東西，就是“主觀的”，我說有就有~

如果感受不到成就感和被需要感，那就去尋找，創(chuàng)造，記得向外看(可以參看之前的博客: "拼命的工作有人教 快樂的工作沒人教")

那我不寫代碼，得到的啥?

是會(huì)議、PPT與扯皮嗎?就這?

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文