最近做專案遇到常常遇到心很累的事情
就是有些很特殊需要判斷的情況
會被寫在設計稿一個感覺不是很重要的備註裡面
然後還很不顯眼，沒仔細看還不會發現
開會的時候也沒特別強調這邊要有特殊判斷
可能對於PM來說這個只是小事情，但對於工程來說是件大事
舉個例子，但詳細規格就不贅述了
最近在做一個問卷審核系統
然後有分需要"覆核"的問卷和不需要的
不需要覆核的問卷只要"審核"過了就算這個問卷完成了
後面的數據分析也是依照"審核結果"來當作依據
而需要覆核的問卷要先"審核"然後再"覆核"過了才算這個問卷完成
後面數據分析的則是由"覆核結果"當作依據(審核結果就不看了)
然後會有一個開始進行數據分析的按鈕給使用者按
讓使用者蒐集夠多的問卷以後按下去
然後我們把"完成的問卷"丟下去分析
聽起來非常合理且單純，我們前後端也就照個這個規格一直往下做問卷系統+數據分析
.....直到看到兩小行備註
「按下數據分析後，若需要覆核的問卷沒有完成覆核但已經完成審核
依然可以分析，但就是用"審核結果"當作分析依據」
這兩行被挖出來之後，前端(我)後端瞬間炸裂
因為問卷完成這件事再也不是可以進行數據分析的唯一指標
還要考慮它是否為一份需要覆核但沒被覆核完成但已經審核完成的問卷
現在要回頭補這段邏輯前後端都非常的麻煩
而且可能還會有沒注意到的漏洞
加上這個案子時程又趕，現在挖出這個東西所有人都不知道怎麼辦才好
如果一開始就有特別提醒我們有這種商業邏輯
也許還能想想有什麼辦法滿足客戶需求
到了現在這個階段基本上是沒救了
但如果我們希望能針對這件事情的發生做檢討
避免下次再出現類似情況的話
我也不知道有什麼好建議可以提出
我似乎能理解站在PM角度好像不會覺得這種可以妥協進行數據分析的需求是很難的事
但對於工程來說就完全不是這麼一回事
狀態的驗證、UI顯示邏輯等等都因為放行了"沒有完成卻又可以分析"的問卷要調整
然後設計稿也沒有針對這種狀態的問卷告訴我顯示邏輯
所以我們才會從頭到尾都以為要完成問卷才能數據分析
請各位前輩指點迷津....謝謝

時程就不要這麼趕啊 啊不然就換公司設計稿沒有已審核未覆核的問卷該如何顯示？那不就表示設計稿上沒有說要特別註明一個問卷是不是已審核未覆核。那就當作已完成問卷顯示啊。設計稿沒有改前端就不用改就沒有問題，設計稿要改那就是改需求就是加時間啊。後端跑分析要撈哪些問卷出來跑還不就是改幾行條件就能搞定的事情，多撈已審核未覆核的問卷出來加入要分析的資料集裡面，哪有那麼崩潰。以後就禁止使用那個沒人會看到的備註功能，不然就是你們仔細檢查看清楚，再不然就換公司

感謝b大半夜回我，其實我省略很多細節只說明個大概，像那個已審核未覆核的問卷從定義上是不能算在完成的問卷的，而是這類的問卷被丟去分析以後他要強制被視為完成的問卷，後端也要暴力的更改這種問卷的狀態，導致資料會出現明明是需要覆核卻又沒有覆核結果卻又被算在完成的問卷

照你前面的說法是已審核未覆核要丟去分析，為什麼需要改狀態變成已完成？讓他維持狀態是未完成問卷就好了

但會出現這種資料就是一開始我們在設計後端的時候認為要覆核的問卷如果走到分析的話是一定會有覆核結果，沒有考慮上述的情況

(舊文)(簡體)10年5款遊戲,項目從不延期:如何做項目管理https://www.gcores.com/articles/114366https://www.bilibili.com/video/BV1J4411B7fz

分析的程式抓所有已審核問卷出來分析，如果有覆核結果就拿覆核結果來計算，如果沒有就拿審核結果來計算，不用管他是不是已完成。聽你這樣講感覺是你們把自己綁死在一定要已完成問卷才抓出來分析

因為針對問卷這個前端元件，已完成的話不可編輯，未完成的話可編輯而分析結果的畫面是有連結可以連到問卷去檢視當初審核結果或覆核結果填了些什麼，結果連過去是一個可以編輯的問卷就很奇怪

如果按照客戶需求這個分析過的問卷還要能夠編輯，做覆核那就照做即可，就算你覺得他好像看起來很怪，反正是需求

