2017年8月25日 星期五

Unity iOS Android App上架實戰心得──《麻雀點數計算乙女》


這份心得主要是用來分享,
我和夥伴使用Unity開發、上架App至雙平台的過程中,
在程式與專案管理上遇到的特殊狀況與解法。
至於基本的做法,
就請交給Google與翻譯機吧!



首先說明一下開發背景吧!
這個案子是由我&美術朋友「赫佐艾卡」共同發起的,
分工上就是程式由我負責、美術由他負責,
剩下的雜事誰擅長就交給誰。

原本我們想得很樂觀,
預計花兩個月左右將它完成並上架
(當時規劃的內容很簡單,就只有「點數計算」而已)。

根據不成文的「兩倍工時預估法則」──
一個案子所花的時間,通常是預估的兩倍」。

我估計核心功能大約需要一個月完成,
然後加上一倍的時間作為測試、除錯、上架之用,
合計也就是兩個月。

但我錯了,「兩倍工時」指的應該是那些不在估計之內的「意外」,
必須保留多一倍的時間來應付它們,否則只要發生意外就一定會延遲。

最後我們花了多久呢?六個月

自我檢討時,從日誌統計出來的工時大約如下:

核心功能開發(一個月)
追加功能開發(一個月)
多種插件的研究&使用、雙平台商店設定&反覆送審上架(合計一個月)
UI優化(兩個月)
宣傳等諸多雜事(零散地吃掉時間,難以計算)


也就是說,核心功能是如期完成沒錯,
而且因為撰寫時就做好完整測試、不欠技術債,
原本估的測試除錯時間幾乎沒花到。


而大量的時間,居然是花在優化UI上!
我們每修改出一個版本後,就會請人試用看看,
並且在一旁觀察使用者的反應,不給予任何提示

我們藉此找出了不少UI問題,
例如使用者在某些地方會疑惑,
不曉得接下來該如何操作、不易分辨能否點擊的物件,
以及字太小、按鈕太小等問題。

每次改進完畢後,就會去找另一批新的使用者測試
確保能夠得到全新的測試反應,
如此不斷改進,終於讓新的使用者也能夠順利使用,
而不需要刻意教學了。

這是我們早期的UI,與現在相比顯得陽春許多,
操作起來也很容易誤觸。

優化過後不僅變得漂亮許多,
能點擊的物件也都更加凸顯了。
(感謝朋友「聖淨之風」、「陳淯翔」、「TK」、「Zehe」提供的寶貴意見)

關於UI、UX的知識實在太多,
這邊先推薦一個網站,有興趣的人可以自行上網找更多資料學習:
Google Material Design

而關於我們在設計UI時,
幾個經朋友建議改善的點在於:

「凡是能操作的物件,儘量加上立體感(或陰影),形狀也特別點,
反之則平面化」;

「按鈕之下的背景最好單純點,以免太花而看不清按鈕」;

「相同類型的物件,其風格、顏色和形狀儘量統一」
(這點我們其實做得還不夠完美);

「當用戶可能疑惑,不知道下一步該點哪時,就應該要強調顯示該按鍵
(例如將「開始計算」和「返回」按鍵改為會閃爍」)

※太多閃爍物件的話會影響效能,因此用在刀口上就好。



而另一個吃掉大量時間的怪獸,就是求好心切(貪心不足)
添加了許多不在當初「兩個月」估計中的功能──

-讓用戶在計算點數時採用自訂規則,並且可以儲存多組設定,快速切換。
例如是否允許食斷、複合役滿,
還能夠判斷許多知名的地方役,如大車輪、八連莊、大七星等等。

因為每個玩家想採用的麻雀規則都可能不同,
如天鳳、雀龍門、麻雀格鬥俱樂部......各有自己的一套規則,
據我所見,目前市面上的所有麻雀計點App,都只採用自己一套寫死的規則,
所以我們相信這項功能,必定能為用戶帶來很大的方便。



-除了「胡牌點數」之外,還能計算「所有聽牌的種類與點數」
這也是比較少見的功能,可以幫助用戶找出沒發現的聽牌,
以及快速判斷哪種聽牌得點較高、是否足以逆轉。



-收集美少女圖鑑功能(對,最初這款App是沒有美少女的)。
我們想讓App也陪著用戶一起成長,
而不僅僅是用過就丟的計算機。

而且用戶只要看看影片就能取得金幣,
可以完全免費地計算點數、收集麻雀乙女。



