軟體工程師的職稱頭銜重要嗎？

軟體工程師根據所在的環境不同，通常有不同的職稱頭銜。例如：程式設計師，工程師，技術經理，架構師，策劃工程師，平台工程師等等。對應於英文可能會有：programmer, engineer, technical manager, architect, principle engineer, platform engineer。 在大組織中，升遷可能是職稱上的轉換，例如在前面加個「資深」，大家就都知道你被升遷了。

對於轉換新的工作來說，職稱頭銜是否重要呢？

1.以工作的本質來說不重要

就技術為主的軟體工程師來說，(假設並沒有直接負責管理員工)，職稱頭銜幾乎不重要，更重要的是做事情的內容和能力的展現。

假如在一個組織裡，一位新進員工的職稱是「sr architect資深架構師」，但他的工作內容實質上是對客戶提案，撰寫業務報告。則其實他是做接近pre-sales或者sales-consultant的工作。在未來無論是組織內部還是他要對外尋找工作，通常還是評估實際做的事情為主，並非職稱。

2.以團隊角度來說可能很重要

職稱是公開的，一個團隊組織裡如果有工程師，資深工程師，資深架構師這三種不同職稱的人：一般來說，大部分的人會傾向遵循同意資深架構師的意見。特別是剛組成的團隊或者互相不認識的團隊。畢竟，職稱的功能有時候類似制服，當你在路上看到穿著警察制服的人，在需要協助的時候自然而然會傾向找穿警察制服的人幫忙。

然而，就軟體開發組織成長來說，職稱的重要性是伴隨組織成長的缺點。這個缺點和人類的認知偏誤有很大的關係：團隊貢獻中，絕大部分的人會認為自己佔比重比較大，因而，在決定升遷或者其他公開獎勵時，一定會有很大比例的人覺得自己沒被升遷是不公平的。

團隊貢獻中，大部分的人會認為自己佔比重比較大：許多實驗（參考這裡）都說明，假設一個團隊的總貢獻是100分，有10個人自己評估自己佔的比重，並且加總起來，很容易就超過150甚至250，但這實際上是不可能的。

也因為大部分的人都有這種偏誤，導致於職稱很多時候對軟體開發團隊有負面影響。如果有重新建立軟體開發團隊的機會，可以採用「無職稱」或者「自選職稱」的方式。

3. 無職稱頭銜讓團隊與夥伴的三贏

當組織沒有職稱時，無論是中期還是短期發展，組織成員會更專注於「實質工作產出」而非「表面變化」。這對組織，對團隊成員，甚至對組織外的人都有好處：

- 對組織的優勢

在組織內，成員都知道自己「做出的事情」才是決定自己的「職稱頭銜」，而非「職稱頭銜」決定自己「做出的事情」。自然而言，團隊成員就會以提高自己的能力和對組織的影響力，並且使用的方式不會是以頭銜和權威。升遷和加薪兩者同時都變成機密，再也不會影響其他人的心情。

當組織要招募人才時，組織會更專注於了解應徵者「過去做的事情」，而不是過去有的頭銜職稱。過去我們面試的時候，常常在履歷表中看到非常驚人的頭銜，但是實際上做的事情可能非常基本。

無職稱會讓面試的效率提高，錯誤率降低很多。

- 對團隊成員的優勢

當團隊成員想要換工作時，在他對外面試的時候，很容易就專注於展現自己的產出。而非說明自己的頭銜。

同上一小節之說明，團隊成員專注於工作的本身而非頭銜的表面公平性不足時，更能發揮自己的潛力和提高產出。

- 對組織外部的優勢

其他外部組織在遇到沒有職稱的人前來面試時，更容易專注於尋找人才得要件。換言之，本來評估能力和是不是適合，本就不應該和職稱有關。已經有人自己不帶著職稱頭銜前來面試，就更容易避免錯誤。

建立高度自我激勵之軟體開發團隊的三個方向 (軟體主管的31堂課)

1999年美國的籃球夢幻隊1992 dream team 是所有籌組團隊的人遙不可及的夢想。他們除了籃球技術精湛，經驗豐富之外，更重要的團隊都有拿到奧運金牌的唯一目標，此一目標會讓他們自我激勵，根本不需要額外的刺激。這樣的團隊組成似乎可遇而不可求，在軟體開發的世界幾乎鮮少看到例子。

無論如何，建立能高度自我激勵的團隊，是主管最重要的工作之一。如果你是團隊主管，你必須認識到這是你最重要的任務。

自我激勵會造成工程師的職涯成長，而看得到自己的職涯成長，是能驅動效率的最好的因素(註1)。

軟體開發工作，通常是需要高度的心智活動以及集中的創造力。要造就高強度心智活動，幾乎很難單純由「薪水」或者「物質獎勵」來滿足工程師。加薪獎勵與升遷固然非常重要，但它能維持的效果頂多3-6週，之後所有的工程師都會認為這樣的加薪獎勵與升遷是「理所當然」，並且很快地將獎勵拋諸腦後。這不是說工程師都不懂惜福，而是研發工作本來就很大部分的來源會來自成就的滿足感，而成就的滿足感幾乎是加薪升遷無法長期提供的(參考 1)(註2)。非營利事業有可能天生就存在這樣的激勵因素，例如，慈善組織試圖拯救世界的所有窮困兒童，研究組織試圖大幅延長人類生命到200年...然而這些組織一般都有極為獨特的目標以及具有個人魅力的領導者。

一般的營利組織以及軟體開發團隊如何建立一個能自我激勵的團隊呢？

有三個方向：(1)選對人 (2)找交集 (3)自我導航

(1) 選對人

在選用人才時，就先確定此候選人是正面思考，能自我激勵，自我成長。因為要維護一個人的正確態度，比要矯正一個人錯誤態度來得容易太多。

換言之，選擇已經能夠自我激勵，並且確定此候選人在他過去工作經驗中，已經有自我激勵的事實。

不要選擇個人技術能力很好，但卻在自我激勵上面有非常負面的紀錄。因為，要培養技術能力並不難，但要改變人類的思考模式實在難上加難。現存的coach教練式領導，不過也就只是希望透過引導，造成行為上的調整(參考富比世, 英文版？)，要引導到行為心態的調整，教練(coach)幾乎必須要和學員長期合作才有辦法做到。

選擇的重點在於透過過去的實質發生的紀錄，而不是透過詢問未來的問題。這個做法在選人時非常重要，選擇能高度自我激勵的人才，此人必須在過去工作時，已經展現高度自我激勵的情況。例如，你可以詢問面試者：「請問你最近工作上遇到最艱難的狀況，或者壓力最大的狀況，當時你是怎麼處理的」。這個問題重點在於"最艱難"以及"當時怎麼處理"。有時候面試者可能說沒遇過太艱難的情況，那麼也可以詢問"普通難"或者"壓力普通大"的情況。一個工作超過3年以上的人，當然可能運氣超級好，從來沒遇過艱難狀況，然而絕大部分的人，都可以說出幾個艱難狀態。這時候，不需要太早評斷，也不用加入討論，而是要徹底瞭解，在這個狀態下，面試者通常會表達過去的事情和想法，暫且將其想法放在一邊，妥善記錄事實。最後再由事實來判斷。

舉例以下的對話為例：

主管：「請問你過去遇到工作壓力最大的時候，當時是怎麼處理的？」

面試者：「之前在HXC工作時常常加班到很晚，要趕專案當然覺得壓力很大。怎麼處理喔？就想說當練功啊，學到東西我就要離開了」

主管：「當時你如何判斷已經學到東西然後可以離開了」

面試者：「呃？...就那時候我負責的app都推出去了」

此例的事實是。面試者因環境工作時程長壓力大，處理的方式是轉換心態-當練功，並且設定好離開環境的方式。請記得在此並不判斷好壞，而僅是記錄而已。然而，設定好離開環境的方式並不是以學到東西為主，而是做完東西。光是這樣可能還不足盼對此人是能積極自我學習還是消極無法激勵，需要更多挖掘過去的行為的討論才會確定。

(2) 找交集

我們不可能知道別人腦袋在想什麼，每個人都有所謂 left-hand-column，即便已經選擇最能高度自我激勵，自我成長的人才進入團隊，而且他們也都是非常坦誠並努力工作的人。但我們要知道每個人都有不能說，不想說，或者不適合說的事情。 
有些領導者會試圖找出這些事情，但其實有沒有找到不重要，重要的是「重視left-hand-column的存在」。

一個好的領導者，會找出交集。確保雖然人人有不同想法，但整合個人，團隊以及組織的交集，大家可以獲得三贏狀態(win-win-win)往同一個大目標前進！

當然，一個能力好而且能自我激勵的成員，可以自己找到此交集。不過身為領導者或主管，應該要時時注意：每人對這個交集其實都不太一樣。但好的團隊的每個人，應該都有部分交集。

最底線是：一定要避免三輸的局面。聽起好像很荒謬，但軟體開發的世界偶爾常聽到雙輸或者三輸的狀況。不必要的長期加班，幾乎都會造成雙輸或者三輸。長期加班必然會造成人才的耗損，幾乎也不能避免地造成團隊無法緊密成長，所以起碼就是雙輸，最後也常常造成組織本身無法長期經營，那就變成三輸了。

要建立能自我激勵的團隊，找到每個人不同的交集點。如果真找不到，則很有可能該人才並不適合這個組織，如果一半以上的團隊成員你都找不到目標的交集點，或許你本人並不適合當領導者。

交集點的例子很多，某些有資深能力好的工程師，除了團隊環境之外，或許可兼顧家庭是職涯的重要考量。因此，彈性的工作時間，和受到控制的可在家工作，就會是這類資深工程師(註3)的「left-hand-column」而這可能是最容易取得交集的地方。做法很簡單，就是讓資深工程師自行定義產出和目標，

(3) 自我導航

自我導航(Autopilot)是指團隊成員知道自己為什麼要做，知道該做什麼，知道怎麼做，知道什麼時候做。而更有甚者，他知道自己什麼還不會，所以需要特別努力學什麼。

一個能自我導航的工程師鐵定是資深的工程師，他會自我衡量自己在團隊中的「交集」也會自己「選擇」適合成長的環境。換言之，根本不需要煩惱這樣的成員。

對與已經是自動導航的工程師，僅僅只需要「教練式引導」(coaching) 。領導者或主管，應該必須對coaching有一定程度的了解，如果還不了解，現在就是學習的好時候。

在此最底線是千萬不要micromanagement -  也就是枝微末節都要管。大部分的資訊工作都是高度腦力工作，枝微末節都要管意味兩種可能
(1) 團隊成員根本無力勝任這樣高度腦力工作，而你組出這樣的團隊表示你也不適合作為建構團隊的人
(2) 團隊成員可以勝任高度腦力工作，但你身為管理者想要插手，表示你並不了解高度腦力工作的統御管理方式，所以你大概也不適合作為建構團隊的人。

