只有累積,沒有奇蹟

2021年6月13日 星期日

[NETCore] ASP.NET Core 中的例外處理方式

前言
錯誤處理一直是開發中的重要環節之一,如果在程式發生異常錯誤的當下有效的將錯誤訊息完整的記錄下來,可以大大的節省 debug 的時間與效率,反過來如果在開發時沒有考慮到異常處理的機制,可能在發生問題時要找到錯誤的原因難度就會提高,因此在開發時必須要考慮到異常處理的機制,過去公司都會將 exception 訊息透過推(push)或是拉(pull)的方式傳送到 Logstash 再搭配 Elasticsearch 與 Kibana 搜尋到相對應的錯誤訊息或是 Log。這篇就簡單分享在 ASP.NET Core 中如何使用 ExceptionFilter 以及 Middleware 捕捉異常紀錄的方式,內容若有問題歡迎提出來一起討論。

開個 Error 給他
首先在 Visual Studio 2019 建立 ASP.NET Core API 專案
為了模擬例外狀況的發生,在預設提供的 WeatherForecastController.cs 中直接加上 throw 一個訊息為 "我是醬爆,我要爆了 !" 的 exception,代碼如下
[HttpGet]
public IEnumerable Get()
{
    throw new Exception("我是醬爆,我要爆了!!!");

    var rng = new Random();
    return Enumerable.Range(1, 5).Select(index => new WeatherForecast
    {
        Date = DateTime.Now.AddDays(index),
        TemperatureC = rng.Next(-20, 55),
        Summary = Summaries[rng.Next(Summaries.Length)]
    })
    .ToArray();
}
接著在執行應用程式,可以看到應用程式開啟後即噴出異常訊息

使用 Exception Filter
首先為了更模擬一般開發情境,建立 API 共用回傳的 Model 與自訂客製的例外 CustomerException 等兩個 model,代碼如下
public class ApiResponse
{
    public DateTimeOffset Timestamp { get; set; }
    public string Message { get; set; }
    public string Result { get; set; }
}

public class CustomerException: Exception
{
    private readonly Exception _exception;
}
在 ASP.NET Core 中如果要自訂錯誤機制 exception Filter 必須透過實作 IExceptionFilter 或是 IAsyncExceptionFilter 介面,差異只是 IAsyncExceptionFilter 實現非同步等待(看需求),接著建立例外發生時要用到的類別名為 BombExceptionFilter ,類別中實作 IExceptionFilter 中的 OnException 方法裡面定義當例外發生時要做的處理機制
public class BombExceptionFilter : IExceptionFilter
{
    private ILogger _log;

    public BombExceptionFilter(ILogger log)
    {
        _log = log;
    }

    public void OnException(ExceptionContext context)
    {
        var status = HttpStatusCode.InternalServerError;
        var message = string.Empty;

        var exceptionType = context.Exception.GetType();
        if (exceptionType == typeof(CustomerException))
        {
            message = context.Exception.Message;
        }
        else
        {
            message = "something wrong";
        }

        // log 
        _log.LogError(context.Exception, $"Ex massage: {message}, StackTrace: {context.Exception.StackTrace}", context.Exception);

        // 設定 exception 已處理完畢
        context.ExceptionHandled = true;
        var response = context.HttpContext.Response;
        response.StatusCode = (int)status;
        response.ContentType = "application/json";
        
        context.Result = new ObjectResult(new ApiResponse { Timestamp = DateTimeOffset.UtcNow, Message = message, Result = "我出包了,請給我一點時間" });
    }
}
OnException 中邏輯為當發生例外時,會根據發生例外的種類 exception Type 來取得回傳的錯誤訊息並定義再回傳的 message 屬性中;另外也在第38行將錯誤紀錄在 log 中,可搭配習慣的 log 解決方案,像是 log4net、serilog 看團隊習慣決定;使用 apiResponse 類別作為回傳的格式,其中定義了 timestamp、Message 及 result 等屬性,當發生錯誤時在 result 會定義 "我出包了,請再給我一點時間" 訊息告知呼叫 client 端。

接著在 startUp.cs 的 ConfigureServices 區塊加上 BombExceptionFilter 下列代碼
public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();

    services.AddScoped<BombExceptionFilter>();
}
最後一步在 controller 中的 action 加上 BombExceptionFilter attribute
[ServiceFilter(typeof(BombExceptionFilter))]
[HttpGet]
public IEnumerable Get()
{
    throw new Exception("我是醬爆,我要爆了!!!");

    var rng = new Random();
    return Enumerable.Range(1, 5).Select(index => new WeatherForecast
    {
        Date = DateTime.Now.AddDays(index),
        TemperatureC = rng.Next(-20, 55),
        Summary = Summaries[rng.Next(Summaries.Length)]
    })
    .ToArray();
}
接著我們 run 應用程式看當發生錯誤時自定義的 BombExceptionFilter exception Filter 是否有生效,可以看到結果如下設定成功
有關在 ASP.NET Core 中更詳細的 exception filters 可以參考 MSDN 文件

