你的老板可能真的很棒。我在我自己的編程生涯中就遇到過幾個真心棒的老板，但即使是最棒的老板似乎也常?？偸遣荒芾斫廛浖_發(fā)。

      事實(shí)上，我想說的是當(dāng)涉及到不止編程的幾個元素時，大多數(shù)軟件開發(fā)經(jīng)理都有點(diǎn)目光短淺。

      所以，我編譯了一個簡短的清單，用來說明關(guān)于編程一些最讓你老板、開發(fā)經(jīng)理、技術(shù)大咖等等誤解的方面。

1. 技術(shù)債務(wù)最會拖累項目

      工作在一個滿是技術(shù)債務(wù)的代碼庫上，就像是在爛泥堆中奔跑。起初，在泥漿還不是很厚的時候，勉勉強(qiáng)強(qiáng)走過去還沒問題，但當(dāng)有個 1 米深的時候，你就寸步難行了。

      我最喜歡的作家之一，《7 Habits of Highly Effective People》的作者，Steven Covey，稱之為“P/PC 平衡”或“產(chǎn)量 vs 產(chǎn)能?！?

      通常，管理人員和其他非技術(shù)性人員在推動生產(chǎn)力的時候，寧愿犧牲質(zhì)量——就像殺掉了下金蛋的鵝一樣——從而招致技術(shù)債務(wù)。

      當(dāng)然，通過絞擰這只鵝的脖子，威脅它，你或許暫時可以得到更多的蛋，但用不了多少時間，死去的鵝就永遠(yuǎn)不會再產(chǎn)蛋了。

      如果你的老板正遭受著不懂技術(shù)債務(wù)的痛苦，不知道技術(shù)債務(wù)是如何正在拖累你的，那么建議你可以給他講講《7 Habits of Highly Effective People》中關(guān)于P/PC 平衡中技術(shù)債務(wù)的條款。

      大多數(shù)管理人員可能都會看過這本經(jīng)典的書，所以比起你說寫新功能很難是因為代碼庫太糟糕，還不如說說書中的觀點(diǎn)，更容易被他們所理解。

2. 預(yù)估大多是廢話

      軟件開發(fā)中的預(yù)估大多是廢話。

      這一點(diǎn)，你知我知，甚至團(tuán)隊可憐的項目經(jīng)理也知——當(dāng)然，也有可能他不知道，但是他應(yīng)該知道。

      預(yù)估軟件開發(fā)中的任何事情都是非常非常困難的，因為各種意外會讓你防不勝防。

      每一個軟件項目，每一項任務(wù)都是新的。每次你坐下來寫代碼，總有一些意想不到的狗屎事情發(fā)生。

      但事情就是這樣。沒有人應(yīng)該為此負(fù)責(zé)。不是你的錯，也不是我的錯，不是任何人的錯。它就是要發(fā)生。

      然而，我們依然情不自禁地會去玩這個“預(yù)估”游戲。

      “Joe，你建立客戶登錄頁面需要多久？”

      “哦……呃……”隨便想了個時間，“2 天……哦等等——”忘了 CYA 加倍。 “——要 4 天。”

      “好吧，那我給你 5 天”。

      “好，那就 5 天?！?

      還有一個很好的解決辦法是把任務(wù)分解到足夠小的程度，將所有的預(yù)估控制在 4 小時以內(nèi)。

      經(jīng)驗告訴我，半天時間內(nèi)的預(yù)估，通常能讓你體面地完成工作。超過這個點(diǎn)，那你就是廢話了。

3. 可以立刻或快速完成

      催促專業(yè)人士通常是一個糟糕的主意。

      我用我從寫代碼到現(xiàn)在超過 15 年的時間里，學(xué)到了這個道理，所以我知道當(dāng)我雇用別人做一些事情的時候，如果我催促他們，沒準(zhǔn)他們會按時完成，但結(jié)果將是無用功。

      不幸的是，我發(fā)現(xiàn)許多軟件開發(fā)經(jīng)理似乎不知道這個普遍真理。不知怎的，他們認(rèn)為代碼可以得既快又好。

      可不要誤解我的意思，我也承認(rèn)是有例外的。有時，你的確可以快速地寫出好的代碼，但通常而言總是慢工出細(xì)活。

      同樣不幸的是，大多數(shù)程序員，當(dāng)被告知要快點(diǎn)完成任務(wù)的時候，往往會選擇走捷徑，通過犧牲質(zhì)量來加快進(jìn)程。

      更不幸的是，這樣的“代碼快手”經(jīng)常被當(dāng)作英雄稱贊，因為他們能夠更快地完成任務(wù)，因為他們從不推遲或要求更多的時間。

      然而，這些“代碼快手”往往會將代碼寫得亂七八糟，給其他人留下一連串的技術(shù)債務(wù)。

      如果你正在打交道的開發(fā)經(jīng)理不明白，快與好之間的關(guān)系，那么你最好拿出一些統(tǒng)計數(shù)據(jù)，以說明后期修復(fù) bug 比前期預(yù)防要耗費(fèi)更高的成本。

      組織越大，以及涉及的公事程序越繁瑣，那么快速完成任務(wù)比正確完成任務(wù)的最終成本就會越高。

      （對于這個問題的經(jīng)典書籍——《人月神話》。）