要怎麼樣知道領導者管理者是不是「微觀管理」？只要看他實際做的事情就知道，當時「實際要做的事情」超出「本身的意義」就是這類型。

舉例來說，上班有規範時間，並非微觀管理，沒有規範在大部分得時候反而浪費大家的時間。然而，毫無彈性的硬性規定人必須出現在辦公室的時間，其實就超過規定上班時間的意義。對軟體開發團隊來說，上班時間規範是為了讓團隊容易一起面對面討論，互相砥礪解決問題。例如組織定義9:30~18:30是工作時間，然而，因個人因素不在範圍之內，例如想要8:30~17:30只要該成員能確保他的scrum團隊夥伴都知道他和大家時間略有不同即可，成熟的團隊的紀律來自「自我認知和團隊合作」，並不需要管理枝微末節。同樣的，「規定現在要加班」也是某種程度的管理枝微末節，順便強調一下加班其實是解決問題最爛的方式，尤其是被規定加班。

抱歉 沒有什麼神奇的快速方式！

組織理論其實並沒有捷徑，也沒有什麼神奇的快速絕招。然而只要方向正確，忍耐個幾個月都會看到成效，但是簡單的路總是難行。當然，特定快速的環境 - 例如非常新的新創產業，還不確定能否獲利 - 似乎不值得這樣長期投資？也有不少人主張時間不等人？然而，對大部分的資訊產業來說，大部分的情況是跑馬拉松而非短跑。

技能與績效的考量:

在這裡省略一件很重要的事情！
我們並沒有討論技術能力和工作績效，但其實在軟體開發團隊中個人技術能力與個人工作績效是非常非常重要的！沒有好的能力與產出，要怎麼激勵自己恐怕都沒太大用處。然而，績效和能力應該比較容易在面試與履歷表中檢核出。因此才不在這裡討論。

---

註1:  要使團隊有高效率，自我激勵是最好的方式 。然而其他方式也存在，例如鞭子與蘿蔔。
註2:  但是如果薪水實在太少，不能滿足基本需求，就不在此討論範圍之內。
註3: 不過要特別注意，資深和年紀沒有絕對關係。必須要是做事態度資深，而非年紀資深。

企業巫醫：創業初沒準備好 就先別找工程師（讀書心得）

Don't hire a software developer until you read this book是一本有趣的書，它的副標題是：學習如何管理應用程式的開發流程，確保你的手機程式，網站，網路應用的產品會成功做出來。

這本書和一般的企業巫醫做法略有不同，它只專注在一個單純面向，就是「非軟體人員如何建構軟體開發團隊，並且做出自己要的產品」。實務上，它是一本工具書。裡面的Pro Tips直接而且不廢話的指出應該要的做法。

這本書花了好幾個章節，大致闡述了近年來軟體開發的相關技術與運用，並把重點放在非技術背景的創業者，如何組織建立軟體開發團隊，並且讓團隊往期待的方向前進。

做得到書上的內容的人，大概就是程式設計師心中的好老闆，或者是好ＰＭ。

然而，這本書其實也非常適合給「程式設計師」閱讀

它展示非技術人員領導軟體產品開發「真正關心」的地方：也就是實際產出。至於開發人員使用的程式語言，使用的軟體工具，甚至想要把產品做的完美...這些都是不是考慮的要務。

例如，在書中說明新創產品開發常犯錯誤的幾條

(1) 為求完美把錢燒光了：

MVP需要的是最小規模的產品以及最好的品質。但太追求完美因而增加太多附屬功能，在作者來說是一種無法控制的浪費

(2) 輕忽看似很小的需求規格改變

例如某些開發人員會說「這不會花太長時間，只是把按鈕從這邊移到那邊」。開發人員當然會負責搞定，但是要求預估時間是創業家一定要做的事情

(3) 忽略測試

測試的重要性應該不用多提。然而非技術人員很容易忽略測試的重要。

(4) 即將上線前做需求改變

對作者來說，這等同於自殺任務。其實資深的軟體工程師在內心深處都很清楚這點，但是創業者或PM想要自我毀滅的時候，又有多少人可以阻止？

(5) 開發中後期增加人力以加速開發

在人月神話這本書中有很長的篇幅描述，很多時候增加程式設計師只會讓專案速度更慢。



此外，一般開發人員也可以透過這本書獲得Lean-Startup的精神概念與實務上Agile開發的整合。
舉例來說：它說明了Agile原則，以創業者的角度，來看agile的各種方法論對軟體開發的好處。並且也拿實際工具(Trello)，展示一個創業者實際對開發團隊該做的動作，連同移動Task Card都說明很清楚。MVP，如何做出最小可行規模的產品。從創業者的角度，來看這些工具，其實更可以讓軟體工程師知道專注於最小變動需求的好處。

How to build a self-motivated software developer team

A team which all team members are self-motivated is a dream team where everybody want to join in. But, it is really rare. Well, maybe the 1992 dream team was one of the cases but we didn't see many examples in software developer's world.

Nevertheless, to build a self-motivated team is a major task of a manager. If you are the manager, this should be your priority-zero task, and should be only one zero, if you are going to build a new team.

Self-motivated might be the best way to drive software engineer's performance. Since high productive engineer works high involved in creativities and mental work.  These are hardly be gain or impacted by salary or physical award (reference: 1, 2, 3). Sometimes it could be driven by a noble target: save all poor children in the world, increase average human life to 200 years. But unfortunately, that kind of things normally happens in non-profit organization with a born charismatic leader. 

So how to build a self-motivated software developer team in a common working place?

Three key points: (1) selection (2) intersection (3) automation.

(1) Selection

If a member who is already a self-motivated person, then it will be easy to keep his good attitude. Since it is pretty hard to change a person's mindset, therefore to get a right person is the most easy way.

Do select a person who already has record on self-motivation. DON'T select a person who has good skill-set but has bad records on self-motivation and you believe you can change his/her mindset, I won't say it is possible but you need to understand that you really have much less changes. Since you can't be with the person 7x24 and his mindset is only inside his brain.

The key point of selection is try to understand his past. Do not judge his "self-motivation" by ask future question like: will you be self-motivated in our team? Understand his past working experience by asking the difficult moment. Especially, sometime he might not be in spotlight and what he did on that moment.

Again, identify a person's past is the best way to select right attitude candidates. And a best fitting person can really have positive impact for the team. 

(2) Intersection

There is no way to read team member's mind. People have left-hand-column, even if you already selected best people to join your team and you were very sure they all are honest. But they surly have things which can't tell or won't tell.

Some leaders or managers will try to dig it out, it is fine to do but not that easy. The best way is to admit the existence. And then leaders should focus on the intersection which is the area that covers the target of a single team member, the team and the organization. And that is also the area where creates win-win-win.

A self-motived member could find that area by himself. But if you are leader/manager, you should keep in mind that figure out the area and knowing the area is very different in each individual. To fine tune a bit earlier can largely reduce the risk of un-motivated situation.

For example, "Ken" is always in good performance and deliver pretty good result. And you believe that you knew that his career interesting is pure technical area. Which means he might want to be an architect in the future. However, if you see he is pretty happy to lead junior members to work out teamwork activities, for example : organize a study group, handle company travel, or year end party. That might be a sign of that he is actually want to be a manager in the future. If his actions is toward his goal then it is fine. However, if his actions didn't reflect your assumption, then it is your time to reset yourself or/and make a little changes.

The bottom line is to avoid lose-lose-lose situation. This sounds funny and should not even considered to happen. But there are too many true sad stories existed in the world. An usual/typical sample in software developer's world was: a team (which members are well-pay) worked over-time on an ambiguous project for months, delivered a product which didn't fit PM's expectation, company lose money, members lose life, customer didn't get result: no body wins.

To avoid 3-lose situation, make sure there is an intersection of all. If you were the manager, make sure you can guide your members into his own intersection. But if you really see that there is NO intersection at all, make sure to create one.

(3) Autopilot

Autopilot means a member knows exactly what to do, how to do. And most important thing is if there are tasks out of his current skill set, he will know how to learn. He can even do self-consideration of intersection and selection. Totally worry-free.

Again, if the selection was done good, to let team member become autopilot will be easy. All you need to do is coaching. Coaching is another topic of a few books plus lots of trainings/experience. If you are an experienced leader/manager then you already know how to do, just reminder to keep open your mind. And also please keep in your mind that open-your-mind is never easy.

The bottom line is to avoid micro-management.  Software development is highly brain consuming job. Micro-management never works in software development, it does work in other kind of job but it definitely doesn't work in software development. If you need to talk to your member about when to arrive in office, when to leave, what to update in Slack, how to write email. That means you are NOT trying to build self-motivated team or this specific person won't fit in a self-motivated team.

Sorry, No short-cut

There is no short-cut in for organization theory. However, practically do the right things normally will get the positive result in a few months. Of course, sometimes in a rapid startup environment, it seems no time to wait. But most of us in software developer world are running marathon not a sprint.

Skill sets and performance concerns:

There is one more thing. I didn't discuss skill sets and performance here. But this is actually extremely critical for a software developer's team. Without an excellent skill sets and performance delivery the self-motivated will be useless. However, this "should" be not difficult to identify during interview and resume check.

中高階人才選用：成長心態鑒別的技巧

或許Carol Dweck這名字有點陌生，但是這位1946年出生的教授與她指導的學生(Lisa S. Blackwell, Kali H. Trzesniewski 這兩位才是研究作者，教授是列為共同作者) ，闡述的學習成長理論，卻經常的出現在教育界與職場上。

簡單的說，根據對美國小朋友的實驗，鼓勵「成長作為」比鼓勵「天賦能力」更能讓小朋友學習快，解決問題更有彈性，獲得更好學習效果。說的更直白一點，要多對小朋友說：「你做的很努力唷，好棒棒」「你做的方式很有創意耶，好棒棒」，千萬不要對小朋友說：「你好聰明唷，好棒棒」「你好厲害喔，好棒棒」。研究者把小朋友的內心，分成兩種心態(mindset)：成長心態growth mindet，以及，固定心態fixed mindset。說的更直白一點，這些研究認為擁有成長心態的小朋友，未來的發展無限，人生就是彩色的。由於這個研究，引發了之後的更多類似相關研究，對於教育者而言，某些過去鼓勵方式，反而可能對小孩子有錯，而後，這些研究者，成立了 Mindset Works公司，開始賣服務與各類教材。

各企業巫醫們，自然能從中獲得啟發。比較好的像是lifehack，所做的此圖也還真的有啟發性。