使用 Middleware
Middleware 與 exception 相比就簡單許多,在 如何在 ASP.NET Core Middleware 加上單元測試 Unititest 文章中有詳細介紹關於 middleware 基本使用方式,這裡就不在多加說明,新增 CustomerExceptionMiddleware 的中介層來處理 exception 的邏輯,代碼如下
public class CustomerExceptionMiddleware 
{
    private readonly RequestDelegate _next;
    private readonly ILogger _logger;

    public CustomerExceptionMiddleware(RequestDelegate next, ILogger logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task Invoke(HttpContext context)
    {
        try
        {
            await _next(context);
        }
        catch (Exception ex)
        {
            await HandleException(context, ex);
        }
    }

    private Task HandleException(HttpContext context, Exception ex)
    {
        context.Response.StatusCode = (int)HttpStatusCode.InternalServerError;
        context.Response.ContentType = "application/json";
        var message = ex.GetType() == typeof(CustomerException) ? ex.Message : "something wrong";

        // log 
        _logger.LogError(ex, $"Ex massage: {message}, StackTrace: {ex.StackTrace}", ex);

        var result = JsonConvert.SerializeObject(new ApiResponse
            {Timestamp = DateTimeOffset.UtcNow, Message = message, Result = "我出包了(Middleware)"});
        return context.Response.WriteAsync(result);
    }
}
在代碼中加上 try/catch 將發生錯誤的 exception 捕捉起來,並設定回傳 statusCode 為 IIS Server Error 以及與上述 exception filter 相同將錯誤記錄在 log 中,另外將錯誤的 result 設定為 "我出包了(Middleware)" 區別是 middleware catch 到的錯誤,接著新增擴充方法 UseCustomerExceptionMiddleware 方便在 startup 使用
public static class ApplicationBuilderExtension
{
    public static IApplicationBuilder UseCustomerExceptionMiddleware(this IApplicationBuilder builder)
    {
        return builder.UseMiddleware();
    }
}
修改 startup.cs 將稍早的 BombExceptionFilter 註解,Configure 代碼加上 UseCustomerExceptionMiddleware 方法
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    ...
    app.UseCustomerExceptionMiddleware();
    ...
}
重新執行應用程式,可以發現當 application 發生 error 的時候有 catch 到錯誤訊息
宣告使用 middleware 成功 !

感想
以上針對 exception 在 ASP.NET Core 的處理方式,分別是使用 exception filters 與 middleware 兩種方法,另外還可以使用內建的 UseExceptionHandler 方法達到類似的效果,詳細可以參考 Cash 大大 ASP.NET Core 使用內建的 ExceptionHandler Middleware 實作全站 Exception 處理的文章說明,這裡就不再班門弄斧的多加說明;還有在開發中有需要注意順序性的問題,可以透過 MSDN 的圖片了解到 middleware 與 filter 的執行順序,避免認知錯誤造成自己在開發上時間的浪費,希望這篇文章可以幫助到需要的朋友 :)

參考
ASP.NET Core Web API exception handling
ASP.NET Core 中的篩選條件
Asp.NetCore依赖注入和管道方式的异常处理及日志记录
ASP.NET Core 使用內建的 ExceptionHandler Middleware 實作全站 Exception 處理
[鐵人賽 Day17] ASP.NET Core 2 系列 - 例外處理 (Exception Handler)
Using ExceptionFilter for exception handling in AspNet Core Web API

2021年6月1日 星期二

[筆記] 技術管理者論壇#1 技術與商業間的平衡

前言
這篇是參加 #技術管理者交流論壇 - 技術與商業間的平衡 的活動筆記,技術管理者論壇說明如下
這是一個專屬於「技術管理者」的交流社團,所謂的技術管理顧名思義指的是在職務角色上需要肩負起技術選擇與應用,並隨公司狀態持續改善技術框架的成員。例如研發與IT部門的管理者,或者是架構師。
當天是論壇所舉辦的第一次線下活動 : 活動頁說明,自己參加後也整理當天活動的筆記方便日後回顧(lag 很久),如果內容有錯誤或是有理解錯誤的地方請跟我說會立即修正,謝謝

