Self-complacency v.s. confidence

Recently, I've interviewed a candidate who applied for Sr. software engineer job and he did demonstrate an unusual character of Taiwanese engineer: self-complacency. 

The interview started from a quick technical review to know his skill set base on his resume.

At first, we quickly ask "How do you identify your Linux skills" and he said "I am very good at Linux". Then we ask a few basic Linux commands, for example: "How to know your current disk usage?". "How to know current Linux kernel version". He actually cannot answer much.

Then, we asked "How do you identify your level of SQL?" and again he said "I am very good at SQL". But he actually don't know any basic concept of "outer join" and "normalization". He explained SQL is what he is working on not the scope of his research area. Then we asked "how to avoid SQL injection in application" but he still can't say anything.

Since his resume said that he is "excellent" in English, we asked if we can continue interview in English. He took a deep breathe and then said "no".

Finally, he explained that he can quickly learn "anything" in one month but then forget that in next month. But he still emphasized that "I think I do have the talent of software development, give me a mission and I can commit the code". This might be true that he can learn "anything" quick and "commit code" for the job. But it is definitely also true that no one will hire such risky engineer.

To me, at first, I think it is extremely unusual to see an engineer with 7 years experience has such self-complacency and with such low actual skill set. But then his resume shows that he worked for 6 different companies in past 7 years. Change job doesn't means that the candidate is bad. But it is still a sign for Taiwanese programmer. Another sign is that he did have very good education background and also good delivery in first 2 jobs. But then, he seems stay in there. 

How to distinguish  self-complacency from self-confidence?

We do want engineers have confidence to take challenges. But how can we tell a candidate has confidence or just too complacency? 

During interview, our suggestions are

(1) Check skills by fact

Ask simple, un-ambiguous technical questions. Do not rely on his words on resume. For example, if his resume shows he has 10 years experience in Linux Operation, make sure you will ask at least 3 most simple questions and 5 middle level questions. If his resume says that he has 10 years in Java, make sure ask the last moment of his java coding. Sometime, the answer will surprise you.

(2) Check experience by real actions

Some candidates described experience like this "design XXXX system". This could be very important task but also could be a self-complacency thing in candidate's mind.

If this candidate lead design meeting, come out a design document - even a hand writing document or drawing picture from whiteboard. That means we can check the design and know how many of "special" things inside the design. 

However, if candidate couldn't say any concrete delivery (we don't need to ask him to provide right away, just want to know if there is), then it is very possible that he "believe" that he did the design job but actually the design was inside his mind. 

You need to heck the actual actions and delivery of it. You can ask "please let me know the exactly things you did on design XXXX system and also the delivery at that time"

(3) Find critical point by the actions candidates did

Always looking for fact of candidates did in previous jobs. It is very similar to (2). We will need to understand his behavior via his previous actions when face a critical situation.

However, I am sure everybody will prepare a pretty nice answer of "why you leave your current company". So just save your time, ask other question.

Check candidate's resume and you will always find some critical moment in his career. For example, a project which requires a new skill set, then you can ask how candidate learn new skills. Or, senior engineer might play leaders role in certain situation, then, you can ask what is the worst thing happened during his leading. 

Always Consider Facts

In short, always consider to gather fact during interview and identify if candidate fit your organization through fact, not to guess.

Scrum: Feature-boxing of Sprints

In certain scenario, a scrum project could allow different length of Sprints and still satisfies Timeboxing principle. It benefits an involving software product of build MVP, increase integration quality and make members even more focus.



Time-boxing is one of fundamental practices in Scrum methodology. Most of actions in scrum are time-boxed. It makes sure the project keep going and also lets members focus on current task.

Time-boxing is one of the cure of Parkinson's Law of Triviality for all kind of meeting. No matter it is Sprint kick-off or daily standup. I believe it should apply to not only project management but also other area of organization, as long as the timeframe is a consensus of members. 

You can easily find the definition or discussion of how important time-boxing (or timebox) is in google. For example: this one or this one.

Timeboxing in Sprint

A Sprint in scrum also apply to time-boxing. Normally it means when project kick-off, all scrum members will decide how long is a Sprint. The recommended length is 4 weeks in software development. After that all Sprint will be in 4 weeks, no matter how many stories have done or what changes happened between Sprints. That also means if a project is in Sprint-11, 40 weeks was gone. 

A fixed timebox sprint make process happens. But is it necessary to keep the same length of Sprint?

Still timeboxing but flexible in next Sprint

Timeboxing is still critical and should be applied in the moment before event start. Sometimes, we should not fix timeframe in project kick-off and keep for next 40 weeks or more.

In fact, every Sprint kick-off meeting should also discuss a timeframe of this specific Sprint.

Image a sprint-kick-off meeting. Everybody: Product Owner, Scrum Master, Scrum Members were together in this Sprint kick-off meeting, discuss stories and story-points. If PO select 3 stories: P1, P2 and P3 which needs 2 weeks, 1 weeks, 3 weeks. What team should do? The general practice should be keep P1 and P2 in this Sprint and also select a few lower priority task to fill up that one left week. However, there are a few drawbacks in this situation. Firstly, remember Parkinson's Law? members might extends the time for not select lower priority tasks which sometimes is not a bad idea. But secondly, if a scrum team keep doing select a lower priority to fill up time slot, it make the "priority" not "priority" any more. 

If all members have consensus of flexible Sprint length, they can easily setup next Sprint to 3 weeks. And that Sprint will done  P1+P2. Or with Product Owner's agreement, they can setup next Sprint to 6 weeks to complete all P1~P3. 

In some scenario, the most beautiful way should be keep P1 in next sprint only. And this Sprint will be just 2 weeks. 

Make MVP possible

Why do one story at one Sprint is a beautiful way? Well, in some scenario, we need to make MVP(Minimum Viable Product)...and keep make MVP for a while to identify market and make sure minimum waste. Unfortunately, no body can foresee the future. A quick/early delivery is the reason why MVP is useful and also the reason why it is good to stick a single story delivery in a single Sprint. To achieve that, we need flexibility in different Sprint.

The key person of MVP is Product Owner (PO). And to make MVP possible, the bottom line of scrum is to have PO's real participant. In reality, it is very very hard to PO to focus on what he needs to do. A single story delivery forces PO to make a decision of the real priority of backlogs. Since the team will really delivery a things in every Sprint and of course PO should then put the thing in the market. PO can't say: well, it is too early to go for market. Since this is his priority one! Priority one should go for market right away! 

Why Quality improved?

Very simple, each Sprint with only one story has its own QA process and due to the complexity of change is short. we can easily fix integration issue or new defeat much quicker than a sprint with more than one story.

Agile: Feel comfortable to Adopt reality

An agile team should be comfortable to adopt changes and those changes should reflect to reality. But should still keep the critical concept. There is always a way to enjoy both without compromise to an uneasy method. 

To be flexible in Sprint length doesn't mean to break Timeboxing. But it does break some rule from the regular Scrum training. Nevertheless, process is continuously improving is the bottom and spirit of Agile. Scrum master or organization leader should take responsibility to make sure the process could be tailored after retrospective.

Case Study

As developer manager of a enterprise software product, I modify a bit of product release method to make sure PO's backlog is a real priority to reflect market needs. 

The result is since 2016/July to 2017/Mar (8 Month), we delivery 5 releases. The longest Sprint is 8 weeks and the shortest Sprint is 2 weeks. We actually complete 5 major stories and achieve following technical result.

(1) Quality: no side effect in these 5 release. Compare to previous fix Sprint length model much lower technical defeat in beta.

