※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1673465331.A.707.html
→ brucetu: 時程就不要這麼趕啊 啊不然就換公司 01/12 03:50
→ brucetu: 設計稿沒有已審核未覆核的問卷該如何顯示？那不就表示設 01/12 03:56
→ brucetu: 計稿上沒有說要特別註明一個問卷是不是已審核未覆核。那 01/12 03:57
→ brucetu: 就當作已完成問卷顯示啊。設計稿沒有改前端就不用改就沒 01/12 03:57
→ brucetu: 有問題，設計稿要改那就是改需求就是加時間啊。後端跑分 01/12 03:57
→ brucetu: 析要撈哪些問卷出來跑還不就是改幾行條件就能搞定的事情 01/12 03:57
→ brucetu: ，多撈已審核未覆核的問卷出來加入要分析的資料集裡面， 01/12 03:57
→ brucetu: 哪有那麼崩潰。 01/12 03:57
→ brucetu: 以後就禁止使用那個沒人會看到的備註功能，不然就是你們 01/12 03:58
→ brucetu: 仔細檢查看清楚，再不然就換公司 01/12 03:58
→ a2643: 感謝b大半夜回我，其實我省略很多細節只說明個大概，像那 01/12 04:07
→ a2643: 個已審核未覆核的問卷從定義上是不能算在完成的問卷的，而 01/12 04:07
→ a2643: 是這類的問卷被丟去分析以後他要強制被視為完成的問卷，後 01/12 04:07
→ a2643: 端也要暴力的更改這種問卷的狀態，導致資料會出現明明是需 01/12 04:07
→ a2643: 要覆核卻又沒有覆核結果卻又被算在完成的問卷 01/12 04:07
→ brucetu: 照你前面的說法是已審核未覆核要丟去分析，為什麼需要改 01/12 04:10
→ brucetu: 狀態變成已完成？讓他維持狀態是未完成問卷就好了 01/12 04:10
→ a2643: 但會出現這種資料就是一開始我們在設計後端的時候認為要覆 01/12 04:10
→ a2643: 核的問卷如果走到分析的話是一定會有覆核結果，沒有考慮上 01/12 04:10
→ a2643: 述的情況 01/12 04:10
推 enthos: (舊文)(簡體)10年5款遊戲,項目從不延期:如何做項目管理 01/12 04:11
→ enthos: https://www.gcores.com/articles/114366 01/12 04:11
→ enthos: https://www.bilibili.com/video/BV1J4411B7fz 01/12 04:12
→ brucetu: 分析的程式抓所有已審核問卷出來分析，如果有覆核結果就 01/12 04:13
→ brucetu: 拿覆核結果來計算，如果沒有就拿審核結果來計算，不用管 01/12 04:13
→ brucetu: 他是不是已完成。聽你這樣講感覺是你們把自己綁死在一定 01/12 04:13
→ brucetu: 要已完成問卷才抓出來分析 01/12 04:13
→ a2643: 因為針對問卷這個前端元件，已完成的話不可編輯，未完成的 01/12 04:15
→ a2643: 話可編輯 01/12 04:15
→ a2643: 而分析結果的畫面是有連結可以連到問卷去檢視當初審核結果 01/12 04:15
→ a2643: 或覆核結果填了些什麼，結果連過去是一個可以編輯的問卷就 01/12 04:15
→ a2643: 很奇怪 01/12 04:15
→ brucetu: 如果按照客戶需求這個分析過的問卷還要能夠編輯，做覆核 01/12 04:19
→ brucetu: 那就照做即可，就算你覺得他好像看起來很怪，反正是需求 01/12 04:19
→ a2643: 至於有沒有覆核結果又是另一個坑了…因為所謂的沒有覆核結 01/12 04:21
→ a2643: 果有可能是它其實被覆核完成了，只是被覆核人員認定這個問 01/12 04:21
→ a2643: 卷不適用，資料庫就會記null，如果適用就是一個分數(float 01/12 04:21
→ a2643: ) 01/12 04:21
→ a2643: 另一種情況是它還沒被覆核所以是null 01/12 04:21
→ brucetu: 如果正確的需求是一旦按過分析就不可以再編輯，那就加個 01/12 04:22
→ brucetu: 欄位把問卷標示成不可編輯。遇到別人搞你又要凹時程就是 01/12 04:22
→ brucetu: 先硬幹能動就好了 01/12 04:22
→ a2643: 所以如果是覆核完成但覆核結果是null時，這時候用null當分 01/12 04:25
→ a2643: 析依據才是對，不能去拿審核結果 01/12 04:25
→ a2643: 但如果它因為是還沒被覆核所以覆核結果是null，那就要拿審 01/12 04:25
→ a2643: 核結果 01/12 04:25
→ a2643: 但我覺得b大的不要用那個沒人看得到備註是好方向 01/12 04:27
→ a2643: 我真沒想到一個備註會寫這麼重要的商業邏輯 01/12 04:27
推 brucetu: 你說的是要判斷 ”如果問卷已完成 and 覆核結果是null， 01/12 04:29
→ brucetu: 這條問卷就是不適用” 這種問卷就不要拿來分析（抓所有已 01/12 04:29
→ brucetu: 審核的問卷再剔除上述條件的不適用問卷） 01/12 04:29
→ brucetu: 商業邏輯沒有整段文字涵蓋完整的敘述，而是有其中一句藏 01/12 04:37
→ brucetu: 在備註裡，這個操作不知道怎麼吐槽了... 01/12 04:37
→ a2643: 我可能描述得不太好，不適用這個名詞只是商業邏輯上的名詞 01/12 04:38
→ a2643: 而已，並不是說他可以從分析名單中被剔除，覆核完成後的覆 01/12 04:38
→ a2643: 核結果就算是null也要進去分析名單，會有分母的問題 01/12 04:38
→ a2643: 例如我有兩分覆核完成的問卷，一份有分數一份null，那我分 01/12 04:40
→ a2643: 析的樣本總數還是要算2而不是1 01/12 04:40
→ a2643: 這種時候就會告訴使用者總數2份有分數1份不適用1份 01/12 04:44
→ a2643: 那如果是因為已審核未覆核導致的覆核結果為null，這種時候 01/12 04:45
→ a2643: 要去拿他的審核結果，假設有兩份這種問卷且審核結果都有分 01/12 04:45
→ a2643: 數，那就是總數2份有分數2份不適用0份 01/12 04:45
→ a2643: 因為有可能會出現一份覆核完成的問卷，審核結果有分數，覆 01/12 04:51
→ a2643: 核結果被判定不適用所以給null的情況，這種情況要用null當 01/12 04:51
→ a2643: 作分析依據且總數分母+1 01/12 04:51
→ a2643: 如果是已審核未覆核這種狀態的問卷去分析（覆核結果一定是 01/12 04:51
→ a2643: null)就要拿審核結果當分析依據且總數分母+1 01/12 04:51
→ brucetu: 聽起來就是多了一堆判斷要刻但沒有到打掉重練的程度，這 01/12 04:56
→ brucetu: 種狀況大概也只能你們加班努力趕。其實需求就應該完整的 01/12 04:56
→ brucetu: 整段文字一次描述清楚，以後不要寫在備註加上利用資料範 01/12 04:56
→ brucetu: 例確認需求吧。備註我都用來放外部資源連結而已 01/12 04:56
→ a2643: 確實是沒又要打掉重練，但就是多很多額外判斷，然後不知道 01/12 05:01
→ a2643: 有沒有地方會因為加上這些判斷再延伸出額外的bug 01/12 05:01
→ a2643: 但我覺得因為pm覺得這只是小事情所以寫在備註，他可能沒想 01/12 05:04
→ a2643: 到事情這麼大條，要讓工程回頭改一堆地方 01/12 05:04
→ a2643: 然後答應客戶的時程其實快到了，我們也確實都走到最後幾步 01/12 05:07
→ a2643: 了，現在挖出這個備註讓我們必須回頭檢查所有的地方，不知 01/12 05:07
→ a2643: 道要多少額外的時間成本 01/12 05:07
→ letmesee3085: 找一個從rd轉pm的人 01/12 06:58
→ taikobo: 單從敘述看起來是PM有寫在規格裡但工程師漏看到,不過需 01/12 07:48
→ taikobo: 求變更本來就不是什麼新鮮事,甚至常有一開始沒說,客戶突 01/12 07:48
→ taikobo: 然說要另外加判斷的情形發生,只能靠工程師的經驗,在架構 01/12 07:48
→ taikobo: 上盡量設計彈性一點...結論就是這沒有標準答案的 01/12 07:48
→ DrTech: 軟體業常態，根本不用解決，而是要適應。 01/12 07:55
→ DrTech: 不要當大家，SA，Scrum，DevOps玩假的，就是為了專業迅速 01/12 07:56
→ DrTech: 解決這類變動。 01/12 07:56
→ DrTech: 備註的文字，或需求還可能隨時變耶，怎麼都寫不清楚。 01/12 07:58
→ DrTech: 千萬不要認為規格不會變，可以寫清清楚楚。小弟在軟體業工 01/12 08:00
→ DrTech: 作超過20年，待過大大小小的公司，根本不可能發生。 01/12 08:00
推 DrTech: 工作氣氛還比較重要。當規格寫不清楚，或有人漏看，團隊怎 01/12 08:03
→ DrTech: 麼溝通的，氣氛怎麼樣，結果如何，真的比較重要。 01/12 08:03
推 Manusya: 把spec看清楚是開發人員的責任，但工作合作本來就互相， 01/12 08:54
→ Manusya: 所以開發者可以去訓練PM，每次發生這種事，就嚴正告知PM 01/12 08:55
→ Manusya: 應提醒各種規則，好的PM應就此學習而調整溝通方式。 01/12 08:55
→ Manusya: 我就是被訓練的那個，現在開發模式是，我寫完spec，會口 01/12 08:59
→ Manusya: 頭跟開發人員對著文件一條一條說明，有些備註我如果偷懶 01/12 08:59
→ Manusya: 沒講，開發者會主動指出，因為過完spec後，功能做不出來 01/12 08:59
→ Manusya: ，就是他們的鍋了 01/12 08:59
推 aidansky0989: Code的耦合性可能也要思考一下，會不會是過度耦合 01/12 09:07
→ aidansky0989: 導致不好改 01/12 09:07
推 Manusya: 反過來說，如果事後證明是我在過spec時沒提出該需求，我 01/12 09:10
→ Manusya: 會被主管罵 :-)如果PM做錯不會受到懲罰，譬如被罵、譬如 01/12 09:10
→ Manusya: 開發進度延遲導致PM績效不好（因為開發者會加班趕進度） 01/12 09:10
→ Manusya: ，那就無解了。 01/12 09:10
推 OriginStar: 看來是原PO問題比較大，基本上原PO就是照單全收，沒有 01/12 09:17
→ OriginStar: 對spec和需求提出疑問，有些是功能上的疑問，有些是商 01/12 09:18
→ OriginStar: 業邏輯的疑問，有些是流程上的疑問，我想溝通是雙向的 01/12 09:20
→ OriginStar: ，我想PM也會接受工程師提出的疑問吧 01/12 09:20
推 k798976869: 對清楚 再修改就好 軟體就是一直改一直迭代 又不是硬 01/12 09:28
→ k798976869: 體真的有出貨hard deadline 01/12 09:28
推 alihue: 工程師自己去跟使用著談需求，PM 只是做專案管理與控制需 01/12 09:59
→ alihue: 求範圍與衝突的角色。只是有能力這樣做的工程師很稀少且 01/12 09:59
→ alihue: 早在在不錯的大公司了 01/12 09:59
噓 BigCockman: 自己沒看到備註跟規格有啥關係 就寫在上面了自己做錯 01/12 10:29
→ BigCockman: 還覺得是PM的問題？ 01/12 10:29
→ a2643: 感謝各位版友們回覆，先針對漏看這件事多做說明好了，其實 01/12 10:30
→ a2643: 我也不否認漏看工程師有一定責任，只是一開始開發會議上pm 01/12 10:30
→ a2643: 本來就會跟工程師對需求，規格文件只是事後拿來輔助回憶而 01/12 10:30
→ a2643: 已，那當初說到要把問卷丟下去分析這個瞬間其實pm也沒特別 01/12 10:30
→ a2643: 說有要特別的判斷某類未完成的問卷依然可以分析，我們工程 01/12 10:30
→ a2643: 師自然而然就一直認為要完成的問卷的才能分析，再加上設計 01/12 10:30
→ a2643: 稿圖面都是用這種前提下設計出來的UI，所以就一直沒人發現 01/12 10:30
推 wulouise: 感覺有些東西也沒做好抽象化，全部都直接照規格寫 01/12 10:32
推 wulouise: 可編輯不應該綁死特定狀態，結果分析不該綁特定欄位 01/12 10:39
→ a2643: 設計稿也沒有告訴工程師所謂的已審核未覆核且已分析問卷這 01/12 10:41
→ a2643: 種「半殘」的case顯示邏輯 01/12 10:41
→ a2643: 所以我會認為是對於功能上認知的差異，就開發會議上pm沒特 01/12 10:49
→ a2643: 別強調這裡分析的對象，設計稿也沒特別針對這種情境告知顯 01/12 10:49
→ a2643: 示邏輯，而是輕描淡寫的用兩小行備註藏在一個超肥大的設計 01/12 10:49
→ a2643: 稿的某一小處，沒注意的工程師確實有責任，但我也必須說那 01/12 10:49
→ a2643: 個小到沒特別提醒還真的很難注意到，我會發現純粹只是剛好 01/12 10:49
噓 ko27tye: 你是想解決問題還是討拍啊 01/12 10:51
→ OriginStar: 簡單說就是針對無效問卷也能提供分析的功能保留彈性， 01/12 10:51
→ OriginStar: 就沒有這次的問題，需求上沒講，但設計上可以保留彈性 01/12 10:52
→ OriginStar: ，有沒有時間做和需不需要提供給客戶是不同層面的問題 01/12 10:53
噓 BigCockman: 你搞反了吧 文件才是真理 會議是輔助你了解文件或提 01/12 10:56
→ BigCockman: 出建議用的 01/12 10:56
→ BigCockman: 我看起來像是你自己文件沒看清楚 在開會時又不提出來 01/12 10:57
→ BigCockman: 現在怪東怪西的 01/12 10:57
→ a2643: 回b大，經過這次以後我確實認同你的話了，文件還是自己仔 01/12 11:06
→ a2643: 細看過比較安全，不要太相信pm開會時整理出來給我們的，因 01/12 11:06
→ a2643: 為他們整理的版本可能會漏掉他們以為不重要但其實很重要的 01/12 11:06
→ a2643: 東西 01/12 11:06
推 BigCockman: 嗯 總之 文件有,你沒做 你肯定吵輸 文件沒有,你沒做 01/12 11:35
→ BigCockman: ,pm叫你做 你吵贏的機率高多了 01/12 11:35
推 vi000246: 其實結果就兩個 文件有你沒做 那就加班做 01/12 11:55
→ vi000246: 文件沒有額外的需求 那就多要一些時間做 01/12 11:55
→ vi000246: 做為開發 要對產品有點基本的sense 這樣spec沒寫清楚的 01/12 11:56
→ vi000246: 地方才會知道有可能的問題 再去問PM補齊細節 01/12 11:57
→ vi000246: 每個人心理想的跟表達出來的都不一樣 不要腦補 01/12 11:58
→ vi000246: 寫不清楚就問 或是看完spec 再確認一次自己認知的流程 01/12 11:58
→ vi000246: 跟 spec的流程是否一致 01/12 11:58
→ vi000246: 要自己想到各種spec上沒寫到的極端use case 01/12 11:59
→ DrTech: 不覺得文件是真理。花大量時間寫很標準的文件，甚至走CMMI 01/12 12:09
→ DrTech: 那套，什麼ISO都上，都永遠解決不了文字與言語溝通，就是 01/12 12:09
→ DrTech: 會一直有認知落差的情形。 01/12 12:09
推 neo5277: 恩認同可能是耦合度太高，不然就只是多個流程判斷而已 01/12 12:10
→ DrTech: 遇到需求認知落差時，團隊怎麼溝通達成目標，氣氛好不好， 01/12 12:10
→ DrTech: 才是職場的重點。 01/12 12:10
→ DrTech: 認真檢討文件，或技術耦合度，都不如解決"人"的問題。人好 01/12 12:12
→ DrTech: 了，什麼事情都能解決。 01/12 12:12
→ DrTech: 不然，你就算搞個很重的標準流程，產生所有可能文件，搞一 01/12 12:13
→ DrTech: 堆微服務，實務上都沒用。 01/12 12:13
推 internetms52: 下次畫一下event storming，檢討人沒有甚麼太大的 01/12 12:16
→ internetms52: 意義 01/12 12:16
推 bill0205: 本來就應該對於spec抱持著懷疑還有多方思考的態度 01/12 13:22
→ bill0205: PM沒寫清楚就算了 工程師不能照單全收 01/12 13:23
推 TAKADO: 江湖走跳，強烈建議PG通靈術一定要點滿。 01/12 13:31
推 hidog: 先寫test case,找PM討論,再開始開發 01/12 18:13
推 WaterLengend: 文件就是個追憶手冊，確認的時候拿出來用的，寫不寫 01/12 20:25
→ WaterLengend: 能搞砸的就是會搞砸 01/12 20:25
推 bnd0327: 好像也有所謂的規格描述語言，但沒用過無法評論 01/12 20:29
推 viper9709: 這個就是考驗PM的功力跟經驗了... 01/12 20:31
推 GoalBased: 下次把文件看清楚呀，你要檢討pm請他下次把備注的字體 01/12 21:37
→ GoalBased: 放大一點 01/12 21:37
→ lazarus1121: 每天的立會就是為了這種突然加進來的備註而存在的 01/12 23:14
→ lazarus1121: 時間一久連PM都會會忘記自己加了什麼 嘻嘻 01/12 23:15
→ lazarus1121: 不過看文章的描述PM沒啥問題吧，SA跟PG問題比較大 01/12 23:17
→ lazarus1121: 除非他偷改需求卻沒跟你們說 01/12 23:17
→ MonyemLi: 騰訊，考慮一下薪資福利跟下班時間吧，當下環境是個重 01/14 10:34
→ MonyemLi: 要的考慮要素 01/14 10:34
推 overhead: 覺得只是你和PM都還不夠熟練，才會產生這種問題。下次P 01/14 19:39
→ overhead: M盡量改善文件寫法，你盡量用心看完每字每句用心推敲後 01/14 19:39
→ overhead: 再做就好了。這種事情總會發生，盡量減少就是了。 01/14 19:39