[譯]你須要一位英雄：項目經理

你須要一位英雄：項目經理

/**
 * 謹獻給不知何時能再見的小黑
 *
 * 原文出處：https://www.toptal.com/qa/you-need-a-hero-the-project-manager
 * @author dogstar.huang <chanzonghuang@gmail.com> 2016-04-23
 */

勇敢的、在心裏有一個應用想法的、且在銀行有一點錢的企業家啊，這篇文章是專爲你而準備的。你在雞尾酒 餐巾寫下的圖表將會影響整個世界，裝滿錢的大卡車已經派往你的房子。爲了確保他們能按時到達，這裏有一 些可以使產品週期運轉順暢的簡單建議。

爲何在首位須要一位項目經理

"計算機程序是人類製造的最複雜的東西"，道格拉斯·克羅克福德說道。可能你沒據說過這個名字，但對於程序 員來講他真的至關有名。他如今是一位貝寶資深軟件架構師，而且開創了各類很酷的技術，此部分已超出本文 的範圍。他是知道不少關於如何工做於大型項目的人。

就我我的而言，我已經編程了13年，甚至如今，從某種程度上講，每個項目都把我帶進了未知領域。有太多太 多不一樣的技術，而且新技術正以如此驚人的速度在創造中，以至於我歷來都不以爲我徹底能夠知道發生了什麼。 縱使每一個項目都有其獨特的挑戰，這裏仍然有一些常量：

• 項目面臨時間壓力
• 預算比我想的更少
• 我比客戶想的更貴
• 我沒有像客戶想的那樣徹底傾聽
• 客戶沒有像我想的那樣解釋完整

很明顯，咱們須要一位保姆。一位能夠介入創建基本規則，讓每一個人保持誠實，並確保咱們沒有忘記重要東西的 人。一位能夠促進各方相互溝通的人。

這我的，這位英雄，就是項目經理。

爲何項目經理在一個箱子裏？他是一隻貓。貓愛箱子。

當我開始寫這篇文章時，Toptal沒有提供與項目經理的聯繫，但如今有了。 協做！我只能想象閱讀如下建議的當權者意識到了他們缺乏了一個很好的機會。

爲何一個程序員產生不了好的項目經理

除了項目管理協會的認證外，項目經理能帶來的最重要的東西是經驗。所以，要有不少 程序員才能產生至關不錯的項目經理；咱們比其餘人更有技術項目的經驗，咱們分析的頭腦擅長於編目信息以及 設置具體的目標。

上帝才知道，你支付給咱們足夠多了，因此看起來指望咱們能夠管理本身而不是強制你也爲其餘人的時間支付更 合理，對吧？

好吧，對於初學者，你是爲咱們寫代碼而支付。

當咱們從編程發呆中走出來，要去決定優先處理什麼，或者討論這周實際上要準備完成多少時，沒寫代碼。接着 它至少須要10分鐘才能回到剛纔的「空間」，尤爲是若是在剛剛的會話中緊張過分的話，極可能是在爭論特性優 先級。嗚呼，我知道，但這所有都是關於最有效使用昂貴的資源。

最重要的是，咱們真的會只見樹木，不見森林。若是你從這篇文章中沒學到任何東西，那麼請記住這一點：當我 花了成天時間在盯着一些具體的bug時，個人大腦失去了對更大藍圖的追蹤。

當我修復了這些bug，大腦會獎勵我，而且我會認爲已經完成了不少事情，如今能夠玩玩視頻遊戲了。當有人提醒 我首頁仍是有問題時，真是讓我大吃一驚，由於我已經花費了整整一天在把整個項目的每一小塊的詳細的知識都 填充到了個人大腦，還排序了剩下哪些是忘記的。這就是個人大腦是如何工做的，以及其餘不少的程序員也有類 似的心理。

當咱們從編程發呆中走出來作項目決定時，沒寫代碼。

爲何一個客戶產生不了好的項目經理

那麼，若是咱們程序員不想負責項目經理作的事情，那麼它勢必會落到客戶的頭上。這是你的錢。這是你的願景。 無論怎樣，你最終都會爲所有的事情負責。

然而，你也有不少牌。

不少客戶像咱們其他人同樣都是平凡地進行平常工做，有的甚至飽受拖延或健忘之苦。儘管這固然不是在描述你 ， 請找一位專業記事者（Professional Rememberer）在身邊以便你能夠抽身回到更重要的工做，讓整個項目活下來。

若是你已經工做過，或者監督過相似規模的技術項目，你真的須要爲項目找一位好的項目經理。若是尚未，請不 要低估可以預測可能會發生的問題的人的價值。時間估算終歸是時間估算，而bug每每會在乎料以外突如其來。對 於另外一個（若是隻是業餘的）應聘者的花費是值得的，能夠有一我的在身邊而且知道流程中哪部分須要，或者很可 能須要，最多關注。