4. 有的開發(fā)人員實(shí)際上是在幫倒忙

      有一個事實(shí)是，我們都碰到過那種對團(tuán)隊弊大于利的程序員。

      不同的程序員，他們的軟件開發(fā)領(lǐng)域能力和技能水平有著巨大的差異。

      事實(shí)上，有些軟件開發(fā)人員糟糕到他們在工作中寫的每行代碼都是在浪費(fèi)公司的時間和資源。

      這種類型的開發(fā)人員也許應(yīng)該付錢給公司，而不是公司付給他錢。

      這對你而言可能是顯而易見的，但對老板卻不盡然。比如說，在你看來，可能 Joe 是一個徹底的失敗者，是需要被解雇的，因為他只會干些“點(diǎn)金成石”的蠢事。所有他接觸的東西都變成了沒用的“石頭”。

      但是如果你的老板不明白團(tuán)隊中有這些人比沒有更糟，那你能做些什么？

      好吧，大多數(shù)軟件開發(fā)人員都怕自己被認(rèn)為是一個愛搬弄是非打小報告的人——我完全理解。

      但是……你必須這么做。這是對的。如果某人確實(shí)是團(tuán)隊中的害蟲，那么讓管理人員知道這一點(diǎn)也是你的份內(nèi)事。

      我知道這將會令你陷入不舒服的處境，但是如果你不報告，那你就不是稱職的程序員。你會成為殺死項目的幫兇。

      至于所謂的報告，只要謹(jǐn)慎措辭和給一些提示就可以。

      比如你可以這么說：

      “嘿，我不喜歡做這種事情，但我覺得，如果我是你的話，我會想知道是否有人直接妨礙了團(tuán)隊。所以，我覺得這是我的責(zé)任來告訴你一些我一直在觀察的東西。

      ……

      當(dāng)然，這些都只是我的觀察，所以請和其他團(tuán)隊成員商量一下，根據(jù)你自己的經(jīng)驗來判斷?！?

      或者，如果你也可以使用這種不那么婉轉(zhuǎn)的方式：

      “嘿！Joe 很菜。他寫代碼實(shí)在是太慢了。事實(shí)上，他唯一可取之處就是他的慢，因為自從他來了之后，項目就基本上只能以蝸牛的速度前進(jìn)。你再不正確了解他就晚了。”

5. 更好的設(shè)備是你可以投資的最便宜的生產(chǎn)力之一

      我非常討厭程序員告訴我——他們的小氣鬼老板不給他們配備第二個顯示器，或者讓他們用的是已經(jīng) 5 歲高齡的電腦。

      老實(shí)說，我真心不理解為什么有的軟件開發(fā)經(jīng)理不同意為那些 8k+ 美元的程序員花費(fèi) 2k 美元改善硬件——這是很劃算的投資。

      老舊的硬件裝備讓程序員真心很懊惱，很煩躁！

      每當(dāng)有程序員抱怨這種工作情況時，我通常會建議他們另謀高就，因為這種老板的愚蠢恐怕無藥可治。

      什么都別說，我告訴你：

       好的設(shè)備能讓軟件開發(fā)人員一天多干一小時的活，讓開發(fā)人員更有生產(chǎn)力。即使只有我說的數(shù)值一半的量，加起來的總時間也不會少。

       如果算一年 250 個工作日，那么就是 250×$35 美元=$8750。即使你砍去一半或四分之一，這依然是個不錯的投資。

      如果你的老板不懂這個道理，那么老實(shí)說，我不認(rèn)為你能有什么辦法。如果你真心喜歡你現(xiàn)在的工作，那么就只能自己給自己投資了。

