告別失控

《告別失控》是2016年人民郵電出版社出版的圖書，作者是[美] 米奇、W.蒙托（Mickey，W.，Mantle）、羅恩·利克蒂、羅恩·利克蒂（Ron，Lichty）。

基本介紹

• 中文名：告別失控 
• 作者：[美] 米奇、W.蒙托（Mickey，W.，Mantle）、羅恩·利克蒂、羅恩·利克蒂（Ron，Lichty）
• 出版社：人民郵電出版社
• ISBN：9787115415318

內容簡介

這是一本系統闡述面對混亂而容易失控的技術開發團隊時，如何管理、建設和強化團隊，成功交付開發成果的大作。兩位作者Mickey W. Mantle和Ron Lichty以合起來近70年的開發管理經驗為基礎，通過深刻的觀察和分析，找到了軟體開發管理的核心問題——人的管理，並圍繞如何真正理解程式設計師、找到合適的程式設計師、與程式設計師溝通這幾個核心話題，一步步展開，擴展到如何以人為本地進行團隊建設、管理和項目管理。

作者簡介

Mickey W. Mantle

從事軟體開發工作超過40 年，作為軟體和硬體產品創建者、管理者和領導者，先後供職於Evans& Sutherland、Pixar、Br?derbund 和Gracenote 公司。他現在從事移動/ 平板套用開發、寫作和諮詢工作。

他的經驗包括指導全球的研發團隊和管理跨學科的團隊進行7×24小時的高效工作以交付成功的產品。憑藉在印度、俄羅斯、加拿大和日本挑選、創建和管理離岸開發機構的經驗，他對使用跨時區、跨地域的不同人員和團隊進行軟體開發所面臨的管理挑戰有深刻的見解。

Ron Lichty

從事軟體開發工作超過30 年，歷任程式設計經理、開發總監、產品與工程副總裁，先後供職於蘋果、富士通、Razorfish 和Schwab。他寫過4 本書和數百篇文章，為創業公司和其他大小公司提供諮詢，解決軟體開發的難題，確保運行正常。

他是6 家創業公司的顧問。他曾是矽谷歷史悠久的開發者組織SVForum 的董事會成員，目前是新興技術特別興趣組的聯合主席，創辦了它的軟體架構特別興趣組，還擔任過東灣創新組軟體管理實踐特別興趣組的主席。

譯者簡介

趙普明，從事軟體開發工作近十年，從程式設計師、項目經理、開發經理到技術總監一步步走過來，對技術團隊管理深有感觸。帶領過多個技術團隊，崇尚敏捷、開源、分散式的核心小團隊開發，也做過遠程開發。譯有《像計算機科學家一樣思考Python》一書。

黃倩，工學博士，河海大學副研究員，先後畢業於南京大學計算機科學與技術系、中國科學院計算技術研究所，主要從事視頻壓縮、視頻處理等方向的研究工作。參與了AVS、HEVC等國內外視頻壓縮標準的制訂，發表學術論文近20篇。譯有《編程珠璣（第2版）》等技術書籍。

張維維，愛書，多年從事軟體行業，擔任過開發工程師、系統架構師、技術經理、產品經理、創業者等，關注能改善人的生活的技術和思考，並力圖有所貢獻。

錢昊，畢業於北京大學計算機系，現在北京師範大學第二附屬中學工作，從事數學和信息等方面的課程教學。將程式設計作為業餘愛好，喜歡擺弄各種電子設備，對語言和翻譯領域饒有興趣。另有獨立譯著和合譯譯著各一本。

目錄

第1章　程式設計師為何難以管理　1

1．1　程式設計師都做什麼　3

1．2　成功的程式設計經理為什麼難當　6

第2章　理解程式設計師　8

2．1　程式設計工種　9

2．1．1　客戶端程式設計師　9

2．1．2　伺服器程式設計師　10

2．1．3　資料庫程式設計師　10

