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

看板Soft_Job作者 (GodCK)時間1年前 (2023/01/12 03:28), 編輯推噓20(23推 3噓 158→)
留言184則, 27人參與, 1年前最新討論串1/3 (看更多)
最近做專案遇到常常遇到心很累的事情 就是有些很特殊需要判斷的情況 會被寫在設計稿一個感覺不是很重要的備註裡面 然後還很不顯眼，沒仔細看還不會發現 開會的時候也沒特別強調這邊要有特殊判斷 可能對於PM來說這個只是小事情，但對於工程來說是件大事 舉個例子，但詳細規格就不贅述了 最近在做一個問卷審核系統 然後有分需要"覆核"的問卷和不需要的 不需要覆核的問卷只要"審核"過了就算這個問卷完成了 後面的數據分析也是依照"審核結果"來當作依據 而需要覆核的問卷要先"審核"然後再"覆核"過了才算這個問卷完成 後面數據分析的則是由"覆核結果"當作依據(審核結果就不看了) 然後會有一個開始進行數據分析的按鈕給使用者按 讓使用者蒐集夠多的問卷以後按下去 然後我們把"完成的問卷"丟下去分析 聽起來非常合理且單純，我們前後端也就照個這個規格一直往下做問卷系統+數據分析 .....直到看到兩小行備註 「按下數據分析後，若需要覆核的問卷沒有完成覆核但已經完成審核 依然可以分析，但就是用"審核結果"當作分析依據」 這兩行被挖出來之後，前端(我)後端瞬間炸裂 因為問卷完成這件事再也不是可以進行數據分析的唯一指標 還要考慮它是否為一份需要覆核但沒被覆核完成但已經審核完成的問卷 現在要回頭補這段邏輯前後端都非常的麻煩 而且可能還會有沒注意到的漏洞 加上這個案子時程又趕，現在挖出這個東西所有人都不知道怎麼辦才好 如果一開始就有特別提醒我們有這種商業邏輯 也許還能想想有什麼辦法滿足客戶需求 到了現在這個階段基本上是沒救了 但如果我們希望能針對這件事情的發生做檢討 避免下次再出現類似情況的話 我也不知道有什麼好建議可以提出 我似乎能理解站在PM角度好像不會覺得這種可以妥協進行數據分析的需求是很難的事 但對於工程來說就完全不是這麼一回事 狀態的驗證、UI顯示邏輯等等都因為放行了"沒有完成卻又可以分析"的問卷要調整 然後設計稿也沒有針對這種狀態的問卷告訴我顯示邏輯 所以我們才會從頭到尾都以為要完成問卷才能數據分析 請各位前輩指點迷津....謝謝 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 112.104.141.64 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1673465331.A.707.html
→
01/12 03:50, 1年前 , 1F
時程就不要這麼趕啊 啊不然就換公司
01/12 03:50, 1F
→
01/12 03:56, 1年前 , 2F
設計稿沒有已審核未覆核的問卷該如何顯示？那不就表示設
01/12 03:56, 2F
→
01/12 03:57, 1年前 , 3F
計稿上沒有說要特別註明一個問卷是不是已審核未覆核。那
01/12 03:57, 3F
→
01/12 03:57, 1年前 , 4F
就當作已完成問卷顯示啊。設計稿沒有改前端就不用改就沒
01/12 03:57, 4F
→
01/12 03:57, 1年前 , 5F
有問題，設計稿要改那就是改需求就是加時間啊。後端跑分
01/12 03:57, 5F
→
01/12 03:57, 1年前 , 6F
析要撈哪些問卷出來跑還不就是改幾行條件就能搞定的事情
01/12 03:57, 6F
→
01/12 03:57, 1年前 , 7F
，多撈已審核未覆核的問卷出來加入要分析的資料集裡面，
01/12 03:57, 7F
→
01/12 03:57, 1年前 , 8F
哪有那麼崩潰。
01/12 03:57, 8F
→
01/12 03:58, 1年前 , 9F
以後就禁止使用那個沒人會看到的備註功能，不然就是你們
01/12 03:58, 9F
→
01/12 03:58, 1年前 , 10F
仔細檢查看清楚，再不然就換公司
01/12 03:58, 10F
→
01/12 04:07, 1年前 , 11F
感謝b大半夜回我，其實我省略很多細節只說明個大概，像那
01/12 04:07, 11F
→
01/12 04:07, 1年前 , 12F
個已審核未覆核的問卷從定義上是不能算在完成的問卷的，而
01/12 04:07, 12F
→
01/12 04:07, 1年前 , 13F
是這類的問卷被丟去分析以後他要強制被視為完成的問卷，後
01/12 04:07, 13F
→
01/12 04:07, 1年前 , 14F
端也要暴力的更改這種問卷的狀態，導致資料會出現明明是需
01/12 04:07, 14F
→
01/12 04:07, 1年前 , 15F
要覆核卻又沒有覆核結果卻又被算在完成的問卷
01/12 04:07, 15F
→
01/12 04:10, 1年前 , 16F
照你前面的說法是已審核未覆核要丟去分析，為什麼需要改
01/12 04:10, 16F
→
01/12 04:10, 1年前 , 17F
狀態變成已完成？讓他維持狀態是未完成問卷就好了
01/12 04:10, 17F
→
01/12 04:10, 1年前 , 18F
但會出現這種資料就是一開始我們在設計後端的時候認為要覆
01/12 04:10, 18F
→
01/12 04:10, 1年前 , 19F
核的問卷如果走到分析的話是一定會有覆核結果，沒有考慮上
01/12 04:10, 19F
→
01/12 04:10, 1年前 , 20F
述的情況
01/12 04:10, 20F
推
01/12 04:11, 1年前 , 21F
(舊文)(簡體)10年5款遊戲,項目從不延期:如何做項目管理
01/12 04:11, 21F
→
01/12 04:11, 1年前 , 22F
01/12 04:11, 22F
→
01/12 04:12, 1年前 , 23F
01/12 04:12, 23F
→
01/12 04:13, 1年前 , 24F
分析的程式抓所有已審核問卷出來分析，如果有覆核結果就
01/12 04:13, 24F
→
01/12 04:13, 1年前 , 25F
拿覆核結果來計算，如果沒有就拿審核結果來計算，不用管
01/12 04:13, 25F
→
01/12 04:13, 1年前 , 26F
他是不是已完成。聽你這樣講感覺是你們把自己綁死在一定
01/12 04:13, 26F
→
01/12 04:13, 1年前 , 27F
要已完成問卷才抓出來分析
01/12 04:13, 27F
→
01/12 04:15, 1年前 , 28F
因為針對問卷這個前端元件，已完成的話不可編輯，未完成的
01/12 04:15, 28F
→
01/12 04:15, 1年前 , 29F
話可編輯
01/12 04:15, 29F
→
01/12 04:15, 1年前 , 30F
而分析結果的畫面是有連結可以連到問卷去檢視當初審核結果
01/12 04:15, 30F
→
01/12 04:15, 1年前 , 31F
或覆核結果填了些什麼，結果連過去是一個可以編輯的問卷就
01/12 04:15, 31F
→
01/12 04:15, 1年前 , 32F
很奇怪
01/12 04:15, 32F
→
01/12 04:19, 1年前 , 33F
如果按照客戶需求這個分析過的問卷還要能夠編輯，做覆核
01/12 04:19, 33F
→
01/12 04:19, 1年前 , 34F
那就照做即可，就算你覺得他好像看起來很怪，反正是需求
01/12 04:19, 34F
→
01/12 04:21, 1年前 , 35F
至於有沒有覆核結果又是另一個坑了…因為所謂的沒有覆核結
01/12 04:21, 35F
→
01/12 04:21, 1年前 , 36F
果有可能是它其實被覆核完成了，只是被覆核人員認定這個問
01/12 04:21, 36F
→
01/12 04:21, 1年前 , 37F
卷不適用，資料庫就會記null，如果適用就是一個分數(float
01/12 04:21, 37F
→
01/12 04:21, 1年前 , 38F
)
01/12 04:21, 38F
→
01/12 04:21, 1年前 , 39F
另一種情況是它還沒被覆核所以是null
01/12 04:21, 39F
還有 105 則推文
→
01/12 11:35, 1年前 , 145F
,pm叫你做 你吵贏的機率高多了
01/12 11:35, 145F
推
01/12 11:55, 1年前 , 146F
其實結果就兩個 文件有你沒做 那就加班做
01/12 11:55, 146F
→
01/12 11:55, 1年前 , 147F
文件沒有額外的需求 那就多要一些時間做
01/12 11:55, 147F
→
01/12 11:56, 1年前 , 148F
做為開發 要對產品有點基本的sense 這樣spec沒寫清楚的
01/12 11:56, 148F
→
01/12 11:57, 1年前 , 149F
地方才會知道有可能的問題 再去問PM補齊細節
01/12 11:57, 149F
→
01/12 11:58, 1年前 , 150F
每個人心理想的跟表達出來的都不一樣 不要腦補
01/12 11:58, 150F
→
01/12 11:58, 1年前 , 151F
寫不清楚就問 或是看完spec 再確認一次自己認知的流程
01/12 11:58, 151F
→
01/12 11:58, 1年前 , 152F
跟 spec的流程是否一致
01/12 11:58, 152F
→
01/12 11:59, 1年前 , 153F
要自己想到各種spec上沒寫到的極端use case
01/12 11:59, 153F
→
01/12 12:09, 1年前 , 154F
不覺得文件是真理。花大量時間寫很標準的文件，甚至走CMMI
01/12 12:09, 154F
→
01/12 12:09, 1年前 , 155F
那套，什麼ISO都上，都永遠解決不了文字與言語溝通，就是
01/12 12:09, 155F
→
01/12 12:09, 1年前 , 156F
會一直有認知落差的情形。
01/12 12:09, 156F
推
01/12 12:10, 1年前 , 157F
恩認同可能是耦合度太高，不然就只是多個流程判斷而已
01/12 12:10, 157F
→
01/12 12:10, 1年前 , 158F
遇到需求認知落差時，團隊怎麼溝通達成目標，氣氛好不好，
01/12 12:10, 158F
→
01/12 12:10, 1年前 , 159F
才是職場的重點。
01/12 12:10, 159F
→
01/12 12:12, 1年前 , 160F
認真檢討文件，或技術耦合度，都不如解決"人"的問題。人好
01/12 12:12, 160F
→
01/12 12:12, 1年前 , 161F
了，什麼事情都能解決。
01/12 12:12, 161F
→
01/12 12:13, 1年前 , 162F
不然，你就算搞個很重的標準流程，產生所有可能文件，搞一
01/12 12:13, 162F
→
01/12 12:13, 1年前 , 163F
堆微服務，實務上都沒用。
01/12 12:13, 163F
推
01/12 12:16, 1年前 , 164F
下次畫一下event storming，檢討人沒有甚麼太大的
01/12 12:16, 164F
→
01/12 12:16, 1年前 , 165F
意義
01/12 12:16, 165F
推
01/12 13:22, 1年前 , 166F
本來就應該對於spec抱持著懷疑還有多方思考的態度
01/12 13:22, 166F
→
01/12 13:23, 1年前 , 167F
PM沒寫清楚就算了 工程師不能照單全收
01/12 13:23, 167F
推
01/12 13:31, 1年前 , 168F
江湖走跳，強烈建議PG通靈術一定要點滿。
01/12 13:31, 168F
推
01/12 18:13, 1年前 , 169F
先寫test case,找PM討論,再開始開發
01/12 18:13, 169F
推
01/12 20:25, 1年前 , 170F
文件就是個追憶手冊，確認的時候拿出來用的，寫不寫
01/12 20:25, 170F
→
01/12 20:25, 1年前 , 171F
能搞砸的就是會搞砸
01/12 20:25, 171F
推
01/12 20:29, 1年前 , 172F
好像也有所謂的規格描述語言，但沒用過無法評論
01/12 20:29, 172F
推
01/12 20:31, 1年前 , 173F
這個就是考驗PM的功力跟經驗了...
01/12 20:31, 173F
推
01/12 21:37, 1年前 , 174F
下次把文件看清楚呀，你要檢討pm請他下次把備注的字體
01/12 21:37, 174F
→
01/12 21:37, 1年前 , 175F
放大一點
01/12 21:37, 175F
→
01/12 23:14, 1年前 , 176F
每天的立會就是為了這種突然加進來的備註而存在的
01/12 23:14, 176F
→
01/12 23:15, 1年前 , 177F
時間一久連PM都會會忘記自己加了什麼 嘻嘻
01/12 23:15, 177F
→
01/12 23:17, 1年前 , 178F
不過看文章的描述PM沒啥問題吧，SA跟PG問題比較大
01/12 23:17, 178F
→
01/12 23:17, 1年前 , 179F
除非他偷改需求卻沒跟你們說
01/12 23:17, 179F
→
01/14 10:34, 1年前 , 180F
騰訊，考慮一下薪資福利跟下班時間吧，當下環境是個重
01/14 10:34, 180F
→
01/14 10:34, 1年前 , 181F
要的考慮要素
01/14 10:34, 181F
推
01/14 19:39, 1年前 , 182F
覺得只是你和PM都還不夠熟練，才會產生這種問題。下次P
01/14 19:39, 182F
→
01/14 19:39, 1年前 , 183F
M盡量改善文件寫法，你盡量用心看完每字每句用心推敲後
01/14 19:39, 183F
→
01/14 19:39, 1年前 , 184F
再做就好了。這種事情總會發生，盡量減少就是了。
01/14 19:39, 184F
‣ 更多 a2643 的文章
文章代碼(AID): #1ZlmtpS7 (Soft_Job)
‣ 更多 a2643 的文章
文章代碼(AID): #1ZlmtpS7 (Soft_Job)