你的靈魂 - 談產品名稱的命名
《產品、組織有沒有靈魂，看名字就知道了。》
命名
現象與問題
名字在不同角度，會有不同用途，問題也會因此衍生出來，底下整理常見問題：
問題的描述方法依據：如何意識到問題的存在 整理。
現象一：同一個產品，不同時期有不同的名字
例如同樣一個產品，在初創期叫做 ABC，過了兩年，因應市場改變，改名叫做 ADC。過了半年，因為策略方向改變，改名叫做 AAA，又過了一年，產品線整併，改名叫做 AAA ABC。
這種改動合理？是的，這是合理的。但是內部溝通與教育訓練會很痛苦，溝通成本會越來越高。
重構與組織重整 一文提到組織與系統的重構，其實背後的意義就是產品的重構，重構的原因是因應市場的變化。
現象二：行銷名稱與系統程式名稱不一致
但行銷會因為策略、目標改產品名稱，但系統通常 (80%) 不會因此跟著改變，程式依舊保留最早的名稱。
以 Java Package 為例，Package Name 一定是第一個名稱，因為很少有機會去重構這個名稱，或者改變相關的配置。
如果這產品稍微有點歷史，新人看到程式碼，再看到產品名稱、或者相關名詞，很容易感到困惑。有經驗的新人，會開始問人，但通常問一圈之後，很少人能拼出全貌。沒經驗的新人，個性又內向的話，那就 ….. let it go … 或者自行想像、與拼湊，然後東西可能就會越來越歪。
現象三：產品跟系統不是一對一關係，名字無法對應
產品 A 實際上由系統 A / B 組成，但是系統 A / B 各有自己的名字。
這很恐怖。
我很常舉例著名搜尋引擎 Elastic 的產品線：從官網上看到的資訊，與自己抓下來安裝的資訊，是一致的。
現象四：名字沒有規則，新人無法融入環境
命名沒有規則可循，如果產品線很大，或者依賴關係很複雜，新人光是理解與記憶名稱的關係，就瘋掉了。
命名方式
整理幾種常見命名方式，這些方式可以混用。
獨佔性、開創性
直接用某個專有名詞當作產品名稱，通常具有開創性、或者獨佔市場的效果，像是：
- SQL Server
- API Gateway
- Serverless
讓使用者『默認』以為世界上只有這種東西，實際上不是。
一些年輕人會以爲 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 ….
紀念性
意象
- Facebook: 其實我覺得這名字好爛
- Linkedin: 連結所有人
- Elasticsearch 的 node 用漫威角色當名稱
- docker 也有個動態命名資料庫，參閱 moby/pkg/namesgenerator/names-generator.go
開發代號 (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 都有提到命名的問題。
名稱這件事情隨著組織發展到一定階段，一定會是一個問題，接下來就是如何讓大家：
- 意識到問題的存在
- 形成討論
- 找到共識
- 定義規範
- 落地執行
- 形成文化
一開始直接丟問題很容易被高層打槍，是正常的，因為資訊不足，高層對問題或方法沒有看到具體的方法無法決策。只有耐心溝通與引導才能讓事情發生。
結論
會認真取名字，就會認真看待這件事情。 (我覺得啦 XD)
我走到哪都會蓋一個叫 TeamRoom 的協作系統 (通常用 Redmine)，然後有成功，也有被毀掉的，但重點就在 Team and Room，怎麼叫，心裡就會怎麼想，因為 語言影響思維。
Team是一群人，Room是一個空間，TeamRoom是一群人在一個空間一起努力的地方。
Updated: 2020/03/15
最近命名這議題在公司內部有一些討論，這是好事，代表有人已經 意會 到這事情的存在。但是這種新概念 (在組織裡) 沒有做好溝通，很容易就被高層打槍。因為考慮也還不夠齊全與清晰。
延伸閱讀
- 談談敏捷開發的看法
- Study Notes - Overview API Gateway
- Version Control
- 寫在介紹 Redmine 之前
- 看見怎樣的全貌
- Products Naming for AWS
- 如何意識到問題的存在
- Artifacts Management
- 重構與組織重整
更新紀錄
- 2020/03/15: 調整文章結構，新增
現象與問題段落
Comments
About
著作
演講
AWS Certifications