對於企業組織要選用中高階人才，自然會希望找到「具有成長心態」的而且「很有能力」的人。換言之，就是要找在龜兔賽跑中，早就已經跑很快，而且也謙虛向學的兔子！對於已經具有十多年工作經驗的老江湖，確蠻有可能在面試過程中，不著痕跡的隱藏自己。那麼企業要如何找到具有「成長心態」的人才，而非找到「很會面試隱惡揚善」的人才？

當然企業不可能重複一次Dr Dweck的實驗，不過確可以用情境實例面試精神，找到簡單的三個「事實」來鑒別人才。

請緊記情境實例面試的原則：了解此人過去的經驗與能力，而非此人「對未來的憧憬與幻想」。換言之，企業組織雖然是為了未來，才需要雇用人才。但是，鑒別人才確必須要依賴了解這位候選人「過去的事實」。

1. 困難問題實例：最近2,3年來，解決最艱困的工作方面問題是什麼，自己如何解決？

這個問題必須要問的簡單清晰。畢竟一個有10多年工作經驗者，必然會遇到困難問題，而既然是最艱難的問題，必然有下列幾種狀態，確實問出幾種客觀狀態，來鑒別此候選者的成長心態。

(a) 問題的艱難程度：不能太過簡單無聊的問題
(b) 此人對此問題的獨立貢獻程度：也就是是這個人「做」的，而不是他「叫別人做」。
(c) 問題解決方式的創意：這和下一題可能有關，但艱難的問題不見得要用創意的方式解決。

如果是資訊科技產業，這個問題要修改為「技術相關的艱困問題」。

2. 創意問題實例：最近5年內，對組織做出最有創意的貢獻是什麼？

此問題的基本精神在於，一個具有成長心態的人才，一定是會做出有創意的貢獻。當然也不可能每天都有創意，把時間放長為五年，應該已經很寬鬆。必然要透過這個問題，以及接下來的對話，確實問出以下客觀狀態：

(a) 這個創意，是此候選人「做」的，而不是他「叫」屬下做，或者是「建議」別人做的。
(b) 這個創意，範圍夠大，確實有所貢獻。
(c) 這個創意貢獻是否能有實質證明。

3. 失敗問題實例： 在工作上，做過最爛最失敗的事情是什麼。

雖然這是面試的老問題，但此問題必須按照事實，看出是否有「避重就輕」。特別是，許多工作十幾年的人，在職場都可以歷練出舌燦蓮花的本領。因此要檢查幾個事實狀態：

(a) 問題的嚴重性：確實有些人運氣特別好，工作十幾年都沒犯錯過。但這個機率實在太低，當一個候選人簡單的講一些根本不是失敗的例子，大概就只是避重就輕。面試時，可以簡單值說：說這些失敗其實根本不重要，能否在舉一個「嚴重犯錯失敗」的例子。另外也有可能是，其過去十幾年來工作內容太不重要，以至於沒有嚴重失敗的經驗。

(b) 失敗的歸咎責任：詢問問題時，一開始請讓候選人自行暢所欲言，許多固定心態(fixed mindset)的人，在能夠暢所欲言的時候，自然而然的會把責任轉移到非自我本身。例如：「那時候我們的QA根本沒找到問題，所以後來系統出錯的時候...」或者是「當時我們的人力不夠，所以就只能拖延...」

(c) 事後的影響：成長心態的人，對於重大失敗會有決定性的影響，因此，這個失敗事件，能否對他後來的「行為」「想法」有改變才是重點。

固定心態的人，很有可能會說「以後運氣還不錯 就沒發生同樣的事情了」或者「也就是因為如此 所以我才想離職」，更慘的是，規避了解失敗的真正原因，特別是曾經當過主管的失敗例子：「因為之前的屬下太過自由導致出問題，所以我現在就很嚴格管理所有細節」「那時候跑scrum有很多問題，所以現在都不用scrum了」。

成長心態的人，則比較傾向找到失敗的真正因素，改善真正因素：「那時候跑scrum有某某問題，所以我們現在scrum會做XX調整」。而重大失敗，更是會變成具有成長心態的人，隱含的內心記錄的一部分。

建立軟體開發團隊 (1) 計畫 組成

... of the 20,000 notable players for us to consider, I believe that there is a championship team of twenty-five people that we can afford, because everyone else in baseball undervalues them...(Moneyball 魔球)


軟體開發團隊的建立和運作，不可能有完美的狀況。但是，妥善的計劃，能大幅降低軟體團隊的運作風險，並且讓團隊成員專注於發揮專長和創意，減少不必要的浪費時間。

特別是浪費時間在於解決非技術性問題。


問題有可能來自各方面，例如：

(1) 目標極端困難。例如：要在3個月內完成類似AWS EC2的雲端運算平台。

(2) 目標不確定性極端的高。例如：團隊目的是要完成一個不知道誰簽訂的模糊合約。

(3) 團隊還沒組成，目標也還沒確認，就已經有時間壓力。例如：一個2-3個人合作的新創公司，剛剛獲取資金成立。

(4) 團隊的組成有時間壓力。例如：在大企業中，因為高層要求，一定要在某月某日找齊7個人組成團隊

(5) 團隊已經有部份是問題成員，在此同時還要因組織任務擴張而增加人力。

(6) 因為組織變動(例如企業改變目標，併購等等)，讓某個團隊大幅流失人才，而需要重整補齊人力。

(7) 因為文化與跨國合作困難，導致前期人力大幅流失而需要重整團隊。


負責組織團隊的人，最最基本的認知就是：

軟體團隊組成這件事情：本身一定會有困難與挑戰。不具備困難與挑戰的軟體團隊，其實沒有存在的必要。(註1)


以下三個步驟可以供組織團隊負責人參考：

(1) 了解探索事實，盡可能將事實攤在陽光下

許多新團隊一開始就建立在「各種假設」上。例如新創團隊「假設大家對Scrum都有相關經驗」，或者「假設在3個月後可以找到2個優秀的iOS開發人員」，或者「假設大部分的使用者都有fb的帳號」，或者「假設3個月內某個模組可以先行開發完成」。

在許多情況之下，很多事情的確有假設，才能進行下去。

但是，在建立團隊的時候，除了瞭解背景假設之外，先確認事實才重要。

以下事情必須要儘早確立。

(a) 團隊目標願景：

可參考下節「確切定義短期中期目標」。如果是非營利組織，團隊願景就非常重要。因為這可能是召集成立團隊的最大動力。一般企業，營利組織，除了獲利之外，也可能會伴隨其他更遠大的目的。例如：「讓人類可以移民火星」之類的(註2)。

一個有崇高理想的非營利團體，也就不應該將盈餘拿來作為績效獎金。而是以團隊能達到的願景作為激勵人心的最大方式。(例如Kiva)

相對的，如果只是單單純純想賺大錢的公司，例如某東南亞賭場在台灣的軟體部門。也就不需要唬爛一個崇高的偉大目的，就只要讓團隊了解「大家來歡喜寫程式賺錢吧」即可。因為有正確的認知，才能集合正確的團隊。一個誠實的宣稱「大家來寫程式賺錢吧」的團隊，自然不會將社會責任活動當作是團隊成員想要做的事(例如：到沙灘撿垃圾，協助獨居老人)，當然「培育企業人才」也不太需要，甚至Scrum裡面的「自己選取task來做」也根本不用，採用由上而下的軍隊式管理，讓工作以最有效率的方式完成，才是這種團隊的最好方式。


(b) 資源現況：

目前的現況是不可否認的事實，但許多人一開始的時候，會將現況和未來的希望混為一談。在此時此刻擁有的資源就是現況。

例如：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人。...這就是資源現況。

但也有可能是：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人，但是辦公室座位目前只有4個空位。...這也是資源現況。

更有可能是：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人，但是辦公室座位目前只有4個空位。而團隊目前總薪資預算為1千萬台幣，其中還得包含筆記型電腦採用費用。扣掉已經到職的兩個人，年預算只剩下600萬台幣，所以可以找10個人，但是平均年薪只能為60萬，或者找6個人，平均年薪為100萬。...這也是資源現況。

作為一個建立並組織團隊的人，資源現況的瞭解和掌握，必須要越清楚越細節越好。實際上，絕大部分的情況下，只要稍微多花個幾個小時，就可以掌握到很多現況細節。


(c) 組成專長：

即使已經是軟體開發的專家，這仍然是一件需要擔心的事情。

如果團隊的短中期目標確定，組合的專長可能大致確認。然而，某些專長不見得是「團隊成員需要有的」，這些專長可能可以用「短期購買」取得。

團隊領導者在取得事實的階段，需要清晰可見的專長分佈圖。

以上圖為例：簡單地列出做一個購物網站可能需要的專長，並且也把目前團隊已經擁有的人才能力列在其上。未來在組合團隊時候就比較容易考慮周詳。

要注意的是，這樣的圖並不是要完全技術上正確，而是要做為未來計畫的參考。因此有可能一再修改，也不見得需要用了不起的繪圖軟體製作。


(d) 關鍵成功因素：

哪件事情做好了，會讓這個團隊成功。成功關鍵因素應該只有1-3個，不應該太多。 這個關鍵成功因素必須要很「實際」，能夠被「衡量」，當然也必須要是能「達成」。至於困難不困難就不一定。以xspace的火箭設計為例，他的關鍵成功因素不只是火箭能發射，還要能「掉回地球後，能自己站立，以便低成本回收」。

軟體開發團隊的「建立組成」的通常是願景能否達成的關鍵成功因素。然而，建立組成的本身也有關鍵成功因素。例如，在2個月內吸引3個具有5年工作經驗，並且容易合作的工程師到職。



....其他需要搜集以及展現的事實還有不少。完整清單請參考(註3)。當然，不可能花幾百天的時間，只是為了收集事實，只要在合理的時間內，盡量收集了解重要的事實。

(2) 確切定義短期中期目標

前段所述的事實如果了解的夠完整。定義短期中期目標就很簡單。

短期目標是1週到4週內「必須」完成的事情。中期目標則必須要能夠「完成一項的關鍵成功因素」。

以建構軟體團隊而言，八九個短期目標完成後，差不多就等於一個中期目標完成。

任何軟體開發計畫，必定會有目標，而讓團隊朝向「同一個方向」前進。所謂團隊，當然是一群人往同一個方向前進，才能叫做團隊。一群在同一個組織架構的人，或者在同一個老闆底下工作的人，不見得是一個團隊，很有可能每個人在軟體開發

(3) 根據目標擬定計劃和備用計畫- Plan B

兵法有云「夫未戰而廟算勝者，得算多也；未戰而廟算不勝者，得算少也。多算勝，少算不勝，而況無算乎！吾以此觀之，勝負見矣。」

計劃本身並不重要，但是做計畫這件事情很重要。

計劃要達到的目的要非常清楚。而且必須「至少」包含兩件事情！