-四國語言切換
因為沒有經費將翻譯外包,故80%以上都是我自己查字典翻譯的,
後來兩位赫佐艾卡的朋友(賽巴、真誠)也協助了一部分,感謝他們。


-建立FB粉絲頁代替官網,定期發文與粉絲互動。
卻碰到好幾個變態外國人騷擾...

英文這麼破還敢來把妹!(怒)


-存檔格式的設計與加密,防外掛修改記憶體,程式碼混淆。
由於是單機版App,邏輯幾乎都寫在客戶端了,
所以不太可能完全防止破解,
只是為了增加破解者的麻煩,延長版本壽命而已。

研究了八門、燒餅這種任何用戶都能簡單運用的記憶體修改工具之後,
針對它做出了基本的記憶體修改防範
(重要參數都不保存在記憶體裡,每次都重新宣告);

也確認過我們的App被反組譯後的結果,
並將程式碼做過混淆,
但遺憾的是,免費試用的混淆軟體最後仍無法順利運作就是了。

延伸閱讀:
從開發者的角度談遊戲防弊(上)
從開發者的角度談遊戲防弊(下)


-顯示Android狀態列。
什麼是狀態列呢?就是最上方的網路、電量、時間顯示那一列了,
我相信這對許多使用者來說是很在意的事。

iOS要辦到很簡單:
Player Settings > iOS Resolution > Status Bar Hidden 取消勾選

Android在5.3版之後,此選項已被移除,必須用別的方法。

從網路上找到,我目前採用的做法

↓這邊就是狀態列了↓
使用時需注意,別把↑NavigationBar(導航列)↑也開啟了,
否則在hTC等部分手機可能會發生如上問題,
虛擬按鍵常駐而擋到了UI。
(感謝阿智學長、我爸和五伯父特別告知此問題)


-Android獨有的「Escape」鍵,防連點
Escape就是返回鍵,也就是上圖左下方那個白色返回箭頭。

我記得在Android的規範當中,有要求App的Escape鍵必須要有功能才行,
但既然要做我就想做到好,
所以先將所有UI之間的關聯性列清楚,
再設計成讓用戶每按一下返回鍵,就會回到上一層的介面。

再來就是當畫面中正在播放動畫時,要禁止任何操作,包括點擊返回鍵;
也要防止快速連點返回鍵或任何按鈕
(舉例來說,像是快速連點了5次購物,應該只視為1次)。


-使用了許多初次接觸的插件(但真的很實用!)

Unity Analytics - 資料分析後台

非常重要!
若沒有它的話,單機App對於用戶在手機上的任何行為,
幾乎可以說是一無所知。

有了它,即使是完全不自架Server的單機App,
也能夠記錄各種事件,
作為未來的改良參考。

收集到的事件大約4~5小時後會回傳到Unity的後台顯示,
例如DAU(每日活躍用戶)、MAU(每月活躍用戶)、
新增用戶數、留存率等等;
還可以自訂事件,將自訂的內容也回傳到後台。

當沒有網路的時候發生事件,
也會先暫存起來,等網路連上時再自動發送。

※據官方文件所述,自訂事件上限500個字元,
並且最多包含十個參數,但官方未提及的是,
每個參數也有上限100字(不論中英都只算1個字)。


我將自訂事件的參數名稱取成日期+版號+平台(至少可容納100字),
這樣一來就能自動將每天的Log,依平台及版本分類,
而不是像預設的格式那樣全部雜成一團。

就像這樣,事件中包含超過100字的參數是無法傳送的,
僅僅剩下像是"Test110"這樣的事件名稱。
如果事件內包含字數超過500,則連事件本身都無法收到。
而100字當中,即使全是日文也沒有問題,
不會因為全形字就佔兩倍字數。

Unity Ads - 影片廣告插件

顧名思義,就是能在App中提供影片式廣告,
需注意僅限於iOS及Android平台中使用,於其他平台會Error。

分為兩種類型:

1.獎勵式廣告(不可手動跳過,看完後可給予用戶獎勵)
Advertisement.Show ("rewardedVideo", options);

2.可跳過廣告(用戶5秒後可手動跳過,不會觸發獎勵事件)
Advertisement.Show (zoneId, options);

可以在Unity Ads的Dashboard動態改變設定,
決定在播影片時是否靜音,而不需要更新App。
iOS和Android平台分開設置。

