我在阿里做開發的高效打工技巧總結

ITPUB社群發表於2023-12-27
阿里

我在阿里做開發的高效打工技巧總結

來源：阿里雲開發者

阿里妹導讀

如何高效打工？本文作者站在開發的視角總結了一些打工技巧，包括如何高效開會、如何與人溝通、如何做PM等，希望可以給大家提供一些幫助。

前言

如果您的工作中完全不需要自己寫PRD 、技術方案、測試用例，那麼這篇文章除了會浪費您寶貴的15分鐘之外，別無益處，可以繞行了。

背景

很多新入職的工友反饋，大家現在除了編碼之外，在廠子裡還有很多七七八八的雜活才是工作耗時的大頭，比如有些專案裡面，溝通&對接相關的工作佔比甚至大於70%，實際寫程式碼&自測也就一兩天，前面那些細碎的內容，也不方便錄入工時，非常苦惱。
出於對工友的愛和保護，鄙人決定在這裡分享一些打工的技巧，希望能提供一些微不足道的小幫助。

如何高效開會

作為會議發起人

首先，作為會議發起人希望大家能自覺做到如下幾點：

提前準備文件

提前準備好會議文件，比如技術方案評審，在你評審之前，至少要寫好了完整的技術文件，並且提前私下裡和參會的上下游開發勾兌過協議，並且在開會前，把文件貼在日程裡面。最討厭都做方案評審了，上下游都還在抓瞎，最後留下來一大堆action“會後再對”，一場會議出現超過3個“會後再對”就一定有嚴重的資訊gap。
所有的評審型別日程，都不應該發展成討論會。
為了防止有些眼神不好的工友不知道貼在哪裡，我貼心做了大量截圖，大家可以貼在日程描述，或者只貼在日程的評論區

我在阿里做開發的高效打工技巧總結

控制會邀時間

我有個朋友，首先這個朋友確實不是我本人，其次這個朋友有個習慣：任何超過1小時的會邀，他都預設不參加。因為超過1小時的會議，除非是線上故障的覆盤，否則肯定又臭又長不確定的點又多。不管是技術方案還是產品方案，作為一線技術人員，確實可以繞行，這種會我認為一個大團隊，派一個代表參加就好了，比如PD在開發就可以不在了，開發在就不要測試也旁聽了。
所以我希望大家能在做好充分準備的前提下，合理評估會議真正需要的時間。
根據我的經驗，5人日以內的業務需求，技術方案評審可以控制在15分鐘；10人日以內的需求，技術方案評審可以控制在30分鐘左右。
1小時的技術方案評審，比較適合多個子域聯合評審or全鏈路技術方案串講。
至於《勾兌介面協議》、《拉齊開發進度》、《XX專案技術日會》這種單個事項的資訊同步，10分鐘，最多10分鐘就夠了。
10分鐘真的可以做很多事情，如果大家發現自己10分鐘還沒能描述清楚某個問題，我建議是不要開會，直接去需要溝通的那個人面前，搬個凳子坐他身邊進行一些結對程式設計。

提前確認別人有沒有時間

我有個朋友，首先這個朋友確實不是我本人，其次這個朋友還有個習慣：任何發過來提示自己日程衝突的會邀，他都預設不參加。因為如果自己作為一個會議參與人，真的這麼重要，那麼至少要有人提前釘釘打個招呼描述一下背景，其次應該提前發起，既然提前發起，就要檢查下核心人員是否available。

我理解很多倒排期的需求或者線上緊急事項，不得已要臨時拉會。
但是作為一個職業的打工人，如果你10個會邀有8個都是臨時拉起來的，那真的很想問一句：“規劃”這兩個字在你的打工人詞典中是不存在的嗎？
個人經驗，一個明確上線時間在15天之內的需求，pd至少要提前2天約prd評審會邀，開發在明確技術方案之後，要至少提前2天發技術方案評審會邀。
為了防止有些眼神不好的工友不知道如何檢視參與人繁忙，貼圖如下：

我在阿里做開發的高效打工技巧總結


作為會議參與人

提前閱讀會議文件

正常情況下，任何會議都要有個主題，主持人應該提前準備文件，如果對方沒有主動丟擲來，你在參會前需要主動去要。
如果某個工友連續3次拉會，但是沒有任何文件準備，你可以預設這個工友不是很需要你了，這場會議有你沒你區別不大，可以考慮不去了。

