顯示具有 consultant 標籤的文章。 顯示所有文章
顯示具有 consultant 標籤的文章。 顯示所有文章

6/20/2020

新手主管的準備 - 1 (軟體主管的31堂課)









沒有時間嗎?可以直接看這個清單

沒有人生下來就知道如何作為一個領導者,軟體開發的主管也不例外,即便是資深厲害的主管也都會遇到第一次當主管的困難。

無論是什麼原因,當你有機會變成主管時,需要有意識的認知到,主管的責任和義務會跟你過去的工作截然不同。越快有這樣的認知,並且越快做好準備,你就越有機會成為一個好主管。反之,沒有這樣的認知並且也不做準備,就會有很大可能變成傳說中的壞老闆。

工作本質上的改變


以軟體開發的主管為例,在你變成主管的那一天開始,工作就有本質上的不同。無論之前是不是擔任團隊領導(team leader)的角色,作為主管之後,你的責任範圍就會自己擴大為「團隊」,並且近一步擴大到「其他團隊的互動」。
根據團隊的規模大小,在人數很少的團隊,主管也會進行實質工作,例如撰寫程式,測試等等。然而,工作本質上會讓主管必須要更關注「團隊其他成員」如何完成自己的工作。表面上,簡單的方法,是透過code review。實際上,更推薦新手主管至少每週要找一小段時間,直接坐在某些團隊成員的旁邊,和他一起pair programming。這並不只是兩個人一起看著同一個螢幕寫程式,同時也代表可以了解團隊成員是怎麼完成周邊任務,例如撰寫文件,撰寫測試,執行測試,檢查是否符合規格等等。

工作本質上的改變必須要真正被「實踐」。實踐的方式就是必須要認知時間的重新分配。


工作時間的分配

大部分的人會傾向做自己「喜歡」做的事情。很遺憾的是,如果新手主管只做自己喜歡的事情,那有很大的機會會造成團隊的失敗。

一般來說,新手主管至少每個月都要和團隊成員進行一次1vs1的懇談至少每週要花1小時,重新檢查一次目前重要事項的進度,以及風險評估。至少每週要花一小時,和重要相關的其他團隊主管溝通。至少每週花一小時,和自己的主管溝通......這些零零總總之的「至少項目」,如果沒辦法有效進行,那麼會花上起碼1/3的工作時間,而且可能也達不到該有的較果。這也是為什麼許多新手主管看似忙得要死,但卻常有溝通問題。

時間,是軟體開發裡面,最需要被控制的資源,但也是最不容易被控制的。主管會比工程師更需要知道怎樣有效分配時間。


衡量成果的改變


作為新手主管,必須要認知到衡量自我成功的要素,會是團隊的成功。換言之,任何團隊的問題,無論是不是自己造成的,都會是自己的問題。誠所謂權力越大,責任也越大。

認知到衡量成果的改變,也代表你需要追蹤和關注的,不只是個人的產出,還會是團隊整體的產出。並且,規模團隊越大,個人產出會變得越不重要。舉個極端的例子:假設一個大型軟體產品開發團隊裡面,有前端工程師,後端工程師,手機app工程師,維運工程師等等,每個工程師小組表面上都按照標準完成任務,但是整合起來就是會有各種問題,那麼這仍然是個失敗的狀態,而軟體主管是這個失敗狀態的主要負責的人。


要做好資訊相關的主管任務,其實相當不容易,當至少有認知到以上的改變時,就可以開始進行準備工作(參見 新手主管的準備 - 2)。



9/08/2019

如何指派工作 (軟體主管的31堂課)


作為團隊領導者,自然會遇到任務分配,指派工作任務的情況。軟體開發團隊也不例外,雖然敏捷式開發方式中的Scrum方法論,是希望在每個Sprint中採取「自己認領」工作,但其實極少有團隊可以完全做到這點。

指派工作任務最完美狀況是:團隊成員對主管有100%的信任,同時對組織中短期目標也有深切體會;並且都有完整的技術能力可以達成任務;而且所有人對於專案與時間管理都有經驗;而更重要的是,每個人都士氣高昂,迫不及待地完成任務。很遺憾的是,這種情況幾乎不會存在,好的軟體主管必然認知到的是,自己的任務必然是在於讓團隊成長前進,往好的地方邁進,而非期待自己「已經處於」一個完美的團隊。

如果你是個軟體團隊的主管,常常在夜深人靜時自己抱怨自己的環境與團隊,並且自認為委屈,那麼你就是屬於「期待自己已經處於完美團隊的主管」,這通常不會是讓事情變好的心態。

指派工作的方式看似很多,但重點只有幾個:

(一) 指定清楚的目標


指定清楚目標表面上很簡單,但主管自己其實需要考慮是這件事的真正目標,和指定任務的項目。

舉例來說,如果軟體主管指定任務目標為:「A工程師,請把某個AWS的一組VM,從micro升級到xlarge。」這看似清楚目標,但升級機器,必然不是目標,升級機器要達到的結果才有可能是目標,更有可能的是結果後的結果才是目標。

例如,稍微清楚描述目標:「A工程師,我剛收到通知明天由於行銷活動,我們網站流量應該會暴增,為了讓我們能處理高流量,請把某個AWS的一組VM,從micro升級到xlarge。」

但是,更好的方式其實是,清楚目標先指定,然後再討論出來。例如:「A工程師,我剛收到通知明天由於行銷活動,我們網站流量應該會暴增,為了讓我們能處理高流量,我們在AWS上的各種VM和使用的服務,有需要做哪些改變呢?」

當然,目標本身一定要涵蓋作法/行動。沒有具體行動的目標也沒有意義。

(二) 時間視為最重要衡量方式


時間是衡量所有事情的最重要的方式,在清楚指定或者討論目標作法之後,所有的行動必須以時間為衡量方式。而時間除了長度,還有實際完成時間。

例如:「A工程師,根據我們剛才討論結果,我們需要升級所有120個VM,這需要2小時,並且是在後天早上10:30am之前完成」

(三) 寫下來!


指派工作的另一個重點在於,所有任務指派一定要文字化或者圖形化,即便是很簡單的瑣碎小任務,也應該用一張紙寫下來。現在專案管理工具其實很多,例如JIRA。當然也可以用它來指定所有任務。


12/18/2017

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.



11/13/2017

在台灣建立研發中心?


