[請益]如何有效減少與PM對於規格認知上的差異

brucetu01/12 03:50時程就不要這麼趕啊 啊不然就換公司

brucetu01/12 03:56設計稿沒有已審核未覆核的問卷該如何顯示？那不就表示設

brucetu01/12 03:57計稿上沒有說要特別註明一個問卷是不是已審核未覆核。那

brucetu01/12 03:57就當作已完成問卷顯示啊。設計稿沒有改前端就不用改就沒

brucetu01/12 03:57有問題，設計稿要改那就是改需求就是加時間啊。後端跑分

brucetu01/12 03:57析要撈哪些問卷出來跑還不就是改幾行條件就能搞定的事情

brucetu01/12 03:57，多撈已審核未覆核的問卷出來加入要分析的資料集裡面，

brucetu01/12 03:57哪有那麼崩潰。

brucetu01/12 03:58以後就禁止使用那個沒人會看到的備註功能，不然就是你們

brucetu01/12 03:58仔細檢查看清楚，再不然就換公司

a264301/12 04:07感謝b大半夜回我，其實我省略很多細節只說明個大概，像那

a264301/12 04:07個已審核未覆核的問卷從定義上是不能算在完成的問卷的，而

a264301/12 04:07是這類的問卷被丟去分析以後他要強制被視為完成的問卷，後

a264301/12 04:07端也要暴力的更改這種問卷的狀態，導致資料會出現明明是需

a264301/12 04:07要覆核卻又沒有覆核結果卻又被算在完成的問卷

brucetu01/12 04:10照你前面的說法是已審核未覆核要丟去分析，為什麼需要改

brucetu01/12 04:10狀態變成已完成？讓他維持狀態是未完成問卷就好了

a264301/12 04:10但會出現這種資料就是一開始我們在設計後端的時候認為要覆

a264301/12 04:10核的問卷如果走到分析的話是一定會有覆核結果，沒有考慮上

a264301/12 04:10述的情況

enthos01/12 04:11(舊文)(簡體)10年5款遊戲,項目從不延期:如何做項目管理

enthos01/12 04:11https://www.gcores.com/articles/114366

enthos01/12 04:12https://www.bilibili.com/video/BV1J4411B7fz

brucetu01/12 04:13分析的程式抓所有已審核問卷出來分析，如果有覆核結果就

brucetu01/12 04:13拿覆核結果來計算，如果沒有就拿審核結果來計算，不用管

brucetu01/12 04:13他是不是已完成。聽你這樣講感覺是你們把自己綁死在一定

brucetu01/12 04:13要已完成問卷才抓出來分析

a264301/12 04:15因為針對問卷這個前端元件，已完成的話不可編輯，未完成的

a264301/12 04:15話可編輯

a264301/12 04:15而分析結果的畫面是有連結可以連到問卷去檢視當初審核結果

a264301/12 04:15或覆核結果填了些什麼，結果連過去是一個可以編輯的問卷就

a264301/12 04:15很奇怪

brucetu01/12 04:19如果按照客戶需求這個分析過的問卷還要能夠編輯，做覆核

brucetu01/12 04:19那就照做即可，就算你覺得他好像看起來很怪，反正是需求

a264301/12 04:21至於有沒有覆核結果又是另一個坑了…因為所謂的沒有覆核結

a264301/12 04:21果有可能是它其實被覆核完成了，只是被覆核人員認定這個問

a264301/12 04:21卷不適用，資料庫就會記null，如果適用就是一個分數(float

a264301/12 04:21)

a264301/12 04:21另一種情況是它還沒被覆核所以是null

brucetu01/12 04:22如果正確的需求是一旦按過分析就不可以再編輯，那就加個

brucetu01/12 04:22欄位把問卷標示成不可編輯。遇到別人搞你又要凹時程就是

brucetu01/12 04:22先硬幹能動就好了

a264301/12 04:25所以如果是覆核完成但覆核結果是null時，這時候用null當分

a264301/12 04:25析依據才是對，不能去拿審核結果

a264301/12 04:25但如果它因為是還沒被覆核所以覆核結果是null，那就要拿審

a264301/12 04:25核結果