(2) Productivity: averagely, more code conduct per engineer compare to previous fix Sprint length model. However, at the same period of time, we enjoy more team building activity then before and very very very few overtime.

(3) Motivation: engineer could see the result (no matter good or bad) few weeks after delivery. Previous fix Sprint length model needs 3 to 9 months to know if our works really matters.

If you'd like to know more detail, please drop me email.

工作中速度與效率的迷思

孫子兵法：兵聞拙速 未睹巧之久也

媒體大亨Rupert Murdoch：不是大的打敗小的，而是快的打敗慢的

效率以及速度，在職場上的重要性應該眾所皆知。然而，速度並不見得會產生「效率」，當然也就可能沒有「績效產出」。

工作中的速度與效率常見有幾種迷思如下：

速度的相對論

在職場上，速度時常是相對的。

有個笑話最適合描述這樣的相對論：兩個好朋友去非洲野營，在帳篷睡到半夜，聽到有獅子在附近低鳴，似乎打算把這兩人當作食物。其中一人開始穿衣服鞋子，另一人惶恐地問「我們有辦法跑得比獅子快嗎」，已經穿完鞋子正在做熱身操的那位仁兄回答：「我不需要跑得比獅子快，我只要跑得比你快就好」

然而，相對論的確有其迷思與限制。例如，在大型企業中，或許你已經是個主管，相對於其他同事，你也有創意，而且你辦事速度也很都快，看似一切穩當。但是有一天，你所屬的部門被公司老闆出售給外國企業，而該企業也表明只需要技術人才，不需要主管階級時，你才發現原來速度的比較對象，不應該僅僅是在自己的組織之中。(沒錯，這裡說的是HTC最近的賣部門給google的事情)

過程與結果的本末倒置

速度應該是「過程」，而效率和產出，才是「結果」。

把速度當作結果等於是本末倒置。

所以，讓網頁的使用者回應時間，從2.5秒，加速到0.25秒，看似一個有指標性質的結果。但已產出的觀點來看，其實可能是要達到「服務更多使用者」「增加效率」或甚至「減少電費」這些確切結果的「過程」。

工作中單以「速度」作為結果的績效指標，很快就會導致局部最佳化的組織問題。

沒有目標的ASAP

當詢問同事/主管說「請問這件事情應該何時完成」，如果時常聽到ASAP-as soon as possible 越快越好，而沒有具體的解釋，其實是危險的指標。

沒有具體衡量的速度，可能導致幾種錯誤想法：

(1) 這是不計一切代價要越快完成越好的事情，即便犧牲性命也在所不遲，因為一旦完成就會有很美好的事情發生。這樣的想法過於革命性的危險，事實上，僅有極端少的事情是不計一切代價，連生命都可以不要的。

(2) 每個人的時間感受不同。也許CEO的告訴中間主管的ASAP，在當時他的心中是指3個月，而中間主管告訴工程師的ASAP，在他當時的心中是指3個禮拜，可是，工程師的感受可能是5天。最糟的情況是，工程師會誤以為ASAP表示可以犧牲品質，如同上段所述，是可以不計一切代價達到速度。

(3) 有太多事項都是ASAP時，表示根本沒有設定正確的目標以及優先順序。




附註，關於速度突破職場困境，請參考這篇

如何建立一個還不錯的部落格(blog)

The only thing you really have in your life is time. And if you invest that time in yourself, to have great experiences that are going to enrich you, then you can’t possibly lose.  (Steve Jobs, Entrepreneur)

你真正擁有的其實只有時間，如果你把時間用在投資自己，得到很棒且能豐富你人生的經驗，你不可能會失去什麼。」 史蒂夫‧賈伯斯


部落格和Facebook(臉書), twitter, instagram有根本上的不同。相較於快速的互動，部落格更具有長期性，也因為長期性，讓近年來的知識型部落格(註1)，成為一個需要長時間投入，也可能會長時間回收的事情。就短期行銷而言，部落格或自己的網頁，遠不如fb的粉絲團或twitter的密集短暫貼文。然而，就長期內容累積，擁有比較完整的表達敘述來說，自有網頁或者部落格仍然比較適合...只是要投入比較長的時間。


關於生活類型的部落格可以參考註2，在此謹分享專業類型的部落格。

專業人士為什麼需要有自己的部落格

這裡的專業人士是指：工程師，程式設計師，法務專家，行銷人員，心理諮詢，作者...等等。和一般生活類型：旅遊，吃喝玩樂...的訊息傳遞有很大的不同。

很有可能專業類型的部落格，僅在特殊情況下會被陌生人看到，大部分是「為了自己而寫」，而長期累積之下有很多好處：

1.  提升與反思

教學相長，當你能把一件事情表達清楚，表示你對這件事情了解得更清楚。在寫作的同時也更容易發掘自我問題。

2. 資訊傳遞

某些專業領域有自己的知識瓶頸，或者想要傳遞和其他人略有不同的觀念。一篇簡單清晰的部落格文章，就可能會達到效果。例如：Scrum認證，不要再浪費錢了。這篇是對於Scrum認證的反思，在google search "scrum認證"的時候已經會出現在第一頁，讓想要考Scrum認證的人，可以多一個參考觀點。

3. 專業行銷

由於退休新制的實施，現在換工作的門檻越來越低，而專業人士必須要能展現與行銷自己的能力。履歷表或者linkedin固然是好方法，但是有效的，長期的分享自己的能力與觀點，更能展現自己與他人的不同。請參考這裡，與這裡。


但請切記，部落格只是「額外」產生上述三個好處，自己寫的愉快才是重點。

工具選擇

如果你還沒有自己的網頁，部落格。想要開始，自然要先選用平台/工具。當然，已有許多部落格文章在討論「部落格」工具的選擇。

例如：

* 2017部落格平台調查報告 ：這篇主要是討論收費的平台

* Blogger 和 wordpress的比較 ：如果懶得研究太多免費平台，考慮這兩個就好。

假如你是資訊專業者(程式設計師等等)，自己搞台電腦或者VM，自建網站，也是個好玩的方式。但如果不是為了好玩或者學到網站營運的技術，就專業分工的角度來看，採用成熟的平台或許更好。例如：你也不會自己host email server對吧？

不過其他類型的專業人士(心理諮詢，牙醫，法務人員，行銷，業務，作家，顧問等等)，採用現有的平台是最簡單，效果穩定，而且不用花太多時間處理雜務。

在還沒有決定怎麼做之前，有幾個建議：

1. 如果你不想要廣告，未來也不打算透過部落格廣告賺錢，不建議用痞客邦這類型預設有廣告的平台。

2. 網址名稱很重要。現行第一層網址，例如.com，已經有超過1000個可以選。也表示不要太特殊的網址也並不貴。以你現在看到的這個blog網址：5233.space，一年也不到300台幣，第一年還是特價70元台幣而已。

BestProgrammerInTaiwan.com 五年，2242台幣

3. 如果你的讀者群，不包含中國大陸(註3)，那麼免費的google blogger會是最佳選擇。因為即便綁定「自己的網域」名稱，它仍然免費。以你現在看到的網域www.5233.space，就是在godaddy買了網址名稱之後，綁定到google blogger上。

建立的基本步驟

如果對於建立部落格還沒有計畫？可以考慮採用以下方式：

1. 決定目標

最好有個清楚的部落格專業範圍。例如：心理諮詢，程式設計，軟體工程，如何創業等等。決定目標也比較容易決定名稱和網址名稱。

範圍可大可小，而範圍大小各有優勢與缺點。

2. 建構平台環境

