第一宗：需求不明確之罪

癥狀： 客戶只有一個模糊的想法，比如“做個像淘寶但比它好的App”。

產品經理與客戶的對話：

客戶：“我要一個按鈕，點了之后用戶會很開心。”

開發(fā)：“‘很開心’具體指什么？彈個動畫？發(fā)個優(yōu)惠券？”

客戶：“就是那種……感覺！你們是專業(yè)的，你們來定義。”

開發(fā)：（內心OS：我又不是用戶肚子里的蛔蟲?。?/p>

最終，開發(fā)團隊基于猜測做了一個“五彩斑斕的黑”的按鈕，點擊后播放一段掌聲。上線后用戶反饋：“這App有毛病吧？”

第二宗：過度承諾之罪

癥狀： 銷售為了簽單，把月亮都許諾給了客戶。

銷售：“沒問題！AI自動生成代碼、區(qū)塊鏈存證、元宇宙展示廳，三周內全部搞定！”

開發(fā)團隊拿到合同后，技術總監(jiān)當場表演了一個“笑容逐漸消失”的表情包。

最終，團隊用“人工智障”模擬AI（后臺其實是實習生手動操作），用截圖假裝區(qū)塊鏈，用360度全景圖冒充元宇宙，上演了一場大型科技魔術。

第三宗：會議馬拉松之罪

癥狀： 試圖用開會來解決“如何減少開會時間”的問題。

一天安排8個會，每個會1小時。開發(fā)人員只能在會議的間隙里，抽空寫代碼。

最經典的會議是“需求評審會”，變成了“產品經理的辯護會”和“程序員的批斗會”。

一個功能開發(fā)只需2小時，但為了討論這個功能的按鈕顏色、圓角弧度，開了3次會，總計5小時。

第四宗：薛定諤的截止日期

癥狀： 項目截止日期既確定又不確定，完全取決于老板/客戶何時詢問。

周一老板問：“這個功能周五能上線嗎？” 項目經理拍胸脯：“沒問題！”

周二，客戶要求加個新功能，項目經理依然：“沒問題！”

到了周五，老板和客戶同時來問，項目經理只能祭出終極法寶：“在測試了，在測試了。”（其實開發(fā)剛搞定一半）

第五宗：測試，永遠的背鍋俠

癥狀： “在我的電腦上是好的！”

測試人員被迫練就“十八般武藝”，包括但不限于：用腳操作手機、同時點擊屏幕上十個按鈕、在電梯里和地下車庫進行網絡測試。

第六宗：技術債高利貸

癥狀： 為了趕工期，代碼寫得像一坨意大利面，還安慰自己“以后會重構的”。

新來的程序員看前輩代碼，仿佛在看天書，注釋寫著：“此處有魔法，勿動！”

修改一個簡單的字體顏色，導致整個頁面布局崩潰，因為CSS選擇器像蜘蛛網一樣相互纏繞。

每次迭代都像是在已經搖搖欲墜的紙牌屋上再疊一層，全團隊進入“祈禱模式”，祈求它不要塌。

第七宗：謎之溝通

癥狀： 各個部門說著不同的語言。

產品經理說：“這個流程要絲滑。” 開發(fā)理解為：多加幾個加載動畫。

運營說：“我們要搞個裂變活動！” 技術理解為：在分享按鈕上加個“裂開”的動畫效果。

第八宗：盲目追新綜合癥

癥狀： 為了技術而技術，不管項目實際需要。

結果，一個只有100個用戶訪問的內部管理系統(tǒng)，被拆分成20個微服務，部署和維護成本是原來的10倍。

為了用一款號稱能“提升效率50%”的新框架，全團隊花了兩個月學習，結果發(fā)現生產力下降了80%。

第九宗：深夜上線，黎明前的黑暗

癥狀： 堅信半夜上線對用戶影響最小。

5分鐘后，監(jiān)控報警響徹辦公室，網站500錯誤。

所有人睡眼惺忪地開始“救火”，一邊查日志一邊懷疑人生。天亮了，Bug修好了，大家頂著黑眼圈看著日出，相視無言，唯有淚千行。