現代經濟學鼻祖:亞當斯密的國富論中,描述產品價值有三個主要來源:「土地」,「資本」與「勞動」。其中土地泛指自然資源,勞動在現代社會不僅僅指人力,更重要的有執行力和創意的人才。

而今資訊社會中,因為交通和電信費用降低,以至於人才流動成本也跟著巨幅地降低(註1)。資本主義當然會讓「看不見的手」運作,而讓企業組織的經營,朝向最低成本最高效率方向前進。人才的取得也不例外。

最近一兩年已經有太多企業巫醫在討論「台灣人才外流」的問題。其中不外乎以聳動的標題。例如:

*「我在台灣看不到工作的未來」... 或許只有你看不到也說不定?
*「低薪惹禍誰想待在鬼島」... 低薪是一回事,但是台灣在所有地球上居住人口超過1萬個人的島嶼裡面,絕對排不到鬼島行列,請想一下菲律賓印尼加勒比海這些島國。
*「台灣小而亂普遍又低薪」...的確台灣不大,但是普遍低薪和亂這兩個形容詞,卻在該文中沒有任何支持的數據和研究,只是個人感想當作新聞來操弄。

有時候,單看客觀事實並不有趣,不太能成為焦點,然而客觀事實卻是,想確實進展的最佳依據。所以,我們應試著了解,就經濟學的角度而言,企業組織應該「移動台灣人才」還是「在台灣建立研發中心」比較適合呢?(註2)

首先,要簡單區分「人才」,「員工」和「人力」。人力泛指勞動力,在最基本的教育水準下,就可學習工作得稱為人力,資本主義天生會使用最低薪資,在當地合法的範圍內榨取人力。員工指的是企業內受雇的所有人,可能需要某種訓練過的技能,但其學習能在短時間達成。人才比較難定義,在此暫時指需要長期間的教育培養,並且已經有7年以上的實務工作經驗的專業人士。而在此要討論的,就是「人才」的移動,而非人力或者員工的移動。

最簡單衡量人才流動應該是看「實際獲利」,包含薪資,居住成本等等。衡量一個國家的薪資有很多方式,雖然沒有最好的方式,但是觀察GDP和NNI都可以考慮。

可是,更有趣的數字在於GDP和PPP的差距。

最最粗淺的說,人均GDP表示此國家平均每人在該年生產的價值。三大組織:聯合國,世界銀行,國際貨幣組織:每年都會公布此數字。彼此間資料收集方法略有不同,數字彼此有一點點差距。

讓我們專門看五個國家的2016 GDP:台灣,中國,日本,韓國,新加坡。


   GDP美金
台灣 22,453
中國 8,133
日本 38,917
韓國 27,632
新加坡 52,961

這和我們內心理解差不多,台灣似乎遠不如其他先進國家,不過大陸的「平均值」仍然很低(當然比較特定區域:例如上海,那結果可能不太一樣)

然而,更有趣的數字是PPP:平均購買力。PPP其實和GDP的計算方式雷同,只是將匯率和物價也考慮進去。而PPP才是在該國家裡面的人,實際上消費真實情況。將GDP和PPP之間的差距,除以GDP就是「購買力相對於生產力的增額」。參見下表:

(本文的數字都是美金計價,並由wiki節錄國際貨幣基金會取得)


  GDP(美金) PPP(美金) 購買力相對於生產力的增額
台灣 22,453 48,095 114%
中國 8,133 15,399 89%
日本 38,917 41,275 6%
韓國 27,632 37,947 37%
新加坡 52,961 87,855 66%


這個表顯示幾個事實:

(1) 在這五個國家內,日本的GDP和PPP最接近,而台灣差距最大。

(2) 單純看GDP,台灣遠不如日本韓國。然而,單純看購買力,2016年台灣比日本韓國都要來得高。

(3) 假設這五個國家的人才能力差不多,則在台灣建立以人才為主的研發中心是「最划算」的選擇。因為同樣價格的人才,在台灣實質獲利是最佳的。同樣100單位的錢,在這五個國家中,台灣實質可花費214, 日本是106, 中國目前是189,韓國為137,新加坡是166。(註3)

(4) 購買力和物價很大的關係,然而購買力要和GDP同時考量,因為就算有極低的物價,GDP不高也是沒有意義。

(5) 絕大部分先進國家這兩個數字都很接近,某些國家(例如GDP一直都排名前三名的盧森堡)甚至購買力增加率是負的!


然而,單就這兩個數字,很容易看出缺陷。例如把菲律賓加入之後變成下表:



  GDP(美金) PPP(美金)  
台灣 22,453 48,095 114%
中國 8,133 15,399 89%
日本 38,917 41,275 6%
韓國 27,632 37,947 37%
新加坡 52,961 87,855 66%
菲律賓 2,991 7,696 157%

難道字面上的解釋,菲律賓比台灣更適合建立研發中心?吸引更多人才。這張表可以解釋菲律賓可以找到更多「人力」。無法解釋為什麼沒有更多人才。因此,需要再加上另一個指數:HDI 人類發展指數。

人類發展指數計算很繁雜,最粗淺的說,指數越接近1表示這個國家越先進,先進包含基礎建設,教育等等。(註4)


  GDP(美金) PPP(美金) 購買力相對於
生產力的增額
HDI HDI權重之PPP 人才庫
划算指數
台灣 22,453 48,095 114% 0.885 42564.075 90%
中國 8,133 15,399 89% 0.738 11364.462 40%
日本 38,917 41,275 6% 0.903 37271.325 -4%
韓國 27,632 37,947 37% 0.901 34190.247 24%
新加坡 52,961 87,855 66% 0.925 81265.875 53%
菲律賓 2,991 7,696 157% 0.68 5233.28 75%


將HDI的權重考慮進PPP中,並按照購買力對比於生產力的增加,計算出「人才庫划算指數」。在此指數很簡單的看得出來,建立以人才為主的研發中心,還是台灣最划算。(註5)

當然這個模型有很多缺陷和假設,但是起碼它是以確切的事實作為考量,並且可以具體的討論和修改。相較於譁眾取寵的喊叫人才外移的嚴重性,相信來得有用。


NNI, GDP, PPP三者的細節,請自行參考wiki

(1) NNI (國民收入)
(2) GDP(國內生產總值)
(3) PPP(購買力平價) :要注意的是,購買力評價,並不是很好衡量生活水準的方式。此方式較適合用於國家間互相比較,不太適合同一國家不同時間內比較。
(4) HDI 人類發展指數 
(5) 人才庫划算指數:=((PPP*HDI)-GDP) / GDP