和合作工友互為backup

正常的產技團隊，可能在專案初期，或者某些前期對焦專案中，需要頻繁接到名字比較玄幻的會邀，比如《AE下單最佳化討論》、《23年xx協議邊界升級溝通》、這種會議，PD、開發、測試，大家如果比較忙，可以出一個人就好了。
同理，作為一個開發團隊，跨域需求，全鏈路的串講會議，只需要域內介面人出席就好了，除非有需要某個特定人員參與的特定事項。

時間衝突的會議要提前說

如果會議和自己時間衝突，可以大大方方的點一下暫定或者拒絕，並且主動同步會議主持人，然後確認誰作為自己的的backup參加會議。
如果你有backup，你有必要提前給對方交代好相關背景，不要讓backup一臉懵逼的出現在會議現場。
如果你沒有backup，大可以直接告訴對方。因為結果無非只有兩種：1.你很重要，會議改時間 2.你很不重要，會議如期舉行。
總之是好過一群人在會議室裡面call你，然後在浪費了所有人3分鐘之後，聽到你在電話那一頭尷尬的說一句我不方便，要愉快的多。

希望大家有些邊界感

正式場合，比如RRD評審或者技術方案評審，大家不要串臺。
產品方案評審的時候，希望開發同學不要提問PD有關技術方案的細節，請專注於需求理解本身。
技術方案評審的時候，希望PD不要太多介入技術細節，比如表結構設計，系統架構。
聞道有先後術業有專攻。
否則除了浪費大家時間，就是徒增矛盾。

如何不被測試罵

技術方案評審前要講清楚背景

哪怕大家都參與了PRD評審，在技術方案評審的時候，也必須重複一下本次開發的需求範圍。確保大家理解一致。

臨近上線或者上線後發現有需求遺漏，真的很尷尬。

一定要自測

單元測試、整合測試、頁面點點按鈕。

能執行的自測方案都要儘量去實施，我發現好多工友有點子測試依賴綜合症，好像我們的APP的這些個按鈕，只有測試才有許可權點選一樣。動不動造個測試訂單，造個trace，什麼都要抓個測試來做。
沒必要，真的很沒必要。
有些工友甚至連自己產品的debug包都不裝，抓trace要麼找前端要麼找測試。
我真的很建議HR巡檢一下所有的產技團隊，看看誰工作手機沒裝測試包。

不要揹著測試承諾任何事情

任何線上變更（功能程式碼釋出、配置項變更、等等）的上線時間、風險範圍，不管是PD還是運營來問開發，都不要揹著測試給出任何口徑。

所謂的測試人日= 1/2 開發人日，這種粗估策略，只適用於開發&測試內部排期用，嚴肅場合的評估，需要測試同事親自評估。

如何不被別的開發罵

先找產品

跨域合作，尤其是涉及到新功能開發的，建議開發同學不要直接繞過對方產品直接找其他團隊的開發。

我們要相信PD的能力。
所有跨域合作的訴求，先及時的反饋給PD。
讓PD溝通好排期和優先順序之後，給到你指定開發再去對接。
避免一些不必要的麻煩。
不要自己冷啟動。

說清楚前因後果

跨團隊協作的時候，任何溝通，尤其是開發之間的，希望大家提前快速完整的描述好業務背景。一個團隊的開發，對另一個團隊的業務真的沒有大家想象的那麼熟悉。

你需要任何幫助或者協作的時候，請務必提前整理好文件或者話術，說清楚因為xxx，所以需要對方提供xxxx幫助。

如何做PM

專案管理話題太大了，俺也不太懂，這裡只提供一些針對開發同學，比較簡單實用的工作技巧。

拉群

是的，就是先拉釘釘群，拉一個xxx幹活群。不要用會議群，謝謝。
看了太多專案，拖拖拉拉聊了一星期，開了100個會議群，到處都是不同的排期口徑和發言人，太傷了

  • 確保所有參與的產技工友都在群裡

  • 及時更新群公告，群公告必須包含