a264301/12 04:27但我覺得b大的不要用那個沒人看得到備註是好方向

a264301/12 04:27我真沒想到一個備註會寫這麼重要的商業邏輯

brucetu01/12 04:29你說的是要判斷 ”如果問卷已完成 and 覆核結果是null，

brucetu01/12 04:29這條問卷就是不適用” 這種問卷就不要拿來分析（抓所有已

brucetu01/12 04:29審核的問卷再剔除上述條件的不適用問卷）

brucetu01/12 04:37商業邏輯沒有整段文字涵蓋完整的敘述，而是有其中一句藏

brucetu01/12 04:37在備註裡，這個操作不知道怎麼吐槽了...

a264301/12 04:38我可能描述得不太好，不適用這個名詞只是商業邏輯上的名詞

a264301/12 04:38而已，並不是說他可以從分析名單中被剔除，覆核完成後的覆

a264301/12 04:38核結果就算是null也要進去分析名單，會有分母的問題

a264301/12 04:40例如我有兩分覆核完成的問卷，一份有分數一份null，那我分

a264301/12 04:40析的樣本總數還是要算2而不是1

a264301/12 04:44這種時候就會告訴使用者總數2份有分數1份不適用1份

a264301/12 04:45那如果是因為已審核未覆核導致的覆核結果為null，這種時候

a264301/12 04:45要去拿他的審核結果，假設有兩份這種問卷且審核結果都有分

a264301/12 04:45數，那就是總數2份有分數2份不適用0份

a264301/12 04:51因為有可能會出現一份覆核完成的問卷，審核結果有分數，覆

a264301/12 04:51核結果被判定不適用所以給null的情況，這種情況要用null當

a264301/12 04:51作分析依據且總數分母+1

a264301/12 04:51如果是已審核未覆核這種狀態的問卷去分析（覆核結果一定是

a264301/12 04:51null)就要拿審核結果當分析依據且總數分母+1

brucetu01/12 04:56聽起來就是多了一堆判斷要刻但沒有到打掉重練的程度，這

brucetu01/12 04:56種狀況大概也只能你們加班努力趕。其實需求就應該完整的

brucetu01/12 04:56整段文字一次描述清楚，以後不要寫在備註加上利用資料範

brucetu01/12 04:56例確認需求吧。備註我都用來放外部資源連結而已

a264301/12 05:01確實是沒又要打掉重練，但就是多很多額外判斷，然後不知道

a264301/12 05:01有沒有地方會因為加上這些判斷再延伸出額外的bug

a264301/12 05:04但我覺得因為pm覺得這只是小事情所以寫在備註，他可能沒想

a264301/12 05:04到事情這麼大條，要讓工程回頭改一堆地方

a264301/12 05:07然後答應客戶的時程其實快到了，我們也確實都走到最後幾步

a264301/12 05:07了，現在挖出這個備註讓我們必須回頭檢查所有的地方，不知

a264301/12 05:07道要多少額外的時間成本

letmesee308501/12 06:58找一個從rd轉pm的人

taikobo01/12 07:48單從敘述看起來是PM有寫在規格裡但工程師漏看到,不過需

taikobo01/12 07:48求變更本來就不是什麼新鮮事,甚至常有一開始沒說,客戶突

taikobo01/12 07:48然說要另外加判斷的情形發生,只能靠工程師的經驗,在架構

taikobo01/12 07:48上盡量設計彈性一點...結論就是這沒有標準答案的

DrTech01/12 07:55軟體業常態，根本不用解決，而是要適應。

DrTech01/12 07:56不要當大家，SA，Scrum，DevOps玩假的，就是為了專業迅速

DrTech01/12 07:56解決這類變動。

DrTech01/12 07:58備註的文字，或需求還可能隨時變耶，怎麼都寫不清楚。

DrTech01/12 08:00千萬不要認為規格不會變，可以寫清清楚楚。小弟在軟體業工

DrTech01/12 08:00作超過20年，待過大大小小的公司，根本不可能發生。

DrTech01/12 08:03工作氣氛還比較重要。當規格寫不清楚，或有人漏看，團隊怎