註1:就在不遠的15年前(2003),當時出差到歐洲每個月要額外花上5千元台幣左右的電話費網路費,用以和家人聯繫。如今出差到歐洲每個月頂多花1千五百台幣元,就可以獲得比15年前更高品質的視訊通話。

註2:這裡有很多假設,假設國際企業需要的是人力而非人才,假設企業組織是理性的,假設台灣人才也是理性的。

註3:這裡的增額,和個人在單一國家內花費的感受會有所差異。換言之,要有所感受,必須要在差不多時間,同時在日本和台灣取得相同工作的類似薪資才能做比較。

註4:也因為HDI指數很大一部分涵蓋教育,因此數值越接近1,國民教育水準會越高。

註5:沒錯 人才庫划算指數 是自己的推測 並沒有什麼研究根據...XD

7/12/2017

Serverless design for IoT - An example leverage AWS and GrovePi



AWS announced IOT service in about 2015 and gradually release other relative service (for example: IoT Button) for those who need to tackle with the problem on huge amount of increasing response of "The Things". And it is of course the area which cloud provider what to provide a optional solution.

To demonstrate the benefits of leveraging the serverless design and also utilize the power of AWS cloud. I build an example project combines Serverless design, AWS IoT, Respberry Pi, Grove Sensor system and GrovePI. It will provide in door air quality (office) for me if I want to know that before entering office. So that I can have an excuse to work from somewhere else? :)

In this example, a GrovePi mounts in Raspberry Pi (B+) to control Grove's Air Quality Sensor, HCHO sensor and dust sensor. As a software engineer, I assembled all these inside a paper box. See picture below.

RPi and GrovePi are inside the box. 3 sensors are out there.




Reminder: to use AWS service, the most important things is to read official document. AWS has many different services and there are too many out-of-date articles in somebody's blog. It doesn't mean that authors were wrong, it is just out-of-date. Of course, it is the same in Raspberry Pi and all other 3rd party open source library, try to read official document (or official wiki/blog) to have overall view.

The full implementation and design concerns 


(please check all the project detail in github)

(1) Grove's 3 sensors + GrovePi + Raspberry Pi

   The hardware parts. Check GrovePi's official web site to know how to put them together.

    GrovePi might be the easiest way to program Grove's system from Raspberry Pi, if you have more then 2 device in a machine. However, if you have only one sensor, then just use RPi's GPIO.

(2) AWS IoT service

   Although we didn't program anything in side the hardware, we still need to setup things in AWS IoT service. And of course, it will be better to read at least the tutorial.

Screenshot of AWS IoT Tutorial
   AWS IoT pricing model is counting by message (512bytes). At this moment, about $5 per million message. Which means about $5 per 500MB! This is much more expensive than own a EC2 service to serve device message. However, if you don't need to keep all monitoring data transit in AWS every few seconds and you need only monitoring state changes (maybe a few times per day) then a "Device Shadows" is the best for you.

   In this example, we register a "Thing" named: InDoorSensor1 and the most important thing is to have default Shadow Object as below:
{
  "desired": {
    "welcome": "aws-iot",
    "air quality": 43,
    "action": "wait"
  },
  "reported": {
    "welcome": "aws-iot",
    "action": "wait",
    "air quality": 43
  }
}

   The device will keep sync the Shadow in AWS and if the desired state change to "do", it will (a) do a one time air sensor data collection and then (b) update air quality in Shadow object (c) change to "wait" state. In sort, the Shadow and Device will sync the state (wait or do) and the state's sync is the major function provide from AWS.


(3) AWS IoT Python SDK + GrovePi Python library

AWS provides a few SDK for device, in this project, we use Python to do AWS Cloud access (no matter notification or change Shadow state)

In the Raspberry PI B+, you need to:

    (a) install AWSIoTPythonSDK
    # pip install AWSIoTPythonSDK  (also see here)

    (b) consider the protocol (MQTT vs Websocket). In some environment, the MQTT port might be block. AWS SDK provides MQTT via WebSocket which of course allow broker use port 443.

    (c) certificates: please do read AWS IoT Certificate document if you didn't have experience before

If you use Raspberry PI version B+ 2 or 3, then it will be easy to install nodejs/npm and all other fancy stuff.


