你的靈魂 - 談產品名稱的命名


《產品、組織有沒有靈魂,看名字就知道了。》


命名

現象與問題

名字在不同角度,會有不同用途,問題也會因此衍生出來,底下整理常見問題:

問題的描述方法依據:如何意識到問題的存在 整理。

現象一:同一個產品,不同時期有不同的名字

例如同樣一個產品,在初創期叫做 ABC,過了兩年,因應市場改變,改名叫做 ADC。過了半年,因為策略方向改變,改名叫做 AAA,又過了一年,產品線整併,改名叫做 AAA ABC。

這種改動合理?是的,這是合理的。但是內部溝通與教育訓練會很痛苦,溝通成本會越來越高。

重構與組織重整 一文提到組織與系統的重構,其實背後的意義就是產品的重構,重構的原因是因應市場的變化。

現象二:行銷名稱與系統程式名稱不一致

但行銷會因為策略、目標改產品名稱,但系統通常 (80%) 不會因此跟著改變,程式依舊保留最早的名稱。

以 Java Package 為例,Package Name 一定是第一個名稱,因為很少有機會去重構這個名稱,或者改變相關的配置。

如果這產品稍微有點歷史,新人看到程式碼,再看到產品名稱、或者相關名詞,很容易感到困惑。有經驗的新人,會開始問人,但通常問一圈之後,很少人能拼出全貌。沒經驗的新人,個性又內向的話,那就 ….. let it go … 或者自行想像、與拼湊,然後東西可能就會越來越歪。

現象三:產品跟系統不是一對一關係,名字無法對應

產品 A 實際上由系統 A / B 組成,但是系統 A / B 各有自己的名字。

這很恐怖。

我很常舉例著名搜尋引擎 Elastic 的產品線:從官網上看到的資訊,與自己抓下來安裝的資訊,是一致的。

現象四:名字沒有規則,新人無法融入環境

命名沒有規則可循,如果產品線很大,或者依賴關係很複雜,新人光是理解與記憶名稱的關係,就瘋掉了。

命名方式

整理幾種常見命名方式,這些方式可以混用。

獨佔性、開創性

直接用某個專有名詞當作產品名稱,通常具有開創性、或者獨佔市場的效果,像是:

讓使用者『默認』以為世界上只有這種東西,實際上不是。

一些年輕人會以爲 SQL = SQL Server。這就是 M$ 的命名策略,類似的還有 Azure DevOps,也是同樣的思路。

功能性

功能性命名是最普遍的產品命名法,例如 AWS 的 EC2,全名是 Elastic Cloud Compute。

AWS 產品名稱分析參閱: Products Naming for AWS

隱喻性

用別的領域的開創性名稱,類比產品的精神。很多人用的希臘神話、電影人物名字類比產品,像是:

  • 普羅米修斯: 希臘神話, 監控服務
  • Android: 出自電影 銀翼殺手
  • Borg: K8s 前身, 電影 StarTrek 裡的外星人
  • c3p0: Java Connection Pool, StarWar 的機器人名字
  • Athena: 希臘女神雅典娜、AWS 的 BigQuery

家族編號、系列代號

像是金庸武俠裡的 少林寺輩份 名稱,像是『玄』字輩,有玄苦、玄難;『虛』字輩,最有名當然就是天龍八部的 虛竹

OS X 用美國國家公園當作代號,早期用貓科當作命名。

年份

為了識別新舊,產品名稱加入時間概念,通常是上市的那一年。像是 Windows 2019, Office 2016 ….

紀念性

意象

開發代號 (Code Name)

開發代號通常在發想 前期 使用,等到產品定位清晰之後,對外會用正式的名稱,但是內部溝通使用代號為主。

  • 開發代號 英文稱為 Code Name
    • 用途:團隊溝通使用,可以創造 團隊文化
    • 不要跟公司、產品名稱、部門 … 有直接關係,也就是說 namespace / id 不要有這些字,甚至 git repos 也不要用。
    • Android 用糖果代號
    • 最近我都用 三體 相關的 XD
    • 我第一個工作的產品叫 Neo,因為那時候 駭客任務 (Metrix) 剛上映。
  • 版號 (Version):開發溝通用的、邏輯也會使用 (版本相容性、功能控制), 不要跟業務單位溝通,詳細參閱 Version Control

業務單位的版號跟開發者用的可以不一樣:例如 Windows Server 2016, iPhone X. 主要原因:產品名稱會變、老闆會變、公司名稱會變(併購、被併購)、行銷用語跟名稱是不一樣的。

名稱的使用情境

程式的變數都有適用範圍 (scope),例如物件導向的變數有分 local、class variable,簡單說就是變數的可視性 (Visible),常見的關鍵字是 public / protected / private。

名稱也是,以下是幾個使用的角度,幾個場見的問題:

  • 行銷對外使用:通常就是在市面上看到的名稱,最好讓行銷單位命名,但是不能一直改,會造成市場識別混亂。
    • 通常同一個產品,幾年下來都會異動名稱幾次,因為定位考量、市場考量、用詞考量 … 等等行銷識別因素。
  • 內部溝通使用:建議使用代號,代號不太會變動,而且可以放在程式碼裡面。

名稱規範的落地:管理共識

這篇文章是 18 年寫的一段草稿,本來在談敏捷的想法,後來也把這段思路輪廓記錄下來。最近這題目又被拿出來討論,重新整理一下這篇文章,類似的文章還有 AWS 產品命名Artifact Management 都有提到命名的問題。

名稱這件事情隨著組織發展到一定階段,一定會是一個問題,接下來就是如何讓大家:

  1. 意識到問題的存在
  2. 形成討論
  3. 找到共識
  4. 定義規範
  5. 落地執行
  6. 形成文化

一開始直接丟問題很容易被高層打槍,是正常的,因為資訊不足,高層對問題或方法沒有看到具體的方法無法決策。只有耐心溝通與引導才能讓事情發生。


結論

會認真取名字,就會認真看待這件事情。 (我覺得啦 XD)

我走到哪都會蓋一個叫 TeamRoom 的協作系統 (通常用 Redmine),然後有成功,也有被毀掉的,但重點就在 Team and Room,怎麼叫,心裡就會怎麼想,因為 語言影響思維

Team 是一群人,Room 是一個空間,TeamRoom 是一群人在一個空間一起努力的地方。

Updated: 2020/03/15

最近命名這議題在公司內部有一些討論,這是好事,代表有人已經 意會 到這事情的存在。但是這種新概念 (在組織裡) 沒有做好溝通,很容易就被高層打槍。因為考慮也還不夠齊全與清晰。


延伸閱讀

更新紀錄

  • 2020/03/15: 調整文章結構,新增 現象與問題 段落



Comments