Product 的意義，就是愛；
愛，就是幫別人解決他的難題；
解決別人的難題，同時就創造了價值；
創造了價值，自然別人也喜歡你。
持續帶來價值，就是有效產品系統。
Product 的世俗思維，卻是從營利入手。
2013.07.26

病左三日
兩天前，和同事討論了個理論。

受過project management training 的manager (e.g. production stream) 和沒有受過相關訓練 (e.g. sales & marketing stream) 的思考模型是很大差別。
若取雙方的精英比較，
Mkt 人，思維主體是紅海模式。Only details matter, 盡在細節中。
Product 人，思維主體是藍海。任你怎樣打，飛高十萬呎，無人爭。

Optimized Debug Process
1. Reproduce the problem
2. Analysis possible point of error
3. Reproduct problem with point of error caught by console log = Proof
4. Find Methodology of Fix
5. Plan Fix
6. Fix it
7. Success

Crash Bug – how to fix? Best algorithm
Crash Bug are some bug which don’t output anything, just crash. Often the engineer has completely no idea where the problem is.
1. Remove lines of codes. Trace back to a point where there is no crash. Set it as a Starting Point (A).
2. Mark the current point as (B).
3. Use a divide and conquer approach. Between (A) and (B), find a middle point (C) which is no crash. Removing and adding back lines of codes, or mark them comment.
4. Minimize the scope until you find which line is the cause of problem.
5. Go to Optimized Debug Process (3) above

IT 行內有不明文事業階梯

Programmer/Engineer: 專注 Scope、Time和Quality，務求做到準確的Scope、Time，並在合適的Quality之下。
Analyst Programmer: Scope和Time複雜程度較大，Quality和技術要求較高。都是務求做得準確。
System Analyst: base on AP + Reuse, Architecture issue, Module control
Lead Programmer / Debug Expert: take over all bug issues in a company
System Architect: SA + DE
Project Coordinator/Producer: Biz, Product, Strategic Planning
Project Manager / Senior Project Manager: SA + Producer

今天，寫一些基本功。
用來訓練新員工很適合的教程。

新員工，需要有態度、團隊能力、責任心、學習能力、技術。尤其是前四樣。
這些是較長期才能訓練到的soft-skill。單靠工作訓練，很難短期能有明顯改善。
個人做法都是在selection process中已filter走不合格的。
任何訓練總有個開始點。而這文的開始點就是以上條件。

1. Scope Sense
先訓練員工明白甚麼是scope。IT Project 都是些抽象產品，員工若對scope不熟悉，通常會不是做少了就是做多了，結果只會影響進度和準期。
Steps:
1.1. PM自己先清楚整個 Project 的 Scope。
1.2. PM將Project分成不同的Task和Module。每一份都是manageable state。
1.3. PM 和Engineer 開 Sprint Planning / Daily Scrum，傳遞Task/Module
1.4. Engineer 要清楚知道Task/Module的definition，才算是傳遞到。

2. Agile Scope
知道Scope，另外的就是時間。
估計時間，最有效的，是PM和Engineer 都估計一份，比對，然後若有分別找出差別的原因。
正常有實力的PM和Engineer，坐在一起估計，應該不會差太遠。若其中一方欠缺估計能力，則另作別話，也不適合參與估計過程，或只適合作培訓用途。
估計到時間，按需要加上一點緩衝或休息時間，就可以pack成module。
若有些task因一時間欠缺資料而不能作出估計的話，可以分作兩份：一份是調查用的時間，另一份是工作時間。

3. Agile XP
１和２都是Agile的實戰版。若公司除了PM外，還有Senior Engineer(SE)，如何分工？
refer to post: https://dayios.wordpress.com/2013/09/11/xp-scrum-agile/
若有SE，則需要訓練E學懂配合SE。

XP: Extreme Programming

SCRUM + XP
兩個人做development。
Team Setting: 一個Senior Engineer(SE) 加一個Engineer(E)。
Planning: 先和Project Manager (PM) 做Scrum Agile。Daily Scrum，夾Scope 和Schedule。
Analysis: SE和E 夾分工方法，夾個別部件的做法。
Implementation: Engineer 專注push forward進度；SE專注解決所有技術問題、研發Library、測試、其他雜項handling、Product問題等等。

上一篇談PM的文中，指出Scope Management是最重要的。
這篇寫寫如何有效和優質地確認一個Project 的Scope。

首先，Scope 是UX的一種。
Scope Management 是High Level的，而不是技術層面的。
Scope Management 是要回答到Why & What。若你發現你對一個Project 的Why & What 有一個很有信心的確實回答時，你就是對Scope已掌握得好。