至於有沒有覆核結果又是另一個坑了…因為所謂的沒有覆核結果有可能是它其實被覆核完成了，只是被覆核人員認定這個問卷不適用，資料庫就會記null，如果適用就是一個分數(float)另一種情況是它還沒被覆核所以是null

如果正確的需求是一旦按過分析就不可以再編輯，那就加個欄位把問卷標示成不可編輯。遇到別人搞你又要凹時程就是先硬幹能動就好了

所以如果是覆核完成但覆核結果是null時，這時候用null當分析依據才是對，不能去拿審核結果但如果它因為是還沒被覆核所以覆核結果是null，那就要拿審核結果但我覺得b大的不要用那個沒人看得到備註是好方向我真沒想到一個備註會寫這麼重要的商業邏輯

你說的是要判斷 ”如果問卷已完成 and 覆核結果是null，這條問卷就是不適用” 這種問卷就不要拿來分析（抓所有已審核的問卷再剔除上述條件的不適用問卷）商業邏輯沒有整段文字涵蓋完整的敘述，而是有其中一句藏在備註裡，這個操作不知道怎麼吐槽了...

我可能描述得不太好，不適用這個名詞只是商業邏輯上的名詞而已，並不是說他可以從分析名單中被剔除，覆核完成後的覆核結果就算是null也要進去分析名單，會有分母的問題例如我有兩分覆核完成的問卷，一份有分數一份null，那我分析的樣本總數還是要算2而不是1這種時候就會告訴使用者總數2份有分數1份不適用1份那如果是因為已審核未覆核導致的覆核結果為null，這種時候要去拿他的審核結果，假設有兩份這種問卷且審核結果都有分數，那就是總數2份有分數2份不適用0份因為有可能會出現一份覆核完成的問卷，審核結果有分數，覆核結果被判定不適用所以給null的情況，這種情況要用null當作分析依據且總數分母+1如果是已審核未覆核這種狀態的問卷去分析（覆核結果一定是null)就要拿審核結果當分析依據且總數分母+1

聽起來就是多了一堆判斷要刻但沒有到打掉重練的程度，這種狀況大概也只能你們加班努力趕。其實需求就應該完整的整段文字一次描述清楚，以後不要寫在備註加上利用資料範例確認需求吧。備註我都用來放外部資源連結而已

確實是沒又要打掉重練，但就是多很多額外判斷，然後不知道有沒有地方會因為加上這些判斷再延伸出額外的bug但我覺得因為pm覺得這只是小事情所以寫在備註，他可能沒想到事情這麼大條，要讓工程回頭改一堆地方然後答應客戶的時程其實快到了，我們也確實都走到最後幾步了，現在挖出這個備註讓我們必須回頭檢查所有的地方，不知道要多少額外的時間成本

找一個從rd轉pm的人

單從敘述看起來是PM有寫在規格裡但工程師漏看到,不過需求變更本來就不是什麼新鮮事,甚至常有一開始沒說,客戶突然說要另外加判斷的情形發生,只能靠工程師的經驗,在架構上盡量設計彈性一點...結論就是這沒有標準答案的

軟體業常態，根本不用解決，而是要適應。不要當大家，SA，Scrum，DevOps玩假的，就是為了專業迅速解決這類變動。備註的文字，或需求還可能隨時變耶，怎麼都寫不清楚。千萬不要認為規格不會變，可以寫清清楚楚。小弟在軟體業工作超過20年，待過大大小小的公司，根本不可能發生。工作氣氛還比較重要。當規格寫不清楚，或有人漏看，團隊怎麼溝通的，氣氛怎麼樣，結果如何，真的比較重要。

把spec看清楚是開發人員的責任，但工作合作本來就互相，所以開發者可以去訓練PM，每次發生這種事，就嚴正告知PM應提醒各種規則，好的PM應就此學習而調整溝通方式。我就是被訓練的那個，現在開發模式是，我寫完spec，會口頭跟開發人員對著文件一條一條說明，有些備註我如果偷懶沒講，開發者會主動指出，因為過完spec後，功能做不出來，就是他們的鍋了

Code的耦合性可能也要思考一下，會不會是過度耦合導致不好改

反過來說，如果事後證明是我在過spec時沒提出該需求，我會被主管罵 :-)如果PM做錯不會受到懲罰，譬如被罵、譬如開發進度延遲導致PM績效不好（因為開發者會加班趕進度），那就無解了。

看來是原PO問題比較大，基本上原PO就是照單全收，沒有對spec和需求提出疑問，有些是功能上的疑問，有些是商業邏輯的疑問，有些是流程上的疑問，我想溝通是雙向的，我想PM也會接受工程師提出的疑問吧