起心動念
去年底 Gipi 在與幾位好朋友聊天時聊到,台灣在培養技術人才/技術主管/架構師的培養上,好像有一些缺口在;這缺口到底是如何的形成呢?為什麼台灣的人與老闆對於技術這件事的重視程度一直沒有辦法往上拉深,人員在公司裡的角色為甚麼沒有辦法變得越來越重要,為什麼我們還是沒有辦法讓我們自己站在舞台上變成商業上重要的主角,到底原因是什麼?技術那麼重要,很多公司都會提到技術/人才是公司資本,但坦白說多少老闆是真的理解這件事情,好像蠻難的,但真的是老闆的問題嗎? 好像也不盡然是,但到底問題出在哪裡呢 ?
於是 Gipi 找了四位召集人(Tomas、Ant、91及 Paul) 提到想辦一個技術論壇,在討論過程中 Tomas 提到在過去可能在推技術、敏捷、如何做好產品像是傳教師的角色,要不要來幹點更好玩的事情,想要可以真正創造社會價值的事情,能不能實際帶企業做轉變或是帶人做成長的 Mentor program 出現,直接帶人 1on1 的養成計畫。
實際上技術主管的養成是相對難的事情,尤其你要在面對多變的商業環境上不單純是管理人的問題,很多在做技術決策,商業決策你的洞見才是關鍵的地方,在技術論壇中會分為多個part,除了有講者分享過去的經驗之外,還會有更多分組的討論與交流,不單純的只是聽講而已,更希望的是藉由討論的過程中可以從別人的身上吸取經驗,這也是社群中最重要的力量。

補充 : 技術管理者論壇籌辦初心說明

召集人
第一屆技術管理論壇的五位召集人,希望透過技術管理這個議題,讓台灣技術管理者或是技術從業人員越來越清楚的知道,你在商業的世界上面重要角色到底是甚麼?怎麼發揮自己的價值 ? 怎麼越學越好 ? 怎麼影響越來越大。同時技術社群的傳承也是相對重要的,在公司裏面同樣也是 為什麼都是資深的員工站著重要的位置,年輕人都沒有機會呢?很大的一部分可能是因為缺乏傳承。希望明年交棒出去做到傳承讓別人來做做看,五位召集人轉而擔任幕後協助的角色。

接著請五位招集人與大家聊聊建立技術管理者論壇的起心動念

Tomas
  • 傳承 : 大家在每一個自己的組織走到現在都是個「傳奇」,都是你組織的那個傳奇,怎麼把傳奇傳承下去都是個重要的課題。
  • Legacy Code = 祖產 : Legacy Code (遺留代碼、技術債) 從兩三年前我開始推廣這字叫「祖產」,如果用「技術債」這個字比較像是一個包袱,是一個很沉重的事情。但反過來想 如果沒有 Legacy Code 怎麼會有現在的公司營收,如果用祖產的觀念來看技術債則會有不同的思維,思考怎麼樣幫祖產來做變現或是拉皮(refactoring)的動作,如果不會可以找祖產拉皮師 91,怎麼用重構而不是用 rewrite 來解決組織的痛點是大家要一起學習的。
  • 共好 : 在不同公司大小規模不同產業的的企業,可能都會遇到些題目(問題)是差不多的,能不能有種整合匯聚或是共同學習的方式,想透過一些方法想將在台灣看到的一些組織的困境讓它浮現,提供可以解決問的patten,找到每一個企業根據 context 的最佳解或最適解。
Paul
  • 做了一個採訪系列的節目,採訪一位從香港來台灣的老闆,在討論過程中提到一個問題,
  • Q : 你覺得做管理跟以前在寫程式 你覺得差異最不一樣的是什麼 ?
  • A : 寫程式至少東西是有解的,會的方法論算一算之後可以寫出一個 pattern;但是在管理方面自己也還在學習,因為管理的人的時候用同一套方法可能最後全部的答案(結果)會不一樣。其實你會發現很多工程師踏入到管理領域之後會很困難,因為在管理每一個人時需要花不同的管理方法、需要用不同的方法來溝通,才會得到想要的答案。自己在這部分也在學習中。
  • 如果能夠跟各種不同的人溝通都能順暢時,很快的組織溝通就慢慢的順暢,跟 Tomas 聊天的過程學到對話的細節是重要的,舉例來說在問「為什麼你這樣做」跟「你要不要跟我說說你為什麼這樣做」,感受不同你得到的答案也會不一樣,這是很細的管理議題(IF-ELSE),希望大家在過程中玩得開心。