就以質量保證（QA）爲例。合適的QA是任何項目中想獲得本身想要的必不可少的東西，但它歷來都沒獲得應有的重 視。一位好的項目經理會最大化有限的QA資源，還爲你質量保證了你的程序員。有時候，咱們會越界；有時候，我 們會犯錯。你須要一位技術熟練的人充當監督的角色，以肯定你的程序員是否僅僅有一個休息日，或者是否他或她 實際上與項目格格不入。早期遠離人員問題可能意味着項目的生死存亡。

最後，即便是你，哦我至高無上的客戶，有時也須要一點點檢查或者平衡。這是我最難寫的，由於咱們計算機程序 員沒有因咱們率真的本性而聞名。我只想說，我已經作過不少這樣的項目：客戶堅定認爲每件事都是優先級最高的 而且每件事都必須完成。我毫無疑問這一點是對的，這些可憐的客戶，並無掌控好一天中小時的數量。最終他們 沒有獲得他們指望以及/或者不指望的正向結果，而且我以爲這樣的後果是能夠避免的，若是客戶把評估工做量的 權威委託給一位項目經理而且婉轉地但堅決地保持對項目的進行檢查。在大多數技術項目須要時作出冷靜的判斷很 難，而這又是你的想法，你的錢。電腦也不會關心你或我是否哭、是否對它尖叫。（我知道這點是真的由於我試過 了。）

產生一位好的項目經理的非完整技術清單

無論你是決定忽略前面的1000多個字且本身管理項目，仍是準備聘請某人但想知道更多關於此流程的東西，這份清 單都能幫助到你。我歷來沒有（正式）當過項目經理，因此我不能說哪一個工具給定哪一個項目使用，但我經過這些技 術取得很好的成功：

里程碑

當開始一個新項目時，不少人直觀地知道把項目劃分紅稍微更易於管理的塊很重要，而每一塊值得工做數週到數月 不等。在項目最初，有一個啓動會議來展現這些里程碑是很好的。對於如何到達他們有點模糊是不要緊的，最重要 的事是保持在每一個里程碑後進行檢查以便從你們增長對項目的瞭解中收益，確保項目里程碑仍然（大體地）和最初 相信那樣吻合。

時間評估

咱們程序員絕對討厭評估由於咱們都知道他們是錯的，並且還會用來和咱們做對。他們是錯的不要緊，由於根據定 義，他們是基於一把的未知。他們會用來和咱們做對也是不要緊的，由於咱們的工做是至關輕鬆的而它無傷大雅。

因此每次開始工做於一個新的里程碑時，隨意要求評估。你應該指望每一個主要的特性伴隨着一兩行大體地評估了此 特性須要花費多長時間。我一般會做出樂觀的評估，而後質疑它。一般狀況下，這個額外的時間佔了看不見的陷阱。

用戶故事

用戶故事是應用中某個單一功能的簡要描述。他們做爲重要特性的紀錄是有用的，而且應該是一口大小、能夠適合 索引卡並一般伴隨着少許的繪畫。更爲重要的是，他們充當着客戶想要什麼和程序員須要告訴電腦作什麼之間的橋 梁。對於你，對於客戶來講，他們都是足夠簡單的，在幾分鐘內就可推敲出來，但細節對於咱們程序員則是水很深 而不能輕易涉足入內。

對於用戶故事的快速認識，我找到了這些由Mountain Goat Software 和Roman Pichler提供的高品質的 簡潔指南。關於更多關於「敏捷項目管理」的整套理念，請試下這篇由Paul Barnes發佈的Toptal博客： 對敏捷項目管理的終極介紹。

佈局（樣板）

這不是一篇爲何你須要一位設計人員的文章，由於我以爲大部分客戶已經明白，但值得重複，由於若是把一個 具體的、深思熟慮的設計擺在你的程序員面前的話，你會看到生產力大大提高了。每一次咱們須要作出一個設計 決定時，咱們須要離開這個「空間」，而且每一次由於沒有提供最終草稿而須要返回以及改變某些東西時，好吧， 你在作數學題。。。我不是在抱怨，由於設計是有趣的，但以個人經驗，這是能夠避免的、額外收費的時間的頭 號資源。

大部分設計者在Adobe Photoshop，Adobe Illustrator，或者Sketch中提供佈局（compositions），也稱之爲 comps。若是你正在本身作，你可使用諸如Balsamiq或者InVision
這樣無數的在線工具的其中一個。這個comp不須要有和最終成品同樣的顏色或者風格（由於這些之後會很容易改 變），但請花一些額外的時間確保所有的UI元素都展現並列入在內。

