為什么寫(xiě)代碼是一件很爽的事情?

我的看法是：

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

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

軟件交付的上下游

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

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

順流而下

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

• 不確定性
• 反饋周期
• 無(wú)形/有形
• 人的問(wèn)題/程序的問(wèn)題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上游的蝴蝶

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

(1) 上游的Problem：

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

(2) 中游的Solution：

• 通常涉及到的人也不多(會(huì)遠(yuǎn)低于下游的Implementation)
• 是在給定問(wèn)題或上下文的基礎(chǔ)之上;如果給定的問(wèn)題或上下文有誤，那Solution就出問(wèn)題;Solution階段也會(huì)做問(wèn)題/上下文的確認(rèn)。
• 通常是線(xiàn)下工作，但是需要在各種會(huì)議或者一對(duì)一的對(duì)話(huà)中，來(lái)反復(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)
• ”沙場(chǎng)秋點(diǎn)兵“ - 安排合適的人解決合適的問(wèn)題
• 有些工作會(huì)追溯回上游的Solution, Problem階段

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

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

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

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

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

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

為什么不寫(xiě)代碼是件”不爽”的事

非彼無(wú)我，非我無(wú)所取。

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

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

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

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

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

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

那我不寫(xiě)代碼，得到的啥?

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

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

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