91
  • Gipi 昨天在 fb 有發一則很有趣的故事,故事來是「[五項修練的故事3:洞穴人的陰影]」,這故事提到原始人的部落分為兩派,一派是主張狩獵的長茅派,一派是主張採集的竹簍派,這兩派人主要是在不同的高塔裡面用不同的視角看到的東西產生不同的心智模式;長茅派在高塔上看到的是部落東邊的環境,有很多的水牛 野豬等,因此主張狩獵為主;竹簍派看到的是部落西邊的環境,有很多的葡萄 玉米,主張採集為主。兩派所看到的東西不同導致心智模式也不相同,導致部落裡面產生很多矛盾與爭執最近漸行漸遠。
  • 這情況跟我們觀察到業界的情況很類似,技術人員會覺得管理人員只會出張嘴 壓時籌 不會做產品;管理人員可能技術人員不懂商業價值,只會關注在自己的技術浪漫中;兩邊觀點不同導致很多企業間的資源浪費與沿生出來的痛,我們想要改善這情況
  • 工作初期擔任 Team Leader 到這幾年在企業擔任顧問與教練,所扮演的角色就是在兩座高塔中之間做溝通,持續的了解管理人員與技術人員「想要」跟「需要」的是什麼,公司的目標是什麼,在透過翻譯與引導的方式讓對方一起活下來,
  • 希望透過技術管理者論壇,可以幫助大家或是公司看到全局,像是划龍舟一樣不是拼命划就夠了,還需要朝相同的方向,一起用力才有機會用最快的速度朝向共的目標前進
  • 五項修練的故事3:洞穴人的陰影
  • 91 補充 : 指引其實一直都存在,只是我們未曾去發掘、體會與練習 from FB

Ant
  • 生涯規劃
  • - 10 大科技公司裡面,有幾位 CEO 有工程背景 > 8位
  • - 20 大受青睞的公司裡面,有幾位 CEO 有工程背景 > 12位
  • - 自己或是朋友在面試時會詢問面試者,對於自己職涯或是生涯規劃會是什麼? 8成會說是架構師,1成 CTO
  • DX : 在過去國內或是國外近幾年談的都是 User experience (UX),但比較少提到 Develop experience (DX),從內部(技術人員)的角度出發發現中間可能會有可以結合的點
  • 傳承 : 最近都有與 Conf 的召集人在談,這幾年在常見的 Conf 上台的人絕大部分的都是認識的,Ant 鼓勵有興趣的年輕人上台分享,如果想不到題目可以一起討論,思考分享怎樣的題目讓大家更有幫助,希望在技術分享上也可以做到傳承的精神。

技術管理
技術管理論壇主要談的不是技術,在目前技術社群相當的多 相信可以談得比技術管理者論壇講的更廣更深,這裡想談的是技術管理;大多數工程師到了一定位階之後(可能)會被逼著去管理,在過去管理可能大多數想到的是人的管理,要如何引導你的團隊,如何管理專案在時程內交付,對管理來說不只是單單管理人就好,技術本身需要管理的,很少學到怎麼樣技術管理的議題比如說
  • 如何做好在技術上面的商業決策
  • 如何做技術的選型
  • 如何評估選型之後怎麼做好與技術之後的發展軌跡
  • 如何面對技術債與新功能與之間的取捨
這大部分都是老闆要求才做的,但是我們很少被培養具備這樣的能力;引此技術管理不是純談技術也不是純談管理的部分,而談的是技術的管理。技術到底怎麼演進 怎麼規劃 怎麼讓技術衝擊商業 怎樣讓技術輔助商業 怎麼讓技術解決更難的商業問題,這才是技術管理最核心的要件。


識別可能性
PM 需要懂技術嗎 ? 大家覺得需要的原因是甚麼呢
對不懂技術的 PM 來說,在談時程合不合理時,可能無從判斷起;在談解決方法好不好不知道時,只能信任工程師的建議與判斷;懂技術這件事情對於管理有什麼幫助

提高可能性
包含下列這些事
  • 獨特性 : 產品或是技術有沒有獨特性。技術本身是有機會讓產品有競爭力的,但在過去可能很少被談論。可以有專利但在一班公司很少談這件事情,可能認為技術就是一個實踐手段但不具備獨特性的地方,但如果可以識別技術的邊界,利用其技術特性創造產品的可能性或是商業的可能性,本身是會有獨特性的。
  • 延展性 : 在做技術選型時是否有思考到他能夠延展的邊界是什麼,可能不會討論套件是不是夠完整 討論社群是不是夠成熟 可能在過去很少在思考 如果今天是在做一個商業軟體的話 可能要思考這些事情,是不是有那麼豐富的支持,因此可能在技術選型或是技術決策時候可能要考慮到技術的延展性,也是一個相當重要的關鍵點
提高可管理性
在溝通時可以提高溝通的品質,了解技術解決方案的優缺點是什麼以及是否合適;在風險的控管與品質上掌握度較高。
過去在管理開發團隊上都 focus 在 #提高可管理性 出發,PM 與技術主管可能大部分工作都在做這件事情,但忽略 #提高可能性 這更重要的事情,技術管理不單單在講把帶的 RD 團隊帶好就好,希望更廣泛一點從技術管理的角度來談論是值得被探討的。


