Software Consulting Business (Negotiation) --- part 2

在平時就要多練習談判時的技巧：隱藏需要、提出好問題、表現出不自在、說「不」並要求對方回答「不」、淨空思緒。

做生意時，說「不」，是有技巧的，通常要加上關懷呵護，例句：

『 OOO，我做不到，真的沒有辦法，但是我確實想跟你合作。我們如何可以找到替代方案？』

在覺得可能會有衝突的時候，直接詢問：

『你想要我怎麼辦呢？』

發現自己講話講得太多時，嘗試最簡單的反詰：

『我說夠了，OOO，你覺得要怎樣處理這些事呢？』

與談判對手協商議程：
『OOO，我不確定這個消息對你有沒有價值，如果沒有，可以直說，我就不往下講，好嗎？可以。那麼這就是我們的約定。如果不對，我們就停下來。如果可以，才往下討論。』

// 給對方說『不』的機會，並且再三求証他的意願。

=== 應用技巧的 5 個步驟 ===

1. 確定你有一個強而有力、由對手觀點陳述的使命與目標，可以使對手看到並決定你的產品及服務是他們需要的。

2. 確定你知道對手的真正痛處 --- 他們之所以談判的真正原因。你提出問題，並創造願景。

3. 評估你和對手雙方的所有預算 --- 時間、精力、金錢、情緒投資。絕對不能忘掉這些預算，要隨時監控，觀察雙方決策如何受到影響。

4. 確定你是和真正的決策者打交道。

5. 沒有書面議程，絕不打電話或送出電子郵件。
議程的內容可以分成幾類：問題、心結、要求、下一步 
『要求』要進入議程，才能驅使對方做出決定。

Software Consulting Business (Negotiation) --- part 1

做生意總是不停地要提案，報價，仔細想想，每一次的報價就像是一場談判。以下的內容出自「一開口，就說不」一書。

要做好「以決策為基礎的談判」 (而非「以情緒為基礎的談判」) ，需要做好下列四件事：

• 專注於使命與目標
• 控制個人的需要、不輕易表現對成交的渴望
• 不怕說「不」
• 不怕別人說「不」

認真遵守上述四個直接了當、可達成且有效的目標，才容易得到理想的最終成果。

重點在於：要專注在可控制之因素，並且就這些『可控制之因素』去訂出合理的目標，而不是把談判的『結果』當成目標，因為談判的結果是一種不可控制的事。

Software Consulting Business (Progress)

回想從 2019 8/11 至今，也做了整整半年的生意。從完全沒有計畫、只憑感覺做，到把 Million Dollar Consulting 一書看完。大致上可以列出下列幾點的進展，我引用 Million Dollar Consulting 一書的重點來說明：

1. Seeing only economic buyers.
   領悟這點滿重要的。我領悟之後，就明白，我的買家大部分是高階主管或是中小企業主。其它人往往都只是 Gate keeper 而已，見他們只是浪費時間。為什麼 economic buyer 很重要呢？最重要的原因是，如果要 charge value-based fee ，只能找 economic buyer 來談。只有 economic buyer 才真正關心 output 。

2. Writing proposals with options.
   我從這一點想出了兩招可以快速幫自己增加利潤的招式：
   (a) 讓渡著作權               + 10%
   (b) brand mark removal  + 20%
   這些都是 options ，選購項目，但是客戶往往有誘因要購買。

3. Charge value-based fee / Conceptual agreement
   Alan Weiss 透過一再地與客戶交談，找出創造價值的契機。他把 value creation、pricing、proposal 合為一體。

   我的話，也是採取類似的精神。和客戶深入地討論軟體的需求、訂出合適的規格、提案、報價 、實作。我的報價，如果一般人只看我寫多少的 code 的話，會覺得真的是非常貴。但是，在這個討論的過程之中，最大的價值創造階段，其實是在「訂定規格」。我寫的每一個功能，都要是真真切切派得上用場的，這件事在訂規格的時候就已經確立了。

   (續) 我後來重看了這部分的章節，覺得自己其實誤讀了一個很重要的部分。我自己在與客戶談需求時，並沒有詳細地去把 conceptual agreement 這一塊談好。如果要提高成交率、且為客戶創造高價值的話，其實應該要對這個部分，下功夫去詳談。conceptual agreement 包含 objectives, metrics, value 三個元件，它也是連結 trust relationship 與 accepted proposal 中間的重要環節。

4. Populating the Accelerant Curve.
   目前的話，最左端的產品服務，是一些不收錢的免費文章
   左二的部分，需要做 open source project 、提供可客製化的軟體解決方案。(半客製化)
   右二的部分，是幫客戶寫軟體。(全客製化)
   最右邊的部分，則是每年收取軟體維護費。 total development cost 的 25%

5. Create marketing gravity.
   通常只有 referrals, speaking, networking 可以短期且快速地帶來客戶。目前我的經驗來講，referrals 和 networking 有成功的案例， speaking 則還沒有…


