您現在的位置是:首頁 > 舞蹈首頁舞蹈

為什麼產品經理認為很簡單,實則開發很難?

由 人人都是產品經理 發表于 舞蹈2022-12-13
簡介(媽的,引起了一些噁心的回憶)不靠譜度:★★★☆☆ ——還是讓你的人“簡單”出個案子然後我們再聊吧第三種“簡單”:沒錢“我有一個簡單的小需求,很容易實現,一千塊做不

遊戲策劃外包靠譜嗎

為什麼產品經理認為很簡單,實則開發很難?

作者:司馬奔騰

全文共 2568 字,閱讀需要 6 分鐘

———— / BEGIN / ————

對於產品和開發,兩支天賦我都基本加通了產品(遊戲策劃)方面的天賦點——是因曾經被坑了太多,失去了找到高契合度產品合作者的信心,於是自行轉職修煉而成。

作為一個二轉角色,這題還是可以答一下的。

在分辨需求方靠譜度這方面,公司豢養的程式設計師是遠不如宅家接外包的soho狗們的。被不靠譜的發包方坑乃是soho狗成長路上所必經的磨礪,於是就逐漸總結出了一些分辨不靠譜需求方的常識。

其中最重要的常識就是:在闡述時使用“簡單”二字,是需求方不靠譜的標誌。

有不少接外包的同學,甚至一看見“簡單”二字,直接就不再繼續聊。

因為在提技術需求的語境中,“簡單”有三種隱含含義:

第一種“簡單”:沒釐清技術點

出現“簡單”一詞,很可能是因為相關技術點沒有釐清。

沒釐清技術點,貿然開工會導致研發過程中溝通頻繁、研發目標難以明確以使交活時有較大機率陷入扯皮風險、具體研發時間無法估算。

例句:(對著UE示意圖講)這個位置,用來擺放使用者頭像,簡單做一下就好。

分析:將需求點轉化為技術點的能力,是產品經理與遊戲系統策劃的基本功。隊友基本功不行,這單需求也未必就沒救,關鍵就看需求點是否明確。

針對需求點明確的情況,如例句,可以用追問的方式細化以挽救。

如:

頭像多大,多少乘多少?

——大概400*400吧。

目前定不了是嗎?

——是的。

你剛說400*400,長寬比例固定是1:1嗎?

——我想想……不一定,具體要等介面Demo出來後再看易用性。

大小不寫死,我清楚了。只在這一個介面用嗎,其他View會有頭像展示嗎?

——可能會。

那寫的時候還要照顧下複用性,清楚了。看你畫的是矩形,確定是矩形邊框嗎?

——不,是圓角。

圓角弧度多少?

——額,我要再確定下。

好。頭像上有可能會疊其他東西嗎,比如,加個V?

——會有類似的。我本來是想做到VIP系統再提。

現在提,後面再加會有坑。

——現在需求還不明確,總之就是有可能會在頭像上擺會員標誌。會員標誌可能會有好幾種,但還沒設計出來。每種會員標誌的出現邏輯還沒定,VIP系統文件還沒出完。

會員標誌圖片資源是從伺服器得還是從本地得?

——這個……都差不多吧。

換個問題,會員標誌有熱更新的需求嗎?

——沒有。

好的。使用者頭像的圖片來源是?

——使用者自己在本地相簿裡選的。

要和伺服器同步嗎?

——要。

這方面的後臺API有嗎?

——……沒。

什麼時候能有?

——不確定,需求還沒提。

使用者選取頭像的操作是?

——點選頭像,彈出系統自帶的照片庫,選擇圖片,確定。

任何情況下點選頭像都執行照片庫彈出和選取的邏輯嗎?

——額……不是,應該是進到主頁裡。

這塊設計還不明確是嗎?

——……是。

那你先簡單設計一下把,完了之後簡單畫一個互動流程圖給我就好了。

——……