(4) IoT Shadow


    The Shadow means an identify object of IoT device. This allows client to change the state of a object and then sync to IoT device. In certain scenario, it allows programmer no need to take care of network error handling or any off line case. However, you still need to fully understand what means exactly the "desired" and "reported" state.
   It is possible to edit Shadow state from AWS admin console direct for testing purpose. (you won't want to do so if you have thousands IoT device).



(5) Lambda, API Gateway


    Supposedly, an application will NOT access specific IoT device, it normally access a service and that service provides information or allow meaningful user actions.
    In this case, a lambda service is simple a python program which can (1) retrieve current state and also current air quality value (2) update state to "do". And as always, the Lambda is behind an API Gateway and which means, potentially, all other application could use this API to access necessary (filtered) information.

see the activity hand draw:



Next Project

Hopefully, I can have more budget to purchase Raspberry PI 3 and also CO2 sensor and then also gather data to draw graphic in D3. Also, I am thinking to use LINE to send air quality information to my colleague or neighborhood. 



5/22/2017

企業巫醫 - 講重點!




在許多企業巫醫的書籍文章演講中,都繪聲繪影的描述「講重點」是極端重要。但也僅只是說它很重要,卻擺明著忽略這件事的真正重點:「關鍵重點難以找到」,或者更直接的「怎樣找到重點」。


就只是像提醒健康很重要的提醒「講重點」的文章像是:這裡這裡

另一些文章,表面上提出一些找到重點的方式,但是壓根也是一堆廢話。例如:從對方觀點找到真正價值。聽起來很有道理,但就像部落巫醫說:「得罪了祖靈,所以你生病了」,看似有理,但是到底做了什麼得罪了祖靈才是重點吧。「如何」知道對方的觀點,才是找到重點的重點。這類型的文章例如:這裡這裡這裡

只而更有些文章,提出了似乎務實的步驟,但都是太過一般化的案例,不是類似秘書處理好老闆的行程,就是與別人討論時的對話重點。這些在技術為主體的組織裡也根本派不上用場,例如:這裡這裡


絕大部分的人在工作上,並非不講重點,而是講不出來或找不到。而很遺憾的是,複雜環境(參考Cynefin架構)下的關鍵重點,並沒有簡單的三步驟,也沒有五個必備SOP之類的方式就可以取得。

關鍵因素的掌握,需要知識與經驗的累積。

知識的累積會堆積成智慧,經驗的累積會變成靈感,而智慧與靈感綜合起來,就能在複雜事物上以很短的時間將其抽象簡化,而抽象簡化的事物就容易看出重點。

雖然沒有捷徑,但就像是健身減肥一樣,從任何時間開始都不嫌晚。而且從任何時間點開始,都可以在比自己想像的時間內還早獲得效果。

知識的累積


只要抱著開放的心態,多閱讀,多請益,大概就很容易做到知識的累積。(知識快速累積可參考這裡)

值得注意的是,知識也有分軟硬兩種類型(註1)。

軟知識:談判技巧,溝通技巧,專案管理,人際關係,等等都屬於軟知識。換言之,軟知識可能會隨著文化背景改變而有截然不同的結果。

軟知識,容易落入「嘴砲唬爛」的範圍。軟知識的累積因為太多太多地方可取得,就不在這裡討論。要稍微注意的是,無論是什麼樣的人對「軟知識」都有自己的一套煞有其事的說法,要注意不要落入「純唬爛嘴砲」的範圍之中。

硬知識:數學,工程,程式設計,等等都屬於知識。換言之,硬知識不會隨環境的改變而改變,但它會隨時代的進步而進步,容易站在巨人的肩膀上前進。

硬知識,容易變得「極端」,不是容易被忽略,就是容易被過度強化。

絕大部分在組織工作的人,只要有數年以上工作經驗,都知道軟知識的重要。而各類型心靈成長,溝通協調,領導管理的書籍課程就孕育而生。在組織中,最極端的中階主管就會有意無意透露出「軟知識」遠比「硬知識」來得重要的許多(註2)。

最佳的情況是:硬知識和軟知識必須要互為成長基柱。兩者兼具的成長。

硬知識的累積:非常簡單,(1) 先設定知識累積範圍,例如設定為軟體品質改善 (2) 利用mindmap圖,整理自己已經在腦海的知識 (3)去圖書館至少借7本相關書籍,(4)上網尋找相關知識 (5) 閱讀並且搜尋完之後,僅憑自己的記憶和腦中統整結果,再次畫出mindmap圖,有必要的時候進行實作(例如寫程式)


經驗的累積


經驗可以解決在Cynefin framework中,「複雜」與「渾沌」這兩個象限的問題。(關於Cynefin請參考這篇)

不過,經驗的累積方式是經驗是否能「持續累積」的關鍵。

同樣一件事情做20年,有些人會取得20年的寶貴經驗,有些人卻是像是只做了1年一樣:只是做了20次一年。

以軟體開發為例:

1. 在SAP的ERP環境下,撰寫相關模組20年,如果沒有產業相關知識的成長,只負責出各種報表,那麼和2年經驗也差不多

2. 做為專案經理超過20年,如果遇到事情只會加班解決,那麼和1年經驗也差不多(參考這裡)。

3. 做為有10年開發經驗的java程式設計師,如果遇到組織調整,需要使用其他程式語言,但用各種方式拒絕推託,那麼未來可能就變成只有數年經驗值的程式設計師。因為推託學習不但會讓技術停滯不前,還會退後。

經驗的持續累積也很簡單。重點在於「持續」:每隔一段時間檢視自己的工作筆記,看看自己是否做了任何改善現在工作的技術的事情。如果沒有,就表示沒有持續累積經驗,經驗僅只是停滯而已。

沒有工作筆記?趕快去買一本吧,筆記本太便宜好用了。







註1:當然有些知識很難分軟硬,這裡只是概述而已。
註2:例如,軟體開發有個傳言:「coding co的好,要飯要到老。」

3/31/2017

企業巫醫 - 向上管理的實務作為?



向上管理是個歷久不衰的名詞,它和「人格特質分析」「領導與管理」等名詞雷同,每隔一小段時間就會以各種形式,出現在企業巫醫們的討論中。

近期隨意查詢就可以找到不少相關文章: 向上管理(cheers雜誌),如何讓老闆聽我的反對老闆的六種方式向上管理的四步驟 ......

「向上管理」向來是一個譁眾取寵的話題,眾多企業巫醫仍然以泛泛之談,試圖教導並解決一個現實而又務實的問題。

企業巫醫,總是能選定看似重要的無法辯駁,共通的話題,而且此類話題完全視個人情況而有截然不同的作為。因此,企業巫醫可以提出極端空洞的說詞,卻又多少讓人覺得有趣。除了「向上管理」之外,「創業」「創意」「領導與管理」「人格特質」等等都是屬於這類。

實務上,「向上管理」不能是打算進行的行為,而是產生貢獻中的其中一個結果。換言之,追逐向上管理,等於是捨本逐末的追逐影子行為。

因此,先務實地做到基本三件事情,假如踏實的做到了,向上管理就不是問題,而是附帶的結果。

1. 真正了解關於自己的現況事實

事實現況聽起來簡單,要找到也很簡單,但是要承認自己的現況事實其實有點難。

事實必須是清楚的,不模擬兩可的。例如,假設你是NBA球員,去年平均上場25分鐘,平均得分14分,這就是事實。至於你的技術能力好不好,並不是「事實」的一部分。以資訊科技的相關工作來說:參與過專案是事實,寫過java/python程式是事實,取得JSCP證照是事實,有Scrum證照是事實,帶領過開發團隊是事實,參與open source相關研討會是事實。

然而,具有良好溝通能力不算是一種事實,喜愛資訊科技不算是一種事實,

現況也必須是清楚的,不可能模糊。例如,目前薪資是現況,工作年資是現況,是否有直接report的人(也就是是否為管理者)是現況,最近一年有沒有拿到其他公司的offer也是現況,曾經拿到比現在薪水高的offer也是現況。

然而,覺得自己薪水被低估不是現況,覺得自己不受到重要不是事實,幾乎大部分的感受也都不是現況的一部份。

請參考這裡這裡這裡


2. 讓自己的實際產出超乎期待 


二因子激勵理論,描述「保健因子」和「激勵因子」兩種個人激勵因素。而其實這也是務實的評斷自己工作的方式。請參考這裡

要確定自己的產出超過期待,必須要確定產出有「超出」。

以基層程式設計師而言,在過去一年該寫的程式功能都有如期完成,並且品質在一定範圍之內。這樣的工作內容並沒有「超乎期待」,只是滿足「現在的薪水」而已。

要超乎期待的方式有很多。最容易的方式,是在目前工作範圍之外,「額外」並且「主動」完成有意義的事。例如,以基層程式設計師而言,在過去一年該寫的程式功能都有如期完成,並且品質在一定範圍之內,並且,主動地在額外的時間舉辦小規模研討會,分享工作上技術的進展。另一個例子,以基層程式設計師而言,在過去一年該寫的程式功能都有如期完成,並且品質在一定範圍之內,並且,由於主動學習其他程式語言,因此在其他專案上也能做額外貢獻。


3. 建立短中期職涯計畫並確實執行


在資訊科技產業中,實踐長期職涯規劃幾乎是不可能(註1)。

然而這並不代表自己現在就應該隨波逐流,看主管決定什麼就做什麼。個人應該要維持短中期的職涯規劃。特別是短期規劃。

短期規劃,必須要和技術能力以及現在工作有密切相關。

例如:

「作為一個程式設計師,未來8個禮拜,要能學會Scala基本用法,並且提出現在產品裡用Scala做分析的計畫」

「作為一個QA新鮮人,未來4周,要能將現在100個手動測試的case,至少其中20個變成自動化測試。同時,原本的工作也不會拖延」

中期計畫乃是半年到2年左右。必須要是「可以明白斷定達到與否」的目標。

例如:

「作為一個QA新鮮人,在2年內我想要變成資深QA,斷定是否為資深QA是以是否升遷或取得其他公司資深QA的offer」

當你完成數個短期計畫,通常表示你也踏實的逐步成長。即便有些短期目標沒有照時間完成,也沒關係,幾次之後,仍然是踏實往中期目標前進。

重點在於:這些目標是你自己決定的,並非主管或其他人硬塞給你。而目標既然和目前工作有關,自然就會協助你在工作上成長。


......
如果你非常非常確定已經完成以上三點,但覺得在這個組織中的成長仍有阻礙,還是很需要「向上管理」,用以獲得好的評價,獲得升遷?這基本上是不太需要,因為你應該儘速離開這樣的組織才是最好的方式。




註1: 「長期職業規劃」和「個人理想夢想」並不同。個人理想夢想可以需要很長很長時間實踐,也可能只需要很短的時間,也可能和職業無關。當然個人夢想就需要長期投入,也可以規劃,也可以不規劃。不過,不投入自己時間的夢想,通常就是空想而已。

3/23/2017

企業巫醫 - 贅字 廢話 泥巴仗




在組織中,溝通合作是大部分的人一定會做的事情。

溝通合作說起來簡單,畢竟人類是靠群體合作而存活在地球上。不過,在企業內部的有效溝通並不如想像中的容易(註1)。

某些人在對話或文字表達上,有意無意的更增加溝通的難度。如果是無心的,僅只是造成困擾而已。但如果是刻意為之,會讓溝通困難,讓事情滯礙難行。

無論有意無意,溝通上常見三個問題:「贅字」「廢話」「泥巴仗」

在這三個之中,贅字和廢話很煩人,但真正要解決的是可怕的泥巴仗。


贅字


典型的例子,像是最近淡江大學解聘兼任教師的新聞:高教工會主任:「學校也一再地向(兼任教師)表示說,也是因為今年的8月1日,勞基法要開始適用於,未具本職的兼任教師身上,學校不想負擔這樣的人事成本,所以他們才會做了一個解聘跟不續聘的動作。」

有人稱這類型的贅字為「語言癌」。(註2)

凡舉「關於XXXX這個部分」,「做一個XXX的動作」,無意義的拉長語句都是。

當然也有些人認為拉長語句是「敬語」的表達方式(註3)。

此外,狀聲詞:「嗯」「唉」「阿」因為在對話中,有實質表達情緒的功能,所以不算是贅字。

不過,贅字真正的影響其實很小,只是太多贅字會讓聽的人很不舒服而已。



廢話


在說明事情,或者文件上,用過多虛浮的形容詞,掩飾無意義的內容。或者,重複不證自明的真理,用以掩蓋無法找到重點的對話。

在政府機關的公務人員出國報告網,可以輕易地查詢到充滿廢話的報告。

例如:一個公司是多面向的結合。(簡單的說,整句都是廢話)

例如:透過本次會議實際瞭解大陸生醫相關市場現況,就本所研發之核醫藥物推廣應用極具參考價值,可納入本所未來研發方向之參酌。 (簡單的說,出國去參加這個會議,最後只是參觀看看而已,沒什麼東西是真的影響組織的研發方向!)

另一個例子:不論是什麼樣類型的數位化工具,除了便利性外,都應兼顧到安全性,日後推動電子化政府的過程中,應與各級資訊安全主管機關做密切的合作,確保資訊科技的演進不會成為資安漏洞。(資訊科技本來就不應該是資安漏洞,各級安全主管機關本來也就應該合作,哪會需要出國參加會議之後才知道這兩件重要的事?)

當然,某些企業網站資訊,也是廢話很多。不過,大部分是似是而非的術語,構築專業能力的感受。

例如:透過嚴格的專案控管與扎實的系統建置專業能力,我們有信心提供客戶最安心、最可靠的大數據優質服務。(如果把形容詞拿掉,這句話其實很短:我們提供專案控制和系統建置的大數據服務。但更具體一點,就是:其實有案子我們就可以接來做,大數據只是個行銷名詞)

有時候廢話很煩人,因為要花些力氣才能抵達事實真相。廢話浪費的很多時間,不過如果採用Scrum方法論,在會議上只專注於現況和事實,應該不太可能會有廢話太多的問題。至於網頁資訊和技術文件,就應該盡可能去除廢話。

泥巴仗


最高級,並且更難應對的是泥巴仗。

特別是在中大型組織,中階主管通常都位於關鍵職位。而好的中階主管,仍具備本職學能(註3),會根據事實來溝通。也因此,優秀的中階主管通常會強調技術事實,產業事實,專案事實,資源分配事實...等等諸多事實根據,作為溝通以及決策的基礎。因此,反倒不會強調本身的溝通協調能力。因為這樣的能力,如同影子一般隨附在工作之中。

然而糟糕的中階主管,由於已喪失本職學能(註4),就會強調其「協調溝通」成為其最重要的工作。然而,不基於事實和邏輯的溝通,會變得混亂不堪。某些糟糕的中階主管,在遇到爭議性問題時,會用打模糊的方式,試圖讓大家在泥巴仗中度過。而最高階的泥巴仗,會用看似合理的邏輯,但展示對技術完完全全無法掌握的事實。

例如:這個影片,非常經典,看似誇張,但在資訊科技產業其實常常發生。在該影片中,真正做事情只有一個人,而中階主管遇到技術難度的問題會省略甚至推諉,不能體會真正的重點而死咬不重要的細節,而技術人員要探索細節又會說這是專家的工作範圍。當然該影片是太誇張了一點,但其實在中大型組織時常發生類似的事情。

另一個例子:在老大靠邊閃中的有名片段,first thing or second thing。主角完全是用打泥巴仗的方式,在黑幫大老會議裡,刻意激怒某老大。而其他大老反倒會覺得生氣的老大很沒風度,一開始沒發現主角在打泥巴仗。

在此徵求案例:徵求在資訊科技中,重要會議裡打泥巴仗的案例。 


混亂泥巴仗是很可怕,要對應泥巴仗有先決條件,就是這不能是在「只有兩個人」的情況下。換言之,會議或者文件,至少要有三個人在場才有機會擺脫泥巴仗。

只有兩個人的情況下,只要有一人刻意打泥巴仗互相把對方弄的髒兮兮的,而且這個人還是中高階經理,另一個人根本不可能解決。唯一的方式是,儘速逃離現場,在下次確保有第三人以上在場。

在有起碼三人的情況下,以下方式可以解決泥巴仗問題。


1. 不隨之起舞


泥巴仗成立的條件是互抹泥巴。例如,在軟體專案中,當大家在解決A模組為何落後時,如果有人反覆提及一些沒有直接關連的事情:也許是另一個專案也落後了,也許是某RD的溝通態度不好。這些都是泥巴仗的徵兆。


2. 以白板展現事實


人的思考和言語是線性,因此在看穿複雜問題時,光是在腦中想是很容易被泥巴仗牽著走。

最好的方式是,一旦發現「同時」討論兩件以上的事情,就應該在白板畫圖或者條列。

畫圖是最好的選擇,最簡單的可以考慮心智圖或者魚骨圖。一旦有人試圖混淆事情,只要指一指說明我們現在在討論這個點,等討論完有決定之後,再往下一個點前進。而如果兩件事情有關連,就用線條與另一個點來說明此關連。

這也是為什麼,幾乎所有優秀的資訊從業人員(無論是低階還是高階)在會議中都喜歡坐在白板附近。


3. 耐心


簡單的說,就是有耐心的條理事情。透過工具(白板或紙)讓事情呈現。當知道對方採用泥巴仗手法-無論他是不是故意,就表示事情不會很快結束,因此要秉持著耐心條理問題。更重要的是,把這件事情當做類似刷牙洗臉的小事,在處理過程中沒有心情起伏 - 當然就不憤怒生氣)。