我本身也很討厭那種強制跳出的惱人廣告,
因此《麻雀點數計算乙女》是完全不採用這種的,
只有在用戶確定想看廣告(看完可取得金幣獎勵)時才會播放。


在Unity Editor上觀看測試廣告時,點擊操作畫面會穿透點到底下的UI,要小心。
實機上沒發生這種問題,
但為了安全起見,還是加一塊全螢幕半透明擋板(類似Loading效果),
同時也可以讓玩家在等待廣告播放前,明確地感覺到有點擊成功。

※似乎沒有防止連點,所以要自己加上防連點判斷。


技術上的提醒:
雖然預設Unity Ads會自動在Awake()載入遊戲編號,
但偶爾會發生沒載入的情形,所以還是在Awake()幫它載入一次較好。
像這樣:

#if UNITY_IOS
        Advertisement.Initialize ("1234567", l_bAdsTestMode);//遊戲編號,是否為測試模式
#elif UNITY_ANDROID
        Advertisement.Initialize ("1234568", l_bAdsTestMode);
#endif


廣告Server會自動判斷,每用戶每24小時最多觀看25次廣告,
如果想讓用戶看更多的話,只能再串接其他廣告插件了。

至於廣告能獲得多少收入呢?這因國家而異。
不過用戶看廣告所獲得的金幣價值,
通常是遠大於我們實際得到的廣告收益的,
這麼做還是為了讓用戶能夠完全免費使用
而經濟上有餘裕的用戶,也可以直接購買金幣,而不需要看廣告。

例如中國明明觀看了最多次影片,結果一毛收入也沒有;
反觀歐美、日本的千次觀看收益高上這麼多。

雖然知道這點,但我們對海外的宣傳真是十分不擅長,
也不好意思去2ch之類聊天的地方打商業廣告,
順其自然的結果就是這樣Orz

明明是市面上最好的產品啊......
要是身邊有在玩日麻的朋友,請推薦他們使用《麻雀點數計算乙女》看看吧,
真的很好用的!

 Google Play下載       iOS App Store下載

Unity IAP - 應用內付費,驗證付費是否造假

先填寫iOS負責人、稅務與銀行帳戶資料
https://blog.mowd.tw/p/793
http://coderanch.net/138

然後建立iOS App

設定售價與IAP項目
(建議透過Application Loader建立,介面更加人性化,亦可從文件批次上傳)
http://www.jianshu.com/p/033086546126

串接方式請參照Unity官方教學,
https://unity3d.com/learn/tutorials/topics/ads-analytics/integrating-unity-iap-your-game

而當中的Purchaser.cs
要初始化某項IAP商品時,使用的是「產品ID」而非「Apple ID」。
builder.AddProduct ("產品ID", ProductType.Consumable, new IDs
{
{"產品ID", AppleAppStore.Name},
 {"產品ID", GooglePlay.Name},
});

這其實不太會弄錯,
但是當功能一直試不過的時候,
一個焦慮的工程師會開始測試修改所有能改的地方...

另外,由於Google Play的產品ID有特別規範,
需由小寫英文字母 (a-z)、數字 (0-9)、底線 (_) 和點號 (.) 組成,
且開頭必須是小寫英文字母或數字,
所以若想在兩個平台使用相同產品ID,則必須遵守此規範。
※需注意,Google Play的產品ID一旦建立,即使刪除也無法再次使用同樣ID!


IAP驗證

UnityIAP驗證官方說明

Unity > Window > Unity IAP > Receipt Validation Obfuscator

將Google Play的授權金鑰貼進去,按 Obfuscate secrets,
就會在專案中產生GooglePlayTangle與AppleTangle兩個混淆過的檔案。
(不要去改它)


畫面中塗黑處就是Google Play的授權金鑰


同時也必須將金鑰貼到Analytics的Dashboard,才能進行驗證。


之後再按照Unity IAP官網的說明,
將驗證用的程式碼加入Purchaser.cs,即可在用戶端付費時驗證收據,
避免用戶在收據上造假。

※官網說明得不夠清楚,
要記得在Purchaser.cs最頂端加上這行,引用該函式庫。
using UnityEngine.Purchasing.Security;


IAP商品上架

在Unity Editor測試購買IAP時,
若設定一切正確,就會直接通過;
但要在iOS和Android實機上測試購買時,還需要做下列準備。

【iOS】
必須先等App初次送審通過,
否則在iTunes Connect會是「遺失元資料」的狀態,
在實機上購物會顯示「驗證失敗」。