子域1：對應開發、對應PD、對應測試子域2：對應開發、對應PD、對應測試
技術方案評審時間：xxxxx聯調時間：x'x'x聯調環境：dpath(xxxx)提測時間：xxx釋出時間：xxxx
PRD: 連結1、PRD: 連結2技術方案：連結1、連結2

  • 任何資訊變更，及時@所有相關人，同步在群裡

約會

技術方案評審、提測、釋出計劃review

這些會議，都要根據排期時間，提前2天以上約好日程。
否則時間會越來越亂。
如果明確了後天就是要技術方案評審，哪怕今天你一個字都沒寫，也要先把日程約上。

熟悉技術方案

10人日以內的小需求，作為技術介面人或者技術PM，要保證自己瞭解所有方案技術細節，哪怕是那些不需要你來寫的程式碼。
大的專案，至少需要了解自己大組的各個子域，對外的協議變更。
比如你知道子域A需要新增一個欄位abc，供子域B消費。
你不需要知道abc的實現邏輯，但是你必須要知道，這兒有個新增的abc。
否則，去參加全鏈路會議會毫無價值，大眼瞪小眼，有問題問你也不知道，很尷尬。

彙總一下技術方案

搞一個單獨的文件，彙總一下所有文件，真的真的很重要。
尤其是涉及的子域比較多的時候，最好畫一個全鏈路的圖，這個圖不需要有太多細節，醜也沒關係。
流程圖、UML都可以。
關鍵是可以表現一下需要參與改造的子域，以及上下游，方便串講的時候梳理依賴關係，避免開發到了一半，發現需某個團隊額外介入，到時候大家都很為難。真的最最討厭互相甩鍋了。

主動參加全鏈路會議

如果這是一個大專案，而你只是某個子域的技術介面人，AKA域內PM（大部分工友在大專案裡面都是這個角色）。
那麼參加各種專案週會、日會、對焦會，是你義不容辭的責任，除非你的PDM、PTM剛好願意代勞。
另外如果你參加，保證資訊上傳下達的同時，不要，不要再拉其他工友一起去了，節省一些人力資源。

主動尋求PMO的幫助

當我第一次發現專案裡面有PMO這個角色的時候，非常認真的問過他/她幾個問題——尤其是開發中，業務還在反覆變更需求範圍的drama專案。
我:"請問PMO有沒有資格拒絕臨時新增的需求？"
對方：“nope”
我：“那麼誰有資格拒絕這些不合理變更？”
對方：“不知道”
我：“那你有權利做什麼？”
對方：… （沉默）(笑而不語)
多年來，我一直奔走呼籲，建議那些需要立項的，有PMO團隊介入的需求。要在專案裡面，給到PMO最大的權力，包含並且不限於：《PRD sign-off之後，拒絕臨時變更的權力》、《開除專案成員的權力》…
比較遺憾的是，目前PMO同學的權力還比較有限。所以據我所知，就一線技術同學的視角來說，能提供的主要幫助包括並且不限於如下幾點：

  • 找會議室。如果你需要會議室，但是在預期的時間段內，訂不到任何會議室，建議找PMO協調。

  • 拉架。如果不幸，專案進展中確實發生了一些不愉快的爭執，不管是跨團隊技術之間的資訊GAP，還是業務需求的臨時變更，都一定要及時同步給PMO，尋求PMO的協調，不要單打獨鬥。

  • 上報風險。所有已知風險，會影響開發or測試進展的事項，必須第一時間同步到PMO，尤其是，需要升級到各個子域主管關注的關鍵問題，最好由PMO統一上升。

  • 抓人。如果真的發生了，開發或者測試途中，技術側發現當前專案前期評估出現遺漏，需要其他團隊的PD甚至開發介入，最好由PMO牽頭協調資源，不要技術之間直接溝通。

你曾經擔任的角色是 CodeReviewer 還是 被 CodeReviewer ？


CodeReview 是開發過程不可或缺的重要一環，如果將程式碼釋出比作一個工廠的流水線，那麼 CodeReview 就是流水線接近於終點的質檢員，他要擔負著對產品質量的保障工作，將“缺陷”從眾多的“產品”中挑出，反向推動“生產方”改進生產質量。

來自 “ ITPUB部落格 ” ，連結：https://blog.itpub.net/70024420/viewspace-3001755/，如需轉載，請註明出處，否則將追究法律責任。

相關文章