沒有太多考量的話，就...

(a) 直接到blogger.com建立一個自己的部落格，

(b) 到godaddy.com買個不會太貴的網址。建議直接買5年。因為部落格需要長期經營，5年的網址，通常也不過2000台幣。

(c) 綁定godaddy網誌到blogger.com，請參考這篇說明。

(d) 寫2-3偏草稿

(e) 隨意試用一下Blogger.com的設定

3. 持續撰寫文章

最好能維持每週一篇，每年50篇的速度。專業部落格是不太適合一天一篇，實務上也不太可能。

要持續不間斷撰寫文章，才能迫使自己持續不斷的在專業上成長。

4. 定期檢視

定期檢視部落格文章數量與分類是否合理。更重要的是，當部落格文章達到一定數量時，可以和自己的linkedin以及履歷表連結。

5. 橫向連結

無論有意無意，橫向連結同類型文章或網站，是建立一個還不錯的部落格的要件。




如果你還沒有確實的實施計畫，可在此索取「建立部落格一頁計畫書」，可以確實並腳踏實地的建構自己的部落格網站。

---

註1. 這裡指的知識型部落格，是非「吃喝玩樂型」的部落格。然而，以pixnet為例，絕大部分訪客數多，能用廣告賺錢的的部落格，都是屬於「吃喝玩樂型」。請參考排名：https://blogranking.events.pixnet.net/

註2. 成為人氣部落格的方法，生活部落格5步驟，部落格衝人氣的方法...

註3. 因為截至目前為止，大陸長城會擋住大部分google的服務。

Serverless design for LINE AI Chatbot

Chatbot is one of the interesting application in AI area, it creates opportunities for enterprise to serve customers only with very low cost or even generate new revenue.
In past few years, major Instant Messaging providers allow developers to hook their service. Means as long as you have existing simple message process and response system, you can quickly interact with all kind of message channel.

Normally, a software developer will start from build a system in a server box, no matter Linux or Windows. Recently, the server might be a VM in public cloud, no matter AWS, Azure, Linode or DigitalOcean. However, a serverless design model might be a better choice.

Why Serverless?

Firstly, a serverless system will be easy to scale in/out. It doesn't mean you can't scale in/out in traditional VM in public cloud or your own datacenter. It just means that all the Lambda, no matter which provider, is actually decouple from it development environment. Supposedly, you start from one Lambda function to a few thousands same Lambda function without consider "traditional question", for example: should I shutdown VM when not in peak our, should I do some script to check if current VMs are closed to overloading?

Secondly, a serverless system will be easy to plug-in which means during the design phase, developer will be forced to think de-couple functions in small modules (bricks). Developer will also be forced NOT to rely on specific environment, even though docker is one of the solution but purely Lambda function will create much better environment-free structure.

Furthermore, it will also help to define boundary of sub system and help the future maintenance.

The Design Concerns

(1) IM independent

LINE occupies a huge market in Taiwan, about more than 90% of mobile user has LINE account. The most incredible thing is many elder people who never touch Internet before have LINE accounts! However, this design won't use any LINE specific methods. We've try the same engine in Yahoo Messenger and it also works.

(2) AWS Lambda

-- (2.1) try NOT to use context

AWS Lambda has a standard invoke parameter (event, context), The event is actually the user input when invoke Lambda function. The context is what developer might need to understand the 'environment context'. The major design concern here is try NOT to use context when possible. Because this will make you hard to move out your lambda to other public cloud environment. If you really need to have ARN or identity, try to limit environment in just one Lambda.

-- (2.2) async invoke

AWS Lambda could be invoked in 3 types: Event, RequestResponse, DryRun. The "Event" is actually asynchronous call. For any IM message receiver Lambda, you should  keep that Lambda as simple as possible to response IM webhook. Put other things via "Event" Lambda. Because most of IM provider (LINE, fb) ask a very short timeout in IM webhook. DO NOT just put http webhook and response to IM a synchronous call stack

Of course, see detail from AWS document: here.

-- (2.3) timeout/memory

AWS lambda allow to config timeout and memory size. AWS CloudWatch could see a Lambda's resource consuming. It is fine to use larger memory or setup a longer running time but developer should know WHY.

-- (2.4) quick testing

It is necessary to have your own developer server for test your Lambda function and trigger a deployment script to upload to AWS. If you didn't actually use "context", it will be very simple to have a quick test in every Lambda handler.

# in the end of your Lambda python script.
if __name__ == '__main__':

    event = {'param1':test'}
    lambda_handler(event,None)

Of course developers need other framework (unittest).

-- (2.5) deployment

As always, from a developer should have a semi-automatic way to do deployment. This is a very simple deployment script to (a) zip python files (b) upload to S3 (c) create lambda function (d) config function using S3 zip file.

(a) zip lottery.zip -r lambda_lottery.py lottery60.py
(b) aws --profile ailine s3 cp lottery.zip s3://bucket/
(c) aws --profile ailine lambda create-function --function-name lottery --runtime py
thon3.6 --role "arn:aws:" --handler lambda_lott
ery.lambda_handler --timeout 10 --code "S3Bucket=bucket,S3Key=lottery.zip"
(d) aws --profile ailine lambda update-function-code --function-name lottery --s3-bu
cket bucket --s3-key lottery.zip

-- (2.6) scheduled (cron) Lambda

Chatbot might need to do scheduled task to response to user, maybe send a regular morning call. To trigger a scheduled Lambda might be one of the major cloud-provider-dependent thing we have in Chatbot design.

(3) AWS API Gateway

AWS API Gateway is another major cloud-provider-dependent things, however, it is not hard to use other provider or have our own lab testing environment. The major concerns of API Gateway are (a) should convert IM provider's http request to a given format: which becomes a Lambda input. (b) security concerns: how to make sure only IM provider's system could access this API Gateway

(4) AWS dynamodb

Chatbot uses dynamodb to store use information and also message log. It is also pretty easy to use local JSON formate nosql.

(5) AWS elasticsearch

Chatbot leverages AWS elasticsearch to store knowledge base. It is easy to setup a developer's elasticsearch server to do lab test before deployment. The real concerns in public cloud might be the future budget:)

(6) AWS S3

Chatbot still need some static content (html or js) and S3 is the most easy way to provide public static content. It is also the place to upload latest Lambda code.

The Implementation

See: github repository 

Take a look?

This chatbot could understand and speak only Tradition Chinese, since she is a Taiwanese robot:). You need to have LINE account to chat with her.

聊天機器人小姍的Line QR 

加小姍為好友  

企業巫醫 - 統計與謠言

In god we trust all others bring data 
  -  W. Edwards Deming (全面品質管理TQM之父)


網路讓資訊傳播成本降到極端的低，同時也讓資訊品質降的極端的低。

謠言的成因有非常多。有些僅只是美麗的誤會，例如：十幾年前開始流傳的泰戈爾的詩。有些則是恐嚇類型的無風起浪，例如：誠品可怕迷魂盜，泰國罐頭。有些只是試圖吸引人目光的搞笑惡作劇，例如：裝翅膀飛起來

。

最糟糕的類型，莫過於以「統計數字」造出看似符合邏輯的謠言。並且，從這樣的謠言中獲得利益。


許多時候，數據本身難以查詢正確性。而且由數字導引出的邏輯，更容易因人而異，因地制宜。從數字所引導的偏誤，有時候甚至比單純的謠言還可怕，因為它可能會在網路上留存多年，難以辯證。如果只是單純搞笑也就罷了，如果個人或者組織，以這類型的資料來作為決策的判斷依據，那下場可能非常慘。錯誤的資料，比沒有資料更糟。