2．1．4　Web開發人員及其他腳本編寫者　11

2．2　程式設計師的類型　11

2．2．1　系統工程師/架構師　12

2．2．2　系統程式設計師　12

2．2．3　應用程式員　13

2．2．4　非真正意義上的程式設計師　13

2．3　領域知識　14

2．4　程式設計師的工作要求與能力　14

2．5　工作地點與關係　18

2．5．1　內部雇員　18

2．5．2　遠程雇員　19

2．5．3　契約工　19

2．5．4　契約管理團隊和外包公司　20

2．6　代系特點　20

2．7　個性特點　22

2．7．1　左腦型的人與右腦型的人　23

2．7．2　夜晚型的人與白天型的人　24

2．7．3　“牧童”與“農民”　25

2．7．4　英雄　25

2．7．5　內向的人　26

2．7．6　憤世嫉俗的人　26

2．7．7　奇葩　27

2．8　小結　27

2．9　工具　27

第3章　尋找並招聘優秀的程式設計師　28

3．1　確定要招聘哪種程式設計師　30

3．2　編寫職位描述　32

3．3　推銷職位　35

3．4　招聘全職雇員　37

3．4．1　持續不斷地招聘　37

3．4．2　招聘預算　38

3．4．3　招聘案例分析　40

3．4．4　雇員推薦　41

3．4．5　高效的招聘　43

3．4．6　招聘秘訣　43

3．5　招聘契約工　45

3．6　審查簡歷　46

3．7　縮小範圍　48

3．8　準備面試　49

3．9　面試　54

3．10　做出雇用一個程式設計師的決定　59

3．11　給程式設計師發合適的錄取通知　62

3．12　跟進直到程式設計師答應　67

3．13　小結　68

3．14　工具　68

第4章　幫助新員工順利入職　69

4．1　引導員工儘早入職　69

4．2　為新員工的到來做準備　71

4．3　介紹　76

4．4　確保成功　77

4．5　最初的預期　78

4．6　小結　81

4．7　工具　81

第5章　成為高效的程式設計經理：向下管理　82

5．1　贏得技術尊重　82

5．2　招聘傑出的程式設計師　87

5．3　強化現有的團隊　87

5．4　管理不同類型的程式設計師　87

5．5　引導　92

5．6　保護　92

5．7　評判和改進績效　94

5．7．1　設立目標　94

5．7．2　績效審查　97

5．7．3　知道何時削減損失　101

5．8　組織思維　102

5．8．1　人員配置　102

5．8．2　組織　107

5．8．3　對功能失調的組織進行故障診斷　115

5．9　交付成果和慶祝勝利　116

5．10　小結　117

5．11　工具　117

經驗法則與至理名言　118

管理中面臨的挑戰　121

人員管理　141

管理團隊，順利交付　164

第6章　成為高效的程式設計經理：向上管理、對外管理及自我管理　183

6．1　向上管理　183

6．1．1　了解你的上司　184

6．1．2　準備好溝通材料　185

6．1．3　了解你老闆的老闆　186

6．1．4　時機　187

6．1．5　成為模範員工　188

6．1．6　概要　188

6．2　向外管理　189

6．2．1　與你部門內的人合作　189

6．2．2　了解其他部門　189

6．2．3　利用重要的支持功能部門　191

6．2．4　管理跨公司關係　196

6．2．5　概要　201

6．3　自我管理　202

6．3．1　個人風格　202

6．3．2　時間和優先權管理　205

6．3．3　溝通管理　207

6．3．4　管理實踐　209

6．3．5　跟蹤管理　213

6．3．6　尋找導師　215

6．3．7　概要　215

6．4　小結　216

6．5　工具　216

第7章　激勵程式設計師　217

7．1　激勵理論　217

7．1．1　馬斯洛的需求層次理論　218

7．1．2　麥格雷戈的X-Y理論　219