對清楚 再修改就好 軟體就是一直改一直迭代 又不是硬體真的有出貨hard deadline

工程師自己去跟使用著談需求，PM 只是做專案管理與控制需求範圍與衝突的角色。只是有能力這樣做的工程師很稀少且早在在不錯的大公司了

自己沒看到備註跟規格有啥關係 就寫在上面了自己做錯還覺得是PM的問題？

感謝各位版友們回覆，先針對漏看這件事多做說明好了，其實我也不否認漏看工程師有一定責任，只是一開始開發會議上pm本來就會跟工程師對需求，規格文件只是事後拿來輔助回憶而已，那當初說到要把問卷丟下去分析這個瞬間其實pm也沒特別說有要特別的判斷某類未完成的問卷依然可以分析，我們工程師自然而然就一直認為要完成的問卷的才能分析，再加上設計稿圖面都是用這種前提下設計出來的UI，所以就一直沒人發現

感覺有些東西也沒做好抽象化，全部都直接照規格寫可編輯不應該綁死特定狀態，結果分析不該綁特定欄位

設計稿也沒有告訴工程師所謂的已審核未覆核且已分析問卷這種「半殘」的case顯示邏輯所以我會認為是對於功能上認知的差異，就開發會議上pm沒特別強調這裡分析的對象，設計稿也沒特別針對這種情境告知顯示邏輯，而是輕描淡寫的用兩小行備註藏在一個超肥大的設計稿的某一小處，沒注意的工程師確實有責任，但我也必須說那個小到沒特別提醒還真的很難注意到，我會發現純粹只是剛好

你是想解決問題還是討拍啊

簡單說就是針對無效問卷也能提供分析的功能保留彈性，就沒有這次的問題，需求上沒講，但設計上可以保留彈性，有沒有時間做和需不需要提供給客戶是不同層面的問題

你搞反了吧 文件才是真理 會議是輔助你了解文件或提出建議用的我看起來像是你自己文件沒看清楚 在開會時又不提出來現在怪東怪西的

回b大，經過這次以後我確實認同你的話了，文件還是自己仔細看過比較安全，不要太相信pm開會時整理出來給我們的，因為他們整理的版本可能會漏掉他們以為不重要但其實很重要的東西

嗯 總之 文件有,你沒做 你肯定吵輸 文件沒有,你沒做,pm叫你做 你吵贏的機率高多了

其實結果就兩個 文件有你沒做 那就加班做文件沒有額外的需求 那就多要一些時間做做為開發 要對產品有點基本的sense 這樣spec沒寫清楚的地方才會知道有可能的問題 再去問PM補齊細節每個人心理想的跟表達出來的都不一樣 不要腦補寫不清楚就問 或是看完spec 再確認一次自己認知的流程跟 spec的流程是否一致要自己想到各種spec上沒寫到的極端use case

不覺得文件是真理。花大量時間寫很標準的文件，甚至走CMMI那套，什麼ISO都上，都永遠解決不了文字與言語溝通，就是會一直有認知落差的情形。

恩認同可能是耦合度太高，不然就只是多個流程判斷而已

遇到需求認知落差時，團隊怎麼溝通達成目標，氣氛好不好，才是職場的重點。認真檢討文件，或技術耦合度，都不如解決"人"的問題。人好了，什麼事情都能解決。不然，你就算搞個很重的標準流程，產生所有可能文件，搞一堆微服務，實務上都沒用。

下次畫一下event storming，檢討人沒有甚麼太大的意義

本來就應該對於spec抱持著懷疑還有多方思考的態度PM沒寫清楚就算了 工程師不能照單全收

江湖走跳，強烈建議PG通靈術一定要點滿。

先寫test case,找PM討論,再開始開發

文件就是個追憶手冊，確認的時候拿出來用的，寫不寫能搞砸的就是會搞砸

好像也有所謂的規格描述語言，但沒用過無法評論

這個就是考驗PM的功力跟經驗了...

下次把文件看清楚呀，你要檢討pm請他下次把備注的字體放大一點

每天的立會就是為了這種突然加進來的備註而存在的時間一久連PM都會會忘記自己加了什麼 嘻嘻不過看文章的描述PM沒啥問題吧，SA跟PG問題比較大除非他偷改需求卻沒跟你們說

騰訊，考慮一下薪資福利跟下班時間吧，當下環境是個重要的考慮要素

覺得只是你和PM都還不夠熟練，才會產生這種問題。下次PM盡量改善文件寫法，你盡量用心看完每字每句用心推敲後再做就好了。這種事情總會發生，盡量減少就是了。