不過，只要稍微留意，加上合理的好奇心，統計謠言是有機會判斷其可能性：

(1) 不解釋的數字

在各類文章或研究報告中，為求精簡，只會根據重要數字做衍生推論。然而，數字背後通常還有「未解釋」的數字，而這個數字可能更為重要。

以企業僅21%的需要大學以上學歷為例。這篇文章，簡單說明勞動部的調查，僅有21%的企業需要大學以上的學歷。然而，這個數字有很大的問題。

也許，該調查隨機抽了100個企業主，其中只有21個企業主宣稱需要大學以上學歷的員工。

也許，該調查抽樣了企業主的「100個正在招募工作職缺總數」，這100個職缺中，只有21個是需要大學學歷。

這兩者有極大的差距。前者，可能這21個企業主，所需要員工數量高達2萬人，而另外79個企業主，所需員工只要79個人也說不定。而後者，正在招募的職缺，和「已經在職」的學歷也並未顯示。而單就此推論，僅21%企業需要大學學歷基本上過於簡化。

所有經過簡化，而沒有附上數據的真實來源的推測，其解釋很容易被扭曲。然而，被扭曲的解釋，當然比較有戲劇性，比較容易被注意。

勞動部網站根本也找不到這份調查。

此外，很多政治性民調也是屬於此類，涵蓋許多不解釋的數字。

(2) 接近完美的不可能

網路上流傳一份超過十幾年的Dr Ephrem Cheng研究顯示，越早退休壽命越長。(參考這裡，這裡，這裡)  

這份數據流傳非常之廣，被引用次數非常多，每隔數年也會在通訊軟體上流來流去。最近當然就是LINE上流傳的長輩文。

上面提供了一份數字，是退休年齡跟「壽命」的對照表如下。

retire	life
49.9	86
51.2	85.3
52.5	84.6
53.8	83.9
55.1	83.2
56.4	82.5
57.2	81.4
58.3	80
59.2	78.5
60.1	76.8
61	74.5
62.1	71.8
63.1	69.3
64.1	67.9
65.2	66.8

不會統計的人也可以看出，在這個表中，越早退休，壽命越長。如果49.9歲就退休，那麼可以活到86歲。65.2歲才退休，就只能活到66.8歲。

以相關係數簡單計算，他的相關程度高達-0.96，換言之，這是一份極為完美的負相關數字。

這種過度完美個數字，應該要看研究論文的細節加以瞭解。例如他的樣本有多大？是什麼時候做的研究。就可取得的事實來看，他的樣本很小，並且研究的時間幾乎可以肯定在1990年以前。由於上述的年紀追蹤到80歲，所以研究對象大概是1930-1950嬰兒潮時代的人。

最重要的是，這些數字並非真實研究論文，卻在很多人的轉貼中，莫名其妙的被冠名「美國權威學者」。


這份研究數字會流傳很久的原因，是他剛好契合 (1) 這看起來是個學術研究 (2) 可以被直銷，財務規劃，人生規劃等等產業拿來利用 (3) 可以有趣的解釋它

除此之外，別無他因。雖然已經有些人發現不對勁，例如這裡。但是許多第一次看到此研究的人，仍然不明究理的轉貼。

如果想知道實際的退休年齡和生存年齡的相關性研究：請參考這篇研究。該篇的結論就交由各位判斷，但至少它的研究方式，數字細節，都解釋得十分清晰。

我已經透過管道寫信給該研究者Dr Cheng，懇請取得確實的研究資料以及統計方式等細節(說不定他也是受害者？)。至今2017/Jan/11尚未收到回覆。

(3) 邏輯上的不可能

邏輯上不可能，或者簡單的說「數字兜不攏」。

中國的2010的地方GDP就是邏輯上的懷疑問題。因為 中國31個省份的GDP加總起來，竟然遠超過全國GDP，而且高過很多。這在邏輯上是不可能的事情，因此自然就有合理的統計造假懷疑。

類似的事情也容易發生在沒檢查，而且其實也不打算認真做統計的相關文章上，例如這裡。因為在許多時候，謠言只是想要造成吸引人的目的，其真實性不重要，當然就也不特別檢查數據。所以自己造成自己數據兜不攏，邏輯上不可能的情況並不少見。

這和前兩者不同，邏輯上的不可能，可以單就資訊本身的內容加以探索，或者是再加上一些事實根據來檢視。因此，比較容易看出謠言的真實性。




最後，稍微提醒一下：廣告的統計宣稱，其實難以查證。例如高露潔的「大部分牙醫師推薦」如果不是公平會主動進行查證，一般市井小民根本無法查證屬實與否。

企業巫醫 - 誰掌握你的升遷？

只有自己掌握了自己的命運。沒有別人。(註1)

升遷也不例外。只有自己掌握自己的升遷，沒有別人。

大部分無法獲得升遷的理由，都只是自己的藉口而已。常見藉口(註2)如下：

- 自己的努力沒被別人及主管看到
- 受到主管不公平的對待
- 主管不賞識甚至打壓
- 組織內制度有很多問題
- 負責的工作實在太艱難資源又少
- 負責的工作實在太簡單沒有挑戰性
- 景氣不好公司不賺錢就罷了，還在裁員
- 比我資深的還很多，很難輪到我


在大組織裡，個人升遷(promotion)仍然是職業生涯重要考量。因而，企業巫醫們的一些闡釋也頗有道理，例如這篇，或者這篇。但有些過於偏激，而且會舉一些憑自己想像的例子。這類型的巫醫頗多，在google上搜尋"升遷"就可以找到不少。


那麼，自己要如何掌握自己的升遷？

超乎期待：做出超越目前工作職掌的成績

升遷指的是企業組織認為你可以「增加」工作範圍或內容。而要讓企業組織，或者主管，要認定你可以承擔更大的工作範圍，最好的方式就是你「已經」做出超越目前工作職掌的成績。

超越工作職掌的方向有兩種，這兩種和雙因子理論/激勵保健理論(參考激勵保健理論)的概念相同。

方向一：保健因素

保健因素指的是，沒達成會有負面影響，但是有達成，且做得再好也不會是超越工作職掌的事情。換言之，有絕對的必要性，但是超過也沒有意義。

例如：

作為員工，準時參與會議，準時上班，按組織規定請假。
作為一個程式設計師，準時交付符合品質的程式碼。
作為客服人員，在時間內回復顧客問題。
作為專案主管，讓控制並管理團隊時程，沒有延誤

有些是屬於規定類型，有些是屬於職務範圍。這些都是歸類於保健因素。換言之「沒做到」是非常糟糕的！非但不用考慮升遷，甚至應該擔心被資遣。

要注意的是兩種對保健因素的誤解：

(a) 誤解一：消極應對

既然這並非升遷，或者有額外價值的項目，那麼也許我就做的勉強符合，60分就好。這樣的心態會讓這些的保健因素，很快的變成你自己的風險。保健因素的最佳處理方式是採用cynefin模型的「簡單因果」類型工作的處理方式。以最佳化，(或自動化)的方式處理。

消極應對，只會讓保健因素變得個人缺點，得不償失！

(b) 誤解二：這不是保健因素

在智慧型職業(例如程式設計師)最常出現的誤解是「這工作不是保健因素，我做到這件事情就是超乎期待」。

事實上，絕大部分的由上而下指派的任務，幾乎都屬於保健因素任務。