如果套用 Business Canvas 的九大區塊來分析上述 5 個重點的話：
1 對應到 Customer segment
3 對應到 Value proposition
2, 4 對應到 Customer relationship management
5 對應到 Channel

用 Event Modeling 的方式來描述規格

如何描述規格？

我做軟體做好幾年了，寫程式換過幾種語言。而寫規格書，卻沒有下過功夫去研究。最近一次開發一個比較大的系統，我自己後來寫出來的規格書，大概包含了三個部分：

1. 用講故事 (story telling) 的方式，用人類語言敘述的系統行為。 

2. Database 的 schema 

3. API 的 spec 

後來，仔細想想，這樣子其實也是有問題。其實一個系統的開發，應該拆解成三個階段：

A. 用「非開發人員」也可以理解的方式，書寫的高階系統行為、概述。講的是系統的目的 (purpose)

B. 以程式語言實作系統 (implementation)

C. 寫出該系統的實作規格 (description of implementation)

以我自己的最近一回做的東西來講，story telling 算是 A 。Database schema 和 API spec 都是 C。而系統在與非開發人員溝通，主要是依賴 A 的部分。換言之，其實我做 A 的部分，算是做得很不清楚，因為只有 story telling ，算是相對難以把事情說清楚的。

Event Modeling

Event Modeling 該網站提出的方法，我覺得算是 story telling 的加強版，即 story telling with time。它建議，首先畫一條水平軸，描述「時間」的進展，然後在這個由時間構成的水平軸線上，會放上一個又一個的長方形來描述系統的 story 。

每一個長方形由三個要素構成：
1. Trigger              - 通常是「使用者介面」或是「外部 API」
2. Action               - 通常是要讀或是要寫入系統，分成兩種：Command 與 View 。Command 是「想要改變系統狀態的意圖」、而 View 是系統當下的「報表」、「結論」

3. Event 　　　　   - 寫入硬碟的業務事件 (business fact)

長方形又可以根據 action 與 external states 可以仔細區分成 4 種 patterns

1.  Command   - state change

2.  View          - view

3.  Translation - external state input

4.  Automation - external state output

使用 Datomic 要注意的事： should not expose the entity number

偶然在 stackoverflow 上，看到了這類相關的問題。

When design the system API, it's very important that your input never have any raw entity ids in it, only external ids. Below is the reason:

1. You don't have an entity id until you transact the entity, so you can't create an entity and all its indexes together. You must first transact the entities, see what their entity ids were, then transact the composite index. 
2. It's no longer easy to do your own renumbering. There are datomic techniques which involve taking datoms from one database and transacting them to another, or recreating a db from its datoms or transaction log. The reason these techniques work fairly easily and robustly is because all pointers (refs) are known and can be renumbered. If you store an entity id in a value, you now need more complicated schema-specific logic to re-transact the datoms correctly.
3. Cognitect has said not to rely on stable entity ids because they haven't ruled out the possibility of renumbering them in the future. Right now, however, no renumbering occurs, but I would rather not tempt fate.

nREPL debug

最近研究透過 nREPL 來除錯，發現有幾個重點

1. 透過 nREPL 可以連上 running process ，考慮安全性，通常 nREPL 只監聽 127.0.0.1

2. 如果要在 local 端開 vim 除錯，就得用 ssh 做 local port forwarding

3. 很常見的情況是，deployment machine 不可以用 ssh 直接連上 ，因為中間還又卡一個 kerberos 機。

    這樣子的話，解法還有兩種：

    (a) 我個人會採用的，是直接把 vim, vim-fireplace 灌在 deployment 機上  

         https://github.com/humorless/dotfiles/issues/8

    (b) 使用 DrawBridge

Company of One book review --- 「技能與可行性測試」

書名：「一人公司」
作者：Paul Jarvis


「成長是導致許多初創企業失敗的主要原因，甚至包含很多頂級企業也是。」

「足夠是成長的相反。」

「衡量成功的標準不應該是季度利潤的增加、不斷成長的新客戶取得、或是成功的退場策略(exit strategy)。相反的是，我們可以專注於「生存策略」(exist strategy) --- 以堅持、盈利，以及盡力為客戶提供服務為基礎。」

我最欣賞的段落，節錄如下：
「多數成功的商業人士在進行主題演講時，當他們在分享他們有多明智，選擇投入更充滿熱情的工作生活時，我注意到他們沒有談論到兩個關鍵因素。第一，他們在投入之前就對他們自己所做的事很熟練，而且這些技能非常搶手。第二個遺漏的關鍵因素是，他們在攀登到最高的舞台之前，他們能夠先跨出一小步，為自己即將跨出的一大步試水溫。(確保他們提供的東西有足夠的需求。)」

這個經典的段落談了創業的關鍵要素：技能與可行性測試。