註1:特別是為求避免衝突,每人的說的話和實際心裡想的都有差距(參考left hand column),這讓組織 - 特別是資訊科技組織 - 運作上增加不必要的難度。

註2:  並不是去除重複字眼,極端簡潔就是好事。在文學作品中,言詞的優美有時候會透過層層疊疊的語句產生,請參考這裡。不過單就企業組織的溝通 - 例如開會 - 應該和寫小說是不一樣的。

註3: 參考這裡

註4: 以資訊科技來說,最基本的本職學能是寫程式,其他可以參考這裡這裡


2/16/2017

建立軟體開發團隊 (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) 外在環境 - 辦公室設備 是否有遠端甚至跨國合作團隊等等






2/06/2017

Scrum - 團隊中永遠的反對黨



最近被問到的幾個問題:

   - 怎麼聚焦討論,譬如說有人很愛插話,或者有人很愛在會議室角落另開討論群,或者有人非常堅持己見,很愛先否決對方 ...

   - 有遇過非常固執的人,總是以否定句開頭去否定對方嗎 ?


   - 有人固執的反對什麼事情都反對


....


以Scrum/agile方法為核心的團隊有先天上的「平等」和「自發」的假設。Scrum假設人人都有某種能力,並且也假設,團隊成員對於「溝通」都有某種程度的共識和經驗。