例如，你負責撰寫android app任務，根據自己的努力，確實在規範的時程內，以規範的品質上架完成。這「本來就是」你的任務。完成這件任務，的確是好事，但如果沒有做出超越任務的範圍，那就是預期內的職掌。既然是預期內的職掌，當然會取得預期內的「報酬」，例如薪水。自然也不會取得「額外」的報酬，例如鉅額加薪或升遷。

試想，你搭計程車，司機在合理的時間內，安全的把你載送到你要求的地點。你自然會付出正確的車資，不太可能付出「額外」的費用吧。

方向二：激勵因素

如果有做到，會讓人感到「很滿意」。

這個方向並不容易，但其實是「最能自己掌握自己升遷」的真正方式。

激勵因素根據工作內容而有所不同。以前述的搭乘計程車為例，如果計程車司機在車上「額外」提供一般計程車不會有的卡拉ok服務，並且未要求額外收費，在你開心的抵達要求的地點時，非常有可能自願的拿出額外報酬。

智慧型職業比較難找到激勵因素的方向。有幾個尋找方式可供參考：

(a) 參考方式一：擴增保健因素

這個方式比較基本。例如：一個app的程式設計師，被要求在6個月內完成app並上架，結果在5個月就完成，並且其品質也在要求的範圍內。對企業組織來說這個事件就算合理的「激勵因素」

(b) 參考方式二：額外的相關支援

類似計程車卡拉ok。例如：android app程式設計師，被要求在6個月內完成app上架。結果的確在時間內完成。並且，由於他採用react native，竟然也順便完成了iOS app。這就是額外的支援項目。

(c) 參考方式三：擴大 

主動執行擴大職掌範圍的任務。例如app程式設計師，其任務是開發app並上架，如果主動協助開發伺服器端，或其他功能模組，就算是擴大範圍。

更顯著的例子是：app程式設計師，其任務是開發app並上架，但主動組織團隊，做出新的實驗性質的計畫。那的確證實了擴大職掌和展示了領導潛力。

其他：

離開組織，以及自己建立組織-創業。 也是都是合理「自我升遷」的方式。

當然，離開組織之前，要先確定問題不在自己身上。如果問題出自自己身上 - 無論是能力或溝通問題 - 換到其他地方，也不可能解決問題，只是碰運氣而已。參考這篇，或者這篇，或者這篇。

創業是自己造成升遷的最簡單方式。在那一夕之間，你就變成董事長兼CEO了。然而，能不能生存並獲利，又是另外一回事。創業需要另一方面的能力與知識。要成功並不容易，參考這裡，與這裡。

---

註1：在某些地區，某些情況下，當然有不得已的時候。例如，如果你是生在阿富汗，伊拉克，索馬利亞等國家，確實很難掌握自己的命運。所以，本篇指的是一般在台灣的普通上班族。

註2：為什麼這些是藉口？請參考說明如下：

-- 自己的努力沒被別人及主管看到
-- 受到主管不公平的對待
-- 主管不賞識甚至打壓

(a) 短時間或許有可能自己的努力不被發現，甚至可能被瓢竊或者搶功勞。但長時間不可能！而且事實上，如果你真的能力極佳努力也夠，僅只是沒被看到而已？那你應該很容易可以找到更好，並且更容易看到你的能力和產出的地方！

(b) 爛主管的確有可能打壓好員工，但沒有人強迫你為某個主管工作，你當然可以離開。但是在離開之前，請先參考這本書(我愛白痴老闆)。也可以參考（得罪老闆怎麼辦）


-- 組織內制度有很多問題

(a) 大企業制度上不可能完美，因為制度目的通常是為了企業生存。只要企業符合法律規範(在台灣是勞基法)就沒什麼好抱怨。並且，適應制度也是能力的一環。當然你也可以自創一個擁有好制度的組織。


-- 負責的工作實在太艱難資源又少

(a) 如果你覺得能力不足負擔這個工作，那不升遷的確是合理
(b) 如果工作真的太難，那應該自己去換個簡單的工作
(c) 所有企業組織的資源都是缺乏的，資源缺乏不是問題，只是現實

-- 負責的工作實在太簡單沒有挑戰性

(a) 如果你覺得工作太簡單，可能是因為主管覺得你無法負擔更重要的工作
(b) 也有可能對你來說工作太簡單，但是對主管來說你沒把簡單的工作做好，以致於無法給你有挑戰性的工作


-- 景氣不好公司不賺錢就罷了，還在裁員
-- 比我資深的還很多，很難輪到我

(a) 如果升遷是你最重要的考量，應該離開這類型的工作環境

企業巫醫 - 提昇效率的秘方

這裡有幾本書...

- The Productivity Project	最有生產力的一年
- Four hours work week	一週工作四小時
- The Art of Non-Conformity	不服從的創新
- THE $100 STARTUP	三千元開始的自主人生
- Do over	(不確定是否有中文翻譯)
- Nomad Life	遊牧生活

這些書籍有很直接的共通點：

(1) 個人經驗

和一般以二手資料的企業巫醫的書不同，這些書籍都是以「個人實際經歷」為主要組成。可能沒有精湛繁複的巫醫術語，但是「因為自己有做過」也比較容易說服別人。

(2) 專注，效率，生產力

這些書籍或多或少都強調個人效率的重要。基本上不外乎討論80/20法則，生理因素，心靈意志，工具方法等等。

(3) 個人品牌創業

這些書籍的作者，其實都是「個人品牌創業家」。個人品牌創業大約在2006-2008年之後，在網路上蔚為風潮。特別是在北美，這些個人品牌創業家通常都會有(a)自己的blog (b)自己的書籍 (c) 一個看似專精的知識領域...接下來通常就組合優勢開始以自己的名聲盈利。

為何強調效率與生產力的重要？

合理的推測，這類型的書慢慢也會在亞洲流行起來。雖然僅只以個人經驗與觀點來詮釋某個複雜的龐大主題，可能失於偏頗。但相較於純以「個人想像」和「無根據的推理」的企業巫醫書籍比較起來，還是踏實的多。


其中，「專注，效率，生產力」是三位一體的永不衰退話題。自從有工業革命開始，效率/生產力便是工業界主要獲利來源。在1995之後的網路時代，雖然「創意」與「變革」突然成為顯學，但究竟沒有效率，無法被執行的創意，等於是一種空想。創意變為有效可執行的事項，才有實務上的意義(參考這裡)



因此，能否有專注，高效率，高生產力的產出，變成知識工作者必備的能力。而也是「缺乏資源」創業者成功的關鍵之一(參考這裡)。

而也正是因此，「提高生產力的祕方」，在近年來變成出書的顯學，甚至也成為「被創業」的利基來源(註1)。

個人提升效率生產力的祕方

很遺憾，並沒有什麼祕方可以「簡單而且戲劇性」的提高個人效率或者生產力。至少，沒有不需要努力的祕方。

在業界確實有各種「顧問」，可以針對特定的個人，特定的案例，提供收費的咨詢服務(註2)。但最終，教練顧問只能提供指引，還是只有自己幫助自己。


先考慮以下低成本的「尋找自己的祕方」的三步驟，大概只要花2天：

(1)  4小時閱讀

花四小時專心看完以下五本書就好，應該都有中文版。

- Getting Things Done  
- The Productivity Project 
- The 4 hour work week
- Lean startup
- Do Over


這些書所提的做法都比較務實，然而，不見得適合每個人。單看一本書，也會讓你的視野受到侷限。花時間去找一堆書來選，也太浪費。請先看上述幾本即可。看書並將自己覺得有用的地方做些記錄即可。

其中一本看起來是在講創業？即便你一點都不想創業，它提供的方式仍然對一般工作很有幫助！