*** 達到短中期目標的做法 
*** 實質建立工作環境與實際做法

建立軟體開發團隊的初始計畫至少需要涵蓋以下內容：

(a) 團隊目的，短中期目標

....請參考前兩段...

(b) 團隊組成

需要哪些專長的人在這個團隊。更重要的是，哪些技術背景的人的組成最適合這個團隊。最好的方式是將所需要的「實質技術能力」清楚地列個圖示，根據分佈圖，來劃分團隊組成。

切勿用想像的方式。

以上圖為例：這是一個打算建立電商網站的技術分布圖，和目前團隊成員(四個人)所擁有的技術連結。可以很清楚的看到哪些領域還沒有適當專長的人。也可以清楚地展示，團隊目前組成和未來最需要的地方。

這個草圖並非正確的描繪出細節，而且也把技術不相干的東西納入（例如裡面有個API doc，其實是還沒有去做的事情）。但整件事情的精神在於「視覺化」。透過視覺化，對團隊的變化才有整體性的考量和規劃，而不會落於枝節上。


(c) 團隊運作原則

近年來流行Agile的Scrum方式。可以參考這裡。


(d) 初始化工作項目

當團隊的成員是逐漸到職，最初的工作項目是能夠讓團隊快速形成共勢。這看似枝微末節，但是是隱含的關鍵成功因素。

初始化工作項目，在新成員到職的前幾天，最好是鉅細彌遺。規劃了新成員第一天到第五天，「每天」要做的事情和達成的結果。並規劃前4週，要達到的大項目，以及前3個月的必須要的貢獻程度。

團隊是由一個個單一個人組合起來。將個別成員的適應期縮得越短，對團隊的組成越有利。

規劃前五天的細目，絕對不會讓這個新成員變得沒有創意，也絕對不會扼殺他的潛能。反而是讓他可以在極短的時間之內，先擺脫掉和「智慧創意」無關的邊緣事項。因為這些邊緣事項，如果在前一段時間沒有擺脫，之後會一直出來煩大家。

以下是某個電商開發團隊的前三天初始化工作項目，同時也是檢閱清單：

Day-1  
    - Mentor介紹工作環境，取得電腦和其他硬體設備
    - Mentor協助取得email和其他必要的帳號
    - 取得目前程式碼版本控制系統權限，確定可以clone
    - 確定clone目前的程式庫

Day-2
    - 取得目前的UI/UX設計文件，Mentor協助了解文件內容
    - 參加Scrum會議，理解Scrum雞與豬的原則 
    - 在Mentor協助下，建立自己開發環境

Day-3
    - 在Mentor的協助下，在自己的開發環境確定能修改程式/簽入(commit)/建立branch，最後產生自己的build。
    - 了解基本的測試項目

以上僅是3天的範例，這些看似細節，但要在三天之內完成也不並容易。


(e) 定期檢討方式

檢討方式可以參考這裡和這裡。

簡而言之，建立團隊的過程也需要被檢討。

例如：

新加入的成員，在當初面試的時候所呈現的能力，和實際上工作的產出，是否吻合。

新的成員對於非技術類型的雜事，是不是很快能找到資訊。例如git的位置，目前各個branch的狀況，自動化建構的方式，建立開發環境的方式等等。

---

註1：如果這個挑戰對負責組織團隊的人來說太過困難，最好不要接受這樣的任務。一個失職的程式設計師頂多讓專案推遲幾天，或者品質降低一些；但是一個失職的領導者，會讓整件專案崩壞。


註2：例如xspace

註3：建立軟體開發團隊的事實搜集清單

(a) 團隊目標願景
(b) 資源現況
(c) 組成專長
(d) 關鍵成功因素
(e) 關鍵風險 - 一旦發生就可能會失敗
(f) 關鍵技術 - 是否有必須具備的關鍵技術，需不需要招募這樣的人才
(g) 利害關係人 - 哪些人跟這個團隊有實質的相關
(h) 外在環境 - 辦公室設備 是否有遠端甚至跨國合作團隊等等

為自己工作 - 契合組織目標

雖然這幾年，創業蔚為風潮，但在台灣，大部份的人還是受雇於組織或企業。

「為自己工作」這句話看似自私，但其實所導引的結果才是對企業組織以及對個人有利。至少，對白領階級的知識工作者是如此。(註1)

表面上，大部份的人似乎並不是為自己工作。實際上，會去工作的原因是可獲得報酬（報酬涵蓋：薪資，技能知識學習，個人成長，成就感，社會參與感...等等），因此，無論表面原因為何，也無論自己是否有認知到這個事實，即便是受僱用者，絕大部份的人是為了自己，或者自己的家庭，而工作。

然而，在職場上常聽到各種抱怨心聲。其中有很大部分，其來源是沒有認知到自己是「為自己而工作」：

例如：

  *  工作很無聊學不到東西
  *  自己的價值不受到老闆重視
  *  對公司貢獻超級高，但是相對報酬卻很少
  *  做事人少，出嘴巴的人多 (特別是在政府單位)
  *  組織方向不正確，快要完蛋了

抱怨不是大問題，但失去自我方向之後，就很難在職涯上突破。個人的工作目的，必須要「由自己想辦法契合組織目標」。否則，就會有「不是為自己而工作」的念頭。一旦有這種念頭，很快的就喪失信念以及工作熱誠。

誠如前述：「為自己工作」這句話看似自私，但其實所產生的結果才是對企業組織以及對個人有利。

如果真切的認知到事實是「即使是受雇用，但自己其實是為自己工作」則進一步更能在工作上展現能力，切合組織目標。也更能給予組織更多的價值。因此，認知事實，才是生涯展開的最重要的事情。前述的理由就根本不會存在。

例如

  *  工作很無聊學不到東西：請隨意google一下就知道，企業組織雇用員工，不是為了讓員工學東西。而是解決問題或者產生新的價值。而工作學不學得到東西，也請google一下，都是取決於自己而非工作的本身。

  *  自己的價值不受到老闆重視：員工的價值就像在擺在口袋裡的針，只要你夠尖，有一天一定會穿刺而出。如果你覺得不是被擺到口袋，那就找到一個會擺你到口袋裡的組織。光是抱怨是沒有意義的。

  *  對公司貢獻超級高，但是相對報酬卻很少：先確定是自己的貢獻真的超級高。以業務員為例，許多大企業的業務，其業績是靠著大企業的品牌和產品，而非個人能力。以程式設計師為例，其程式產出，絕大部分是靠團隊能力，而非個人能力。

  *  做事人少，出嘴巴的人多 (特別是在政府單位)：也許你的生涯規劃就是要去這類型地方？如果是這樣，也沒什麼好抱怨。如果不是，就趕快離開，也沒什麼好抱怨。

  *  組織方向不正確，快要完蛋了：在一個快沉的船上，就是你發揮能力的時候。如果你自認為是個策略舵手，當然應該矯正組織方向。如果你覺得自己是在大組織裡的小螺絲，那麼你為何能「判斷」組織方向不正確？或許是你的判斷不正確？無論如何，你永遠有離開組織這個選擇。



在大部分時候，人總是可以找到契合組織目標的方式？主要有三種：「自然篩選」「個人規劃契合組織」「創業」

1. 自然篩選

當然，企業組織會自然的篩選「契合組織目標」的人。自然篩選的程度與經濟學上的「看不見的手」有過之而無不及。

例如：一個長期處於保守狀態的組織，自然而然會留下不積極的人。一個以退休津貼優渥的組織（例如公務員），自然而然，就會吸引「為了退休而工作」的人。當然，當一個人拼命念書，絞盡腦汁的通過高普考，一進去公家機關就數饅頭等著退休，自然就不會抱怨「工作無聊學不到東西」以及「自己的價值不受老闆重視」，畢竟，進來這個組織的真正目的，其實是為了退休...。

反過來說：一個新創事業，自然而然會吸引想要透過自己的能力，積極開創一片天地的人。而「退休津貼」就不可能是工作的首要目的。但工作是否有趣，組織方向正不正確，就成為關鍵因素。

雖然，個人沒辦法影響「自然篩選」，但如果你的工作目標，和「自然篩選」的目標不一致，當然會工作的很痛苦，而抱怨連連。

解決自然篩選的方式有三種：(1)離開 (2) 改變自己 (3)改變環境

其中，離開是最簡單的。辭職換新工作，自己創業，創業失敗後再創業等等，都是離開。

改變自己很難。但潛移默化之下，很多人會因為自然篩選的環境而改變自己。

改變環境其實難上加難！但是，一旦有機會做到改變環境，你就擁有一個難以言喻的經歷。這個經歷對職涯有絕對的幫助。

2. 職業生涯規劃契合組織

傳統企業組織都知道，激勵員工很重要。但組織出錢出力，費盡心思的「各種激勵」其實遠遠不如讓員工的生涯規劃契合組織目標。

就前段所述，其實無論如何，自然篩選會讓組織留下契合其目標的員工。但這需要起碼數年的時間，而前提也是組織沒有大的變故。 如果組織 - 特別是營利企業 - 的目標和其展示的行為不一致，自然篩選會失衡，要達到平衡。

因而「以個人力量做出契合組織的規劃」才是最簡單，最容易，最能獲得三贏的選擇。

除了工作內容外，每個人常遇到工作上乍看之下不可伉儷的因素，而認為自己無法契合組織目標。在你還沒有丟出辭呈之前，可以執行的個人能力與選擇非常的多。這些選擇都可以有機會做出契合組織的目標。

例如：

* 每天都做無聊的工作：既然是無聊的工作，表示是重複簡單類型，試著將這類工作最佳化，並自動化(註2)。 不知道怎麼自動化？那就去學阿，在工作中學習成長，並透過自動化的貢獻，不但提昇自己的能力，也讓組織獲取更多價值。

* 工作太多，常常超時加班，生活品質太差：所有企業組織，其存在的目的，絕對不是要員工加班完成目的。其存在的目的都是為了獲利。隨著組織分工，以及各種環境變化，容易產生以「加班」的方式來解決問題。這完全可以避免，請參考：解決專案困難的最爛方式; 如何提高工作效率; 80/20法則。也可以網路搜尋一下任何增加工作效率的方式。

重點在於去做！Just Do It！不去做，永遠不知道加班問題能否解決。

* 加薪升遷不如預期：如果是在大企業工作，加薪升遷的確常常不如自己預料。但如果你確定自己有這樣的價值，一段時間一定會被發現，如果不被發現，在離開之前請先想清楚「自己是否真有這樣的價值」？想清楚的方式也很簡單，可以去試著去應徵其他組織，看看有沒有其他組織願意提供給你更好的薪資福利。如果沒有，表示在當下你的確無此價值。如果是在小企業，薪資福利可能無法有大幅成長，但小公司能提供的通常是更多的自由和自我成長。既然你已經自然被篩選到小企業，或許本來就不是很期待制式的加薪升遷了吧。