然而,實際情況通常不太美好。

** 技術人員常常會因為麻煩,而反對業務上的決定
** 業務人員因為對技術不了解而作出自相矛盾的決定
** 開會時候常常岔開話題
** 因為不專心,很多人在開會時候搞不清楚情況
** 某些人常常提很多意見,而且實在太多意見!

任何由人組成的團隊,多少都有溝通問題。如果你是團隊領導者,或者Scrum Master,溝通問題一定是你必須要負責的問題!

Scrum溝通問題,就像處理bug一樣,最好的解決方式是「事先解決」。有三個基本共識必須要事先建立。

建立這三個基本共識,可以讓未來的溝通變得簡單清晰,減少不必要的誤會。

(1) 建立雞與豬的基本共識


專案管理中的「負責角色」有各種說法。RACI可能是近年最常見的。

** 負責人(R = Responsible),負責執行 
** 誰批准(A = Accountable),對任務負全責的角色,通常是負責人的老闆 
** 顧問(C = Consulted),提供意見或建議的人 
** 通知誰(I = Informed),被通知結果的人,例如其他部門的相關人等 

在Scrum專案中,可以被簡化成兩種人:雞和豬。(雞與豬的故事可以在網路上找到很多版本,例如這裡)


豬:負責做的人也是負全責的人

雞:所有其他人(當然必須是和這個專案有關的人)

在溝通時,所有雞都可以出意見,但是豬一定擁有真正決定權。畢竟是豬被切肉出來做火腿,雞只要下蛋而已。

就平等的軟體開發Scrum而言,任務是有自己選取。但是就實務上,專案管理者不但身兼Scrum Master可能還會身兼分配任務的角色。這時候,等於是分配「誰是豬」!

任何會議上,對「豬」的正面或負面意見都可以討論,但是最終決定必須要是「豬」。

例如,PM決定哪個功能要先做,而工程師都反對,原因是嫌未來會有其他麻煩的事情產生。然而,就決定功能的先後次序來說,「PM就是那隻豬」而其他所有人「都是雞」。

團隊必須要有清楚的認知,才不會有無謂的抱怨和繁瑣的溝通。而清楚的認知,是團隊領導者的任務。


 (2) 建立事實優先的基本共識


Scrum溝通,必須,而且只能,建立在事實上。