DrTech01/12 08:03麼溝通的，氣氛怎麼樣，結果如何，真的比較重要。

Manusya01/12 08:54把spec看清楚是開發人員的責任，但工作合作本來就互相，

Manusya01/12 08:55所以開發者可以去訓練PM，每次發生這種事，就嚴正告知PM

Manusya01/12 08:55應提醒各種規則，好的PM應就此學習而調整溝通方式。

Manusya01/12 08:59我就是被訓練的那個，現在開發模式是，我寫完spec，會口

Manusya01/12 08:59頭跟開發人員對著文件一條一條說明，有些備註我如果偷懶

Manusya01/12 08:59沒講，開發者會主動指出，因為過完spec後，功能做不出來

Manusya01/12 08:59，就是他們的鍋了

aidansky098901/12 09:07Code的耦合性可能也要思考一下，會不會是過度耦合

aidansky098901/12 09:07導致不好改

Manusya01/12 09:10反過來說，如果事後證明是我在過spec時沒提出該需求，我

Manusya01/12 09:10會被主管罵 :-)如果PM做錯不會受到懲罰，譬如被罵、譬如

Manusya01/12 09:10開發進度延遲導致PM績效不好（因為開發者會加班趕進度）

Manusya01/12 09:10，那就無解了。

OriginStar01/12 09:17看來是原PO問題比較大，基本上原PO就是照單全收，沒有

OriginStar01/12 09:18對spec和需求提出疑問，有些是功能上的疑問，有些是商

OriginStar01/12 09:20業邏輯的疑問，有些是流程上的疑問，我想溝通是雙向的

OriginStar01/12 09:20，我想PM也會接受工程師提出的疑問吧

k79897686901/12 09:28對清楚 再修改就好 軟體就是一直改一直迭代 又不是硬

k79897686901/12 09:28體真的有出貨hard deadline

alihue01/12 09:59工程師自己去跟使用著談需求，PM 只是做專案管理與控制需

alihue01/12 09:59求範圍與衝突的角色。只是有能力這樣做的工程師很稀少且

alihue01/12 09:59早在在不錯的大公司了

BigCockman01/12 10:29自己沒看到備註跟規格有啥關係 就寫在上面了自己做錯

BigCockman01/12 10:29還覺得是PM的問題？

a264301/12 10:30感謝各位版友們回覆，先針對漏看這件事多做說明好了，其實

a264301/12 10:30我也不否認漏看工程師有一定責任，只是一開始開發會議上pm

a264301/12 10:30本來就會跟工程師對需求，規格文件只是事後拿來輔助回憶而

a264301/12 10:30已，那當初說到要把問卷丟下去分析這個瞬間其實pm也沒特別

a264301/12 10:30說有要特別的判斷某類未完成的問卷依然可以分析，我們工程

a264301/12 10:30師自然而然就一直認為要完成的問卷的才能分析，再加上設計

a264301/12 10:30稿圖面都是用這種前提下設計出來的UI，所以就一直沒人發現

wulouise01/12 10:32感覺有些東西也沒做好抽象化，全部都直接照規格寫

wulouise01/12 10:39可編輯不應該綁死特定狀態，結果分析不該綁特定欄位

a264301/12 10:41設計稿也沒有告訴工程師所謂的已審核未覆核且已分析問卷這

a264301/12 10:41種「半殘」的case顯示邏輯

a264301/12 10:49所以我會認為是對於功能上認知的差異，就開發會議上pm沒特

a264301/12 10:49別強調這裡分析的對象，設計稿也沒特別針對這種情境告知顯

a264301/12 10:49示邏輯，而是輕描淡寫的用兩小行備註藏在一個超肥大的設計

a264301/12 10:49稿的某一小處，沒注意的工程師確實有責任，但我也必須說那

a264301/12 10:49個小到沒特別提醒還真的很難注意到，我會發現純粹只是剛好

ko27tye01/12 10:51你是想解決問題還是討拍啊

OriginStar01/12 10:51簡單說就是針對無效問卷也能提供分析的功能保留彈性，

OriginStar01/12 10:52就沒有這次的問題，需求上沒講，但設計上可以保留彈性

OriginStar01/12 10:53，有沒有時間做和需不需要提供給客戶是不同層面的問題