(2) 停止接受資訊一天

如果你花了4小時看完那五本書，應該可以體驗到讓腦袋休息的重要。找一個假日，無論採用什麼方式，停止接收資訊一天 - 電腦，手機，書籍等等一概停用。隨便去做點跟工作無關的事情。

(3) 檢視並決定提升效率生產力的做法

經過了4小時學習，又經過了1天的沈澱。是時候可以決定哪一些「做法」，是最適合自己。只要是最適合自己的做法，就是自己的祕方。

如果還是想不到好方法，可以參考這篇。這是經過看了那五本書之後，經過一天的沈澱，個人認為最簡單適合自己的方式。也許對讀者也是個好的參考。

---

註1：例如，隔一陣子就會冒出來的「增加記憶力補習班」「全腦潛力開發課程」「超級記憶力」.....不過最終的結果，通常是這些提供祕方的企業巫醫們，口袋裝滿無知大眾的錢，而這些花大錢上課的群眾，其生產力與效率卻鮮少聽過提升的例子.....至少從來沒聽過任何創業有成的人曾經說：「喔！對了我創業成功的祕方，就是上了XX人的腦部開發課程，讓我記憶力變得過目不忘喔」

註2：在台灣大多以企業開班的方式存在，但這種效果極端有限。而美國英國兩地，都有針對個人的「導師服務」。但其收費都很驚人，而且大概也無法遠端服務。例如這家seven coach。也有很多個體戶，例如這位John Spence。

企業巫醫 - 如何拒絕或調整客戶不合理的需求

在各類型的軟體開發情境中，有時候開發人員會有機會面對客戶的需求。而最近就有一位研發團隊的工讀生，在即將離職時，問了一個經典的問題：

--------------
你們是如何拒絕或調整客戶不合理的需求？
--------------


問題的本身很經典，但是卻必須要追本溯源。

首先，需求(requirement)本身是很難被界定清楚，因為客戶也許也不能清楚的界定需求。Henry Ford 福特 - 福特汽車的創辦人，現代化造車的始祖 - 早在一百年前的名言，至今仍難屹立不搖：

--------------
“If I had asked people what they wanted, they would have said faster horses.”
"如果我問客戶要甚麼，他們會希望跑得更快的馬"
--------------


然而，「直接了當的詢問」仍然是基本的第一步。不過也要先確定問到正確的對象，問了正確的問題，正確地理解回答。透徹的了解問題，才能知道客戶的需求是不是真的不合理，抑或，其需求背後有另外的需求。接下來才能知道怎麼反應。

還沒經過深思熟慮就直接拒絕，很有可能是自己故作姿態，甚至是知識技能不足的表徵。(註一) 

反過來說，隨意「答應」客戶，風險也很驚人。因為也許答應了一件根本不應該做的事情，或者答應了一件其實客戶表達錯誤的事情。最悲哀的結果是雙輸：客戶與企業都受害，甚至三輸：客戶企業與社會三者都受害。

而這聽起來極端荒謬的事情，卻一直在企業界發生。


因為誤解客戶需求，或者不夠及時調整需求導致於雙輸的例子，在近20年內的有很多，隨便找一些範例如下：

* FoxMeyer的SAP引入案例(1,2)

* Waste的SAP引入案例

* 台灣戶政系統當機事件(1,2,3)




那到底要怎麼做？

1. 根據事實的正確溝通

抽象化的形容詞，對溝通不會有助益。

例如：「高可靠度的系統」「網路速度很快」「網站介面很好用」「滿足業務需求」「盡快完成」

抽象化的言語，在務實的書面報告中越少越好。當然某些摘要形式的報告，會很抽象，但隨後必定附上務實的參考依據。

例如：

「高可靠度系統」：已兩台伺服器互為備援的方式，達到高可靠度

「網路速度很快」：過去對外連線的速度是1MB，現在提高到1TB，因此網路速度很快。

「網站介面很好用」：過去每個月平均有150次客服電話，是在詢問網站某些功能要怎麼使用，現在每個月僅有10次。並且，每個月平均使用人數並沒有減少。

2. 透過具體內容決定接下來的執行事項

互相理解現在的情況是第一步。接下來要做什麼是第二步。

為什麼決定接下來要做什麼和「客戶不合理的需求」有關？

首先，合不合理的判斷本身就很難客觀。對某人來說不合理的事情，對另一個人可能完全正常。彼此價值觀的差異不可能在短時間彌平。但是「具體要做的下一個動作」卻是清晰可見，只要接下來的執行「事項」，確實都是雙方認為最重要的事項即可。

和第一段相同，具體內容必須是清晰可見的動作(action)

例如：

* 將第一批手機抽15%樣本共150隻，進行電池過度充電放電測試。並在N月N號之前，給出測試結果報告。

* 將iOS app送到apple-store進行上架審核。

* 在使用者帳號管理系統上，增加可以使用fb帳號登入的功能，在N月N號之前，給出設計文件。

不是清晰可見的動作，會造成很多不必要的誤解，而誤解就會產生不合理的需求。


不清晰的動作例子如下：

* 產線上的手機抽樣測試一下有沒有爆炸問題 -- (這是要多少樣本測試，一隻也可以嗎？要測試哪種類型的爆炸？太陽曬到玻璃破碎也算嗎？)

* 我們的iphone app要趕快上架了 -- (？是要上架到哪邊)

* 讓fb帳號也能登入系統  -- (是什麼時候要完成？只要登入就可以，細節我們自己決定就好了嗎？還是要先看一下設計文件)

3. 務實的密集檢討事實

這可能是最重要，但最被台灣企業所忽略，也最容易被企業巫醫上下其手的地方。

可參考這幾個地方：(a) 錯誤檢討，(b) 自我反省，(c) Scrum檢討


「務實」：指的是根據事實來檢討，而非根據感覺。即便是需求檢討也是。

例如：某中國企業要求網站系統必須能讓IE8使用。但是IE8上的javascript版本實在太舊，這樣的要求讓專案經理非常不高興，覺得根本不合理也太不可思議。

如果不務實檢討，那麼每次與客戶的會議，大概就在針鋒相對中度過。但是探究事實，其實是因為該企業內部系統無法擺脫WinXP，而又因為WinXP能使用的IE就是IE8，導致客戶有此需求。就網站廠商來說，當然不可能協助內部全面升級為Win10，但卻可以提供其他在WinXP上，仍然持續更新的瀏覽器(firefox)。


「密集」：指的是Scrum的精神。需要在一定時間(sprint)讓客戶看到，並且用到那段時間產出。確保客戶對團隊前進的方向是一致。也確保即便團隊方向有誤，也會在一定時間內被發現。

「事實」：有時候事實很難全面探究完整。有時候細節太多，即使都是正確的資訊也過於繁複。

巫醫在同樣的事實上，都會有不同的詮釋。例如：經過鞭打火烤病人之後，病人仍然掛了。巫醫的詮釋通常是：惡靈不願意離開病人，是天命所致。

而以「事實」詮釋「事實」才不是誤人一生的巫醫。當軟體開發團隊常常客戶不合理的需求。不應該隨隨便便將此視為「惡靈不願意離開，乃是天命」。而應該「改變」執行方式，應對不合理需求。如果巫醫不願意改變(註二)，換一個醫生是根據事實最合理的方法。

---

註一：違法的需求，當然是要直接拒絕。這類型的基本常識，不在此討論範圍之內。
註二：如果巫醫很容易以事實說服，那就不是巫醫了

因為沒挑戰想換跑道：先檢討自己吧！