過去 v.s 未來
在過去公司的一些 Project 可能是老闆決定在做什麼,接著開始進行產品研發;但漸漸地現在很多技術可能會影響到商業的決策,舉例來說在 AI 出現之前可能都沒想過 AI 幫助大家做這麼多事情,技術可以直接影響到商業的決策,但是誰來判斷這件事情 不懂技術的人能夠判斷嗎? 可能沒辦法。懂技術的人能夠做出正確的商業決策嗎? 似乎也不行,這也是今天的議題 技術與商業之間的平衡 要跟大家好好討論的。

從傳教到傳承
在開始規劃技術管理論壇時目的不止是要做傳遞知識,更希望的是做到傳承的精神。遇到困難時腦袋是如何思考的? 舉例來說架構如何從0到1,在從1到100的過程 ? 如何去帶領百人團隊 ? 如何去透過技術驅動商業 ? 這些過程其他人是怎麼做決策的,可以透過分享與討論來解決真實世界的問題,好的經驗也值得被傳承下來,也是這個技術管理者論壇最核心的關鍵,傳承的精神是希望透過活動的方式帶領大家去討論,或是透過與有經驗的前輩做 1on1 的機會,從有經驗的人身上做學習得到答案後針對情境去做修正,帶回公司來解決;同時將技術管理的觀念也能被傳承下來,這是論壇的起心動念。

Ruddy 老師
  • 一般的技術人員在成長到一定的經驗後,通常缺乏管理的能力
  • 敏捷比較少講管理兩個字,通常講的是激發,激發團隊的方法讓他們可以表現可以超出團隊的潛能
  • Q : 你們忙不忙? 一個敏捷的團隊應該很忙嗎 ? 讓下屬不忙是管理者(你)的責任
  • 敏捷口訣:小增量、多迭代、尋求回饋
  • 如何提升速度 : 把一個大目標切成一個小目標,如果將目標切成四塊,可能做完其中重要的一塊可以達到80%的效果
  • 一分鐘衡量 : 衡量目標是否有達成,可以透過 OKR 來達到這件事情,目標>關鍵結果>是否達成
  • 一分鐘稱讚 : 目標有達成,不吝嗇地稱讚下屬,稱讚做對的地方,希望持續地保持下去
  • 一分鐘更正 : 目標未達成,嚴正地跟他說哪裡錯誤,要跟他說對他是有信心的,雖然這次表現比較差,你也知道發生錯誤的原因,相信下一次一定會做得很好
  • 一分鐘風險控管 : 看板走的是限制理論,思考現在最大的約束在哪裡,如果是最大的約束要如何解決它。
  • 一分鐘經理(新版)
  • 全公司最用功的是 CEO,第二用功的是 CIO (有趣),你的層次越高求知慾望應該會越高

技術管理者論壇 - 計畫說明
主要分為三大塊
  • 社群
  • 講座
  • Mentoring program
講座
每個月會舉辦一場講座,會邀請在相關議題上有經驗的夥伴來與大家分享

社群
有些技術管理的議題可以直接在 fb 社團中討論,針對提出的問題大家可以分享自己過去如何解決,如何做得更好,核心觀念是希望後人可以有更好的經驗做為參考
歡迎大家有問題都可以在社群提問,有很多大神可以幫忙回答喔喔 XDDD

Mentoring program
希望可以創造社會實質的影響與貢獻
半年的時間與五位召集人 1on1,遇到問題時給予建議與幫助

資格限制
預計申請時間 5月中旬~6月中旬
詳細細節以技術管理者社群公布辦法為主


商業與技術間的平衡 - Gipi
  • 從商業的角度來看,商業更強調的是價值;技術強調的是登峰造極,效能更好;但是追求更好品質最佳的過程,很有可能忽略商業的目標,但如果捨棄掉的話有可能技術上面就沒辦法更精進了。
  • 舉例來說 : 追求 99 ~ 100 的過程是技術能力精進的重要環節,但可能沒那麼符合經濟效應。
  • 技術某種程度上是為了創造價值,商業在談的是更高效率的創造價值,技術應該追求的是極致跟如何應用它,這兩者之間可能會有 trade-off,但絕對沒有100%的對或錯。今天就先來跟大家分享自己對於這議題的看法