BigCockman01/12 10:56你搞反了吧 文件才是真理 會議是輔助你了解文件或提

BigCockman01/12 10:56出建議用的

BigCockman01/12 10:57我看起來像是你自己文件沒看清楚 在開會時又不提出來

BigCockman01/12 10:57 現在怪東怪西的

a264301/12 11:06回b大，經過這次以後我確實認同你的話了，文件還是自己仔

a264301/12 11:06細看過比較安全，不要太相信pm開會時整理出來給我們的，因

a264301/12 11:06為他們整理的版本可能會漏掉他們以為不重要但其實很重要的

a264301/12 11:06東西

BigCockman01/12 11:35嗯 總之 文件有,你沒做 你肯定吵輸 文件沒有,你沒做

BigCockman01/12 11:35,pm叫你做 你吵贏的機率高多了

vi00024601/12 11:55其實結果就兩個 文件有你沒做 那就加班做

vi00024601/12 11:55文件沒有額外的需求 那就多要一些時間做

vi00024601/12 11:56做為開發 要對產品有點基本的sense 這樣spec沒寫清楚的

vi00024601/12 11:57地方才會知道有可能的問題 再去問PM補齊細節

vi00024601/12 11:58每個人心理想的跟表達出來的都不一樣 不要腦補

vi00024601/12 11:58寫不清楚就問 或是看完spec 再確認一次自己認知的流程

vi00024601/12 11:58跟 spec的流程是否一致

vi00024601/12 11:59要自己想到各種spec上沒寫到的極端use case

DrTech01/12 12:09不覺得文件是真理。花大量時間寫很標準的文件，甚至走CMMI

DrTech01/12 12:09那套，什麼ISO都上，都永遠解決不了文字與言語溝通，就是

DrTech01/12 12:09會一直有認知落差的情形。

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

DrTech01/12 12:10遇到需求認知落差時，團隊怎麼溝通達成目標，氣氛好不好，

DrTech01/12 12:10才是職場的重點。

DrTech01/12 12:12認真檢討文件，或技術耦合度，都不如解決"人"的問題。人好

DrTech01/12 12:12了，什麼事情都能解決。

DrTech01/12 12:13不然，你就算搞個很重的標準流程，產生所有可能文件，搞一

DrTech01/12 12:13堆微服務，實務上都沒用。

internetms5201/12 12:16下次畫一下event storming，檢討人沒有甚麼太大的

internetms5201/12 12:16意義

bill020501/12 13:22本來就應該對於spec抱持著懷疑還有多方思考的態度

bill020501/12 13:23PM沒寫清楚就算了 工程師不能照單全收

TAKADO01/12 13:31江湖走跳，強烈建議PG通靈術一定要點滿。

hidog01/12 18:13先寫test case,找PM討論,再開始開發

WaterLengend01/12 20:25文件就是個追憶手冊，確認的時候拿出來用的，寫不寫

WaterLengend01/12 20:25能搞砸的就是會搞砸

bnd032701/12 20:29好像也有所謂的規格描述語言，但沒用過無法評論

viper970901/12 20:31這個就是考驗PM的功力跟經驗了...

GoalBased01/12 21:37下次把文件看清楚呀，你要檢討pm請他下次把備注的字體

GoalBased01/12 21:37放大一點

lazarus112101/12 23:14每天的立會就是為了這種突然加進來的備註而存在的

lazarus112101/12 23:15時間一久連PM都會會忘記自己加了什麼 嘻嘻

lazarus112101/12 23:17不過看文章的描述PM沒啥問題吧，SA跟PG問題比較大

lazarus112101/12 23:17除非他偷改需求卻沒跟你們說

MonyemLi01/14 10:34騰訊，考慮一下薪資福利跟下班時間吧，當下環境是個重

MonyemLi01/14 10:34要的考慮要素

overhead01/14 19:39覺得只是你和PM都還不夠熟練，才會產生這種問題。下次P

overhead01/14 19:39M盡量改善文件寫法，你盡量用心看完每字每句用心推敲後

overhead01/14 19:39再做就好了。這種事情總會發生，盡量減少就是了。