CODING 告訴你硅谷的研發項目管理之道（5）

CODING 已經經過前四期文章，讓你們逐步瞭解了一些硅谷優秀的項目管理者是如何工做、如何維持團隊高效運做的。在過去的十幾年中，中國的互聯網行業發展過於迅猛，致使不少管理人員都是趕鴨子上架，商場如戰場，不給你任何適應的時間，因此不少人尚未從技術人員的身份轉變過來就開始帶團隊，在管理方式上不免會有所欠缺。這也是咱們作這一系列文章的初衷，但願經過這些文章幫助研發管理者，自省或者回顧一下本身的管理思惟，看看有沒有哪些方向能夠借鑑。同時也給將要成爲管理者的技術人員一點預習材料，爲往後踏上管理之路作一些準備。

本篇文章來自於 Forter 的研發 VP：Oren Ellenbogen，同時他仍是 SoftwareLeadWeekly 的創始人和 Leading Snowflakes 的做者。本篇文章我的風格比較強烈，Oren 在他本身的 Readme 中展現了不少我的管理風格的喜愛和細節，同時也提供了大量的延伸閱讀材料以供參考。

系列文章地址：
《CODING 告訴你硅谷的研發項目管理之道（4）》

原文地址：https://docs.google.com/document/d/1sx5ssYb_xMrmwPpyjD5xP7RvQ7cHweDYlRGn2SXztKw/edit#

原文做者：Oren Ellenbogen，Forter 研發 VP

譯者注：Forter 是一家經過數據分析爲金融、電商等行業提供反欺詐解決方案的供應商。

正文

先說說我本身，我做爲 Forter 的技術 VP ，主要職責有如下幾點：

• 創造出」勢必達成「的工做氛圍（好比咱們能夠完成業務方面須要咱們作的任何事），同時爲股東和其餘利益相關者提出相應的合理計劃和所須要的支持。
• 經過一流的待遇以確保招到一流的人才。同時咱們還但願能在相應的技術領域作出一些品牌影響力。不能否認，在公司成長過程當中會有一部分人離去，但只要在問他們「你以爲整個團隊的 EQ、IQ、好奇心和效率有沒有隨着時間越變越好」的時候，他們的回答是「妥妥的」，那就證實咱們仍是走在正確的道路上。
• 爲組員定好合理清晰的框架，平衡公司需求和組員的我的職業發展。
• 經過不斷迭代來優化咱們所使用的工具和流程，確保組織和業務的可持續發展。
• 爲組員提供指導，幫助組員提高領導力。

還有一點很重要，就是我是爲你服務的，若是你有任何須要均可以直接問我。同時要明確你不是爲了我工做的，而是爲 Forter，因此當你認爲我在犯錯誤的時候，請直接跟我溝通，我也但願像你同樣獲得成長。

我認爲最重要的事

1.我是 1-(wo)man startups（https://venturehacks.com/arti...）理念的忠實擁護者，尤爲在咱們如今的組織規模下（大概 25～30 位工程師）。雖然咱們中的一部分人在本身的領域很是突出，但爲了保證組織的敏捷性和快速迭代，但願每一個人都能把本身看成複合型人才看待。

你的 take-away 信息：
  1. 熟悉公司前進的方向並對如何達成目標所須要的技能有所瞭解，若是須要學習新的技術棧或者方法論，我會盡我所能幫助你。
  2. 你有權要求安排關於新技術的培訓或者購入相關資料。
  3. 若是你更喜歡在某個領域鑽研，那你也能夠跟我聊，咱們能夠一塊兒看看有沒有這方面的機會，同時也權衡一下利弊。
  4. 咱們鼓勵組員接受新的挑戰和職位。

2.當涉及研發如何幫助業務的時候，個人產品哲學是客戶第一，產品第二，其餘第三。雖然有點老生常談，可是真正可以作到這個標準的組織仍是少數，大部分人都會花很是多的時間在項目和產品層面，可是不多有人願意真正花大量時間去了解：咱們的產品是否真正意義上改善了客戶的體驗。咱們的願景是讓咱們的客戶成功——請把這句話寫下來擺在桌上或者記在腦中 :D。這份材料能夠做爲參考：https://www.useronboard.com/f...

你的 take-away 信息：
  1. 客戶可否受益將是衡量你的產出的重要標準。
  2. 多花時間去和產品、市場和銷售部門的同事聊聊。他們做爲前臺部門能最直接地瞭解客戶的需求。在新項目開始前，找個機會請他們吃個飯，問問他們是如何判斷客戶需求和客戶在乎的點。
  3. 我堅信研發要能促進業務的發展，若是你發現有可以改善如今產品的機會，就應該扛起責任，推進各方來完善。

3.在快速發展的組織中，衝突是不可避免的。

你的 take-away 信息：
  1. 沒有衝突的話，咱們將縮在各自的溫馨圈內，即便在須要的時候也沒人敢提出反對意見。
  2. 我很欣賞資深工程師之間的那種信任。當你以爲有什麼事在朝着不太對的方向發展時，要敢於提出異議。在提出意見的時候請儘可能作到友善和建設性，但千萬別憋着。
  3. 不管在何種狀況下，先認清楚本身的身份：我是這個項目的負責人？仍是顧問？仍是路人。
  4. 在提出問題的時候，必定要就誰能作決定達成共識，而後肯定若是這個問題超出權責範圍的話應該去找誰溝通。確保每一個問題能定論而不是不了了之。