站立會議

漫長的會議有時是不可避免的，但你真的不想讓你的程序員負荷過載或者佔用他們過多沒必要要的時間。我有些客戶 看起來指望我能記住在一個兩個半小時會議裏說過的每件事；他們很是失望。站立會議一般限制在15分鐘以內， 按照慣例這期間都是站着的。站着是爲了確保每一個人都參與進來，一樣也是爲了保持會議簡短。

在站會期間，每一個人圍繞成一個圈並進行扼要的狀態彙報，以便所有團隊成員同步其餘人的最新進度。關於站立 會議，更多請見：ExtremeProgramming.Org。若是大家都是遠程工做 或離岸開發而且不想天天讓每一個人上Skype，你能夠試下諸如15Five這樣有趣的工具 做爲變種的站立會議。15Five讓團隊成員能夠在他們方便的時候提供輸入，而且它會提示調查問題以便梳理出更 深刻的迴應。

清單系統（Ticketing System）

雖然任何人均可以維護一個即時貼和Google Docs（以不一樣的顏色高亮每一個人的任務）這樣的系統，但這真的沒必 要；不少人已經爲你嘗試解決了這個問題。Basecamp和Trello因容易使用而聞名，而Pivotal則試圖把整個「敏捷」 理念封裝進一個很是光滑的包。無論你的選擇是什麼，一個好的清單系統至少應該能夠：

• 建立任務
• 分配優先級和截止日期
• 鏈接任務和子任務
• 分配不一樣的決議，諸如「已完成」或「測試失敗」
• 展現指派給特定用戶的所有任務

當一個項目經理給你展現了40個標註明亮紅色、優先級最高、而且都在同一天截止的清單時，你就能確切地明白 這個項目鳥眼視角的價值了。

你不須要使用即時貼追蹤開啓的Bug。

源碼控制

你可能歷來都不會看一眼項目版本控制系統中的代碼，但源碼控制（或者版本）在咱們的清單裏是最重要的工具 之一，是能夠想象獲得的最偉大的備份系統。

大部分現代項目使用Git，儘管有時你會在已經有一段時間的項目上使用SVN。Github容許你免費託管無限制的公 共倉庫（因此，它包含了世界上大部分開源項目），而Bitbucket則容許你託管無限制的私人倉庫因此是商業項目 最喜好的選擇。

無論你選擇了哪一個版本控制系統，它遠程存儲了咱們的代碼以防發生不測，再加上強制咱們編寫一小段註釋來描 述咱們剛作了什麼以便追蹤每一次「提交」的代碼。這能夠防止不一樣的開發人員覆蓋了其餘人的代碼，咱們能夠看 到在一個給定的時期內所有的修改，咱們還能夠建立新的代碼分支存放不是立刻用到的特性。甚至還有一個稱爲 「blame」的命令，顯示了給定的一行代碼是誰負責的，以及是什麼時候提交的。

源碼控制是最偉大的。

測試驅動開發

這是相對昂貴的實踐，這意味着在對於幾個自由職業者預算有限的項目裏不常用。因此你，做爲一個先行者， 不該該爲沒作這點而感到糟糕，但我必須在你的面前提到這個理念由於它提供了對抗Bug的終極防禦。基本上來 講，你的程序員花費了額外的大量的小時在於編寫測試（很小的代碼塊），以確保應用的指定部分以特定的、可 預見的、可重複的方式運做。例如，我可能編寫一個測試斷言當點擊了「登陸」按鈕，會打開一個帶有用戶名字段 的彈出框。

測試之美就是一旦寫好了測試，我能夠立刻經過一個簡單的命令來運行他們。若是寫了200個測試，我能夠在發佈 一個新的應用版本後運行他們以確保沒有在這200個特性中引入任何的bug。它並完美，但它能儘量讓咱們接近 保證無bug（至少少許bug）的應用程序。

總結

這是我所知道的關於項目經理的所有。我不肯定有多少會經過項目管理協會的調集，但這是我從過去十年中所參 與的網站項目中總結出來的所有經驗。固然，我推薦你招聘某我的以便能從他或她的經驗中獲益，但我但願即便 你作不了什麼也能從這些信息中找到有幫助的。你將是這個項目上最終的權威，因此你對它內部工做了解得越多， 你就越有可能帶領它走向勝利。

------------------------

• 本做品採用知識共享署名-非商業性使用-相同方式共享 3.0 未本地化版本許可協議進行許可。
• 本文翻譯做者爲：dogstar，發表於艾翻譯(itran.cc)；歡迎轉載，但請註明出處，謝謝！