你的老板是否不理解你的工作？本文將有助于你更好地理解為什么你的老板不理解軟件開發。

你的老板可能真的很棒。我在我自己的編程生涯中就遇到過幾個真心棒的老板，但即使是最棒的老板似乎也常常總是不能理解軟件開發。

事實上，我想說的是當涉及到不止編程的幾個元素時，大多數軟件開發經理都有點目光短淺。

所以，我編譯了一個簡短的清單，用來說明關于編程一些最讓你老板、開發經理、技術大咖等等誤解的方面。

1.技術債務最會拖累項目

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

[[145379]]

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

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

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

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

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

2.預估大多是廢話

軟件開發中的預估大多是廢話。

這一點，你知我知，甚至團隊可憐的項目經理也知——當然，也有可能他不知道，但是他應該知道。

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

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

但事情就是這樣。沒有人應該為此負責。不是你的錯，也不是我的錯，不是任何人的錯。它就是要發生。

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

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

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

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

“好，那就5天。”

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

經驗告訴我，半天時間內的預估，通常能讓你體面地完成工作。超過這個點，那你就是廢話了。

3.可以立刻或快速完成

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

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

[[145380]]

不幸的是，我發現許多軟件開發經理似乎不知道這個普遍真理。不知怎的，他們認為代碼可以得既快又好。

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

同樣不幸的是，大多數程序員，當被告知要快點完成任務的時候，往往會選擇走捷徑，通過犧牲質量來加快進程。

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

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

如果你正在打交道的開發經理不明白，快與好之間的關系，那么你最好拿出一些統計數據，以說明后期修復bug比前期預防要耗費更高的成本。

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

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

4.有的開發人員實際上是在幫倒忙

有一個事實是，我們都碰到過那種對團隊弊大于利的程序員。

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

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

這種類型的開發人員也許應該付錢給公司，而不是公司付給他錢。

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

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

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

但是……你必須這么做。這是對的。如果某人確實是團隊中的害蟲，那么讓管理人員知道這一點也是你的份內事。

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

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

比如你可以這么說：

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

……

當然，這些都只是我的觀察，所以請和其他團隊成員商量一下，根據你自己的經驗來判斷。”

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

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

5.更好的設備是你可以投資的最便宜的生產力之一

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

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

[[145381]]

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

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

什么都別說，我告訴你：

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

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

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

6.新技術的風險其實沒你認為得那么高

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

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

曾幾何時，每隔一年左右軟件供應商才發布框架或補丁的新版本，因此，錯誤的代價會相當高。

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

但是現在，情況有所不同。

如今的框架，有時甚至是在每天的基礎上發布補丁，并且大多數流行框架都是開源的，所以風險并不高。

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

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

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

7.畫蛇添足的業務分析師和項目經理

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

當然，首先要聲明的是，還是有一些好的業務分析師和項目經理的——但說實話，大部分的業務分析師和項目經理毫無價值。

[[145382]]

曾經一度這些角色是開發項目所必要的。

但是現在，在大多數情況下，我們不再需要他們了。

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

這是一個殘疾崗位，因為他們做的是軟件開發人員應該做的工作的一半，卻對另一半工作于事無補。

而項目經理更神奇，他的目標似乎就是奔著妨礙我們開發，將一切搞得一團亂而來的。

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

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

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

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

然后很明顯在一個真正的敏捷環境中，是沒有業務分析師和項目經理的，他們可能更適合作為Scrum管理員或產品所有者。

積極主動

當然，上面我說的這些東西，有的我可能會用一種開玩笑的口吻說。但在現實中，軟件開發經理和軟件開發人員之間對于軟件開發的理解常常是脫節的。

我敢肯定，軟件開發經理會抱怨說，軟件開發人員不懂業務方面，不知道安排會議安排的難點——但那是另一回事了。

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

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

你有什么高見嗎？歡迎分享。