新的一年，總是容易遇到討論換工作的事情。目前，台灣資訊科技領域整體仍然缺乏人才，因此要換新的工作是非常容易的事情。

真正的問題在於：什麼原因想要換工作？如何換？新工作或事業會不會比較好？自己到底想要什麼？

這些問題根深蒂固地存在每個人的身上。不會有一體通用的方式為所有人解答。

不過，如果單純只是因為現在的工作沒挑戰性，無趣而想要換跑道，還請以下三點簡單的自我審思一下。

檢討一：「沒有挑戰很無趣」的真正源頭

牌桌上的至理名言：「30分鐘後如果你還沒發現誰是冤大頭，那麼你就是冤大頭」。在企業中，如果你沒發現有任何值得挑戰的地方，那或許你自己就是沒有挑戰的真正原因。

當你的工作變得沒有挑戰，而且無趣的時候，請先確定問題的真正源頭。

是不是因為你的能力或者表現，讓你無法得到有挑戰有趣的任務？還是你的視野讓你看不出挑戰性？

還是這工作或事業的本身，真的沒挑戰性？你已經是有如NBA過去的Jordan或者現在的Curry已經快觸到這個事業和工作的極限？還是你抵達的是自我的極限？

檢討二：選項

選項，永遠是考慮決策的要件。

換工作或事業是一個好選項。但是，在既有的領域中，擴展自己的視野和能力也是一個選項。

換工作是個選項。在大企業中，換部門也是一個選項。換工作這選項中，嘗試新的技術領域是個選項，但是嘗試截然不同的工作類型（例如業務相關部門）更是更大的不同選項。

在現有工作內容中，改變自己的做法以求突破，也是一個解決的選項。

選項可能很簡單，也可能很複雜，而且還會參雜很多人的因素。去除自我偏誤，取得個人最想要的結果，比想像中的簡單。不過，要預設自己以及相關人等有完全的邏輯推理是很難的。（參考：沈思）

檢討三：「沒有挑戰很無趣」有時候是真正的挑戰

在資訊科技的領域裡，多的是把原本看起來無聊的東西，重新找到價值並且延伸的例子。

如果你可以將無聊沒挑戰性的事情，轉成有價值，並且有挑戰的事情，等於是你證實自己絕佳的創意以及實踐創意的能力。

這樣的例子在不管在哪個領域很多，從很久很久以前的gmail，到近幾年的類似snapchat的app，許多都是一開始是沒很有趣，但是找到額外的創意之後，將舊有的東西突破。

隨著組織越來越大，表面上無趣的事情會越來越多，光是默默的忍耐並不會讓事情變得更好，只有把無趣轉換成價值，才能展現自己的創意能力。要怎麼做？可以參考這篇



參考文章：換工作的面試-軟體工程師如何展現價值

---

沈思：
一個海盜集團中的5個海盜找到了100顆金幣，每一枚都一樣的大小和價值。 

由於海賊王想要這五個部下傷透腦筋，自相殘殺，規定他們分配金幣的方式如下： 

1。抽簽決定自己的號碼（1，2，3，4，5） 
2。首先，由1號提出分配方案，然後大家5人進行表決，當且僅當超過半數的人同意時，按照他的提案進行分配，否則將被扔入大海餵鯊魚。 
3。如果1號死後，再由2號提出分配方案，然後大家4人進行表決，當且僅當超過半數的人同意時，按照他的提案進行分配，否則將被扔入大海餵鯊魚。
 4。以此類推

 如果你是號碼1的海賊，應該怎麼分配金幣？

台灣博士生與大數據分析：如何評估對大數據分析的本職學能？

最近有個真實故事：

---

(為保護當事人，內容與細節均有所改變) 

台灣人F，目前就讀於某知名國立大學，已經是博士候選人。

最近為要爭取某一私立學校E的教職。在其履歷表上是以雲端計算大數據專家自稱。而E校的某系評會要求他面試15分鐘，用以評估他的能力。試教主題不限。

然而，F其實對大數據除了看過一些商管叢書之外，其實根本一竅不通。因此，他找了以前大學時候已經在業界工作的好友J，問了一些「技術問題」如下：

F：我聽說過spark，是不是大數據分析都用它啊？spark是不是個作業系統？

J：如果這是你的問題，那你壓根離spark太遠。後面就不要再談了。

F：哎喔，我覺得教學只是個演出啦，看表面而已。以你在業界打滾多年，就幫我個忙。couchbase是什麼？有什麼如果講出來會讓大家知道我很厲害的地方？

J：如果這真的是你的問題，你真的什麼都不懂啊，就算你去E校當教授，也是害了別人。

F：....

---

這個真實故事乍看之下太過駭人！但或許反映了學術與實務之間的鴻溝。

其實，台灣有許多學術界的人才，不但學術淵博，技術根底也厚。從數十年前的硬體產業蓬勃發展就可見一般。近幾年的軟體也是，許多教授幫業界「產出」能產生價值的知識性員工，並且也讓業界的知識持續推進。

然而，M型社會反映的層面，不指是一般在職場工作的人，在學術界中也越趨嚴重。

也有不少學術蟑螂。他們靠著極致的生存能力和夠厚的臉皮，穿梭在三流研討會，大企業策略部門，顧問性質演講，以及不在乎學生品質的大學院校中。

這些學術蟑螂做的事情，大概也不會真正傷害到誰，只是，也不會對任何人有好處。只要不是在「自己家裡」，一般人在路上看到蟑螂只會視而不見，也不太會去追打。

但是，如果是在自己家裡呢？

評估對大數據的本職學能，才能判斷來者是學術淵博的長者，還是費力在夾縫生存的蟑螂。如果是像E校一樣，原本的教授群並沒有這方面的背景，要如何在沒有足夠的知識情況下，判斷對方有沒有知識？這雖然有點難，但是，透過一些方式還是可以把誤判機會降低。

(1) 實際經歷探詢（情境實例面試法）

情境實例面試法很基本，但是事先有所準備。做法很簡單，只詢問「過去實際上」發生的事情，用以判斷被面試者現在的情況。而且絕對不詢問開放性問題！！

對於couchbase而言，就不會問「你對couchbase瞭解程度如何」或者「分散式資料庫你有哪方面研究」。因為這類型開放性問題，會浪費大家的時間。也會讓學術蟑螂有機會以混淆視聽的長篇大論，大打模糊仗來損耗面試者的判斷精力。

簡單問題像是：

* 請用1分鐘定義何謂nosql

* nosql的實作有很多，請舉一個你最熟悉的nosql平台工具，一個你實際最常用，最熟悉的就好(在此假設他回答couchbase)。