好的。我總結下:使用者頭像控制元件,圓角矩形邊框,長寬可配置,圓角弧度可配置,頭像上有疊加子控制元件用來顯示會員標誌。會員標誌圖片資源來源於本地Bundle。子控制元件有多個顯示狀態以對應不同的使用者身份。頭像圖片可由使用者選擇,選擇流程邏輯欠缺。頭像圖片需要與後臺同步,相關API欠缺。有缺漏和疑點嗎?

好的。我先簡單找張圖意思一下簡單做著,圖片選擇部分等你設計,圖片同步部分等你們出API,除這兩點之外,週五做完。

以上,算是把一個“簡單”的頭像顯示元件釐清了。遇到不會拆需求的產品經理,只能我們來幫他理,也就是幫他幹本該他來做卻沒沒有足夠能力去做的活。

不靠譜度:★☆☆☆☆ —— 起碼知道要的是什麼

第二種“簡單”:缺設計

對於入行不深的人來說,應用程式=腦洞+程式,遊戲=腦洞+美術+程式。很多工種與工序全然被無視,於是就誕生了——

“就差一個程式設計師了!”

第二種“簡單”,與上面這句話的誕生背景類似。

例句1:(同行介紹來的土豪)你好,我要做個股票分析軟體,就是根據我的演算法給指定股票打個分。演算法是明確的,我用Excel實現的有,你給做個手機版的就好了。介面無所謂,你就簡單做一下就好了,重點是功能。

翻譯:我啥都不懂,手裡有個需求,聽說你是做手機應用的,就先來問問看。我只負責掏錢,其他全都不管。你們程式設計師那麼厲害,介面也給一塊兒畫個吧。

分析:做外包的碰見這種2白,一般就是問個對方心理價,合計下看夠不夠再僱倆人一塊兒幹,一個做UE,另一個負責跟丫溝通,明確他的每個需求點。

例句2:(公司領導)小李,你上個專案做的不錯,年底了,咱們也不會有大的立項。組裡有個小需求,交給你去做吧。就是在手機上做個簡單的小程式,接上公司的CRM系統,有重要事項時給相關負責人發個推送就行了……

分析:

可能性1

看你工作不飽和,隨便給點活做做。

什麼,你管我要產品經理?

本來就是隨便找點活給你你還敢找我要人?

你管我要案子?流程邏輯?介面圖?後臺API?自己解決吧!

可能性2:

專案做完了,年景不好接不來啥單子,後面倆月沒你事兒了,年底要發獎金了。找個東西噁心噁心你,識相點自己辭職吧,別耽誤大好前程,部門裡也省點錢。

——這就是我開會時經常說的“雙贏”。

(媽的,引起了一些噁心的回憶)

不靠譜度:★★★☆☆ ——還是讓你的人“簡單”出個案子然後我們再聊吧

第三種“簡單”:沒錢

“我有一個簡單的小需求,很容易實現,一千塊做不?”

“就這個簡單的小功能,你報五個工作日?”

“僅僅是簡單的Flash移植H5並套個殼上傳App store而已,你好意思要這麼多?”

分析:沒啥可分析的……無非是想打免費炮,約不約就看自己了。

不靠譜度:★★★★★ —— “幫個忙嘛,請你吃飯!”

結論

並沒有特定的“看起來簡單實際上難以實現”的需求。非專案開發者,無法評判具體實現的難易。即便是同項目組的程式設計師之間互相提需求,在不清楚對方程式碼結構的前提下,也沒有足夠的資訊量去評判實現難易度。

妄談“簡單”,多為需求提出方Too simple。

與“簡單”類似的不靠譜需求關鍵字,還有:

戰鬥系統Demo,主要驗證一下感受,角色技能你就 稍微 做幾個,關卡 隨便 做一下就好。這塊 先就 只做單機,應該還是比較 簡單 的。

我就是這麼從一個程式設計師被逼成策劃的。

———— / END / ————

作者:司馬奔騰,做遊戲的德魯伊

原文地址:https://www。zhihu。com/question/38825761

本文由 @司馬奔騰 授權釋出於人人都是產品經理。未經作者許可,禁止轉載

11月11日廈門站,騰訊產品大牛手把手教你構建PM核心知識體系

名額僅剩最後几席,戳“ 閱讀原文 ”立即搶座!