在產(chǎn)品設(shè)計(jì)上要注重邏輯的合理性，我曾經(jīng)做過(guò)一個(gè)產(chǎn)品，有個(gè)功能是分類篩
選，我們根據(jù)內(nèi)容類型把不同的內(nèi)容進(jìn)行歸類，運(yùn)營(yíng)人員可以根據(jù)不同的分類篩
選內(nèi)容，也只能分類查看。這樣一來(lái)在后續(xù)的運(yùn)營(yíng)過(guò)程中運(yùn)營(yíng)人員無(wú)法統(tǒng)籌查看
全部的內(nèi)容，如果想看一下最近更新的內(nèi)容或者內(nèi)容總數(shù)，只能各個(gè)分類查看后?
才知道，很麻煩，還挺考驗(yàn)人的記憶力的。
再舉一個(gè)例子，我曾經(jīng)看過(guò)一個(gè)產(chǎn)品有個(gè)業(yè)務(wù)邏輯，兩個(gè)管理模塊A和B，A模塊是
B模塊的內(nèi)容源且有信息的第一管理權(quán)。A模塊的信息被下架后，B模塊也同時(shí)下
架，但是后臺(tái)使用者卻可以手動(dòng)把B模塊的信息再上架。這樣就不合理了，內(nèi)容源
中已經(jīng)沒(méi)有該信息了，但是B模塊卻依然顯示著。兩者有時(shí)關(guān)聯(lián)，有時(shí)不關(guān)聯(lián)。
其實(shí)從技術(shù)上來(lái)講，怎么做都可以，完成由人定義。但是如果邏輯上不合理的
話，不僅開(kāi)發(fā)過(guò)程中難以溝通，而且運(yùn)營(yíng)人員在使用過(guò)程中也會(huì)覺(jué)得很亂。
我之前講后端產(chǎn)品受使用者干預(yù)性比較大，因?yàn)楸旧砭褪枪┧麄兪褂玫?，所以?/p>
們?cè)谠O(shè)計(jì)功能的時(shí)候也會(huì)收集運(yùn)營(yíng)人員的需求。在這個(gè)過(guò)程中有時(shí)候運(yùn)營(yíng)人員的
需求是合理的，有必要的，但有時(shí)候也不合理，純屬那種拍腦門的決定。
這種拍腦門的后果就是對(duì)需求的定義隨心所欲，造成的結(jié)果是功能很多，加大了
開(kāi)發(fā)量，某些比較小的功能即便運(yùn)營(yíng)人員讓加了，但實(shí)際過(guò)程中基本不會(huì)使用。
所以在這個(gè)過(guò)程中，產(chǎn)品經(jīng)理就要控制運(yùn)營(yíng)人員的欲望。
邏輯上的合理性，也可以成為產(chǎn)品經(jīng)理評(píng)判某個(gè)需求的標(biāo)準(zhǔn)。
之所以要做到靈活性，主要原因有兩個(gè)，一個(gè)是對(duì)于運(yùn)營(yíng)需求的滿足，另一個(gè)是
某些功能需求的不確定性。
先說(shuō)第一點(diǎn)，我原來(lái)做個(gè)功能當(dāng)時(shí)我們想把游戲官網(wǎng)的設(shè)計(jì)模塊化，這樣可以提
高游戲官網(wǎng)上線的速度。雖然從功能的角度來(lái)講可以這么做，但是從設(shè)計(jì)的角度
來(lái)講并不合適，出于營(yíng)銷的目的官網(wǎng)還需要展現(xiàn)游戲的個(gè)性化。所以當(dāng)時(shí)我們做
了樣式替換的功能，運(yùn)營(yíng)人員如果不想使用模板，可以依靠替換CSS文件來(lái)做到官
網(wǎng)的個(gè)性化。
有些功能的需求是不確定的。比如說(shuō)一個(gè)電臺(tái)節(jié)目的簡(jiǎn)介最大字?jǐn)?shù)該限制多少，
說(shuō)實(shí)話有時(shí)候我也不知道，運(yùn)營(yíng)人員也說(shuō)不準(zhǔn)。如果一旦限制的字符比較短，那
在以后的使用中發(fā)現(xiàn)不夠用，還得修改。要不就設(shè)置的非常長(zhǎng)，比如說(shuō)十萬(wàn)字，
我們能夠預(yù)想到肯定夠用了。但這樣就沒(méi)太大意義。這種時(shí)候我覺(jué)得可以不做限
制，完全由人為定義就好。
做技術(shù)的人流行一種說(shuō)法，不要寫死。保持靈活性，也是為了避免某些地方寫死
而給自己造成一些麻煩。
給大家一個(gè)建議，因?yàn)榇蠹业纳习鄷r(shí)間是固定的，周一到周五每天八個(gè)小時(shí)，某
些功能如定時(shí)器很大程度上是為了讓方便大家在非工作時(shí)間管理內(nèi)容。判定某個(gè)
功能如果完全可以在工作時(shí)間控制，而且即便發(fā)生錯(cuò)誤影響也不大，那么就可以
考慮保持其靈活性。
產(chǎn)品經(jīng)理都會(huì)追求好的用戶體驗(yàn)，用戶體驗(yàn)的優(yōu)秀很大程度上體驗(yàn)在細(xì)節(jié)上，可
要知道在追求用戶體驗(yàn)這條路上是沒(méi)有盡頭的。其實(shí)不僅是前端產(chǎn)品，做后端產(chǎn)
品也要控制自己的欲望。如果對(duì)細(xì)節(jié)要求的太多，磨的太細(xì)，恐怕你的產(chǎn)品就永
遠(yuǎn)不要上線了。
我曾經(jīng)就經(jīng)歷過(guò)這種情況，部門中的一個(gè)項(xiàng)目，開(kāi)發(fā)測(cè)試完成，由于服務(wù)器的原
因耽誤了上線時(shí)間。在這個(gè)過(guò)程中產(chǎn)品經(jīng)理就在逐漸優(yōu)化細(xì)節(jié)，按理說(shuō)也沒(méi)問(wèn)
題，但是技術(shù)人員對(duì)代碼的每次改動(dòng)都意味著增加了一次風(fēng)險(xiǎn)，說(shuō)不定會(huì)引起別
的問(wèn)題。
除了用戶體驗(yàn)外，功能也是如此。有些需求其實(shí)運(yùn)營(yíng)人員也沒(méi)有考慮清楚，即便
是提出來(lái)了，也是一時(shí)興起，缺乏說(shuō)服力。如果是這樣，在滿足基礎(chǔ)需求的前提
下，我們不妨?xí)呵野研鹿δ芊乓环?。等最終考慮清楚了再開(kāi)發(fā)，免得做無(wú)用功。
相比較前端產(chǎn)品，特別是APP，后端產(chǎn)品有個(gè)優(yōu)勢(shì)就是技術(shù)上的改動(dòng)隨時(shí)可以生
效。而不需要用戶更新版本，這對(duì)產(chǎn)品經(jīng)理來(lái)說(shuō)是好事，如果出錯(cuò)了補(bǔ)救的成本
小一些。
拿我之前做過(guò)一個(gè)排序功能來(lái)說(shuō)，如果想調(diào)整某個(gè)內(nèi)容的順序，可以手動(dòng)輸入序
號(hào)，序號(hào)越大排序越靠前。雖然這樣能滿足需求，但是隨著使用的時(shí)間久了，積
累的數(shù)據(jù)越來(lái)越多，出現(xiàn)了一個(gè)問(wèn)題。運(yùn)營(yíng)人員在使用過(guò)程中并不規(guī)范，他們輸
入的序號(hào)數(shù)值很隨意，往往會(huì)把新增加的信息序號(hào)數(shù)值設(shè)置的很大。一共90條數(shù)
據(jù)，但序號(hào)數(shù)值可能已經(jīng)到了200。序號(hào)并沒(méi)有連著，時(shí)間長(zhǎng)了列表中的序號(hào)就會(huì)
非常亂。
所以說(shuō)功能設(shè)計(jì)的好壞也跟數(shù)據(jù)的規(guī)模有關(guān)，有些功能在數(shù)據(jù)少的情況下使用沒(méi)
問(wèn)題，但是隨著數(shù)據(jù)量增大就會(huì)暴露出功能設(shè)計(jì)上的缺陷。
之前行業(yè)內(nèi)有一種議論說(shuō)，有些產(chǎn)品經(jīng)理非常不愿意做后端產(chǎn)品，我在工作經(jīng)歷
也發(fā)現(xiàn)，確實(shí)存在這種現(xiàn)象，有的產(chǎn)品經(jīng)理在接后臺(tái)產(chǎn)品時(shí)就是抱著一種應(yīng)付的
態(tài)度。