* 組織做犯法或遊走在法律邊緣的生意：趕快辭職離開！越快越好。你確定你想要加入犯罪組織或者遊走在法律邊緣？！

3. 創業

創業，當然就是為自己工作，當然也一定會契合組織目標 - 因為你就是組織。倘若你創了業，卻因為各種原因，去做不是你訂立的目標的事情，那等於是沒創業。(註3)

不過創業成功難非常高（參考如何確保創業成功）。富貴險中求，高風險當然比較能伴隨高獲利，如果生涯的志向在此，盡可能參考已經成功的典範，或許能降低失敗機率。

---

註1: 藍領階級的勞動工作者可能不全然適用。

註2: 同註1

註3: 當然，也許你是共同創業，或者持有股份很少，那麼請視為在組織為自己工作，不要視為自己創業。

如何組成團隊：三個步驟

分工合作，是人類社會進步的主要原因之一，也是幾乎所有人類活動的基礎（參見國富論：第一篇第一章論分工）

新創公司，資訊產業也不例外，建立一個好的團隊，是擴展未來的主要關鍵。雖然好的團隊沒辦法保證生意蒸蒸日上，一切順心如意。但是一個糟糕的團隊，卻是可以保證企業和組織的失敗指日可待。


市面上團隊合作的企管叢書，方法論，激勵理論，顧問大師...很多。但就和所有的事情一樣，越是很多人在談論的事情，越是困難。成功的團隊真實例子極為罕見。

萬事起頭難，「組織並成立團隊」是達到成功團隊的第一要務。許多人常依賴運氣，或者隨遇而安的隨意組成團隊，但其實組織團隊是一種可以學習的艱深技術能力。

資訊相關工作的人，如果有機會能扮演組成團隊的角色，並有意識的學習其中，將會是個人成長的重要關鍵。（無論未來是朝純技術領導方向前進，抑或管理方向前進）


有很多原因，會讓一個人扮演組織團隊的角色。也許是一個新的專案，讓你來領導專案，而恰巧專案開始的時候沒有既定的人。也許你是新創企業的創始人，你打算聚集一些人來開發創新事業。也許你是資訊相關科系的學生，因為課程需要必須組織團隊完成專案。

不管如何，如果你有「從頭開始找人選人，組織團隊，完成某件事情的機會」，請衷心的痛哭流涕的感謝上帝，這樣的經驗，在資訊科技領域裡是十分難得。

通常，由於各種背景壓力，組成團隊的方式通常就是先根據需要N個人，然後「儘速」透過各種管道，找到可能的人選，經過正式面試，或者非正式的聊天，就逐一邀入加入此團隊。這種方式沒有不妥，只是這樣的方式（如果算是一種方式的話）有很大的成分依賴運氣。如果不想依賴運氣，其實需要考慮的實務步驟也不多。


以資訊相關工作為例，組成團隊必須要有以下三個步驟：

步驟一：定義目標

--- Your goal shouldn't be to buy players, your goal should be to buy wins. And in order to buy wins, you need to buy runs.   (MoneyBall)

定義目標，必須要在團隊開始組成之前，就先找到並且定義完成...最起碼是團隊差不多組成的時候就應該決定。

定義目標並不容易。

例如，以類似的資訊系統外包案而言，有些明顯的目標是「在成本內完成專案並驗收通過」或者「在期限內通過驗收」。但是，倘若一開始的合約是低價得標，而且還是業務亂搶合約，那麼一開始就已經知道不可能在時間成本內驗收通過。則團隊目標必須要轉換，例如「完成專案過程可順便完成重複利用的元件讓未來標案能大幅降低成本」。

大部分的資訊團隊真正的目標並非「技術達成」。例如，「完成iOS APP線上購物」這通常不是真正目標，真正目標通常是「在某移動通訊市場上，讓使用者可以線上購物」。

在營利企業裡，大部分的真正目標通常關聯到增加收入或者降低成本。而在非營利企業（例如研究單位）團隊的目標有可能非常模糊。例如，一個碩士班的實驗室團隊，他的目標可能是「培養人才」，也可能是「讓主持的教授獲得升遷的點數」。

定義目標雖然不容易，但掌握以下三點可以除去大部分的誤差：

(1) 定義目標後，審視檢查這個目標背後是否還有目標。例如，籃球比賽目標，某球員目標是得30分。但其背後還有個目標就是球隊要贏球。在球隊沒贏球的情況下得30分可能沒有意義。

(2) 定義目標後，檢視此目標是否只是某個大目標的一小部分。例如，某些NBA的球隊，會談論是進入季後賽的目標，然而背後的大目標其實應該是拿到總冠軍 - 無論有多艱難。

(3) 定義目標後，檢視此目標是否因為其他條件未達成就失去意義？這時候所謂「其他條件」或許可能是目標。例如，一個團隊負責營運線上購物網站，其目標是「網站每分鐘必須可以提供10萬個使用者同時進行交易，7x24服務不中斷不當機」。然而，若此線上交易網站平均上線交易人數每分鐘才1人，即便營運團隊達到技術目標，商業目標肯定無法達成，則此團隊目標也沒有太大意義。不如改成「與業務團隊合作線上行銷活動，讓每分鐘平均交易人數成長XX%」

步驟二：組合優勢

--- The greatest improvement in the productive powers of labour, and the greater part of the skill, dexterity, and judgment with which it is any where directed, or applied, seem to have been the effects of the division of labour. - (Adam Smith)

無論用什麼方式找到團隊成員，資訊相關的團隊必然有分工，而分工必須要能讓成員發揮相對優勢。而每個相對優勢，都可以達到步驟一的目標之一。

構成團隊過程可能很多，但無非是找到某人，詢問意見，在某時間此人加入。然而，「加入之後做什麼」著重於考慮組合優勢。

台灣經濟學的入門書通常會用蓋木屋與磚屋的例子（參見這裡）簡單的說，組織團隊時，把成員的時間投入在相對優勢的工作上，可以達到1+1>2的效果。

實務上，分工時請考慮一下三點：

(1) 根據相對優勢來分工：盡量只考慮優勢，而不是先考慮缺點。

(2) 分工的結果，還是必須朝「真正目標」前進

(3) 整個團隊需要了解分工與分派任務的原因 

步驟三：產生運轉動能

--- All things are difficult before they are easy.


團隊組織完成，要開始運作，不會像籃球比賽一樣，十個人在場上，裁判吹哨跳球就開始。

團隊前進需要累積動能。就像騎腳踏車一樣，從靜止到穩定前進，會花比較多力氣，然而一旦穩定前進，就很輕鬆。

產生動能指的是團隊成員已經彼此合作，彼此鏈結工作，發生問題也可以彼此協調解決。

以資訊科技為例：

最常見也是最糟糕的產生動能方法是由專案經理透過一連串的方式 - 通常就是開會 - 持續讓事情前進。團隊成員花在正式會議上的時間比例只要超過10%(也就是每週超過4小時)就屬於這種類型。


最佳，但是最罕見的產生動能的方式是由每個團隊成員，透過自身的判斷，做會讓事情前進的動作。類似足球或者美式足球的比賽。在資訊科技團隊中，這種組合需要時間磨合成員，而且也須一點點運氣，讓團隊的成員大部分的能力都可以足以某種程度的獨當一面。

如果你剛好是資訊科技/軟體開發的團隊領導者，至少要先避免最差方式，並且透過你的領導能力，讓團隊慢慢的朝向最佳的方式前進。

實務上有三個重點方式：

(1) 資訊透明：讓所有進行的事情透明的讓所有人取得。要注意，資訊透明指的是針對確定的事實透明。非確定的事實就是所謂謠言，要緊記：謠言止於智者，起於智障！

(2) Scrum中的豬雞原則：請參考這裡。在組織產生動能過程，豬負責的事情就由豬來決定，雞只是提供參考意見。

(3) 檢討 retrospective：需要團隊自我檢討任何不正確或可以強化的地方，檢討並非開批鬥大會，目的在於讓團隊能更有效率的，以及確保團隊真的朝向目標前進。

給不寫程式的人：發展手機APP事業的三步驟

有智慧型手機的人，都會使用某些應用程式(APP)。

你一定也有常用的APP，多少也有自己想要的功能。也許你覺得自己有一些創新的APP想法。或許，你覺得現在用的Line總是有些地方很不滿，你覺得只要照你的想法去做，一定會讓使用者更滿意。

但是，也許你完全不會寫程式，或者雖然是資訊科技背景，但是對於手機應用開發缺乏經驗，也或許只是沒時間學... 最後自己總是覺得無法實現想法很可惜。

其實APP和一般的電腦應用程式不同，不會寫程式的人，其實也可以創造自己的APP，加入這個競爭激烈，但卻很有利可圖的市場。

如果規劃得當，是一個能以極少量成本，兼職創業的好方式。更重要的是，如果規劃得當，這是個極低成本的lean start-up，可以讓你多方嘗試可能性，但不用負擔失敗的風險。

不會寫程式，或者沒時間，但仍能發展自己的APP的成功案例是很常見的事情。例如airbnb，uber等。

事實上，有許多創業家一開始就選擇踏入手機市場，就是因為APP是能在極端有限的資源下，實現自己的創新想法的最容易的選項之一。

主要原因可能是：

在技術上：兩大主要智慧型手機陣營：iOS和Android都盡可能APP的開發方式標準化，簡潔化。目的是在於吸引更多開發群眾。而市面上也有太多工具，可以在某種程度上產生APP，例如appopus.com 或 appsgeyser.com 都可以把文件轉變成APP。技術上來說，等同於擁有一個可以個別銷售的電子書APP（註1）。換言之，APP的製作有越來越簡單的傾向。

在環境上：智慧型手機的市場遠比傳統電腦來得大，而進入市場的門檻極端的低。根據實際的經驗：以電子書而言，撇除掉撰寫的成本，僅就上架與行銷可能只要200美金。如果是具有傳遞訊息(類似Line)加上社群功能(類似facebook登入等等)，大概只要準備700-1000美金。如果是多媒體播放(類似youtube)則僅需要800-1200美金。而以上的參考數字，都涵蓋完整的完成具有完整前後端功能的APP，上架以及基本行銷。換言之，市場環境，大幅傾向低成本門檻。



在實際經驗中，任何人只要能學習以下三步驟，一定可以開發APP並藉此開創事業。（註2）

三步驟：想法具體化，找到正確的人完成APP，進入市場。

步驟一：將想法具體化

將想法具體化：是指把自己對APP的想法盡量用文字以及圖形表達出來，並且對於APP決定好基本的定義。