App送審通過之後,還必須將App內購買項目也送出審核
(勾選要送審的項目後,網頁右上角會有按鈕亮起),
下圖是送審中的樣子,要等它們通過才能進行測試購買,
否則只會因為找不到商品而自動取消購買。


送審時,每個平台需提供螢幕快照,
並且要足夠說明App內容才行(我曾經因為只提供一張而被打回票)。
只需要提供最大尺寸的版本快照,就可自動適用於其他較小的裝置,
也就是只需提供iPhone 6、以及iPad2大小的快照即可。

螢幕快照必須是 JPG 或 PNG 格式,且必須採用 RGB 色彩空間,72 DPI。
iPhone最大5.5吋 = 縱向1242px * 2208px 或橫向2208px * 1242px
iPad最大12.9吋 = 縱向2048px * 2732px 或橫向2732px * 2048px

這支宣傳影片是由「赫佐艾卡」製作初稿,
再由我的死黨「至尊星」幫忙優化的
多虧他們的用心,讓App在商店上顯得更加豐富!

iOS的App 預覽(也就是介紹影片,必須放在螢幕快照之前):

格式:M4V、MP4 或 MOV

容量:不超過500 MB

長度:15~30秒

FPS:30以內

分辨率:
iPhone最大5.5吋 = 縱向1080 * 1920 或橫向1920 * 1080
iPad最大12.9吋 = 縱向1200 * 1600 或橫向1600 * 1200

編碼:256kbps AAC

採樣速率:44.1kHz 或 48kHz

必須為立體聲,啟用所有音軌

參考資料:
Apple App Store App 預覽影片準則翻譯


測試裝置清單

將測試裝置的UDID加入開發人員裝置清單中,
裝置的UDID可透過Xcode取得。
(Xcode > Windows > Divices > 選擇連接上的裝置 > Identifier)

但我從App Store直接更新Xcode時一直失敗,
最後是去下載打包好的版本
並且在解壓縮時,還必須將MacOS更新才行。

註:經實測iPhone 4不能更新至iOS 8,
而新版Xcode要求App最低只能支援到iOS 8,
即使在Unity中設定支援到iOS 7也會被強制改高的,
因此新的App都必須放棄支援iPhone 4了。


接著必須將測試人員加入名單中,
開發者帳戶本身也可以作為測試人員。


然後測試人員的信箱會收到一封信,要求去App Store下載TestFlight,
用它所下載安裝的App來測試(記得使用測試人員帳號登入App Store),
才能夠在沙盒環境下測試付費。
※若是使用Xcode直接將App安裝在手機上的話,
使用IAP購物會失敗。當初在這邊卡好久...


Unity現在有提供方法,不必購買iOS開發者帳戶即可先在裝置上測試App,
這樣會比較省錢,
因為iOS開發者帳戶是在付費通過後就立刻開始計時,一年到期,
等到要送審前一週再申請付費就好了。

完成付款步驟之後,再過幾天就會開始計時了,
並非如網路上某篇文章所說,還要按一個按鈕才開始計時。


iOS送審

官方說明文件

這就是Archive後的畫面,Validate和Export都在右上方

每次要更新版本時,
Xcode > Product > Archive,
成功之後Validate讓它先檢查一遍,
最後Export就可以輸出成.ipa檔,
然後強烈建議使用Application Loader上傳!
上傳後大約需要等10分鐘,就能在iTunes Connect中看到。

跨越了無數障礙,終於讓這個建置版本的「+」號出現,
真是令人感慨哪。

使用Xcode提交很容易出問題,甚至還曾經卡住了數小時,
原來是因為它的UI出問題,明明已經上傳完成卻不會刷新畫面。
其實上傳只需要15分鐘左右,
之後再將Xcode視窗縮到最小再打開,就會刷新了。
什麼鳥問題...
多虧網路上這位仁兄分享,才得以解決這莫名其妙的Bug。

就是這畫面讓我等了數個小時!

但即使Xcode顯示Upload Successful,
等了數小時也仍然無法在iTunes Connect上找到剛上傳的App。
最後改用
Xcode > Open Developer Tool > Application Loader
並且將IAP的敘述、審查資訊的螢幕快照也都補上
(這比在網頁上輸入IAP資訊更加方便許多,推薦),
否則在iTunes Connect的狀態仍會顯示為「遺失元資料」而非「準備提交」。