這也是為什麼每日例行會議只說明三件事情:哪些工作完成,接下來做哪些,遇到什麼問題。

假設有人在某討論會議中說「現在UI速度很慢,登入要等很久」。某種程度來說,可能是事實。但是,「慢」以及「等很久」,都只是形容詞,必須要請他提出何謂慢,什麼叫做等很久才能繼續有意義的討論。

或者,有人提出「如果先做A會讓之後變得很麻煩,應該要先做B」。這其實也是模糊的說法,A和B這兩個功能,如果先做A是會讓以後時程延後8小時?還是8天?還是8個月?這才是根據事實的討論。

然而,這種建立於事實的共識,Scrum Master必須要不厭其煩的提醒和導正,才能建立這種共識。



(3) 建立產出優先的基本共識


大部分的專案,都是需要產出某些東西。無論這個東西是軟體,或者硬體,或者某些解決方案。

在團隊討論中,要讓「為反對而反對」的人閉嘴的最佳方式,就是以「產出優先」而不是以「嘴巴講」優先。

例如,某工程師強烈反對A做法,希望改用B做法。最好的方式就是請這個工程師,作出他自己希望的A做法,用以和B做法比較。如果他說「沒空」或者是有「更重要的事情在做」,那表示他的強烈反對,也不是那麼強烈。

至於對於「只反對而不提出取代方案」的人,其意見大概也只是僅供參考。如果經過負責的豬判斷,其意見很好,當然可以欣然接受,加以改進(例如在code review的時候)。





如果尚未建立這三個共識。就已經發生溝通問題。團隊領導者或者Scrum Master仍然有彌補的方式。

不過,越早了解,並試圖解決溝通問題,通常成本越低。

那麼可能的解決方法有:


(1) 自己的問題?


如果你是一個領導5人以上的團隊領袖,無論你的名稱是Scrum Master還是專案經理,如果你認為團隊裡「大部分的人」都有溝通上的問題。

那麼真正有問題的人是你!!

但是也不要太緊張。這並不代表你是個無能的領導者。只是你的實際行為,讓團隊容易產生溝通問題。

問題的產生點可能是:

(a) 試圖面面俱到,顧及每個人的感受,而非先考慮事實。每個人都喜歡受人愛戴,但是在軟體開發團隊中,鄉愿和受人愛戴只有一線之隔。唯有根據事實,腳踏實地領導事情的進展,才是長久之道。為了顧全少數人的面子,或者僅為了顧及某一兩個老是抱怨東抱怨西的人的心情,對團隊從來都不會有好處,反而只會讓多數沉默工作者更難獲得信任


(b) 未掌握Scrum精神,只是掌握Scrum的作法。請參考這裡

(c) 其他,請參考:作為技術領導者的方式



(2) 解決老鼠屎


如果團隊之中,溝通問題老是產生於某個人。

除非此人是像高斯,愛因斯坦之類的天才中的天才,否則不應該容許有嚴重溝通問題的人存在於團隊。

這類型人有幾種表徵:

(a) 無論什麼事情都悲觀 
(b) 事情不分大小時常抱怨 
(c) 問題都是別人的錯  
(d) 常認為自己懷才不遇
(e) 不願意做某些無聊的雜物

其實,每個人或多或少都會抱怨,也會有悲觀的時候。此乃人之常情。但是如果非常嚴重,那麼這個人就會變成鍋子裡的老鼠屎。只要鍋裡面有一顆屎,即使被稀釋了幾萬倍,也不會有人想吃那鍋飯。團隊也是如此,一個負面老鼠屎,其影響範圍遠超過5個好隊友。

老鼠屎不見得就是錯的,他或許自己創業會變成一個好創業家。因此,及早讓不適合目前至個團隊生活的人離開對大家都有好處。

(3) 縮小範圍


當溝通問題發生,可以將重要的溝通,盡可能縮小範圍,讓溝通清楚簡單。

這聽起來是淺白無聊。但是,實際上在團隊之中,太多無聊的溝通錯誤發生,以致於這麼簡單的事情,仍然值得注意。

以Scrum而言:「DOD」什麼是完成,乃是基本的問題。即便團隊已經彼此合作過一段時間,仍然三不五時要確定一下什麼叫完成。

以溝通進度而言,必然將最近在做的事情,縮小其範圍到「最近的一個完成點」。 無法縮小表示根本不知道自己在做什麼。舉例來說,軟體開發中,如果有一個人的某A任務,需要20個工作天,那麼在3天的進度報告,絕對不能聽到「還有17天就完成」,而是要縮小範圍到:「下一個milestone會是明天,而預期也會如期完成」。因為,最近的一個檢查點(milestone) 如果不能如期完成,就代表未來的17天,很有可能也不會如期完成。反過來說,最近的一個milestone會完成,那麼未來就比較有可能如期完成。

縮小範圍也可以讓「雞和豬」的責任範圍展示的更清楚。

有個真實的案例:有個團隊舉辦慶功宴,由甲和乙兩位負責。甲很熱心的定好了餐廳,並且就「自認為剩下的事情乙會處理」,然而乙心理認為,既然甲定了餐廳,表示後續的小事情甲也會處理,畢竟許多事情和餐廳有關係。那麼到了慶功宴當天,當然除了餐廳定好之外,其他的雜物(例如當天如何報帳之類)一件都沒完成。

另一個真實的案例:有個軟體開發專案,大家都認為某甲的程式需要重構(refactorying)。但是,某甲認為他需要4周才能完成,因此遲遲不肯進行,大家也難以和某甲溝通。專案經理於是縮小範圍,先找某甲也認為很小規模的一個功能-原本預計一天-加以重構,透過pair-programming,確定某甲專注於這個任務上,最後只花了1小時。因為有這樣的證明,專案經理於是要求某甲先完成全部程式碼翻修,最後整體只花了2天就完成,雖然仍是麻煩事,但遠比某甲估計的4周來的快太多。其原因也很簡單,重構是繁瑣麻煩的事情,當然會被估計成很長的時間。





12/28/2016

數據分析從零開始 - (4) 檔案儲存



數據分析的各階段,都有可能需要儲存檔案。而資料的來源,也有可能是已經存在某處的檔案。

(非檔案儲存?參考註1)

越重要的資料,就得更重視儲存的方式。而越是大量複雜的資料,就勢必要對資料存儲做好預先的規劃。

雲端儲存 - 巨量資料