以下是一些對思考Scope 有幫助的Brainstorming Tools。都是一些文件或War Room Session。
試試每種都做一次，而做過的文件反覆比較和整合，會加強效果。

1. 你會如何用Problem Statement來形容這個Scope？而相對應的Methodology和Possibile Solution是甚麼？

2. 試試形容一個全面的high-level direction。

3. 分析有甚麼Domain Objects / Domain Assets

4. 畫一個你構想中Draft UI

5. 競爭者如何做類似的Product?

6. 分別寫幾份不同層次而都是完整的Feature List

7. 寫一份Draft Database Schema

8. Use Cases Analysis

9. 你會如何回答這個問題：Why I have to do this?

10. 做一個PPT，對象觀眾是non-IT audience。

聽過不少人講他們如何做Project Management(項目管理, a.k.a. PM)，常見的是很多人其實都不懂得做PM。
所以，想寫一篇有關PM，順便整理一下心得。

大部份人犯的毛病都是太過學術性。讀死書。
現時著名的PM Methodology 主要是PMP(US), Prince2(UK/Europe), Scrum(日系管理)。
它們各有各的長短處。
很多人讀完書，就只懂得用model解決問題，但缺乏了書本沒有教的Project Sense。

Project Sense，在PMP書面叫做PM Triangle。
和PMP不同的是，有Sense的人不是有document說如何處理Budget, Schedule和Scope。而是在腦中有一個PM Triangle。
這本身是一種「球感」。

簡單來說，首先要在腦海中掌握好Scope是甚麼。
若掌握到Scope，已成功了一半。
有了Scope，Schedule和Budget就只單純是會計運算。你會發現大腦甚至會在潛意識中計算到並告訴你能否按Budget和Schedule進行：若不能達成，確定Scope後你會覺得很不妥的。
掌握了這三點，甚麼Communication Plan, HR Plan, Integration, Outsourcing等等，都是自動埋位的。
至於Quality 和Risk，就是項目經理的經驗本身了，只能累積，沒有得速學。

今天和下屬Y說了一個事業祕訣。

一般打工仔，如何決定如何排列工作的優先次序？
Y說，是按照上司交付的工作，再按其他因素的影響和關係來作決定。

我溫和地告訴他，若面試中我聽求職者答這問題，其實只算 Grade C 或C+的答案。
當然，更差的還有 D, E 及F Grade。
這答案只屬C Grade，因為還只算是 do the thing right, but not “doing the right thing"。

對公司最有價值的員工，是能從整個局勢整盤棋，去知道自己角色是什麼，和應做什麼。
簡言之是do the right thing，和think out of the box。
先做好自己，再進一步就局勢向公司提出意見，這是 B和 B+的分別。
A呢？A的員工，就是使同事也能和他一樣，從公司和大局角度想。
就算不全面，若一個員工除自己外能某程度 leverage 別人do the right thing，至少也值 A-。

D 的員工，就是上司交付他之後還要跟進，不足夠獨立；或甩甩漏漏。
E 的員工，是責任感不足，遲到早退或工作時間營私（e.g. 炒股、Facebook、副業、messaging）。這在普世都很普遍，還可勉強接受。聘請這類時是要連浪費的時間也計進去。
E不算最差因為還有墊底的。F，不合格的，是除了自己責任感不足，還影響和感染其他同事。今年做的公司包括我操刀的都炒了幾個這類。這類是普遍僱主就算不忍心也都贊成辭退的。

這模型的妙處是，越高階的員工，越多權力動用公司資源。也更易升職加薪。
道理是簡單：若你是僱主，你會擢升一個為公司著想甚至能激勵同事，也能明暸市場局勢的呢，還是只懂做好份內事的員工？
你會否給予更多資源一些主動思考和帶動有質素的策略的員工？

B 和A Grade 的員工，是可以做到「要錢有錢，要面有面，要權有權」的程度。
分別只在心態。
而這種員工，薪金比同等學歷普遍高50%。

而好消息是，員工的質素和學歷無關。
以前都試過有幾個我聘請的或下屬，學歷都有博士或兩個碩士或以上及名校畢業，多國語言，面試了得，但回想中他們只屬D Grade。

分享，互勉。

簡表、總結、關鍵詞
F：負面影響
E -> D：責任感
D -> C：獨立
C -> B：僱主角度、do the right thing、think out of the box、critical thinking
B -> A：感染力、Leadership
A -> S：專精、獨創性、演化力、
同Grade±：該關鍵詞的幅度、長闊高深