可是當遞送資料時,等了足足10分鐘才回傳告訴我
商品敘述至少要10 bytes以上喔

您下次可以早點講嗎大哥!!◢▆▅▄▃崩╰(〒皿〒)╯潰▃▄▅▇◣


iOS審核效率

我送審過多個版本,每次平均大約1~2天就審完(假日也照審不誤),
比起幾年前動輒審上一週,蘋果的動作真是迅速了非常多。
※據我觀察,他們常在台灣時間半夜2點左右開始審查。

若正在審查中,會顯示在App狀態上

建議先做好一個包含基本功能的版本就送審
及早發現問題及早修正,
才不會臨到要上架時卻被連續打回票。

反正審過之後可以選擇不要開放給用戶下載,
有什麼次要功能,都可以等初版審過之後再追加。

iOS對上架的App有一套規範,開發前可以去查一下,
就不太會觸犯到他們的禁忌而被打回票,
例如在App中提到競爭對手(例如Google)的名字等等。

我只被打回票過一兩次,
原因是Apple需要瞭解,IAP購買的金幣在《麻雀點數計算乙女》中如何使用,
我回覆解釋完,他們就繼續審核了(不需要重新提交檔案)。


另外還遇到幾個Unity匯出到Xcode之後,需手動修正的設定:


即使在Unity設定過也沒有用,
還是必須手動再設定一次,將此處改為None,
否則在部分手機上可能會安裝失敗。


這邊則是Apple故意的,一定要手動重新設定權限
才能使用相關功能。


我原本也沒有設定,直到我的膝蓋中了一箭
(Apple寄信告訴我必須設定權限)


【Google Play】

在此將App上架與設定:
Google Play Console(開發者管理網址)

也必須先「審核」及「發佈」APK(Alpha或Beta測試版皆可),
否則會顯示如下錯誤。


並且發佈到Google Play的APK、與安裝在測試機上的APK,
兩者的Version和Bundle Version Code必須相同,這點iOS應該也是一樣。(未測試)
(在File > Build Settings > Player Settings設定)


PlayerSettings設定

Product Name就是安裝後顯示在App Icon下的名稱,
iOS最多顯示六個中文字、或12個英數+1個半形空格,
超過的部分將會被以「...」的方式省略顯示。
Android能顯示的字數較長(依機型不同也有差異),
故此處建議以iOS的六個字為準。

iOS會自動將Icon邊緣裁成圓角,
所以我們做了兩種不同的Icon分別給不同平台使用。

Android的Icon支援透明色,
但iOS不支援(會被周圍像素自動延伸填滿,甚至不允許使用),
所以我們就把iOS會裁掉的部分用黑色填滿。


Android                 iOS

Version最多三個數字,例如1.0.0,超過將不會被iOS所接受。
Target minimum iOS Version至少要設為8.0,否則也會被Xcode強制改高。

※只要上架審核通過了,下次上傳的新版本,
Version、
Build (iOS)、
Bundle Vertion Code (Android)都必須比前一版大


Android使用測試裝置測試IAP購物須注意:
1) 測試用的帳號,不可與上架用的開發者帳號相同。

2) 測試用的裝置,Google建議先「還原至原廠設定」,
然後要先以測試用的帳號登入,才會讓測試帳號被設定為主帳號。

「欲練神功,必先自宮」,
若不自宮,就不保證會成功啦,請自行嘗試了。

3) 將測試人員加入測試名單(僅限使用gmail帳戶),
讓測試人員透過「選擇接受網址」下載apk,
再收驗證信同意加入測試才行。

版本管理 > 應用程式版本 > 管理Beta版(或Alpha版亦可) > 管理測試人員


4) 在Google Play的App內測試購物是真的會付款,之後可以在「訂單管理」退款




記得測試購物之後,一定要馬上去退款!
像我有一次刷了一筆3000元,
隔了半天才想起來,結果...



...就晚了半天才退款成功,嚇自己一跳。
建議大家不要學我,如果等到信用卡帳單都結算了才想退,搞不好就沒辦法了。

順道一提,由於雙平台都會抽取30%的費用,
還要再扣除各國不同的稅率,
實際能從IAP得到的收入大約只有用戶付出的一半金額甚至更少。


IDFA(廣告ID)

以前要辨識不同用戶時,通常會去取得裝置的唯一編號,
但後來iOS和Android政策都傾向保護用戶個資,
所以雙平台最好一律改採用IDFA(廣告ID)。

