關於市場, 總結一下
我們現在最大的問題是: 把每個"個案"都當成一個新市場
的確每個人都會確實有他的需求, 我相信只要我們願意花費時間, 也都可以理出頭緒, 列出 action list, 但我們現在勞師動眾替他做的費用假設是 X, 那實質上市價應該收的價格應該是 3X ~ 10X 之間, 等於說, 我們老是假設這個需求不會是個案, 我們會找到其他的人來攤平這個成本, 所以我們收的是"服務租用"的價格(而非服務建置的價格), 付出的成本是服務建置的成本, 這樣的交易, 我是廠商我也會樂意做, 因為我用很便宜的價錢就買到了我要的服務
但事後往往發現, 這個需求好像暫時找不到其它人買單... 所以我們就把這個做出來的成品堆放到"模組倉庫", 等待下一個人要時再把它拿出來賣, 這一等可能是一個月 一季 甚至一年 或更久, 沒有人能保證, 對於資本不多的我們來說, 當然也不可能留在原地, 看到一個東西賣不動, 很自然的, 我們的注意力會轉往下一個"有可能" 賣錢的東西, 就這樣週而復始
有一天, 我們運氣不錯, 有人要買倉庫的東西, 我們從倉庫裡拿出來之後, 仍免不了要修修改改, 這個修修改改一樣要成本, 但我們還是跟對方索取"服務租用"的價格(而且他可以隨時不租)
所以我們常常在提供打工仔的價錢, 正職員工的服務
我觀察了很久, 才能夠把這件事抽象化描述出來, 再來談談這會有什麼問題：
1. 優先順序：如果每個別人的需求都是要做的, 我們在面臨需求時, 很容易因為這樣的邏輯而覺得每件事都很重要, 既然每個人都付你錢(這個錢也是你接受的), 都是客戶了, 那要如何評斷誰先誰後? 由誰判斷? 那一把尺是什麼?
2. 產品品質：我們現在很多的服務是疊床架屋"蓋"出來的, 所以我們總是會"將就"把這個需求融入到現有系統, 由於還要兼顧其它開發項目, 交期相對來說往往不長, 所以我們頂多只能做到"現階段看起來沒問題", 就交付出去了, 製作之初沒有一套通盤的考量的時間 (跟主系統是否有牴觸的地方 是否有更簡單的作法), 製作收尾時沒有充分測試的時間, 導致交出去的東西可能就是個六七十分, 對小廠商還好, 他可能也將就, 但對於有點規模的廠商而言, 後續頻頻出錯他是否會質疑我們的專業度?
3. 賠錢阿大佬：很顯而易見的就是"我們在賠錢做", 而且不是賠一點點, 是賠 50% 以上的錢, 也就是說, 接案公司(在初期 然而我們是否有中後期不曉得) 比我們賺錢, 如果我們有點資本額來燒一陣子也就罷了, 但現在事實是我們的資本照這個速度可能半年內就會用完
4. 成員 HP/MP：除了主線開發, 又要應付隨時都可能來的需求(這個需求還未必是以前碰過的 要逢山开路, 遇水搭桥), 而這個需求看起來好像也賺不了什麼錢(小至幾百 了不起一兩萬), 我們會長期的在一種無定向的處境往前進, 今天的事實可能明天就什麼都不是, 有點像是四處征戰, 但又進不了城, 搶不了 錢 糧 娘們 的兵(請見投名狀)
以上的問題我覺得每一個都滿嚴重的
要怎麼改善：
1. 要有核心假設：有了核心假設, 還要有次要假設 末端假設, 就像樹幹長出樹支再長出葉子一樣, 次要假設是順著核心假設長出來的, 末端假設又是根據次要假設長出來的, 每個(不同層次的)假設又會衍生一些 "要做的事" 和 "要驗證的事" 如此一來事情就有了輕重緩急, 我們再做的事也就很容易看出它屬於脈絡中的什麼位置
假設不是不能調整, 如果我們收到的事實跟假設不符, 那就應該要檢討/替換假設, 但原則上核心假設類似 "目前的國家憲法", 次要假設類似"法律", 末端假設則是"行政命令", 所以替換的次序應該會是從末端開始, 再到核心的
例如我們可以找一個我們認為不太會被推翻的"事實"作為事業的核心假設 --> "往後十年電子商務會越來越蓬勃發展, 越來越多個體戶或小公司會想用低廉的成本設立雲端商店", 接著順著這個核心往下想, 我們可能給出這樣的次要假設 "他們需要很快速的上架" "他們需要跟其他買賣平台很方便的同步資料", 到這個層次就需要做很多的驗證, 要捲起袖子幹, 但你起碼知道你目前的辛苦在藍圖上是處於哪個位置, 遇到事情要取捨時, 這種樹狀架構也能幫助你思考何者為先
這可以解決1.
2. 要加強說明/合力參與：讓成員了解, 對方向產生認同很重要, 不然就是一個人在前面摸索, 後面的人搭著他的肩膀義無反顧往前走, 不如發揮集體智慧吧! 出錯機率比較低, 而且向心力會比較高, 重要的是, 成員有自己的專業, 知道走向的話他可以先幫你想在前頭 (至少程式端是如此)
這可以解決一部分的 2. 和 一部分的 4.
至於 3. ... 我只能說盡人事(做好兩點改善)後要看造化了(如果我們團隊終究想賣的是 scalable 的服務而非接案的話)
的確每個人都會確實有他的需求, 我相信只要我們願意花費時間, 也都可以理出頭緒, 列出 action list, 但我們現在勞師動眾替他做的費用假設是 X, 那實質上市價應該收的價格應該是 3X ~ 10X 之間, 等於說, 我們老是假設這個需求不會是個案, 我們會找到其他的人來攤平這個成本, 所以我們收的是"服務租用"的價格(而非服務建置的價格), 付出的成本是服務建置的成本, 這樣的交易, 我是廠商我也會樂意做, 因為我用很便宜的價錢就買到了我要的服務
但事後往往發現, 這個需求好像暫時找不到其它人買單... 所以我們就把這個做出來的成品堆放到"模組倉庫", 等待下一個人要時再把它拿出來賣, 這一等可能是一個月 一季 甚至一年 或更久, 沒有人能保證, 對於資本不多的我們來說, 當然也不可能留在原地, 看到一個東西賣不動, 很自然的, 我們的注意力會轉往下一個"有可能" 賣錢的東西, 就這樣週而復始
有一天, 我們運氣不錯, 有人要買倉庫的東西, 我們從倉庫裡拿出來之後, 仍免不了要修修改改, 這個修修改改一樣要成本, 但我們還是跟對方索取"服務租用"的價格(而且他可以隨時不租)
所以我們常常在提供打工仔的價錢, 正職員工的服務
我觀察了很久, 才能夠把這件事抽象化描述出來, 再來談談這會有什麼問題：
1. 優先順序：如果每個別人的需求都是要做的, 我們在面臨需求時, 很容易因為這樣的邏輯而覺得每件事都很重要, 既然每個人都付你錢(這個錢也是你接受的), 都是客戶了, 那要如何評斷誰先誰後? 由誰判斷? 那一把尺是什麼?
2. 產品品質：我們現在很多的服務是疊床架屋"蓋"出來的, 所以我們總是會"將就"把這個需求融入到現有系統, 由於還要兼顧其它開發項目, 交期相對來說往往不長, 所以我們頂多只能做到"現階段看起來沒問題", 就交付出去了, 製作之初沒有一套通盤的考量的時間 (跟主系統是否有牴觸的地方 是否有更簡單的作法), 製作收尾時沒有充分測試的時間, 導致交出去的東西可能就是個六七十分, 對小廠商還好, 他可能也將就, 但對於有點規模的廠商而言, 後續頻頻出錯他是否會質疑我們的專業度?
3. 賠錢阿大佬：很顯而易見的就是"我們在賠錢做", 而且不是賠一點點, 是賠 50% 以上的錢, 也就是說, 接案公司(在初期 然而我們是否有中後期不曉得) 比我們賺錢, 如果我們有點資本額來燒一陣子也就罷了, 但現在事實是我們的資本照這個速度可能半年內就會用完
4. 成員 HP/MP：除了主線開發, 又要應付隨時都可能來的需求(這個需求還未必是以前碰過的 要逢山开路, 遇水搭桥), 而這個需求看起來好像也賺不了什麼錢(小至幾百 了不起一兩萬), 我們會長期的在一種無定向的處境往前進, 今天的事實可能明天就什麼都不是, 有點像是四處征戰, 但又進不了城, 搶不了 錢 糧 娘們 的兵(請見投名狀)
以上的問題我覺得每一個都滿嚴重的
要怎麼改善：
1. 要有核心假設：有了核心假設, 還要有次要假設 末端假設, 就像樹幹長出樹支再長出葉子一樣, 次要假設是順著核心假設長出來的, 末端假設又是根據次要假設長出來的, 每個(不同層次的)假設又會衍生一些 "要做的事" 和 "要驗證的事" 如此一來事情就有了輕重緩急, 我們再做的事也就很容易看出它屬於脈絡中的什麼位置
假設不是不能調整, 如果我們收到的事實跟假設不符, 那就應該要檢討/替換假設, 但原則上核心假設類似 "目前的國家憲法", 次要假設類似"法律", 末端假設則是"行政命令", 所以替換的次序應該會是從末端開始, 再到核心的
例如我們可以找一個我們認為不太會被推翻的"事實"作為事業的核心假設 --> "往後十年電子商務會越來越蓬勃發展, 越來越多個體戶或小公司會想用低廉的成本設立雲端商店", 接著順著這個核心往下想, 我們可能給出這樣的次要假設 "他們需要很快速的上架" "他們需要跟其他買賣平台很方便的同步資料", 到這個層次就需要做很多的驗證, 要捲起袖子幹, 但你起碼知道你目前的辛苦在藍圖上是處於哪個位置, 遇到事情要取捨時, 這種樹狀架構也能幫助你思考何者為先
這可以解決1.
2. 要加強說明/合力參與：讓成員了解, 對方向產生認同很重要, 不然就是一個人在前面摸索, 後面的人搭著他的肩膀義無反顧往前走, 不如發揮集體智慧吧! 出錯機率比較低, 而且向心力會比較高, 重要的是, 成員有自己的專業, 知道走向的話他可以先幫你想在前頭 (至少程式端是如此)
這可以解決一部分的 2. 和 一部分的 4.
至於 3. ... 我只能說盡人事(做好兩點改善)後要看造化了(如果我們團隊終究想賣的是 scalable 的服務而非接案的話)
留言
張貼留言