經驗分享
  • 要跟大家分享一個過去比較不好的技術管理的經驗,這是前東家的狀況,但後來發現這狀況在台灣還蠻常見的
  • 一間公司有一百位RD時是否應該具備完整的流程呢 ? 答案是沒有,光版本控制工具就有五套。
  • 缺乏制度 : 遇到機器需要擴充的問題,發現Production 的機器不一樣,windows 版本不一樣,裡面的程式碼1/3也不相同,版控上的程式碼也不是最新的,造成不知道 scale out 的基準點(標準)是什麼。
  • 開發也需要維運,白天開發,晚上維運(?
  • 如果沒有辦法從技術架構、技術管理的流程上解決這問題,這問題還是會發生
技術不見得能100%決定能不能活到現在,但會決定接下來能不能活得好
人很重要,但不應該是 100% 的全部;人如果沒有 sense,就很容易一團亂

  • 每天線上問題都有很多 workround
  • 對於需求沒有管理,因此不斷變更需求,業務只要罵得兇就先做,不會去探討背後的價值是什麼
  • 為什麼業務的需求都比技術債來的重要,因為業務單位的需求講得出價值,技術債不好衡量,但技術債真的沒價值嗎?其實不是,債是累積下來的,影響性是跟深地步的,是有可能會越變越糟的。

  • 在過去所有人都可以向RD開發團隊及工程師提出需求
  • 需求沒有經過管理與收斂排定優先順序,因此工程師常常會被不同業務來的需求打斷,或是為了處理線上問題而影響到既有專案的開發進度
  • 為了改善之前的問題,由產品經理收集需求與 stakeholder 溝通,不在直接找工程師來提需求,讓工程師的資源投入在最有效益(最有商業價值、技術債)的地方
  • 由產品經理來收斂問題與排定優先順序,透過運營及數據資料來支撐背後的價值來說服需求單位
  • 產品單位有些需求是需要很長的時間完成,與產品單位討論後初期先透過人工的方式來驗證其可行性,而不是一定要透過技術問題才可以解決。
  • 舉例來說,挑選兩百位客戶,先讓客服人員與客戶溝通與人工目標設定,在透過每周的迭帶與需求反饋,了解客戶會遭遇到甚麼問題,讓這群人在面對問題上也可以很 Agile (更快解決問題)
更好的解決問題可能不是技術解,可能是流程解,可能是管理機制來解決,可能是一個漸進式的改進過程
在談技術與商業之間的平衡的元素前先來談三個詞,敏捷、OKR、選型

敏捷
  • 我們正面對一個 VUCA 的環境
  • 那為何世界會變得如此VUCA呢?
  • VUCA : Volatility、Uncertainty、Complexity、Ambiguity
關鍵一
從競爭面
  • 以前在製造業時代會發現需求改變的周期是長的,六個月~兩年都算是正常
  • 小時候商品在賣可能商品不改包裝還是賣的動,像是乖乖、旺旺仙貝;但現在像是3C產品或是科技產品半年不動,就不會想買了因為有更新好的東西出現。
是什麼改變了 需求變化的速度
消費者意識抬頭 : 以前是供應商驅動,現在是消費者驅動
  • 小時候住在鄉下,附近的電器行賣電視、洗衣機、冰箱,可以選擇的商品與品牌相對少,如果家附近只有兩間電器行只能二擇一做比較,選擇較少
  • 供應商給什麼,消費者只能被動接受
  • 在過去可能只能挑家附近的電器行做選擇,網際網路興起之後,可以上網到電商網頁有更多選擇
  • 市場的變化速度加快,變為3~6個月
  • 全球化之後更不一樣,上 Amazon 之後可以買全世界的商品
  • 漸漸地可能會進入C2B(Customer to Business)消費者主導
  • 變化頻率更快,要根據數據蒐集使用者的偏好來調整商品
從商業合作面
在過去可能誰是領頭,有話語權其他人就會來配合
  • 在過去可能沒辦法想像 Amazon 為何要做雲端 SAAS 服務 ? 為何要自己開發物流 ?
  • 越來越多大企業開始跨出原有產業鏈與領域
  • 當你能更應變的時候,就能主動掌握機會,被動的時候就會發現機會在別人手上
當新的巨頭想要進入不同產業,希望壟斷部分技術
  • 商業連結已經越來越複雜,不是沒有受影響就沒事
  • 不確定性 : 可能主要合作夥伴受到影響,就有連帶關係(連結越多,脆弱點會出現)
  • 關心合作夥伴會不會出狀況,公司會不會有新機會出現
  • 是否有機會建立新的連結,來因應(VUCA)新的變化

關鍵二
科技的變化
  • 隨著時間的推進,科技的進步速度更快。在過去可能 10 年提升一個 level(紅框一),後來演進速度越來越快變為2~3年(紅框二)
  • 科技進步的速度這麼快,大家認為誰可以來掌握 ? 誰在公司做決策因應科技變化 ?
  • 商業推進的速度與科技對比起來,商業是比較慢的;如果可以掌握商業運作的脈絡,掌握不變的部份再把科技的部分加進,會比強調一直在追新技術是相對重要的。
  • 當技術科技變化快的時候人沒跟上,就會用舊的思維來做出(新世界)的決策
  • 別人都上太空了,你還在殺豬公
  • 技術決策還掌握在不碰技術人的身上;產品決策掌握在不接觸新的產品應用的人身上
  • 那我們如何因應科技化變這麼快的環境 ? 敏捷
  • 適應性、快速迭帶、小步快跑

OKR
1999年從英特爾誕生,2019年在台灣才爆紅
  • 為什麼老闆的一個需求到後來(可能)會變成爛的決策 ?
  • 可能是因為 溝通
  • 可能是因為 環境變化
  • 老闆交辦後過了一個月,現在情境可能不一樣了,大環境(外部)在變化但可能內部沒做調整,導致問題發生。事情越頻繁的發生,發現是不是應該讓組織上下要目標對齊,review 後調整彼此的作法
  • 在過去內部從上到下光四層同步一個決策,到貫穿要開始執行可能要兩個月的時間;但在這個時代變化頻率很快的時代,很有可能原本老闆看到的機會,一個月後可能就會不一樣了
  • 基於以上原因,上下層就會產生很大的紛爭。
  • OKR 很大一部分是為了解決這問題,理解公司的目標是什麼後開始進行,而不是圍繞目前手邊做的案子做到完美而忽略了外部的變化
  • 當你理解公司與上層的目標之後,在做的事情就可以時時與目標對齊,隨時調整作法。當每一層都可以很好的做好這些事情,這也是OKR 希望達到的目的。
  • 今年如果公司目標是要將利潤提升 2%,有多少基層員工可以理解利潤提升背後的意義是什麼 ?
  • 其實是有難度的,可能需要透過多層的轉述讓你理解,這中間可能就會有時間與溝通的落差,也可能導致做事情不一致。
  • OKR 形成的本質與敏捷極為相似。

數位轉型
在過去累積經驗的這群人都在做決策,但隨著時間的過去,過去累積的經驗的適用性已經下滑
現在在做決策的高階主管,可能 10 年前在基層擔任開發人員,從開始當主管之後就比較少接觸技術,但科技進步的速度越來越快,技術能力也脫離越來越遠,所以對於以前熟的東西套到現在可能只剩下20%,但他需要去做到最重要的決策
當今天脫離一線單位開始不碰專業與技術時,可能一開始過去的經驗有9成適用,但過三年之後可能剩下6成,幾年後發現做出正確決策的越來越下降,累積久了之後可能就變成債(管理、技術),下一步可能就會思考要進行轉型
  • 老闆在怎麼英民神武,也很難因應各種快速的變化
  • 如果交給你決定,你有把握做出好決策嗎?
  • 當你對商業一無所知的時候,也無法平衡技術與商業之間的決策
  • 上層是很理解對商業的掌握度是很高的,但到越下層了解度是相對較不足
  • 從RD角度理解產品在想甚麼,如果不去理解問題就會一直存在,過去傳統的分工思維需調整,彼此 cover overlap 的部分。
  • 鈦坦 Maryanto 「法國麵包」切法
如果可以合併的話,可以有什麼解法呢
第一種解法
  • 商業管理本身是一門專業,並不是看了幾本書就可以學會的;科技技術也是一門專業。
  • 雙職涯路徑,管理職與專業職是分開的,舉阿里巴巴為例管理是 M(management),專心關注商業面管理決策;技術職是 P(professional)專注在科技與技術管理決策。
第二種解法
  • 讓負責科技決策的人稍微往商業移動,不需要知道商業模式設計的全貌,不需要理解那麼深刻;但不能對於商業的事情是一無所知的。
  • 今天 Ant 也有提到前 10 大科技公司 CEO 10 位有 8 位是工程背景,很大一部分原因是現在做生意要與商業脫鉤是不行的(也無法脫鉤工程),從科技要去理解商業部分難度是比較低的。
重新思考
  • 從組織架構重新思考,從組織面調整
  • 當流程明確清楚的知道交付內容的話適合功能型組織;有一定不確定性的話可能適合BU(專案型)組織;兩者各有優劣與適用性
  • 團隊是 End to End,可以解決大多數的問題,也可以與其他團隊一起合作。比如說敏捷團隊就不會搭配法務
  • 接下來還有甚麼可能性呢?
  • 大部分公司推敏捷很大一部分還是侷限在開發團隊裡頭,並沒有跨出開發團隊
在以前可能公司對外只有少數人在接受外部的需求與回饋(藍色部分),可能是老闆、業務副總、客服主管,接受回饋後再回到公司驅動改變,外部變化掌握在三個人身上,可以發現其他部分就沒辦法掌握。
  • 老闆在怎麼英明神武也有可能沒辦法搞定複雜的問題,只能透過蒐集更多專家的資訊&建議,做出現在適合的最佳解。
  • 轉個角度來看,你也希望做的東西有價值,為什麼不協助老闆呢?也是在幫助自己做出有意義的事情
  • 舉例來說你在開發一個服務,如果希望做出的服務是有價值的,但又不願意去了解是解決甚麼問題,怎麼服務客戶的 怎麼交付價值,如果不願意去理解這些事情,你就是把交付價值這件事情的權力,交付給老闆身上他決定錯了就錯了,自己的時間也就浪費掉了。

上游思維
  • 大家回答 : 跟上游溝通、找其他下游一起找上游理論、換一條河、幫助上游、搬到上游(互相傷害)。
  • 在公司裡面是不是也是面臨到一樣的狀況,上游可能是你的老闆、可能是業務部門
  • - 跟上游溝通 : 找老闆溝通
  • - 找其他下游一起找上游 : 找其他部門一起跟(說服)老闆溝通
  • 解決他(老闆)的問題就是解決你的問題,才不會一直往下游丟垃圾
  • 91影片分享 : Taking Responsibility is taking your power back ! by Will Smith
  • 換一艘船 > 換工作
  • 換一片海 > 換腦海
技術管理重要元素
  • 技術 : 追求極致,思考新的技術是否能解決舊的問題
  • 商業 : 做的東西要有價值,透過驗證 value 做出決定
  • 人文 : 要怎麼領導與激勵下屬,人的部分是不能忽略的
議題討論
如前面所說的,技術管理論壇的初衷不止是希望找適合的人來分享議題而已,而是希望大家聽完後可以針對技術管理的議題進行討論,彼此交流遇到的問題及解決方案,吸收後成為自己的養分。
這 session 現場分20組進行討論,每組都有 Mentor 來引導小組成員分享各自遇到的問題,以及大家一起來思考如何解決它。比較可惜的是場地屬於狹長型,討論與分享上比較不方便些(列入改善清單 XDDDDDD)

心得
議題心得
  • #經驗分享 : 或許是有些過程有一起經歷過的緣故,今天在活動聽 gipi 分享時感觸蠻深的(擔任志工時偶爾插花偷聽一下),在 T 社從一開始進去組織的混亂、開發團隊制度的不完全、被業務單位壓著打到後來局勢逐漸逆轉的經歷,幾張投影片或許聽起來很簡單,但也花了兩年多才搞定這些大大小小的事情。
  • #商業思維 : 在與高層溝通的過程中,應該嘗試用帶來的商業價值角度來討論,技術人員或許不應該活在自己的技術浪漫,堅持要用最新或是最潮的技術解決方案,而忽略了要解決的商業問題是甚麼(技術有可能不是唯一解),了解商業的價值與目的,在把其意義分享給開發團隊,這也是自己這幾年一直在調整的方向。
辦活動初體驗
在技術管理者論壇創辦前期,與 Gipi 聊一聊後就自願報名志工的角色(入教?),從開始的找活動場地到建立活動售票網頁、與贊助廠商討論活動如何配合、活動行前通知與活動問卷填寫...自己也學到辦活動需要注意的地方,還好有另一位有經驗的志工 kyle 協助,否則自己可能會手忙腳亂地。透過親身經歷也可以理解辦活動辛苦的地方,背後有一群人默默付出的付出活動才可以順利進行,謝謝當天贊助錄影的五倍紅寶石軟體,也非常感謝當天一起參與的九位志工朋友們,辛苦了 #辦活動超過百人紀錄達成

注重細節
在起心動念有提到,希望參與線下活動的各位朋友透過議題討論分享各自在組織遇到的問題與解法,讓彼此可以吸收更多經驗帶回到自己的團隊中。在前一天對 rundown 的時候,原本規劃是 14 位一組有 mentor 來帶,91 提到一組 14 位討論的人數太多,會影響到大家發言時間,加上圍著一張海報討論時就有可能變成兩排,沒辦法達到我們希望預期達到的效果,建議人數調整為7位大家才有更多發言與討論的機會。這是自己當初沒思考到的點,下次線下活動也可以作為借鏡 (可能也要等疫情穩定 XDDDDD)


最後,透過活動的大合照來做 Ending,希望大家在這過程可以玩的愉快 :)


Copyright © m@rcus 學習筆記 | Powered by Blogger

Design by Anders Noren | Blogger Theme by NewBloggerThemes.com