表達APP的方式有很多。首先要簡單地寫下自己的想法：例如一個可以互相傳遞即時訊息的APP（類似Line)但如果對方沒即時看到，就改用傳統手機訊息傳出。

接下來，使用網路上免費的畫圖工具，例如invisionapp.com 或者 fluidui.com，將自己的心理的想法具體化。

簡單的通訊APP(類似Line)的設計，練習個幾次，任何人都可以做簡單的設計。

想法具體化不是只有手機流程設計。最起碼還包含兩件事情的具體化：誰是使用者，以及：定義成功。

誰是使用者？

在你的心目中，用有哪些屬性的人會使用這個APP：就是所謂的市場區隔。雖然他可能會改變，但在這個階段，你需要自己具體化一個清楚的使用者描述。例如：「在台灣，25-35歲，單身男性，就業中，未與父母同住，使用Android手機」。

如果你的目標客群很大，例如：「在台灣，使用Android手機」。也並非不可，但是在之後進入市場時，可能不容易看到基本行銷的效果，或者需要極大的努力才能看到行銷的效果。目標客群越清晰，越容易看到行銷的效果。

如何定義成功？

在你的心目中，當APP完成放到市場上，經過3個月，達到哪些事情才算成功？自我具體定義成功，是發展APP的重要基礎。

成功可能是獲利。例如，假設APP是要收費，或者間接收費(例如廣告)，上架經過3個月，實際營收達總額達到1000美金就算成功。

但所謂成功，更有可能不是設定為獲利。例如，APP是免費，而且也沒有廣告，但上架經過3個月，希望實際使用者達到1000人。因為很多APP一開始是希望有大量使用人數，等到夠多人使用時，再考慮獲利模式就變得很簡單。（例如Line是免費使用，一開始是沒有廣告）

有創意的定義成功，能夠讓不寫程式的人，更容易看到手機APP的事業的可能性。例如：APP是免費，也沒有廣告，但上架經過3個月，希望所有已經安裝的使用者，解除安裝的比率低於15%，而且每天使用這個APP的比率要超過65%。換言之並不在乎多少人使用，只在乎這些使用者是真心的黏著在這個APP上。

步驟二：找到正確的人完成APP

好像很明顯，你需要找人幫你寫程式。

但是，其實你真正需要的是：找人幫你完整完成開發APP這件事情。

完整開發APP指的是：

(0) 將想法具體化   <- 這一點在步驟一中，一定已經完成。
(1) 先把APP的流程決定好
(2) 根據流程畫出APP的樣子
(3) 加上自己認定的顏色，圖樣，Logo
(4) 根據設計，撰寫程式
(5) 測試程式，確保品質大致沒問題
(6) 將APP上架：放到googleplay或者applestore
(7) 利用各種行銷方式，讓使用者下載，安裝，使用APP。
(8) 每一段時間收集相關資訊，了解此APP是否成功。


(1)-(3) 就是APP的設計，完成APP設計之後產生出APP的mock-up。這件事情可能在步驟一中自己做，也可以找人來做。

一般人都直覺地認為，「找人去做」表示執行(4) (5) 這兩件事情。但其實你真正需要的是(1)-(8)都需要有人執行。

找到正確的人的方式有很多，首先，先確定自己(1)到(8)能做哪些事情。然後，剩下的事情都要「委外開發」。

委外開發的最直覺方法，就是到外包網站上招標。例如：upwork.com ，guru.com， freelancer.com。外包的價格差異很大，而且軟體產生的品質和價格沒有直接關係。關於如何招標尋找正確的廠商，請參考這裡。

基本的參考數字：一個類似line的訊息傳遞APP，開發需要120-200美金之間，如果要涵蓋基本的UI/UX設計，另外需要50美金，如果要含品質測試以及上架，另外還需要30美金。也就是整體大約200-300美金可以完成一個還不錯的APP。（這個數字不適用於遊戲APP）

委外開發的其他常見有：找有技術能力的志同道合的好朋友；找學校的相關科系學生專案，等等。不過，這些常見方式，都需要一段時間的磨合，以及一段更長的時間的互相體諒與了解。

步驟三：進入市場

進入市場包含「上架」，「基本行銷」。想要長期留在市場，還得進行「維護」以及「未來計劃」。

上架：

完成APP之後，當然就是要進入市場。進入市場第一步就是將APP上架。如果是Android，自然就前往googleplay，如果是iOS，就去applestore。

「上架」需要一些步驟，對於非資訊科技背景的人來說，可能稍微困難，因此，在步驟二：找到正確的人完成APP的階段，必須要把上架當作工作的一部分。

Googleplay上架請詳閱這裡。Applestore上架請詳閱這裡。強烈建議不要看市面上的書籍，或者參考某些部落格的文章來當作上架教學。因為，這些書籍文章可能都是「過期的資訊」。使用官方文件，作為上架的使用指引，才不會浪費自己的時間。

基本行銷：

不過，上架只是讓市場有機會看到你的APP。這個世界上有近千萬個APP存在，要讓使用者能真的下載使用某APP並不容易。因此所謂進入市場，必須考慮基本行銷。

行銷可以很簡單，也可很複雜。最基本的情況是：你需要盡可能讓很多人知道有這個APP，下載這個APP來使用，如果APP需要付錢才能使用，則還得包含說服使用者鼓起勇氣付錢。

最最最基本行銷的過程是：找到目標客群，針對客群送出訊息，等候以及檢視結果。

找到目標客群：

定義目標客群應該是在第一階段完成的事情。這階段的目的是找到目標客群的「資訊傳遞」方式。最簡單的方式，是透過小型行銷公司，直接把你要找的目標客群的email找出來。只要你的定義夠清楚簡單，可以在前述的外包網站，找到小型行銷公司，以30美金的價格，取得大約500個大約目標客群的email。或者，也可以用15美金的價格，送出1000個目標客群的潛在facebook貼文。如果願意在行銷投入更多的資金，可以用200美金，購買一個月的google ad，讓自己的APP廣告出現在某些google adsense能抵達的範圍。

針對客群送出訊息：

取得email之後，可以利用現有的email行銷軟體。常見的像是mailchimp.com，klaviyo.com或者zoho.com，送出廣告信。信中當然就是這個APP的介紹與連結，還有一些說服別人使用這個APP的方式（例如抽獎活動之類）

email 行銷是很老套，但也由於是老套，所以很容易看到效果：例如多少人有打開email，多少打開email的人真的有下載APP。

如果是facebook行銷，可以花15美金，送出1000個目標客群的潛在facebook自動貼文。也可以花60美金，雇用虛擬助理，以人工的方式，逐一在潛在的facebook粉絲頁或個人頁，貼上獨一無二的訊息。關於虛擬助理，請參考這一系列文章。

如果是google adsense行銷，或其他網路廣告方式，預期每個月，可能會花上200美金。

但無論如何，手機APP事業的基本行銷費用，其實並不高。盡量利用前述的免費或者簡單的方式。不會超過200美金就可以達到某個程度的效果。

檢查結果：

等候一段時間，檢查看看APP的成功定義是否有被滿足。

如果你的成功定義已經被滿足。那麼恭喜你：你的APP是千萬中選一的好APP。你的APP事業發展在未來可能輕而易舉。只有極少部份的情況，是可以在一開始就這麼順利。
如果你的成功定義，沒有被滿足。那麼還是得恭喜你：你知道過去的做法一定某處可以被改善。根據手上有的資料，回溯之前的過程，找到可以改善的點，加以修改，然後重新觀察。一半左右的APP是落在這個情況。重點在於，如何根據現有資料修正APP或者修正基本行銷方式。

如果你的成功定義，不但沒有被滿足，而且實在差距太遠。那麼還是得恭喜你：因為你只花自己一些思考時間，以及500美金左右的成本，就證明某個想法在目前不可行。目前你的損失很小，可以再多嘗試其他主意。更重要的是，簡單而低成本的經歷失敗的「失敗經歷」極為難得可貴，是創業成功的不二法門。請參考確保創業成功一文。

---

參考： 

發展自己的APP事業，看似複雜，其實就是這麼簡單的三步驟。當你了解這些步驟，甚至可以把整件簡單事情，交由專門協助產生POC(Proof of concept)的企業來處理。

而你自己，只要專注在於「出個好主意」就好。

---

註1：如果你寫了一本電子書，可以在亞馬遜銷售，也可以在其他APP管道銷售。那為什麼需要自己獨立產生單一電子書APP？有很多可能：例如你想單獨獲利，不想讓各類銷售管道分享微薄的利潤；或者這是免費電子書，你想要免費分送，因為裡面可能有置入性行銷的訊息等等。

註2：開創APP事業如同本文所說很簡單，但要確保事業能成功極端困難，請參考這篇。

資訊科技學生畢業後只想當SA/PM (三個創意作法)

很多畢業生，資訊相關系所，擺明就不想要寫程式，但是卻又想要加入資訊科技產業。老實說如果是做行銷(Marketing) ，業務(Sales)，或者支援類型工作(admin, finance)倒是也無不可。

只是很多資訊科技學生，似乎想要當SA(系統分析師)或者PM(專案經理)，也許只是覺得名字好聽，或者認為：既然是資管學生應該做點管理工作也不為過。

這種想法其實很危險，也不可靠。

系統分析師(SA, System Analyst)扮演的角色在各公司都很不同，有些很像是業務助理，有些是專案經理的小跟班，有些是扮演IT對外採購的角色，不一而足，單看是去哪個公司。

而專案經理(PM, Project Manager)情況可能稍微好一點，顧名思義就是：負責某一個或者一些專案的進行。20年前PMP證照流行的時候，專案管理本身被視為一門複雜的學問，當然在軟體或者新創網路科技產業，PMP那套不太可行，Agile/Scrum/XP 等等方法論興起，讓PM多少都不太可能單純只做管理。

不管如何，缺乏實務經驗(指的是起碼3-4年努力寫程式的經驗)就去做SA/PM等同於是碰運氣，就算花大錢去取得PMP證照以及其他相關證照，也沒什麼用。這就像是從來沒打過籃球的人，想要當NBA籃球教練一樣幾乎不可能。

雖然很不贊成這樣的事情，但與其碰運氣，不如提供實務作法。

(1) 創意一：讓自己真實變成SA/PM (要花一點錢)。

在學校的專案課程中，讓自己變成PM然後讓某同學變成主Co*(註一) 是絕對沒有用的。任何有經驗的主管，一定看得出來你只是負責動動嘴巴，補補文件。

你可能需要付出一些代價，例如100美金，然後想一個app的好主意，到outsourcing網站，像是upwork.com，雇用一些印度，巴基斯坦工程師，實際上幫你寫程式，這時候你100%是PM，你控制了整個專案的進行，負責製作需求與控制工程師進度。更好的是，這還是個跨國專案。

