[請益]如何有效減少與PM對於規格認知上的差異
最近做專案遇到常常遇到心很累的事情
就是有些很特殊需要判斷的情況
會被寫在設計稿一個感覺不是很重要的備註裡面
然後還很不顯眼,沒仔細看還不會發現
開會的時候也沒特別強調這邊要有特殊判斷
可能對於PM來說這個只是小事情,但對於工程來說是件大事
舉個例子,但詳細規格就不贅述了
最近在做一個問卷審核系統
然後有分需要"覆核"的問卷和不需要的
不需要覆核的問卷只要"審核"過了就算這個問卷完成了
後面的數據分析也是依照"審核結果"來當作依據
而需要覆核的問卷要先"審核"然後再"覆核"過了才算這個問卷完成
後面數據分析的則是由"覆核結果"當作依據(審核結果就不看了)
然後會有一個開始進行數據分析的按鈕給使用者按
讓使用者蒐集夠多的問卷以後按下去
然後我們把"完成的問卷"丟下去分析
聽起來非常合理且單純,我們前後端也就照個這個規格一直往下做問卷系統+數據分析
.....直到看到兩小行備註
「按下數據分析後,若需要覆核的問卷沒有完成覆核但已經完成審核
依然可以分析,但就是用"審核結果"當作分析依據」
這兩行被挖出來之後,前端(我)後端瞬間炸裂
因為問卷完成這件事再也不是可以進行數據分析的唯一指標
還要考慮它是否為一份需要覆核但沒被覆核完成但已經審核完成的問卷
現在要回頭補這段邏輯前後端都非常的麻煩
而且可能還會有沒注意到的漏洞
加上這個案子時程又趕,現在挖出這個東西所有人都不知道怎麼辦才好
如果一開始就有特別提醒我們有這種商業邏輯
也許還能想想有什麼辦法滿足客戶需求
到了現在這個階段基本上是沒救了
但如果我們希望能針對這件事情的發生做檢討
避免下次再出現類似情況的話
我也不知道有什麼好建議可以提出
我似乎能理解站在PM角度好像不會覺得這種可以妥協進行數據分析的需求是很難的事
但對於工程來說就完全不是這麼一回事
狀態的驗證、UI顯示邏輯等等都因為放行了"沒有完成卻又可以分析"的問卷要調整
然後設計稿也沒有針對這種狀態的問卷告訴我顯示邏輯
所以我們才會從頭到尾都以為要完成問卷才能數據分析
請各位前輩指點迷津....謝謝
--
時程就不要這麼趕啊 啊不然就換公司
設計稿沒有已審核未覆核的問卷該如何顯示?那不就表示設
計稿上沒有說要特別註明一個問卷是不是已審核未覆核。那
就當作已完成問卷顯示啊。設計稿沒有改前端就不用改就沒
有問題,設計稿要改那就是改需求就是加時間啊。後端跑分
析要撈哪些問卷出來跑還不就是改幾行條件就能搞定的事情
,多撈已審核未覆核的問卷出來加入要分析的資料集裡面,
哪有那麼崩潰。
以後就禁止使用那個沒人會看到的備註功能,不然就是你們
仔細檢查看清楚,再不然就換公司
感謝b大半夜回我,其實我省略很多細節只說明個大概,像那
個已審核未覆核的問卷從定義上是不能算在完成的問卷的,而
是這類的問卷被丟去分析以後他要強制被視為完成的問卷,後
端也要暴力的更改這種問卷的狀態,導致資料會出現明明是需
要覆核卻又沒有覆核結果卻又被算在完成的問卷
照你前面的說法是已審核未覆核要丟去分析,為什麼需要改
狀態變成已完成?讓他維持狀態是未完成問卷就好了
但會出現這種資料就是一開始我們在設計後端的時候認為要覆
核的問卷如果走到分析的話是一定會有覆核結果,沒有考慮上
述的情況
(舊文)(簡體)10年5款遊戲,項目從不延期:如何做項目管理
分析的程式抓所有已審核問卷出來分析,如果有覆核結果就
拿覆核結果來計算,如果沒有就拿審核結果來計算,不用管
他是不是已完成。聽你這樣講感覺是你們把自己綁死在一定
要已完成問卷才抓出來分析
因為針對問卷這個前端元件,已完成的話不可編輯,未完成的
話可編輯
而分析結果的畫面是有連結可以連到問卷去檢視當初審核結果
或覆核結果填了些什麼,結果連過去是一個可以編輯的問卷就
很奇怪
如果按照客戶需求這個分析過的問卷還要能夠編輯,做覆核
那就照做即可,就算你覺得他好像看起來很怪,反正是需求
至於有沒有覆核結果又是另一個坑了…因為所謂的沒有覆核結
果有可能是它其實被覆核完成了,只是被覆核人員認定這個問
卷不適用,資料庫就會記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都還不夠熟練,才會產生這種問題。下次P
M盡量改善文件寫法,你盡量用心看完每字每句用心推敲後
再做就好了。這種事情總會發生,盡量減少就是了。
31
Re: [閒聊] 2022夏秋活問卷調查本次問卷調查到今天中午截止,這邊要跟各位道歉,因為遇到一些狀況,統計分析結果 可能會花不少時間,無法保證能夠在本周末完成,但不會影響各位領批幣的權益。 針對問卷調查中的隨機測驗題,本文先公布答案與說明 題目:請問下圖中哪位艦娘的配裝,在夜戰階段對於 [集積地棲姫III バカンスmode] 的「閾值(CAP)後」補正倍率最低?(單選題)28
[結果] 碧藍航線四週年調查 PTT ver.抱歉讓大家久等了,最近剛好比較忙 所以做統計做的比較慢,部份數據圖會同時看日服的數據 同時加註個人心得 ------------------------------------------------- 第一題:伺服器6
Re: [心得] 數據分析_多家面試心得(原文恕刪) 我剛好在做數據分析的公司工作,主要透過分析顧客行為資料,協助零售業客戶能數據化 經營會員,忍不住分享一下: 1. 關於資料分析師DA很少有做純的這件事 :P,個人經驗是因為數據專案的PM多少也都 要懂分析能看數據才行,人難找,且除非案量夠多、公司願意多花錢養人,不然分析師跨4
[心得] 組織建立數據分析的難與痛各位數據大神、RD大神、PM大神,我對數據分析有些省思,再請各位看看是否有可以一起 成長或討論的地方。 -- Medium 好讀版X
[閒聊]2020經濟預測問卷(4/15開放結果)有鑑於最近市場的波動劇烈,相信大家很好奇未來得局勢,也有自己 的想法,這邊先不討論究竟未來是多還是空,小弟我忽然有個大膽的想法,做了一份簡 單的問卷想來統計一下大家的想法,想做的就是一個關於群眾的大數據分析。 一直以來相信大家的信箱都有各大銀行的國民信心問卷,但是我們看不到統計結果。而 且不同的族群,不同的取樣,相信也有相對的誤差。這邊我想做的就是以台灣流量較大