近年來流行的Cloud Storage,通常是將資料以網路上傳(註2)至某個雲端服務公司。最典型的例子是Amazon提供的S3服務。AWS S3因為使用者眾,以至於其的S3 rest http介面,甚至演變成某種標準。許多類似的服務,或者儲存廠商,會以「相符S3 rest api標準」當作重要的功能或賣點!(註3)

顯而易見,雲端儲存具有管理上的優點。理論上,不用擔心備份,擴充,網路,電力,硬體更換...等等營運上的問題。

然而,巨量資料雲端儲存也有幾個顯而易見的缺點

1. 錢:雲端儲存的費用並不便宜。單以S3為例,2016年的每1T資料光是「存著」的費用,一年就高達276美金,相當於8832台幣。這還未計算上傳下載等操作費用。倘若要進行「長期保存」其費用相當驚人。也因此雲端儲存商針對長期保存的檔案也提供比較便宜的方案。然而,仍然是某種成本。然而,自行巨量儲存也要考慮費用,特別是

2. 營運:單純僅只使用雲端儲存,對整體營運的好處有限。並且,企業還是需要自行考慮檔案的有效使用問題。

3. 移轉:儲存到雲端之後,一旦量變大,很難轉換營運商。



雲端儲存 - 少量資料

至於極少量資料,例如10G之內。無論是企業或者是個人,都可以取得幾乎免費的儲存空間。

但也因為是免費空間,不太可能保證資料不會遺失。可是非常適用於新創公司,或者SOHO族。

最好是利用兩個以上的雲端儲存服務,儲存重要的檔案。

例如:利用googledrive + yandex.disk 儲存重要的檔案。這樣幾乎可以確保檔案不會因為單一基礎建設有問題,而導致重要檔案遺失。(註4)

實際作法:

(1) 尋找適當的工具或API,用以一次性整合這兩個雲端儲存

(2) 設定自動化方式,或者撰寫自動化程式

(3) 定時執行自動化備份,同時備份兩份到不同的雲端服務

Yandex disk的範例程式(參考這裡)



自行儲存 - 巨量資料


企業組織非常有可能需要自行處理檔案儲存。無論是因為技術因素或者法律因素。

傳統上儲存會用硬體商的解決方案,近年來多了分散式檔案系統可以考慮。

自行儲存,一樣要考慮錢(費用),營運。

1. 錢(費用)

    - 硬體費用:必須考慮長期硬體維護的費用
    - 軟體費用:授權或者購買維護
    - 人的費用:必須使用假設的最大值!

2. 營運

    - 如何讓其他系統使用
    - 有問題的時候怎麼辦
    - 備份與災難復原 


傳統巨量檔案資料,是購買netapp之類的硬體解決方案,配合網路架構,讓企業的巨量資料有集中管理的地方。2000年之後,分散式檔案系統因為效率和成本的關係,慢慢變成另一個可行的選項。

早期使用分散式檔案系統管理者,要跨越比較高的技術門檻,這幾年分散式檔案系統日漸成熟,管理也越趨方便。常見的有:(這頁wiki上有詳盡的清單。)

(1) glusterfs
(2) ceph
(3) HDFS
(4) mooseFs
(5) mogilefs
(6) GridFS
(7) Lustrefs


這些分散式檔案系統各具特色,大部分都可以無償取得使用權。然而,有些需要額外的知識或技能才有辦法長期維護。

因此,如果可預期的資料量,以及資料存取技術與成本,小於硬碟技術的成長。使用分散式檔案系統不見得有利。

硬碟的技術符合約略的摩爾定律。在1996年,每1G的硬碟約127美金,2006年,每1G的硬碟價格為0.3美金,但是在2016年,每1G的硬碟價格已經小於0.03美金。(參考這裡

除了價格逐年降低之外,存取速度也是逐年增長。如果預期資料成長量並不高,其實單就更換更換同價格的硬體設備搞不好也就夠了。

然而,巨量資料的增長往往遠超過預期,尤其近年來大資料分析蔚為風潮的情況下,盡可能保留資料便於未來使用成為企業組織對資訊科技的期待。也因此,使用分散式檔案儲存的組織越來越多。

選用分散式檔案系統,必須考慮:

(1) 使用目的和環境條件
(2) 營運計畫
(3) 實際測試


考慮雖然需要詳盡,但是這些「考慮」都是為了配合實際運作。因此,按照上述的考量,擬定可以「每日」有進展的「逐步」前進的計畫,是讓分散式系統成功運作的最好作法。

舉個例子:

(1) 使用目的和環境條件:要能夠簡單擴增(scale-out),並且能利用現有已經存在的NAS/SAN,而且非常容易營運與維護。檔案不需要striping,存取效能一般即可。

(2) 營運計劃摘要:一開始預計使用12台機器,共48顆硬碟。未來一年可能擴增到20台機器,80顆以上硬碟。總資料量可能成長為120TB。僅有一位開發維運人員(devops)。

(3)實際測試:實際分別以4台VM測試過glusterfs, mogilefs, ceph, Lustrefs。其中以mogilefs最為簡單使用。





自行儲存 - 少量資料


少量檔案的儲存,仍然附著在其他系統上。例如email上的附件,版本控制系統,wiki上的附件等等。

大部分的組織,很少著重於少量資料的整體計畫。大多數僅只為「安全性」的規範。例如客戶資料不得外洩之類。實務上,完全依賴個人行為。

現在,大部分的作業系統,都已經可以對其下的檔案做全文檢索(例如mac finder),而也都支援某種程度的備份功能。




摘要



巨量資料少量資料
雲端儲存 錢, 營運, 移轉考慮 
(1) 自動化
自行儲存(1) 傳統NAS 
(2)分散式檔案系統
考慮 
(1) 傳統備份 
(2) 全文檢索 





註1:非檔案儲存有傳統的RDB(例如Mysql, Oracle), Document DB(例如Lotus Notes), 有比較新潮的nosql (HDFS, mongodb, couchbase)。 這目前不在本文的討論範圍

註2:通常是指http。不過由於ftp在2000年之前應用範圍真的太廣,所以還是有不少雲端公司會額外提供ftp介面。

註3:參考這裡 -> http://www.s3-client.com/s3-compatible-storage-solutions.html

註4:為何選擇這兩者?google當然是不用說,因為它的基礎建設相當完整。而yandex則號稱為俄羅斯的google,很明顯由於是俄羅斯最大search engine,大概不會和google採用重複的基礎建設,因此選用兩個截然不同的廠商,可以降低風險。