《代碼之外程序員重啟人生》· 第03篇上一世他解決了項目里最難的問題。最后的匯報材料里卻只剩下一句“團隊共同完成”。項目上線后的第三天。林川收到一封會議邀請。會議主題是會員增長系統(tǒng)二期項目總結(jié)匯報。參會人很多。業(yè)務負責人、部門領導、產(chǎn)品經(jīng)理、項目經(jīng)理以及參與項目的核心成員都在名單里。林川點開邀請時停頓了一下。他記得這場會議。上一世就是這場項目總結(jié)會讓他第一次真正意識到把事情做出來的人不一定是最終被看見的人。那次項目雖然延期了九天但最終還是成功上線。系統(tǒng)最核心的規(guī)則引擎是林川設計的。第三方優(yōu)惠券接口反復出現(xiàn)重復發(fā)券問題也是他連續(xù)排查兩個晚上后發(fā)現(xiàn)了對方接口的冪等缺陷。上線前一天數(shù)據(jù)庫出現(xiàn)性能瓶頸。所有人都認為需要升級服務器。林川重新分析執(zhí)行計劃調(diào)整索引和查詢邏輯把接口響應時間從四秒降到了七百毫秒?？梢哉f項目中最難、最關鍵的幾個問題幾乎都經(jīng)過了他的手。但總結(jié)匯報那天站在臺上的人是項目經(jīng)理周凱。周凱用二十分鐘講完了整個項目。PPT里有項目背景、建設過程、上線成果和經(jīng)驗總結(jié)。最后一頁寫著在項目組全體成員的共同努力下項目順利完成上線。林川的名字沒有出現(xiàn)。規(guī)則引擎被描述為項目組創(chuàng)新設計了靈活的用戶運營能力。重復發(fā)券問題被描述為團隊及時協(xié)調(diào)第三方解決接口穩(wěn)定性問題。數(shù)據(jù)庫性能優(yōu)化被描述為在項目經(jīng)理統(tǒng)一組織下研發(fā)團隊完成系統(tǒng)性能提升。匯報結(jié)束后業(yè)務領導當場表揚了周凱?！斑@個項目難度不小周期也很緊周凱整體推動得不錯?！辈块T負責人也點頭?！疤貏e是跨部門協(xié)調(diào)和風險處理體現(xiàn)出了很強的項目管理能力。”周凱謙虛地笑了笑?！爸饕€是大家配合得好?！绷执ㄗ跁h室最后一排。他沒有生氣。至少一開始沒有。他只是覺得奇怪。那些事情明明是自己做的?？山?jīng)過一份PPT和二十分鐘匯報以后整段經(jīng)歷仿佛被重新編譯了一遍。所有具體的人都消失了。最后只留下一個站在臺上的講述者。散會時周凱走過來對他說“這次你技術上貢獻挺大的后面繼續(xù)保持?！绷执▎枴皠偛艆R報里為什么沒提具體分工”周凱愣了一下隨后笑道“項目是團隊成果沒必要分得那么細。再說領導主要看整體結(jié)果不會關心誰寫了哪個模塊。”林川當時沒有再說什么。因為這句話聽起來很正確。項目當然是團隊成果。程序員也不應該搶功。于是他把那點不舒服壓了下去。半年后周凱憑借這個項目晉升。晉升材料中的核心業(yè)績是牽頭建設會員增長系統(tǒng)完成關鍵技術攻堅與跨部門協(xié)同支撐業(yè)務快速上線。林川依舊是高級開發(fā)工程師?？冃гu價里寫著技術執(zhí)行能力較強但主動影響和成果呈現(xiàn)不足。那時他才明白項目是團隊成果。但晉升從來不是“團隊一起晉升”。一、這一次會議還沒有開始故事就已經(jīng)被別人寫好了林川打開項目總結(jié)會的附件。里面有一份PPT初稿。文件名是會員增長系統(tǒng)二期總結(jié)匯報_v3.pptx他翻到第三頁。標題項目建設歷程。下面是一條時間軸。需求評審、方案設計、研發(fā)實施、測試上線每個階段都寫得很完整。在“關鍵技術攻堅”部分列了三項成果完成靈活規(guī)則引擎建設解決第三方接口穩(wěn)定性問題完成核心查詢性能優(yōu)化每一項都沒有負責人。在下一頁“項目組織保障”中卻寫著項目經(jīng)理統(tǒng)籌業(yè)務、產(chǎn)品、研發(fā)及第三方資源建立日跟蹤、周復盤機制保障項目有序推進。林川看了兩遍。他并不否認周凱做過協(xié)調(diào)工作。項目經(jīng)理本來就應該負責協(xié)調(diào)。真正有意思的是屬于項目經(jīng)理的工作被明確寫成了個人貢獻。屬于研發(fā)人員的工作卻全部被概括成了團隊成果。這不是偶然。匯報材料里越抽象的表達越容易抹掉具體貢獻?！把邪l(fā)團隊完成技術攻堅?！薄绊椖拷M解決核心問題。”“各方共同推動項目上線?！泵烤湓挾紱]有錯。但這些正確的廢話會讓真正承擔關鍵工作的人成為背景。林川沒有立刻聯(lián)系周凱。他先打開了自己從項目第一天開始保存的工作記錄。里面有需求評審紀要技術方案版本Git提交記錄性能測試結(jié)果問題排查過程風險同步記錄上線復盤結(jié)論每一個關鍵節(jié)點都有明確的事實和數(shù)據(jù)。上一世他以為代碼倉庫會替自己證明一切?？深I導不會在績效評審前翻Git記錄。他們也不會逐條查看項目群消息。組織對一個人的認知往往來自幾頁PPT、幾次會議和幾句評價。沒有人會主動幫你完成事實到價值的翻譯。如果你不參與講述自己的工作別人就會替你講。至于那個版本里有沒有你不由你決定。林川關掉PPT。給周凱發(fā)了一條消息我看了項目總結(jié)材料技術攻堅部分缺少具體數(shù)據(jù)和負責人。我整理了一版關鍵成果說明建議補充到匯報中避免成果描述過于籠統(tǒng)。周凱很快回復總結(jié)會時間有限不需要講太細突出整體就可以。林川問“項目組織保障”里為什么保留了具體的項目經(jīng)理工作對方過了幾分鐘才回復項目經(jīng)理需要向領導匯報整體推動情況和研發(fā)分工不一樣。林川看著這句話笑了。原來具體貢獻是否需要寫不取決于會議時間。而取決于是誰的貢獻。二、程序員最容易被一句“不要搶功”困住下午周凱來到林川工位旁邊?！拔铱茨銓R報材料好像有意見”林川轉(zhuǎn)過椅子?！安皇且庖娛羌夹g成果需要準確呈現(xiàn)?！敝軇P拉了一把椅子坐下。語氣像是在給剛?cè)肼毜男氯藗魇诮?jīng)驗?！傲执慵夹g確實不錯但格局要打開?！薄耙粋€項目有產(chǎn)品、測試、研發(fā)、業(yè)務還有第三方。最后做成了本來就是大家的成果?！薄叭绻總€人都強調(diào)自己做了什么這個團隊還怎么合作”林川沒有立刻回答。上一世他就是被“格局”兩個字說服的。程序員很容易被道德化語言限制。不爭是格局。不說是低調(diào)。不強調(diào)貢獻是團隊精神。接受額外工作是擔當。反過來主動說明成果就可能被貼上標簽愛表現(xiàn)搶功勞不團結(jié)斤斤計較只考慮個人得失可奇怪的是真正拿走成果的人很少覺得自己在搶功。他們會使用更體面的詞整體負責。統(tǒng)一協(xié)調(diào)。牽頭推進。代表團隊匯報。最后做具體工作的人因為不愿爭功而保持沉默。負責講故事的人則順理成章地成為了故事主角。林川看著周凱?！拔彝膺@是團隊成果?！薄暗珗F隊成果不代表每個人的貢獻不能被準確記錄?！敝軇P說“領導不會關心這些細節(jié)?！薄澳穷I導為什么會關心你組織了日跟蹤和周復盤”周凱臉上的表情停了一下。林川繼續(xù)說“協(xié)調(diào)是貢獻技術攻堅也是貢獻。”“項目經(jīng)理的貢獻可以寫清楚研發(fā)人員的貢獻同樣可以寫清楚?！薄斑@并不是搶功只是保持事實完整。”周凱皺了皺眉。“你現(xiàn)在一定要分得這么清楚嗎”林川回答“項目獎金、績效和晉升都會分到個人項目貢獻當然需要分清楚?！惫の桓浇蝗话察o了不少。旁邊幾個同事看著電腦卻明顯放慢了敲鍵盤的速度。周凱站起來。“那你把材料發(fā)給我我看看。”林川點頭。“我半小時內(nèi)發(fā)?！敝軇P離開后前端同事轉(zhuǎn)過頭小聲說“你真敢說。”林川問“哪句話說錯了嗎”對方想了想?！皼]錯但以前沒人這么直接?！绷执ㄐα艘幌?。以前沒人直接不代表這件事合理。只是大家都在等另一個人先開口。三、他沒有寫“我很辛苦”只寫了三個數(shù)字林川沒有在材料里寫自己加班到幾點。也沒有寫自己連續(xù)工作了多少小時。辛苦是一種感受。成果需要證據(jù)。他整理了三項關鍵結(jié)果。第一項規(guī)則引擎設計原來的需求是每增加一種會員策略都需要研發(fā)重新修改代碼。林川設計了一套可配置規(guī)則模型將業(yè)務條件、執(zhí)行動作和優(yōu)先級拆分。上線后產(chǎn)品可以通過后臺配置大部分運營規(guī)則。他寫下完成會員規(guī)則引擎的核心方案設計與后端開發(fā)將常規(guī)運營策略的交付周期由3—5個工作日縮短至半天以內(nèi)。沒有強調(diào)寫了多少代碼。只說明解決了什么問題。第二項第三方接口穩(wěn)定性聯(lián)調(diào)時優(yōu)惠券接口存在重復發(fā)放問題。第三方最初認為是研發(fā)重復調(diào)用導致。林川通過請求鏈路追蹤發(fā)現(xiàn)對方接口在超時后實際已經(jīng)執(zhí)行成功但返回結(jié)果丟失。他提出請求唯一標識和狀態(tài)查詢機制最終解決了重復發(fā)券風險。他寫下定位第三方接口超時場景下的冪等缺陷設計唯一請求標識及狀態(tài)補償機制將重復發(fā)券測試發(fā)生率由20%降至0。第三項查詢性能優(yōu)化系統(tǒng)測試期間會員明細查詢平均需要4.2秒。業(yè)務無法接受。林川重構(gòu)查詢邏輯、調(diào)整索引后將時間降至680毫秒。他寫下完成核心查詢鏈路優(yōu)化平均響應時間由4.2秒降低至680毫秒滿足高峰期并發(fā)訪問要求。寫完后他在最后補充了一張分工表。成果事項主要負責人協(xié)作人員規(guī)則引擎設計與開發(fā)林川產(chǎn)品、后端團隊第三方接口問題定位林川第三方、測試查詢性能優(yōu)化林川數(shù)據(jù)庫管理員項目整體推進周凱各模塊負責人業(yè)務規(guī)則確認產(chǎn)品經(jīng)理、業(yè)務負責人研發(fā)測試及上線驗證測試負責人項目組沒有貶低任何人。也沒有把所有成果都寫成自己的。誰做了什么就寫什么。這才是真正的團隊合作。團隊合作不是把所有人的名字刪掉。而是讓每個人的貢獻都出現(xiàn)在正確的位置。林川把材料發(fā)給周凱同時抄送了產(chǎn)品經(jīng)理和測試負責人。郵件正文只有一段話附件為本項目關鍵成果及分工補充說明內(nèi)容基于項目記錄、測試數(shù)據(jù)和問題處理過程整理請各位確認。如有遺漏或表述不準確請直接補充修改。十分鐘后測試負責人回復測試部分準確我補充一項自動化回歸工作。產(chǎn)品經(jīng)理也回復規(guī)則配置確實明顯提升了后續(xù)運營效率建議保留。周凱一直沒有回復。但半小時后PPT更新到了第四版。技術成果頁增加了具體數(shù)據(jù)。林川的名字依然沒有出現(xiàn)。四、他第一次發(fā)現(xiàn)有些人不是沒看到只是不想讓別人看到林川點開PPT。技術成果從三句話變成了三組數(shù)據(jù)。規(guī)則配置效率提升。重復發(fā)券風險消除。查詢性能提高?？雌饋磉M步很大。但成果負責人依然寫著項目研發(fā)團隊。而項目管理部分依舊寫著周凱牽頭。林川明白了。這已經(jīng)不是表達習慣問題。而是主動選擇。周凱需要技術成果來證明項目價值。但不希望技術成果綁定到具體研發(fā)人員。因為一旦綁定領導就會知道項目中最重要的技術問題是誰解決的。他可以承認團隊有貢獻。但不能接受另一個具體的人過于突出。林川沒有繼續(xù)在私聊里爭論。他打開項目總結(jié)會議邀請。點擊“回復所有人”。寫道為便于會議準確呈現(xiàn)項目成果我補充了一份項目關鍵技術成果和分工說明已與產(chǎn)品、測試等相關負責人核對。建議作為會議附件供各方確認及后續(xù)復用。附件發(fā)出。收件人包括所有參會人員。沒有指責任何人。也沒有說周凱刪掉了自己的名字。他只是把事實放到了所有人都能看見的位置。五分鐘后周凱打來電話?！澳銥槭裁窗巡牧习l(fā)給所有人”“因為這是項目總結(jié)材料。”“匯報由我統(tǒng)一負責你這樣會讓信息很亂?！薄拔野l(fā)的是事實補充不會影響你的整體匯報?！薄澳銘撓群臀覝贤??！薄拔乙呀?jīng)發(fā)給你了也收到了產(chǎn)品和測試的確認?！敝軇P的語氣明顯冷了下來?！傲执ㄒ粋€項目里不能每個人都自己對外發(fā)材料。”林川回答“同意。所以我沒有單獨做另一份項目匯報只補充了當前PPT缺失的成果和分工?！彪娫捘穷^沉默了幾秒?！澳阕罱兓艽??！绷执ㄕf“只是開始重視工作記錄?！薄澳氵@樣很容易讓別人覺得你在搶功。”“材料里每個人的貢獻都寫了。”“只寫自己的貢獻才叫搶功?！薄鞍阉腥说呢暙I都寫清楚叫項目復盤?！敝軇P直接掛了電話。林川放下手機。心里沒有上一世面對沖突時的恐慌。過去他最怕別人說自己不好相處。所以每次遇到爭議他都會先懷疑自己是不是太計較了是不是應該再成熟一點是不是忍一下更有利于合作后來他才明白一個人只有在你保持沉默時才覺得你好相處那么他喜歡的不是你。而是你的沉默。五、匯報開始后他坐在最后一排卻不再是背景周五下午兩點。項目總結(jié)會正式開始。周凱站在大屏幕前。西裝熨得很平。語氣從容。“這次項目周期比較緊過程中也遇到了不少挑戰(zhàn)。在各方配合下我們最終按核心版計劃完成上線。”前半部分和上一世幾乎一樣。項目背景。目標范圍。建設過程。進度管理。講到技術成果時PPT上出現(xiàn)了林川整理的三個數(shù)字。周凱說道“在技術方面項目組重點完成了規(guī)則引擎、接口穩(wěn)定性和系統(tǒng)性能三項攻堅。”他仍然使用“項目組”。沒有提林川。但這一次會議桌上的每個人都已經(jīng)收到了那份分工材料。業(yè)務領導看著大屏幕。問了一句“規(guī)則引擎是誰負責設計的”會議室安靜了一瞬。周凱說“主要是研發(fā)團隊完成的?！睒I(yè)務領導繼續(xù)問“具體誰牽頭這個能力后續(xù)其他項目也可以復用?！敝軇P只能轉(zhuǎn)向林川。“林川負責得比較多。”所有人的目光落在會議室最后一排。林川沒有表現(xiàn)出受寵若驚。他打開電腦?！昂诵姆桨甘俏邑撠煹暮蠖藘晌煌聟⑴c了模塊開發(fā)產(chǎn)品團隊完成了規(guī)則梳理?！薄澳壳耙鎸I(yè)務條件、判斷關系和執(zhí)行動作進行了抽象可以復用到優(yōu)惠活動、會員權益和消息觸達等場景?！睒I(yè)務領導問“已經(jīng)在其他場景驗證了嗎”“目前優(yōu)惠活動正在復用不需要重新開發(fā)規(guī)則判斷部分預計節(jié)省四個工作日?！睒I(yè)務領導點頭?！斑@個成果可以單獨總結(jié)后面在部門內(nèi)推廣?！敝軇P站在屏幕旁邊手里還拿著翻頁器。但從這一刻開始會議的焦點已經(jīng)變了。講到重復發(fā)券問題時測試負責人主動說道“這個問題是林川通過鏈路日志定位的。開始第三方一直認為是我們重復請求后來證明是超時后響應丟失?！钡谌截撠熑艘颤c頭?！爱敃r林工給的冪等方案確實解決了問題?！敝v到性能優(yōu)化時數(shù)據(jù)庫管理員補充“索引調(diào)整只是其中一部分林川還重新拆了查詢鏈路否則只加索引達不到這個效果?！绷执]有主動搶話。但其他人開始替事實說話。當一個人的貢獻有記錄、有數(shù)據(jù)也被合作方確認以后想從故事里刪除他就沒那么容易了。六、周凱想用“團隊精神”結(jié)束討論領導卻問了另一個問題匯報臨近結(jié)束。周凱迅速翻到最后一頁?！翱傮w來說項目的成功離不開各部門通力合作。個人只是其中一部分最重要的還是團隊?！睒I(yè)務領導點了點頭。“團隊當然重要?！敝軇P像是終于松了一口氣。但領導下一句話是“正因為團隊重要所以每個人做了什么要記錄清楚?！薄胺駝t項目結(jié)束以后我們既不知道該獎勵誰也不知道以后類似問題應該找誰?！敝軇P臉上的笑容有些僵。部門負責人接著說“這次林川在技術方案和問題處理上承擔了不少關鍵工作后面可以考慮讓他在技術側(cè)承擔更完整的職責?！绷执粗懊娴钠聊?。上一世的這場會議領導從頭到尾沒有叫過他的名字。這一次事情并沒有因為他主動說明貢獻而變得難看。沒有人指責他搶功。沒有人認為團隊因此分裂。恰恰相反。事實越清楚所有人越知道下一個類似項目該怎么組織。哪些能力可以復用。哪些人應該承擔更大責任。所謂團隊精神從來不應該建立在抹掉個人貢獻之上。真正健康的團隊不會害怕優(yōu)秀成員被看見。只有依賴信息差維持權威的人才害怕事實過于清楚。七、會議結(jié)束后他拒絕了一次看似善意的和解散會后周凱在電梯口叫住林川。“聊兩句”兩人走到走廊盡頭。周凱先開口“今天的效果你滿意了”林川說“項目成果準確呈現(xiàn)我當然滿意?！薄澳阌X得我故意搶你的功勞”“我沒有這么說。”“但你就是這個意思。”林川看著他。“那你為什么一直不愿意在材料里寫負責人”周凱沉默了一會兒。“因為項目匯報不能太突出個人。”“為什么項目管理可以突出你”周凱沒有回答。過了一會兒他語氣緩和下來。“林川大家以后還要一起工作。沒必要因為一個名字把關系搞僵?！边@句話聽起來像是在和解。實際上是希望林川接受一個前提只要你繼續(xù)追究事實就是你在破壞關系。林川說“關系不是因為名字搞僵的?！薄笆且驗橛腥苏J為另一個人的名字不應該出現(xiàn)?！敝軇P臉色沉了下來?！澳阋院髸靼茁殘霾皇侵豢凑l做了多少?！绷执c頭?！拔乙呀?jīng)明白了?！薄奥殘鲆部凑l記錄了過程誰解釋了結(jié)果誰站在臺上講述?！薄八晕也砰_始保留自己的版本?！敝軇P盯著他看了幾秒。轉(zhuǎn)身離開。林川沒有追上去。不是所有關系都需要修復。有些所謂的關系本來就建立在你退讓、沉默和持續(xù)貢獻之上。當你開始要求公平對方說關系變了。其實關系沒有變。只是你終于看清了它。八、下班前他收到了一封意外的郵件下午六點。林川收到部門負責人的郵件。主題關于會員規(guī)則引擎成果復用的安排郵件內(nèi)容很短林川請你整理本次規(guī)則引擎的設計思路、適用場景和復用方案下周在部門技術會上做一次分享。后續(xù)相關項目的技術方案評審由你參與把關。這不是晉升。也沒有立刻加薪。但它代表一件更重要的事林川不再只是那個在后臺解決問題的人。他的能力開始與具體成果綁定。組織開始知道這件事是誰做的。類似問題應該找誰。誰可以承擔更大的職責。上一世他總覺得只要能力足夠強總有一天會被發(fā)現(xiàn)。這一世他終于承認價值不會自動傳播。代碼運行在服務器上。成果運行在組織的信息系統(tǒng)里。如果沒有記錄、數(shù)據(jù)、匯報和他人的確認再重要的工作也可能只停留在你的電腦里。林川打開自己的工作記錄。在項目總結(jié)下面增加了一行技術成果已完成部門層面同步后續(xù)推進復用。然后他關掉電腦。這次他沒有感到自己贏了誰。他只是拿回了一件本來就屬于自己的東西對自己工作經(jīng)歷的解釋權。九、程序員可以不邀功但不能沒有成果證據(jù)很多程序員不喜歡主動講自己的貢獻。原因并不復雜。我們認為事實應該客觀。誰提交了代碼倉庫里都有。誰解決了問題項目成員都知道。誰加班到凌晨群里也有記錄?？墒聦嵈嬖诓坏扔谑聦崟M入評價。一次項目結(jié)束后真正被長期保存下來的通常只有一份總結(jié)PPT一封項目郵件一次領導匯報一段績效評價一條晉升材料誰參與制作這些內(nèi)容誰就在參與定義項目歷史。程序員不需要天天在群里強調(diào)“這是我做的?！币膊恍枰褕F隊成果全部變成個人功勞。但至少要做到三件事。第一記錄關鍵成果不要只記錄完成了哪個功能。要記錄解決了什么問題帶來了什么變化有什么可量化結(jié)果哪些能力可以復用第二在項目結(jié)束前確認分工項目總結(jié)不是結(jié)束后臨時編故事。關鍵事項、負責人和協(xié)作人員應該及時記錄。第三讓成果進入正式信息渠道私聊里的感謝很快就會消失。代碼評審里的認可也未必會傳到管理者那里。真正重要的成果需要進入周報、項目總結(jié)、復盤材料或者績效記錄。這不是邀功。就像程序員給系統(tǒng)寫日志不是為了炫耀系統(tǒng)運行過。而是為了讓真實發(fā)生過的事情能夠被追溯。寫在最后有些人總會告訴認真做事的人不要太在意名字。項目成功才是最重要的。團隊成果不需要分得太清楚?？僧敧劷?、績效和晉升開始分配時他們又會非常準確地寫出自己的名字。所以程序員可以不爭虛假的功勞。但不能允許真實的貢獻被抹掉。你可以說這是團隊共同完成的。但也應該繼續(xù)說清楚誰負責方案誰完成開發(fā)誰解決風險誰推動協(xié)作。真正的團隊精神不是所有人的名字都消失。而是每一個認真完成工作的人都不需要擔心自己被從故事里刪除。林川的重啟還在繼續(xù)。下一次他將面對一個更加熟悉的問題。一個同事把沒有完成的代碼交給他說“你技術比較好順手幫我收一下尾吧?！鄙弦皇浪疽箮蛯Ψ酵瓿闪苏麄€模塊。最后項目按時上線。對方獲得了表揚。而林川因為自己的任務延期被評價為時間管理能力不足。這一世他決定讓所有的“順手”都顯示真實價格。本篇留一句話你可以不爭功但不能讓別人通過你的沉默成為你工作成果的唯一講述者。