我最不喜歡什麼

畢竟我不是你的父母，不能一直庇護你。在知道了什麼事情比較重要後，也應該瞭解一下若是表現出哪些行爲且長時間沒有改善的話會有可能會被開除。

1.利用公司和組織的資源來試圖達成我的目的的人。

2.對手上的工做沒有認知，不知道爲何要作這些工做。
爲了忙而忙是一種效率低下的行爲。咱們但願能作正確的事情，因此必需要常常問本身一些問題：
a. 作這件事可否更快地幫助咱們發展。
b. 作這件事可否讓咱們的客戶更加信賴咱們的產品。
c. 作這件事可否幫助咱們在市場上取得優點。
d. 不要默認看上去很自信的人說的話就老是對的，要多和其餘人接觸來確認這些想法。

3.沒有計劃性。
當需求已經很是清晰的時候，我但願你對整個項目有很好地規劃。好比這個功能可能要花 2-3 天，而這項任務可能只須要 2 個小時。以後再開始寫代碼。

4.沒有主觀能動性。
a. 我認爲工程師都應該具備必定的主觀能動性去推進將本身的代碼部署到生產環境上。沒有部署到生產環境的代碼是一種浪費。
b. 在執行以前要確保全部前期準備工做的到位，提早跟相關人員約好會議時間，若是須要的話，提早取得各種許可等等。
c. 不要期望別人來作這些工做，你應該是項目的掌舵人。

5.不肯意花時間提高溝通技能。
a. 不能高效的溝通會嚴重影響組織規模的成長。
b. 功能的負責人應該能精煉討論內容並給出清晰的結論，這不是民主，負責人必須作決定，參與談論的人只須要負責提供建議和權衡利弊。
c. 更主動地去溝通訊息，而不是到了節骨眼纔去問。

我的管理風格

• 在談論中，我有時會表現的有些激動，可能會提升音量。我也挺討厭這樣的本身，但有時就是無法控制，我也在努力改進，若是你以爲有的時候我表現的有些過度，請告訴我，這不是個人本意。
• 若是你在會議中表現出一副不聞不問甚至呆滯的樣子，我會直接點名，由於我很討厭這樣的態度，固然若是有特殊狀況（好比由於家庭緣由這周你都沒好好睡覺）請告訴我，避免誤傷。
• 我可能會時不時重複一些本身已經說過的話，有時你可能會以爲我很煩，我只是但願你接收到了正確/完整的信息而已。我也會常常在各類場合告訴你我是怎麼想的，可能會有些重複，但至少我以爲個人想法都仍是很清晰的。
• 當你想找我聊聊的時候，請不要僅僅在郵件或者 slack 中問一句「在嗎」，請附上你想討論的議題，否則我會默認你接下來是要跟我討論離職的問題。畢竟人在面對未知的時候都是往壞處想，我也不例外。

• 對於組長們（研發經理，資深研發等）來講，我但願能主動告訴我大家是怎麼想的，準備怎麼改進或者執行而不是等個人指示，若是你有問題，來找我，我來幫你，可是歸根結底你纔是掌舵的人。
• 沒有什麼事能比一場激烈的討論更讓我高興的了，前提是要對事不對人，討論完仍是好同事。一場合格的辯論必定要以：「很高興咱們進行了一場有效的討論，感謝各位的全力投入，分享大家的想法，如今就等【項目負責人】來作最終決定了「結尾。
• 我喜歡有計劃的工做，對項目有比較清晰的預估和時間規劃，這樣能夠下降不少風險，固然若是由於各類各樣的緣由致使項目延期，我也不會拿這個來針對你，我會盡量的幫助你來改善這種情況。
• 我是破窗效應（https://en.wikipedia.org/wiki...）的信奉者，在研發產品的時候我但願有整潔的記錄，清晰的註釋，詳盡的規劃。一旦事情開始混亂起來，就很難清晰的瞭解系統的健康度。

• 最後，我喜歡寫不少東西，我但願你也能開始寫做 :D

譯後記

Oren 的 Readme 文檔能夠說是我的風格極強，把本身的管理風格表達的很是清晰，他還在後面加入了大量平常工做中的細節，好比每週 1 on 1 聊天的模版、如何跟他約時間、公司哪些內部資料須要仔細學習等等，因爲太過於詳細，這裏就不作翻譯，對細節感興趣的同窗能夠點擊原文連接自行查看。

同時能夠看出 Oren 是一位對高效溝通和項目時間規劃都很是在乎的管理者，這其實也表明大多數研發管理者的需求，可是因爲現階段研發管理工具過於分散致使效率下降，也提升了統籌全局的難度。CODING 正是看準了這一研發管理痛點，推出了一站式的研發管理系統，覆蓋軟件研發從設想到交付的全流程。同時獨有的研發大數據幫助管理者輕鬆掌握項目動態，提供研發效能，讓企業研發管理真正「看得見，摸得着」。

CODING 助力開發者輕鬆成爲管理者。