6. 新技術(shù)的風(fēng)險其實(shí)沒你認(rèn)為得那么高

      沒什么比提及 .NET 最新最棒的 JavaScript 框架版本更讓軟件開發(fā)經(jīng)理感覺恐懼的了。

      這已然成為了大家心照不宣的雷區(qū)。

      曾幾何時，每隔一年左右軟件供應(yīng)商才發(fā)布框架或補(bǔ)丁的新版本，因此，錯誤的代價會相當(dāng)高。

      曾幾何時，大部分源代碼是封印在“墓穴”中的，不允許其他任何人訪問的，所以一旦該公司不再支持它，你就會進(jìn)退兩難。

      但是現(xiàn)在，情況有所不同。

      如今的框架，有時甚至是在每天的基礎(chǔ)上發(fā)布補(bǔ)丁，并且大多數(shù)流行框架都是開源的，所以風(fēng)險并不高。

      當(dāng)然，你也可以破罐子破摔，但這種情況不多，并且只需要稍作修改即可，而不是大刀一揮，好的壞的都割掉。

      所以，如果編程經(jīng)理依然還活在 1980 年，那么你可能需要為他指出事情發(fā)生了什么變化，以及為什么停留在框架或庫的舊版本比升級它更危險。

      恐懼策略中的安全漏洞就是一個很好的突破口。

7. 畫蛇添足的業(yè)務(wù)分析師和項目經(jīng)理

      我知道接下來我可能會得罪不少人，但我不在乎。我在這里說的都是真話，我是那種看到什么就說什么的人。

      當(dāng)然，首先要聲明的是，還是有一些好的業(yè)務(wù)分析師和項目經(jīng)理的——但說實(shí)話，大部分的業(yè)務(wù)分析師和項目經(jīng)理毫無價值。

      曾經(jīng)一度這些角色是開發(fā)項目所必要的。

      但是現(xiàn)在，在大多數(shù)情況下，我們不再需要他們了。

      軟件開發(fā)人員應(yīng)該直接與客戶對話，以便于讓他們自己搞清楚客戶的需求。所以我們不需要業(yè)務(wù)分析師。

      這是一個殘疾崗位，因為他們做的是軟件開發(fā)人員應(yīng)該做的工作的一半，卻對另一半工作于事無補(bǔ)。

      而項目經(jīng)理更神奇，他的目標(biāo)似乎就是奔著妨礙我們開發(fā)，將一切搞得一團(tuán)亂而來的。

      我知道他們是好意，但在當(dāng)前的敏捷世界，項目經(jīng)理已經(jīng)發(fā)揮不了作用了，所以還要他們干什么呢？他們四處走動試圖讓自己顯得重要，試圖找出他們可以做的事情，最終卻只會妨礙大家。

      很多軟件開發(fā)經(jīng)理的想法仍然停留在過去，停留在那個職位更有意義的年代，他們聽信了世界 500 強(qiáng)咨詢公司的所謂的“潮流”——據(jù)這些公司所言，很多軟件公司需要更多的高薪顧問人員來滿足這些工作崗位。

      如果你的經(jīng)理還是不懂，那么唯一的解決方法就是接受敏捷教育。

     我不建議你直接告訴你的老板說“業(yè)務(wù)分析師和項目經(jīng)理純粹是在浪費(fèi)氧氣”——這可能也不那么容易被接受——所以，相反的，我會專注于說明一支敏捷團(tuán)隊?wèi)?yīng)該如何工作以及需要哪些角色。

      然后很明顯在一個真正的敏捷環(huán)境中，是沒有業(yè)務(wù)分析師和項目經(jīng)理的，他們可能更適合作為 Scrum 管理員或產(chǎn)品所有者。

      積極主動

      當(dāng)然，上面我說的這些東西，有的我可能會用一種開玩笑的口吻說。但在現(xiàn)實(shí)中，軟件開發(fā)經(jīng)理和軟件開發(fā)人員之間對于軟件開發(fā)的理解常常是脫節(jié)的。

      我敢肯定，軟件開發(fā)經(jīng)理會抱怨說，軟件開發(fā)人員不懂業(yè)務(wù)方面，不知道安排會議安排的難點(diǎn)——但那是另一回事了。

      無論如何，關(guān)鍵點(diǎn)是：這不是一個對立的局面，而是一個可以解決的關(guān)于溝通不暢的問題——至少在一定程度上——可以通過合理的交流溝通解決。

      采取積極而不是對抗的的方式，往往才是解決這些問題的最佳途徑。