不過，實際上這樣做出來的東西，失敗率很高，特別是假如這次你第一次當PM - 這裏的PM同時兼具Project和Product。因此，對此創意方式要有正確的期待，也就是說事情的成敗並不是重點，而是在此過程經歷了什麼。這非常接近NBA例行賽開打之前的練習賽，練習賽獲勝固然可喜，但比勝利更重要的是團隊的磨合以及戰術的演練執行。

註一： 主co = 負責主要coding。這個名詞是最近幾年面試學到的，意思差不多就是這個專案課程，程式都是我寫，事情都是我做，其他人出嘴巴。

(2) 創意二：組織同學來做專案

等一下，前一段不是說在學校專案當PM然後某同學來主co是絕對沒用的嗎？為何這裡又說要組織同學來做某專案？

不一樣是，組織同學來進行非課堂的任務，遠比修課需要的專案來得困難，但是更實際。

第一種可能是，到市場上接專案本身到不是問題，因為一開始取得專案的目的，並不是獲得高額利潤，因此價格競爭是有可能的，畢竟你的目的是要取得成為SA/PM的事實，並不是真的要從專案獲利。

然而，業主可能也知道，這種情況下的專案可能不見得做的很好，因此價格競爭有時候也沒太大用處。

第二種可能是，自己找事情來進行。十幾年前BBS風起雲湧的時候，大部份架設BBS的人，都並非學校課程，也不是因為賺錢獲利，只是覺得好玩有趣。架設BBS讓當時的學生取得寶貴的UNIX（FreeBSD等）的營運經驗。如果想當PM，也可以自己找事情，組織同學來進行。不過通常這種情況需要是以技術強度來領導，因此遠比接專案困難。

(3) 創意三：尋求業界導師

由於linkedin和其他社交工具的發展，很容易可以找到業界資深的學長學姊。只要是在他們時間允許的範圍，很容易可以請求協助。當然，每個人的時間有限，所以最好的方式是，互相幫忙，互蒙其利。當你在與不太熟悉的人聯繫上之後，可以用交換的方式，讓他們指導你，並且為你的成就背書。

舉例來說：你可以作為業界導師的私人虛擬助理*(註二)一段時間，幫他處理非機密的相關業務，例如，調查研究競爭對手產品，處理文件，處理linkedin或者其他socail media的日常文章，業務聯繫等等。而作為交換的是：他可以指導你實務專案上"他實際上做了什麼"。數個月後，你甚至還可以取得業界導師的背書以及推薦。

另一個做法是尋求成為學徒的機會。學徒制度是一個非常古老的學習方式，在某些情況下，學徒制度非常有用。如果你是一個剛進學校的研究生，尋找指導老師是最重要的一件事。而如果你是一個畢了業就想要當SA/PM的人，找到正確的業界導師，會讓你事半功倍。

我們會在未來的文章探索學徒制與軟體專案發展的關係。





* (註二)：關於虛擬助理，請查Virtual Assistant

---

沈思 

如果本文對你沒幫助，還請與我們聯繫取得免費協助。

1.  再次強調，在沒有技術背景的情況下，最好是別真的想做SA/PM

2.  如果真的想做，那麼務必考慮這三種方式。

3.  當你想要什麼，執行的方式如果是「碰運氣」或者「期望別人給」永遠都是最糟糕的選項，想要什麼最好是先構思自己要怎麼取得。

創新公司軟體專案時程管理 (三個基本概念)

絕大部份創新公司，其實在衡量任何事情的時候，其所消耗的標準，並不是真正的金錢，而是創業夥伴們的時間。

每個人一天只有24小時，雖然今年是2015了，但是你還是不可能有時光車讓你爭取更多的時間。因此，專案的時程管理變得很重要。

時間管理的技巧方法很多，如果沒有概念可以先參考這裡。但最好先建立一些基本的觀念：

(1) 觀念一：每個人的時間效率有天壤之別

特別是技術類型公司，單指寫程式的效率來說，最好的程式設計師，和最差的有很大的差距。有些研究說是10倍，有些說是上百倍。

不只是程式設計，其他工作類型也一樣。更有甚者，品質的產出也被證實和速度沒有很大的關係。換言之，又快又好是絕對有可能的。

(2) 觀念二：每個人時間的比較利益不同，因此可以分工

那麼，這樣來說我們雇用三個強人不就搞定一切事情了？首先你不可能有機會在一開始找到三個強人，因為強人早就已經有非常好的工作。就算你運氣好到不行，真的雇用了三個強人，有趣的工作可能只有一個，也不可能三個人做同一件事情。

所以分工變得很重要。比較利益法則（參見wiki)解釋了為什麼多人合作有可能1+1>2。只要大家負責的部份，是相對其他人比較專長的部份。

不過分工是否得當，會有相當大的差距。在超大型組織裡面，以現代科技發展的程度而言，分工會自然發現，即便沒有效率也會發生，例如，任何開發中國家，經濟發展的時候，投入初級產業(農林漁牧)的人自然就會慢慢變少，換言之，只要少數人的努力就可以提供食物給其他人，而其他人就可以去做更多讓生活更愉快的事情。

但是在小型組織，例如只有5個人的startup，就必須要時常檢視這樣的分工是否合理，能否達到綜效。

(3) 觀念三：中短期的專案，其完成時間早就已經固定

一個為期1-5個月的專案，當目標和資源已經定義出來的時候，其實完成的時間早就已經被上帝決定好了。問題在於，創業夥伴們，能不能事先看出來。如果一開始對時間的估計有誤，接下來新的專案就要把失誤考慮進去。

對，沒錯這就是Agile/Scrum的基本要素，無論什麼理由，當你打算完成的事情決定好產出的目標之後，時間早就已經被決定，你能夠做的就只是盡自己的能力，縮短預測的失誤，而經過幾次中短期專案，理論上，創業夥伴們的能力和資源調配方式，已經讓大家可以準確預測完成的時間。



越是能了解時間的控制，就越不被時間控制。

---

沉思：

考慮以下說明：時間基本觀念很重要，因為創新公司，事情完成度是以時間來衡量，而不是以事情的進展來衡量。為什麼呢？

跨國專案，發生於startups的三個原因

談到跨國軟體開發專案，大部分的研究或者討論案例集中在大型組織。但其實，最有機會跨國界發展專案（特別是軟體專案）的其實是創新公司startups。

什麼是跨國軟體開發專案？很簡單就是一小群人，分別處於不同的國家，為了同一個專案目標而一起努力。

為什麼跨國軟體開發專案會發生在創新公司？

第一個原因是創新企業的彼此合作。

創新企業，越能取得全球開發資源 越能專業分工。前一陣子很多與container技術相關的創新公司(cloud startups)，許多除了取得很多投資者的注意，彼此之間也會互相合作。例如coreos.com，除了把自己的產品以開放源碼(open source)的方式放在市場上測試之外，他肯定還是得與其他新創公司合作，讓產品可以先行在比較願意嘗試新技術的組織裡試行。

在同一個所謂育成中心的新創公司彼此合作是很合理，但如果你的新創公司鎖定於全球市場，最好一開始就先嘗試接觸其他國家的新創公司。因跨距離的合作而成功，這樣的例子屢見不鮮。（當然因為距離與文化失敗的也不是少數）

第二個原因是委外開發。