它跟用戶裝置的唯一編號差別在於,
此廣告ID是無法永久對應裝置及用戶身份的,
僅用於此單一App,
而且一旦移除App重新安裝的話,又會改為新的廣告ID(更新則不會變)。

而這項功能在每次iOS App送審時,都會被詢問是否有使用,
有使用的話才會開啟此功能,當送審通過之後便能夠產生用戶的廣告ID。

僅限在iOS平台取得廣告ID:
UnityEngine.iOS.Device.advertisingIdentifier

iOS和Android平台取得廣告ID(Windows不可):
Application.RequestAdvertisingIdentifierAsync (
    (string advertisingId, bool trackingEnabled, string error) =>
    {
        Debug.Log ("advertisingId " + advertisingId + " " + trackingEnabled + " " + error);
    }
);


正式上架發佈

Google Play會立即出現在商店上,
iOS則大約會晚個半小時~一小時。
如果要做宣傳的話,建議等確認出現在iOS商店上再做。

由於中國的網路長城,
不翻牆的話只能連接iOS App Store,
無法直接訪問Google Play和Youtube,
因此最好另外尋找中國用戶可訪問的空間。

影片我試了許多空間,有的甚至才剛上傳,
就被系統以莫須有的罪名自動屏蔽了。

最後是找到bilibili可以成功上傳,
不過在這之前還需要回答一大堆問題就是了。

不夠宅還不行呢!

而存放apk,供中國用戶自行下載安裝的空間就難找了,
現在因為實名制的關係,
幾乎全都要綁定中國手機、或者付費,
只有騰訊微雲免費又不綁手機,
提供10G的免費空間,但連結只能維持一週。

所以最後我們也放棄了,
如果有人知道在中國可用的免費空間的話,
可以留言告訴我,我會再補充進文章裡的,感謝您。



最後還有一些開發專案的心得,也順便跟大家分享──

版本控管
很重要,很重要,很重要,所以要說三次。

在本專案中,Unity幾乎只有我在使用,
因此我跟夥伴之間沒有同步專案的需求,版本管理起來算是很輕鬆。

但即使如此,將專案區分版本備份至雲端依然非常重要,
在開發期間內至少發生過四次,
我把專案改壞了而非得還原不可的情形,
幸好有做備份,只要幾分鐘就能救回來了,不然可是欲哭無淚。


先確認「最困難、最核心」的部分做得出來,並且要先做

例如我們做的這款App,目標是以「廣告+IAP(App內付費)」收費,
提供「日本麻雀點數計算」和「抽籤收集美少女圖鑑」的單機服務,
都是先確認過做得出來,專案才正式開跑的。

否則若等進行到一半才發現無法克服的瓶頸,
會讓專案承受毀滅性的打擊

再來就是從這些最核心、最難做的項目先開始進行,
不僅是為了保險,更是因為成員的動力在一開始最強,
若到了結尾的時候才來面對最困難的項目,
會更容易產生逃避、草草了事的心態。


分工與獎懲要明確

三個和尚沒水喝的道理大家都聽過,
多人合作時很忌諱權責不清、獎懲不明的問題,
一件事「沒人做」「出問題無人可追究負責」「做得好不知該歸功獎勵誰」
都不是好事。

所以我們一開始就講好職責及利潤分配,確實遵守。
並且一開始就在App中建立開發人員名單,根據實際工作內容更新,
如此能夠更直接地激發榮譽心、責任心。
※雖然職責區分明確,但我們做出重要決定時都還是會互相確認想法,
常常因此將點子優化得更好,
若猶豫不決時再由負責人做最後決定。

公佈開發人員名單的做法,即便會讓好的人才更容易被其他團隊看上挖走,
我也覺得這是每個人努力所應得的名聲
(反過來說,做不好的話也能從名單上找到是誰負責的)。

不過因為我們的案子並非上下雇傭關係,
而是朋友間的合夥關係,
所以就不採用獎懲的形式,
而是各自承諾每項工作的完成期限

定期瞭解彼此的成果,對雙方都有激勵作用;
而若有成員的進度遲緩下來,
也能夠及早注意到,給予關心和協助;
逾期的人也會自發地請個飲料什麼的。

多虧彼此的這種「加分式」合作,
才讓這個案子持續六個月以來,
即便已經遠遠超出當初預期的兩個月,
兩人都還是不鬆懈地努力到正式上架的一刻。



下次分享日期:2017年9月





沒有留言:

張貼留言