\\\\\
這本《與編碼人員一起工作》是一本指導非技術型讀者管理軟體開發團隊的實用手冊。在這本書中，patrick gleeson 解釋了軟體開發過程是如何運轉的，管理者做些什麼能使其更為高效，以及做什麼能與編碼人員建立起穩固的工作關係。
\\ infoq採訪了gleeson，請他談了談管理軟體開發的主要挑戰以及如何應對它們，管理者做什麼可以預防或減少技術債，管理者應意識到程式設計師的偏見，以及管理者做些什麼能與編碼人員建立起穩固的工作關係。
\\infoq：是什麼讓你下決心寫這本《與編碼人員一起工作》？
\\
\\\patrick gleeson：前些年有段時間，我發現我一直在重複講某些話。通常，與我交流的不是編碼人員，要麼就是企業家，要麼就是同事在找我尋求建議，我們**如何參與到編碼人員團隊構建軟體的工作中，以及問題出現的各種方式。在指導期間我發現，有些東西對於沒在編寫軟體上投入過時間的人來講一點兒都意識不到。但同時若要清楚你是否能夠與編寫軟體的人共事，這些事又是至關重要的。我想，如果我能夠把這些事記述下來，就能幫一些人預防這些錯誤了，這些可都是我在第一線總結的「血的」教訓。
\
infoq：這本書的目標讀者是？
\\
\\\gleeson：有些人不親自寫編碼，而他們的事業成就又取決於編碼人員為他們所寫的軟體，這本書的主要受眾就是他們了。具體來說，主要就是it專案經理、就職於創業公司的人、業務分析師、中小企業ceo，以及任何自己尋找各類軟體開發**委託人的人。但同時它也是以軟體開發人員為出發點而寫的，特別為那些管理其他編碼人員以及投入大量時間與非技術型同事互動的團隊領導。
\
\\
\\\gleeson：我想主要談兩點。第一點是這本書的目標，即成為管理軟體開發團隊的實用指南。我花了很多時間思考激勵編碼人員的獨特因素，圍繞應得到鼓勵的工作和無適當保障措施的不利影響出現的趨勢。還有幾章講了如何招聘開發人員，如何使他們保持愉快的心情。
\\ 第二點，這本書是關於技術與非技術之間溝通的書。它所講的是如何讓不清楚編碼的人更好地理解軟體開發過程，不論是想辦法解釋像技術債之類的概念，還是勸說關鍵利益干係人特定工作方式即使在外人看來違背直覺，但會讓他們得到所需的結果。
\
infoq：軟體開發管理的主要挑戰是什麼？
\\
\\\gleeson：最大挑戰在於軟體開發不像其他業務流程或其他工程規範那樣運轉，有著微妙而實際又很重大的差異。這意味著如果你管理專案時借鑑其他過程和規範，差不多總會失敗。特別是，編寫軟體時想要精確定義需求是非常難的，為乙個指定特性**完成它所需的工作量更是難上加難。這兩點就意味著從其他規範中借鑑專案計畫和管理的做法基本上沒什麼價值。
\
infoq：從敏捷角度出發，你建議如何應對這些挑戰？
\\
\\\gleeson：基本上，像scrum、極限程式設計等等各種敏捷規範都已經承認，這種軟體開發所必然面對的困難是由需求規格和評估中的未知情況造成的。避免把眼光放得太遠，專注於收集資料並從中總結分析，能盡早暴露制定錯誤決策的風險。也許頗有爭議，但我認為這種敏捷方**所提倡的迭代、增量的開發從本質上有些效率低下，它帶來大量的會議、重複編寫大量相同的**等等。但如果接受這些低效，我們可以顯著降低軟體專案的風險，在很多時候這就是個明智的選擇：低效的成功總好過魯莽的失敗。
\
infoq：你建議在什麼時候別用敏捷？
\\
\\\
infoq：管理者做什麼可以預防或降低技術債？
\\
\\\gleeson：時間就是金錢，它隨著技術債的積累而增加，其實這個財務隱喻非常好，因為你會在技術債上支付利息：你拖得越久，陷得就越深。所以管理者最主要的就是讓開發人員有足夠的時間去完成他們的工作，不至於一開始就陷入技術債。為適應變化，會進行需求變更和臨時調整**，這時就會經常出現技術債了。企圖讓軟體需求不發生變更是毫無意義的：這也正是為什麼需要敏捷，所以要管理預期以確保可以徹底響應變化，花些時間「重構」軟體，而不是為了應急積累技術債，這是管理者能做的最有幫助的事了。
\
infoq：管理者應意識到哪些程式設計師偏見？
\\
\\\gleeson：我認為其中最突出的是對新生事物的偏愛。軟體開發關乎的就是要持續關注新生事物，因為重複的東西總會被自動化，所以大家會僅僅因為新鮮而愛上乙個工具、一門技術或一種技巧。這會帶來偏見，偶爾會完全迷失，導致開發人員主張錯誤的決策。管理者應該留心觀察，看看對新生事物的偏愛是否正在扭曲開發人員的判斷。
\\ 害處差不多大的是厭惡。出於不同的原因（經常是做事無把握），開發人員可以發現他們自己實際上投入於不喜歡的特定語言或工具上，有時這很不合理，偶爾會完全影響生產力。在最糟糕的情況下，它會營造有害的環境，其他開發人員僅僅因為使用過去的技術而被輕視，使團隊形成緊張的氣氛。如果一名開發人員陷入總被他們責罵特定技術的境地，管理者就該高度重視起來，阻止事態的發展，因為它沒有工作效率且很不健康。
\
infoq：對於想要與編碼人員建立穩定工作關係的管理者，你有什麼建議嗎？
\\
\\\\\gleeson：記住編碼人員也是人。通過最近40年或更長的時間，大家已經對軟體開發人員形成了刻板印象，而且通常是負面的看法，把編碼人員塑造成了異類。儘管實際上編碼已經成為越來越主流的職業，從事這一行的來自於各種不同的背景。所以帶著對編碼人員的刻板印象與之協作非常有害。這就是說，如果你花時間寫寫**，就會改變對許多事的看法，而對於管理者來說，了解不同的觀點又是極為重要的。例如，構建使用者介面時，編碼人員會花更多的時間在介面相關的原始碼上，而不是介面本身，所以讓他們記住它將如何呈現給使用者不是件容易的事。討論介面時，編碼人員腦中所想與平面設計師所想會迥然不同。好的管理者會預料和調解這些觀點差異，利用這些差異而不是讓它們產生衝突。
\
patrick gleeson從事編碼和編碼人員的管理已經有10幾個年頭了。他曾於各種組織任職，從定製軟體的諮詢到跨國公司，再到小型初創企業，現在他是think smart的技術總監，這家公司為年輕人提供工具，讓他們可以做出更好的職業規劃。他還為電影和劇院兼職擔任過製作人，有一次，他花了一年時間製作電子動物木偶參與了機械人馬戲團，其中有乙隻演奏木琴的機械章魚。
\\檢視英文原文：q\u0026amp;a on the book working with coders
《與編碼人員一起工作》作者訪談
這本 與編碼人員一起工作 是一本指導非技術型讀者管理軟體開發團隊的實用手冊。在這本書中，patrick gleeson 解釋了軟體開發過程是如何運轉的，管理者做些什麼能使其更為高效，以及做什麼能與編碼人員建立起穩固的工作關係。infoq採訪了gleeson，請他談了談管理軟體開發的主要挑戰以及如何應...
《與編碼人員一起工作》作者訪談
這本 與編碼人員一起工作 是一本指導非技術型讀者管理軟體開發團隊的實用手冊。在這本書中，patrick gleeson 解釋了軟體開發過程是如何運轉的，管理者做些什麼能使其更為高效，以及做什麼能與編碼人員建立起穩固的工作關係。infoq採訪了gleeson，請他談了談管理軟體開發的主要挑戰以及如何應...
《與編碼人員一起工作》作者訪談
這本 與編碼人員一起工作 是一本指導非技術型讀者管理軟體開發團隊的實用手冊。在這本書中，patrick gleeson 解釋了軟體開發過程是如何運轉的，管理者做些什麼能使其更為高效，以及做什麼能與編碼人員建立起穩固的工作關係。infoq採訪了gleeson，請他談了談管理軟體開發的主要挑戰以及如何應...