由於網路發展太過快速，使得大部份的國家(也許中國例外？）互相聯繫的管道速度變快非常多，而軟體開發專案，理論上彼此之間只要有共同的開發工具平台（例如git 加上 jenkins 加上 jira）再配合視訊電話工具 -- 目前最跨國的工具仍是skype，就可以一起合作。對於企業來說，只要妥善面試，外包給印度，巴基斯坦，白俄羅斯的軟體程式設計師，其實效果跟雇用當地的工程師其實差不多。（前提是要面試得當）

另外一種委外開發是因為個人背景關係。舉例來說http://www.cognitivescale.com/ (算是2015年最受重視的startups之一）他的創始人是印度人，雖然總部是在德州Austin，但很明顯還有許多研發資源直接設於印度。

第三個原因取得跨國客戶。

internet快速發展的讓人忽略轉捩點的發生，各個國家的資訊障礙彼此之間差異越來越小（恩..也許中國再次除外）換言之，如果一個新創公司的產品，是屬於internet上銷售並且使用的產品，那麼一開始就要考慮取得跨國客戶。

如果要取得跨國客戶，某些時候還是必須要利用非本國資源。以台灣初創公司的角度來說，由於距離世界另外兩大市場（北美，歐洲）仍然有距離，在產品開發上，至少在介面，使用者功能部分，如果委外由英語母語者合作開發會比較接近現實。

跨國專案有其困難度，但如果分工得當，其效果遠比在單一區域來的好。

---

選擇跨國委外開發商的務實流程：三個要點

不管委外開發什麼東西，東西有多複雜，時間有多長，正確的選擇委外廠商就等於成功了一半。

會使用委外開發的目的一定涵蓋兩點：

(a) 讓組織專注在重要的事情，
(b)成本效益。換言之，選擇委外開發的廠商或個人，也至少要涵蓋這兩點。

而對於新創公司來說，委外還有另一點優勢：就是

(c)迫使你自己更瞭解自己在做的事情

因為你需要完整的把細節用文件簡要說明清楚。如果你自己沒辦法把事情說明清楚，那麼不用說無法委外，你可能根本無法有效率的創業。這樣的創業只會讓你日以繼夜的努力，卻事倍功半，就算成功也是運氣成份居多。

在做任何選擇的時候，都要把握20/80法則，也就是用最省時間方式，確認最多關鍵成功因素。建議使用以下三個實際要點：

(1) 要點一：要確定理解規格

確認理解規格，很多人以為是外包商的責任，其實應該是業主的責任。因為業主不應該雇用一個不理解規格的人！換言之，業主要能在委外活動開始之前，確定外包商能理解規格。

這點聽起來很直覺簡單，簡單到就像大家都知道不能闖紅燈，上班不能遲到，開車不能喝酒，寫程式應該要有Unit Test一樣。可是實務上就是有很多人做不到。

根據經驗，所有外包的失敗，有起碼75%的源頭，可以追溯到對規格的不理解。因此確定外包商理解規格才能外包是第一要務。

那要怎麼在還沒簽約前，確認外包商理解規格？

用電話/email問他：Do you understand the spec？然後他會回答：Yes。....這做法是100%完全沒用。

請他看完規格書之後，問他一下：Do you have any question。然後他會回答：No。...這做法一樣100%沒用。

另外，規格也要對QA稍作定義，倒是不需要洋洋灑灑列出421的test case，只要簡要的把最重要的幾個使用者行為定義清楚即可。

最簡單的作法是用過濾刪選。實務作法如下：

1. 篩選掉不認真看文件的。

首先在發標之前，先把規格簡單的描述一下。然後在文件的中後段，穿插一句話：If you see this, please add the secret code "Bravo" in your proposal。這個目的很簡單，就是要刪掉，連看都不看就想要來投標的人。因為透過網站來投標的成本很低，所以有很大的機會亂槍打鳥。要投標的人，一定會提供proposal，而實務經驗來說10個來投標的，竟然只有5個有真的看文件，並且把Bravo這個字眼放在proposal的第一行。

換言之！用一個簡單的方法，就可以篩選掉一半根本沒認真看文件的人。沒認真看基本說明的人，可能壓根錯估時間跟成本，萬一選到這樣的外包商，最後吃虧的一定是業主。

2. 篩選掉無法回答三個技術問題的。

準備三個簡單但是重要的問題，讓外包商回答。舉例如下：

(a) Did you use dynamodb (aws) if you did, let me know why you use it.

(b) Please simply describe how to let android app use fb login.

(c) what is the most difficult things on our specification?


依照這三個問題的回答，業主很快可以判斷，剩下來個5個之中，哪些對於要做的事情比較有信心，哪些是完全沒信心。

3. 篩選掉估計時間不合理的。

前兩個問題都通過之後，就請剩下來的人估計時間。這時候估計的時間，請他要給完成的時間點，而非要花多少天完成。外包商花多久時間，多少人力完成，其實業主不會需要知道，也不可能知道。然而，業主需要知道，幾月幾號幾點，會取得什麼樣的東西。

如果完成的時間本來就預期很長 - 所謂很長是指超過2週。就應該請外包商分里程碑(milestone)分階段產出，分階段驗收完成。時間估計不合理的長或者不合理的短都會有問題。但是，在這個階段倒是可以多花幾分鐘，了解問題在哪？例如也許是他剛剛好這禮拜要畢業，準備畢業考試之類的？有些時間的延宕是可以接受，但是一定要知道原因。


以上三個篩選步驟都很簡單，任何複雜的專案，都只需要花15-20分鐘就可以完成上面三件事情。但是這三步驟絕對會讓你節省不少寶貴時間。

另外強調一下。規格不在於細節，所以鉅細彌遺地250頁規格書一定也沒用。不如一個兩頁的精要版。

(2) 要點二：要確定目標

讓外包商理解目標，以及確定外包商理解目標，也是業主的責任。

所謂的目標是指，根據規格完成的東西的真正意義。例如，規格書上詳述要完成一個android APP，並且可以用fb login，並且可以記錄帳款...等等內容。但是，所謂真正目標可能是：必須要在某月某日之前，讓具有某些功能的APP上線，並且可供使用者免費下載。這目標的確和規格書一樣，但通常規格書沒辦法表達優先順序，以及真正的完成，以此例子來說真正的完成是要放到google play上線通過。

當選定外包商之後，一定要花20分鐘，以電話或者視訊溝通這次外包的真正目的，而規格書是達到真正目的的最大參考，可是規格書本身不是目的。這點一定要說明清楚。

(3) 要點三：要有plan-B

選擇委外開發，通常不會是把核心項目委外開發。因此，理論上外包失敗應該不會有滅絕性的結果。

所謂的Plan-B就是要有外包失敗的計畫。Plan-B類似危機管理(Risk Management)不過遠比危機管理簡單，它只需要知道：外包失敗的結果，以及如何因應。

1.  定義何謂失敗：

首先一定訂清楚定義何謂失敗，每次外包行為只有失敗跟成功兩種，沒有中間的。模糊不清的選項只會讓事情變得更複雜。以前述APP開發為例，所謂成功指的就是在某月某日之前，具有某功能的APP上線，並且通過所有定義好的當初簡要的QA測試。所謂失敗指的就是不滿足成功的所有條件。換言之，失敗不見得我們就不付給外包商費用，有可能外包商分階段完成，但最後完成的日期比預期晚，那仍然是失敗。

2. 失敗如何因應：

一但確定失敗，就一定要用預設因應方式。以前述例子來說，因應方式可能有很多種。

例如，雖然功能都可完成，QA測試也沒問題，可是已經確定無法準時上線。所以因應方式就是把計畫往後推延N天。然而，這個N天必須要是事先定義好。不能是當失敗發生才定義。原因在於，唯有事先定義好的失敗處理，才不會讓其他事情跟著失敗，如同骨牌一樣，一路倒個沒完，那就等於是把核心關鍵任務外包。因為延宕N天是事先定義好，換言之，其他事項早就已經把N天計算進去，因而這個N天就變成無關緊要。

然而，如果不是時間，而是外包商倒閉，或者壓根就消失，當然就要啟動重新委外行動。一樣會延宕N天。這N天，一樣也是必須事先定義好。

換言之，失敗因應其實都和時間有關係。當然和外包成本也有關係，只是通常這樣的外包最後真正付出金錢損失通常不大，因為現行的外包平台大部份的情況下，都會保障業主不會付出冤枉錢。反倒時間與精神損失才是重點。


這三個要點，無論專案有多麼大，有多複雜，都可以在1.5個小時之內完成。根據我們過去N次規模不同的外包經驗來說，採用簡單的三要點作法，讓我們自己將外包成功率從30%提高到90%。

---

email服務的市場：三個其他選項。

對很多台灣學生而言，email似乎不再是有趣的地方。因為email成為生活中一個簡單的存在。一旦考慮需要有自己的email而不用學校的email，幾乎就直接使用gmail。在組織過去三年的面試投遞履歷表中，幾乎沒看過用其他email服務的。

這點其實很可惜，因為這個世界上曾經存在很多有趣的email服務。直到今天還是。

email是Internet最早的應用之一。但其實在還沒有Internet(TCP/IP)的時候，email早就以各種不同的hosting形式，運行在各種早期商業電腦上。當然，主要是以商務應用為主。

在還沒有gmail之前，email通常是由某組織提供，免費的email服務雖然存在(例如yahoo, hotmail)但是限制很多，更有甚者，大部分的人似乎仍然傾向pops/smtp的收信方式，把email留在自己的硬碟裡面。

email服務在gmail推出之後成為一個轉淚點，在剛推出的時候提供1G的免費空間，現在一直在增大中，後來也導致yahoo乾脆推出1T免費空間的email。

現在，如同各種所謂cloud服務一樣，越來越多人不再將email存在自己的硬碟。而也讓email市場突然之間開闊了起來，企業組織（特別是中小型）再也不需要自己管理email server。

如果資訊產業的學生，在畢業前如果只知道自己學校的email和gmail，是非常可惜的。再此簡單的介紹三個其他較為不常見的選項（yahoo, hotmail在台灣比較常見就不多說了）：

(1) yandex.com

最近似乎也有幾篇文章在介紹yandex。它等同是俄羅斯的百度。yandex是斯拉夫語系最大的搜尋引擎，也提供了雲端儲存以及email服務。它的免費email空間有10G而且似乎在增大中。從台灣連線竟然沒有想像中的慢，所以拿來作為自動備份是不錯的選項。

yandex似乎也很在意介面的顏色跟背景，所以三不五時會幫你換一個背景照片，大部分的照片是來自俄羅斯的都市。

如果使用它的email服務，大概就會順便看一下它的雲端儲存(disk yandex)。其實和googledoc很像，只是沒辦法線上編輯文件。不過，某些不知名的原因，yandex竟然強調可以線上修圖！

yandex線上修圖

順道一提，單用javascript就做到線上，並且還能支援相當不錯的離線編輯的，截至今天(Nov/2015)為止只有googledoc。

(2) mail.com

這公司存在市場很久了，不過在台灣也鮮少聽到人在用。光是mail.com這個網址應該就值很多錢，所以可以想見它對email的專注程度。

mail.com有很多創意，例如它應該是最早推出無限制的免費email空間。然而，只有收費版本，才會讓你由pop3/smtp收信，並且才會拿掉廣告。它的收費版本一年600元台幣。

同樣的mail.com也提供雲端儲存服務，免費版本只有2G的空間，不過可以預見會逐漸擴大。

其實，個人最喜歡mail.com的是可以選擇很多不同的domain name。而且是免費的。

舉例來說，如果你的名字是edward，但早就被人註冊走了，所以你不得不用edward212@mail.com註冊。可是，在你註冊成功之後，mail.com有上百個不同的網址（domain name）可以讓你額外附加，例如asia.com, usa.com, consultant.com等等，並且在附加的過程，你可以嘗試看看edward是不是還沒有人用。由於domain選項超級多，所以讓你選到喜歡的名字的機會極大。

個人最喜歡的是post.com，專門用來撰寫文章以及投稿。

如果是技術宅，不妨試試null.net？自開診所的醫生也可以嘗試看看dr.com？總之，拜託不要再用ms93.hinet.net來當自己的email了。

(3) zoho.com

從名字大概可以猜得出來是給soho族使用。

沒錯，他專注於提供中小企業服務。申請好帳號之後，基本上不只有email可以使用，另外還有類似googledoc的整套服務。他的線上編輯功能，是大概googledoc以外最完整的。另外還有一整套CRM服務，以及雲端檔案儲存空間。

他的免費版本的email空間是5G，另加5G雲端檔案儲存。相較於其他免費的服務是很小。不過大部分的人會用zoho通常是為了購買網址之後，將網址的mail由zoho來管理。舉例來說，如果你註冊了shop.com，就可以透過dns設定，把mail轉交給zoho的帳號，所以你就可以在zoho使用ceo@shop.com來收你的email。免費的版本只能處理10個email帳號。收費版本就無此限制。

個人最喜歡的就是zoho.com對於domain name的支援。因為通常這樣的dns設定在其他地方都是要收費的(例如googleapp)。如果你考慮自己創業，zoho可能是市面上最好的選擇之一。目前最大的競爭對手應該是bitrix24（yandex的分支），不過zoho還是佔具比較大的市場。


網路免費服務有很多，對於一般使用者來說，快速找到一個簡單好用，對自己有利的大概就夠了。但是對於資訊產業的學生而言，多嘗試一些新事物，才不會侷限自己的思考。

---

沉思：

* 這感覺上好像單純在批評，但是考慮到交通部仍然是中華電信最大的股東（參考這裡） 也就是說，中華電信資產等於是全民的資產，所以還是得來批評一下：

   (1) 作為一個ISP，感覺上提供email是某種為民服務，但現在到底還有多少人還在用中華電信的ms14.hinet.net的email？hinet.net前面的msXX這個數字，在今天作為負載平衡根本沒有任何意義。只是浪費大家打字時間。

   (2) 作為商用email服務，現行的價格實在很荒謬，大概只有不上網搜尋資訊的人，才會使用每個月至少1500台幣的有限email服務。這個服務不但貴的嚇人，可儲存量也驚人的少，竟然少到和bitrix24.com免費版本差不多。