* 請問你實際接觸couchbase多久了？  (用判斷他最熟悉的工具有可能有多熟，如果少於6個月大概也等於是不太熟）

* 你利用couchbase為平台，撰寫並發表過哪篇論文？(學術界而言，沒有發表相關論文等於是沒有相關方面的研究）

稍微麻煩的問題像是：

* 你有沒有加入couchbase的任何相關的mail-list? (沒有加入mail list也沒關係，但表示其實只是單純的使用者，不會有太多深入的了解)

* 你利用couchbase為平台，撰寫並發表過哪篇論文中，所使用的研究資料量有多大？100G？10T？（資料量極小的nosql，並不代表不正確，只是代表不是大數據而已）

* 你用過哪些版本的couchbase（起碼要記得大版本編號吧）

* 你最近讀了哪一篇論文是以couchbase實作其研究？是大概什麼時候讀的，內容是什麼？


總之，事先準備好不能模稜兩可的問題，並且也定義好不能模稜兩可的期望回答。事先準備的問題也不需要太多，只要7-10提及可。這樣，比較不容易被蟑螂溜進來。並且，在準備的過程中，其實也會讓團隊（無論是學術還是技術團隊）對這方面的知識有基本的增長。

(2) 真實展示

簡單的說，就是請他拿一台電腦，展示一下他對大數據分析中最會「做」的事情。無論是撰寫程式碼，還是建立模型都可以。

真實展示其實很容易騙得過沒有相關知識的人。但是，如果事先已經提醒會有真實展示，可以簡單篩選掉連打開電腦都不敢的小蟑螂。

E校要求試教15分鐘，其實是真實展示的好方法。然而，盡可能展示「動手」而不僅只是「動口」。雖然君子動口不動手，但是蟑螂恐怕也是。

(3) 自我反省

當在一個地方看到蟑螂的時候，通常表示附近還有另外10隻蟑螂(也有人說是數百隻)，只是沒看到而已。會有蟑螂來面試 - 無論是工作還是教職 - 是不是這組織已經有很多蟑螂。更重要的是，自己是不是其中一部分。

自我反省是極端困難的工作，對生活優越的自己，在心理上也不見得好過。但是，在陰暗狹小的地方求生存，總是比不上光明正大的貢獻自己的能力。

請謹記，「自信心」和「自我感覺良好」只有一線之隔。或許，透過實際經驗探詢，先自我檢查自己，才是去評估別人之前，真正自己應該做的事。

Scrum - 專案壓力來自於無法掌握的命運

一個壓力實驗：

有兩個籠子(A,B)，都連結同一個電極器，各有一隻老鼠。A籠子中，有一個燈號和按鈕，當燈號亮起時，如果在數秒內，A老鼠沒有按下按鈕，則就會產生高壓電極，讓A,B兩籠的老鼠都被電的很不舒服。不過，如果燈光亮了，在時間內A老鼠按下按鈕，則A,B兩籠就都沒事。B籠的老鼠則是全然被動的，只要A老鼠能做好他的工作，B老鼠就沒事。當然，經過幾次電極之後，A老鼠很快就學會了一旦看到燈亮，就應該儘速去按按鈕。

過一段時間之後，哪一隻老鼠的壓力大？

經過健康檢查，A老鼠幾乎看不到壓力大的特徵。而B老鼠，則出現各種癥狀：高血壓，胃潰瘍，成長障礙等等不一而足。

(以上內容取自:數位痴呆症：作者Manfred Spitzer)


軟體專案的壓力和該實驗有異曲同工之妙。真正的壓力來源不在於事情有多難，而是在於自己「全然」隨著命運擺佈，無法控制。以A老鼠的情況來說，他仍然是被關著，而還得三不五時瞄一下燈是不是有亮，一旦亮了就得趕快反應。

然而，「至少有一件事情」A老鼠可以控制：他可以決定自己要不要被電極。B老鼠則是沒有一件事情是自己可以決定。因而壓力無從擺脫。

Scrum(實況)是根據事實，固定的時間，以及有效團隊分工來達到敏捷開發的精神。而在此基本精神內，每一個角色都有「至少可以全然控制」的事情，不但可以正確減低無法掌握命運的壓力，更能組合出正確的團隊合作方式。

Product Owner（產品擁有者或產品經理）

在傳統的「瀑布開發模式」，或者，系統整合商SI的「隨意無止盡需求模式」中，產品經理會就所有應該要做的事情列一個驚人的功能清單，交由專案經理負責領導開發。接下來的18個月，產品經理就在B老鼠的壓力下度過，即便有檢查，也不知道產品真正的進度。而18個月後發現意外的機率...已經不是機率而是必然。

而過於認真擔憂的產品經理，更有可能在每一段時間，修改需求，讓開發團隊變成B老鼠，不確定哪個需求改變的命運降臨。

在Scrum中的產品擁有者(Product Owner)擁有非常簡單而清晰的責任，這個責任用非常簡單而清晰的方式減低他的壓力：「撰寫並排序需要完成的使用者情境」。

專案開始時，產品經理會撰寫數個使用者情境(user story)並且排定優先順序，而每個sprint開始時，團隊會告知這個sprint(4周)會完成到第幾個story。產品經理等候4周之後，檢查這些當初答應的story是否有如預期完成，並且在下個sprint開始時，或確定，或重新排列，或增加，或減少接下來要完成story的優先順序。

產品經理仍然不會去「做東西」。然而他確實全然掌握階段性完成，並且確定每sprint開頭都能選他最想要的事情先做完。因此，產品經理確實能掌握這個產品每一段時間的「樣貌」，而不是在最後關頭才求神拜佛，或者要求加班。甚至，在sprint的中間階段，若有必要，產品經理可以要求sprint停止，重新開始新sprint，用來調整後來才發現不正確的優先順序(priority)

Scrum Master (開發領導者)

過去一個團隊的技術領導者，帶領團隊解決技術困難並協調各類工作。他常常會是夾在產品經理（或客戶）以及開發成員中的角色。

在傳統模式下，他若非變成一個技術獨裁者，用以壓迫成員前進並反抗大幅需求改變，就是變成試圖面面俱到的好好先生，用以彌平不同角色的紛爭。「能良好溝通」這個字眼會常出現這個角色的工作描述(job description)，但事實上，困難的專案，不會因為一個很能講話的專案經理，就變得簡單。最後最常出現的結果是：專案經理總是能有效呈現「自己的貢獻和功能」，但無法反應在專案成功。換言之，常常看到自己從來不失敗的專案經理，曾經領導了很多壓根不成功的專案。

Scrum Master並非傳統的專案經理，其責任和角色也有很大的不同。而他能有效掌握的事情，也能讓他減少原本專案經理的壓力。

Scrum Master 掌握「會議」。他可以確保每日會議只「說明三件事」：完成了哪些事情，接下來要做什麼，有遇到什麼困難。確保每個sprint開始的會議，領導團隊能完成哪些使用者情境(user story)，並且確定這幾個要完成的事情，產品經理都有完整而合理的描述。他雖然沒有掌握全部18個月會完成的事情，但是透過掌握每一個sprint，腳踏實地的一個一個完成優先要完成的事項。

Scrum Master 掌握「真實進度」。透過領導決議「和未完成」以及以事實展現的燃盡圖，Scrum Master掌握過去真實進度。因而可以有效推測未來進度，並有足夠的證據顯示給產品擁有者。因此，才能有足夠的「動作權力」成為A老鼠：仍然在籠中，但掌握部分真實權力，以減少壓力。

Member (團隊成員)

傳統模式下，團隊成員經常是壓力末端。所有的壓力最後承受的出口。所有過勞死最可能發生的地方。傳統上最常出現的是：「某功能我們在要X月X日之前出來！」「現在馬上改做XX不然沒辦法驗收」。

而傳統的產品經理和專案經理 - 無論是軟性還是強硬 - 通常不得已的把壓力直接轉嫁給團隊成員。

但是，在Scrum中團隊成員，決定使用者情境：「真正完成的所需要的時間」。而這個權力，僅代表一個事實：由做事情的人傳達做事情的時間與結果。成員不再在決定什麼事情先做後做，只要決定現在在做的事情，什麼時候可以完成，以及「真的去做他」。換言之，Scrum團隊真正的A老鼠，其實只有團隊成員，只有他才會真正的按下按鈕。然而，如果Scrum團隊不能掌握分工負責的精神，團隊成員很快就變成B老鼠：不是被無謂的壓力掌握自己的命運，就是試圖跳脫牢籠。