7．1．3　赫茨伯格的激勵因素和保健因素理論　220

7．2　適用於程式設計師的激勵因素　222

7．3　理論付諸實踐　226

7．4　基本因素——（缺乏時）不滿的原因　227

7．4．1　作為上司被尊重　227

7．4．2　有趣　231

7．4．3　學習與成長　232

7．4．4　良好的工作條件　233

7．4．5　合理的公司政策和管理　237

7．4．6　合乎職業道德的管理　240

7．5　關鍵激勵因素　244

7．5．1　改變世界　244

7．5．2　學習與成長　245

7．5．3　工具和技術　247

7．5．4　認可與稱讚　247

7．5．5　和員工快樂相處　249

7．5．6　利益　249

7．6　個人承諾　251

7．7　技術攻守　253

7．8　了解你的程式設計師的動力——從頭開始　254

7．9　小結　255

7．10　工具　255

第8章　建立成功的開發文化　256

8．1　定義“成功”　257

8．2　程式設計文化　257

8．3　公司文化　258

8．3．1　利用公司文化的複雜度　259

8．3．2　規避公司的負面文化　259

8．3．3　技術在你的公司中扮演什麼樣的角色　260

8．3．4　什麼力量在推動你的公司　262

8．4　成功的程式設計文化的特徵　263

8．4．1　互相尊重　264

8．4．2　創新　265

8．4．3　標準　266

8．4．4　交付　267

8．4．5　溝通　267

8．4．6　虛擬團隊間的溝通　269

8．4．7　公平　271

8．4．8　授權　271

8．4．9　職業精神　272

8．4．10　拒絕傻瓜和笨蛋　273

8．4．11　卓越　274

8．4．12　程式設計上的卓越　274

8．4．13　團隊精神和協作　275

8．4．14　激情　275

8．4．15　關注客戶：“最重要的是客戶體驗，笨蛋！”　275

8．4．16　學習　277

8．4．17　環境　278

8．5　小結　279

8．6　工具　279

第9章　管理成功的軟體交付　280

9．1　定義項目　281

9．1．1　確保需求和假設都足夠清晰　282

9．1．2　把需求限制在“什麼”上，而不是“如何”　284

9．1．3　力求取悅客戶　285

9．1．4　迅速估計工作的規模　286

9．1．5　識別無法商榷的日期　287

9．1．6　激勵團隊　288

9．2　規劃工作　289

9．2．1　將項目拆分為功能點，並按優先權排序　290

9．2．2　將功能點拆分為任務和子任務　291

9．2．3　發動團隊進行自底向上的估計　292

9．2．4　將任務估計集成為項目估計　293

9．2．5　尋找估計中的不足　294

9．2．6　對風險達成共識，而不只是時間表　295

9．2．7　為單元測試與項目測試分配足夠的時間　297

9．2．8　每一次估計都是獨立的挑戰　297

9．2．9　確定項目的節奏　298

9．3　展開計畫　298

9．3．1　參與項目啟動　299

9．3．2　定義“完成”　299

9．3．3　定義“成功”　300

9．3．4　建立項目工作手冊　301

9．4　執行工作　304

9．4．1　設計工作　304

9．4．2　進行設計複審　307

9．4．3　完成項目原型來傳達設計　307

9．4．4　設立共同認可的里程碑　308

9．4．5　確保設立常規代碼檢入會議　309

9．4．6　積極驅動開發　310

9．5　終盤結束期　316

9．5．1　不再增加新功能　316

9．5．2　運行產品　317

9．5．3　準備好宣布成功以及開啟更新版本的工作　317

9．5．4　知道何時減損　319

9．5．5　OEM或國際版　320

9．6　交付軟體　321

9．6．1　慶祝　321

9．6．2　反思　322

9．6．3　分享　325

9．6．4　重構　325

9．6．5　小版本升級　326

9．7　小結　326

9．8　工具　326

工具　327