本文整理自騰訊CSIG技術(shù)總監(jiān)黃聞欣在【W(wǎng)OT2023·深圳站】大會上的主題分享,更多精彩內(nèi)容及現(xiàn)場PPT,請關(guān)注51CTO技術(shù)棧公眾號,發(fā)消息【W(wǎng)OT2023PPT深圳】即可直接領(lǐng)取。
嘉賓 | 黃聞欣
編輯 | 云昭
出品 | 51CTO技術(shù)棧(微信號:blog51cto)
研發(fā)團隊管理是一門常講常新的老話題。互聯(lián)網(wǎng)高速發(fā)展時期,各大企業(yè)的團隊規(guī)模處于擴張階段,“996”開始成為了一個熱詞,管理者更多會去討論如何去設(shè)定愿景,如何創(chuàng)新;疫情后,在降本增效的語境下,團隊管理又開始從強調(diào)創(chuàng)新,轉(zhuǎn)變?yōu)閺娬{(diào)“流程和執(zhí)行”、“時間和成本”。
但問題就在于,當(dāng)強調(diào)“流程”和“執(zhí)行”的時候,團隊成員會慢慢淪為工作上的“螺絲釘”、“工具人”,這并不是管理者所希望的。
團隊成員綜合能力參差不齊是事實,各有特長也是事實,追求人人都能"獨當(dāng)一面"也不現(xiàn)實。那么,如何讓團隊中每一位成員發(fā)揮其獨有的價值呢?
日前,在51CTO主辦的WOT全球技術(shù)創(chuàng)新大會上,騰訊CSIG技術(shù)總監(jiān)黃聞欣帶來了主題演講《AI武裝技術(shù)團隊:從挑戰(zhàn)到突破》,圍繞如何用生成式AI武裝團隊的諸多挑戰(zhàn),詳細而生動地介紹了作為一名技術(shù)管理者,如何讓前沿技術(shù)幫助每一位團隊成員一步步突破自我,發(fā)揮自身獨特的價值。
本文將摘選其中精彩內(nèi)容,統(tǒng)一整理,希望為諸君帶來啟發(fā)。
一、發(fā)心:讓生成式AI幫助團隊每個人發(fā)揮價值
2023年,在一次將近4個小時的公司內(nèi)部分享中,前輩的一句話讓作為管理者的我,找回了最初加入騰訊的初心——小團隊里面可以讓每一個人都發(fā)揮最大的價值。
為什么這么說?我加入騰訊某種程度上也是出于這個原因,我希望我們團隊每一個人都能發(fā)揮價值,而不僅僅是螺絲釘和工具人。但當(dāng)我制定流程的時候,我的發(fā)心就把他們當(dāng)成了工具人。
然而,流程又是必須的。我們內(nèi)部的團隊非常大,成員的能力也參差不齊,如果沒有流程去管控,就會產(chǎn)生嚴重的問題。產(chǎn)品經(jīng)理、交互設(shè)計、UI設(shè)計、測試等等許多角色的各種溝通配合,肯定都需要有對應(yīng)的流程,劃清邊界。
它不像精英團隊,精英團隊中大家的能力都非常綜合,不需要太多工作,大家只要一配合,事情就能做成,而且也不需要太多人。
這種上規(guī)模的能力分層架構(gòu)的團隊的能力、成本問題又該如何去解決呢?
今年3月,OpenAI發(fā)布了GPT-4,那個發(fā)布會讓我焦慮的同時想到了一個命題:怎么讓生成式AI,去幫助這種分層分工的團隊去發(fā)揮每個人的個人價值,這也正是我近三、四個月在探索和實踐的事情。
二、探索過程中的三個障礙
下面分享在探索實踐過程中遇到的三個障礙:認知、數(shù)據(jù)、習(xí)慣。
1.認知:經(jīng)驗是突破認知的第一障礙
大部分的中層、基層干部,都有非常多的成功經(jīng)驗。而成功的經(jīng)驗往往會成為讓自己接受AI的很大的瓶頸。
比如,通常我們認為,需要調(diào)整我們的組織架構(gòu)去響應(yīng)業(yè)務(wù)模型,但卻很少會去想這樣一個問題:轉(zhuǎn)成一個AI賦能的團隊,我們的組織架構(gòu)要怎么去配合?
圖片
很多管理崗并沒有去思考這個問題,因為大家覺得AI也許就是一個錦上添花的東西,這也是為什么每一次興奮過后,大部分AI動作都會歸于平靜。
再比如,很多技術(shù)功底比較厚實的同學(xué)會認為“AI生成的東西不行”,但問題真是這樣嗎?也許是你的Prompt寫得不夠好。所以說,改變認知是一件很難的事情。
當(dāng)然,也有一個現(xiàn)實情況,大家在心理慣性上或多或或少存在“AI袪魅”的現(xiàn)象。
就像,今年我們看到有許多發(fā)布會都講到了非常豐富的AI功能,看起也很好用,但事實上上手之后發(fā)現(xiàn)也就不過如此,所以大家心里面就對AI更加存疑了。
那如何突破認知呢?首先讓整個團隊都突破認知是不可能的,需要挑選出合適的“先鋒官”。實踐中,我們從前端、后臺團隊分別抽調(diào)出一位對AI感興趣的人,在人力盤點、成本結(jié)算上面做出相應(yīng)的調(diào)整,給他們一個新的戰(zhàn)場。
對于AI而言,挑選戰(zhàn)場至關(guān)重要?有太多看似有價值實則無用的事情。
如何挑選一個影響范圍大、收益大的戰(zhàn)場呢?
下圖中我們列舉了許多可能的戰(zhàn)場,需求設(shè)計、代碼研發(fā)、編譯集成等等。
圖片
在這里,我們發(fā)現(xiàn)整個流程產(chǎn)生的數(shù)據(jù)的展示和分析占據(jù)了半邊天。那么影響范圍最大的戰(zhàn)場就呼之欲出了。我們通過AI技術(shù)能不能讓數(shù)據(jù)分析和展示的成本進一步降低呢?答案是肯定的,AI做數(shù)據(jù)分析不要太成熟了。而承載這些數(shù)據(jù)最多的地方——數(shù)據(jù)庫。因此,我們選擇的第一個戰(zhàn)場就是很"普通"的Text2SQL。
此外,它還是一個能夠幫助深入“敵后”的一個戰(zhàn)場。
首先,我們可以站在巨人肩膀上,Text2SQL的收益面大,路徑清晰,所以市面上就有非常多的團隊在做,有經(jīng)驗分享,有開源的私有化的模型,包括對應(yīng)的Fine Tune的流程和數(shù)據(jù)。它們離真實的生產(chǎn)環(huán)境有距離。“深入敵后”的意義就在這里,我給"先鋒們"提出一個要求:我們做的東西一定是要能落地的,因此要判斷你落地到我們在用的數(shù)據(jù)庫平臺之后,用戶會修改多少個字段,然后這個SQL才能真正執(zhí)行。
其次,Text2SQL可以讓我們減少一道"難關(guān)",我們可以嘗試打造出來一條全自動化的數(shù)據(jù)生產(chǎn)流水線,因為Text2SQL的SQL是可以被驗證的,SQL、表、插入數(shù)據(jù)都可以被生成,然后真實地執(zhí)行驗證。
另外,ClickHouse又進一步把我們推到深處。我們很多業(yè)務(wù)都用Clickhouse,包括我們自身,可惜這些垂直的Text2SQL模型的支持真的是很弱。也很容易理解,因為它要面對嚴重缺乏元數(shù)據(jù)的大寬表和一堆獨特的函數(shù),但是這也偏偏是Text2SQL本來就需要面對的難題。當(dāng)時我們就想,Clickhouse這么難的都搞定了,其他什么mysql不是手到擒來。
最后,一個深入?yún)^(qū),是因為我們自己是做性能工程的,Text2SQL可以讓團隊在此基礎(chǔ)上有機會做更深水區(qū)的AI模型調(diào)優(yōu),CPU推理,模型裁剪、MOE等性能優(yōu)化。上述的這些,我們都嘗試去面對去實踐,老板肯定會問“為什么會做這么跨領(lǐng)域的事情”,因為這是一個很深入敵后的戰(zhàn)場,會幫助我們團隊走過AI的全流程,驗證全部想法,挖掘全部坑點。
小結(jié),找到一個最成熟的領(lǐng)域,一定會有收益、收益最廣泛的領(lǐng)域,深入敵后的領(lǐng)域,去完完整整地打穿它,就能讓團隊的AI能力提升起來。接下來有一個重要的事情,就是分享經(jīng)驗。
分享經(jīng)驗有兩點需要注意。一個是AI先鋒們要把深度的經(jīng)驗分享出來;另外一個是管理者要塑造出團隊氛圍。
下圖是大致團隊分享的情況,先鋒隊會有類似的3個課程分享,比如《AI原住民的第一節(jié)課》,緊接著深水區(qū)的經(jīng)驗:比如怎么使用、怎么調(diào)優(yōu)等。
圖片
深水區(qū)的課程都是先鋒隊“以仗養(yǎng)仗”、邊去打仗邊總結(jié)的內(nèi)容,然后用他們的案例沉淀出來,在團隊內(nèi)部做分享。
另一方面,還需要營造一個用AI的氛圍。比如做一個輕量化的閃電分享,時長限制到三到五分鐘,不需要說太多,就分享在工作中用到的一個Prompt、用到的一個AI的tool就OK了。
小結(jié)一下,為了突破認知,從管理維度上看,招聘選人的時候,一定要多問AI相關(guān)的問題,因為AI肯定是未來研發(fā)人員很重要的一項能力,否則就會落伍。接下來是挑選先鋒隊,帶動團隊。其次是閃電分享,去打造自己的氛圍和培訓(xùn)。
圖片
通過這樣的突破認知的過程,產(chǎn)生的價值也是讓我非常自豪的。我們現(xiàn)在有30多場閃電分享,團隊內(nèi)部的成員開始主動地去落地提單和CR,而且成果已經(jīng)落地到了公司內(nèi)部非常重要的業(yè)務(wù)上,比如Text2SQL和數(shù)據(jù)中臺結(jié)合。
2.數(shù)據(jù):訓(xùn)練AI的數(shù)據(jù)從哪里來?
眾所周知,AI非常重要的是數(shù)據(jù)。但這里就會有兩個問題:一、沒流程、沒數(shù)字化、沒有用的數(shù)據(jù),二、即便有了數(shù)據(jù),但沒有飼養(yǎng)的意識。
圖片
第一個問題的在于都不僅僅是數(shù)據(jù)孤島的問題,首先就是數(shù)字化這個事情,哪怕是互聯(lián)網(wǎng)企業(yè)本身也不一定做得非常好。舉個例子,測試過程真的做到數(shù)字化了嗎?其實沒有。我們只是局部數(shù)字化了,測試用例和測試結(jié)果數(shù)字化了,但是測試過程中是怎么點的、怎么用的、怎么測的,這些都是黑盒。
再比如,我們自己有一個比較細節(jié)的例子,當(dāng)我們?nèi)プ鯰ext2SQL訓(xùn)練的時候,數(shù)據(jù)上就有很大一個問題,就是沒有研發(fā)寫SQL語句以及這個SQL語句修正的記錄。類似這樣的很多細節(jié)的過程都是沒有做數(shù)字化。
更內(nèi)核的是,很多時候,流程是缺失或者失效的。流程是數(shù)字化過程數(shù)據(jù)正確性和標準化的基石,沒有流程,沒有數(shù)字化,哪里來數(shù)據(jù)呢?沒有數(shù)據(jù),怎么練AI呢?
我們再來看另一個難點。假定我們有數(shù)據(jù)了,但很多人也沒有喂養(yǎng)的意識。
舉一個例子,我之前績效面談,我們的一個測試同學(xué)遇到一個錯誤碼會去問團隊內(nèi)有經(jīng)驗的大牛,而大牛往往能直接根據(jù)錯誤碼找出問題的原因。他一直跟我說,他很羨慕,希望成長成他那樣。我當(dāng)時,不禁反問,這時候其實如果有對應(yīng)的產(chǎn)品文檔的,然后將這個文檔“喂養(yǎng)”到AI知識庫里,然后再去用你的問題去校驗知識庫能不能夠像大牛那樣去回答你的問題,不是更好嗎?
大牛回答的問題,知識庫也可以回答。例如大家現(xiàn)在用ChatGLM3,再加上Embedding知識庫,效果其實很好的。這是“飼養(yǎng)”數(shù)據(jù)意識的問題。
那么,如何突破這兩個點呢?數(shù)據(jù)如何生產(chǎn)?如何飼喂?
首先,我們設(shè)定了三個非常核心的數(shù)據(jù)自動化產(chǎn)生的鏈路。愿景是希望令研發(fā)等流程中初步沉淀了七八十條精修的數(shù)據(jù),通過整個自動化的鏈路,比如LangChain的鏈路,可以快速生產(chǎn)過百甚至上千、上萬的數(shù)據(jù),并且這個數(shù)據(jù)還是高質(zhì)量的。怎么去做的呢?
圖片
我們設(shè)定了三個模型。第一個模型,即用真實的執(zhí)行環(huán)節(jié)去產(chǎn)生數(shù)據(jù),比如代碼完成后,代碼執(zhí)行過程中,產(chǎn)生了crash,代碼跟crash之間的數(shù)據(jù)就有了。
第二個,用邏輯去泛化。我們知道金字塔原理,就是演繹推理、溯因推理、歸納推理,不同的推理方式利用生成式AI演進出不同的問題,從而泛化我的數(shù)據(jù)。
第三個,通過不同的場景去泛化,例如現(xiàn)在做數(shù)據(jù)庫的Text2SQL,之后也可以泛化到工業(yè)場景、用戶行為場景等等,讓它去泛化出來各種不同的數(shù)據(jù)。
有了生產(chǎn)數(shù)據(jù)的三個核心鏈路,然后就是喂養(yǎng)。首先,我們會將每日wiki的數(shù)據(jù)都會錄入到AI知識庫,也就是向量數(shù)據(jù)庫里面。然后,你就可以通過企業(yè)微信的機器人問對應(yīng)的問題,直接、快速地得到一個相對高質(zhì)量的答案。
另一個重要的是,前面提到的閃電分享也是一個重要的宣傳途徑,把這個能力公開給到團隊里面的其他人去使用。這一步一定要做到,否則,就沒有形成閉環(huán),大家也不知道原來已經(jīng)有了這樣的能力。
圖片
總結(jié)一下,數(shù)據(jù)是很重要的,全自動地產(chǎn)生數(shù)據(jù)更重要。現(xiàn)在,AI發(fā)展地速度幾乎可以按天計算,但最安穩(wěn)的其實還是數(shù)據(jù),數(shù)據(jù)為王。
因此,對于AI團隊而言,不要以為現(xiàn)在有幾百條數(shù)據(jù)就很滿足了,每天能用自動化的流程產(chǎn)生上萬條數(shù)據(jù),同時這個自動化的流程還要能確保這個數(shù)據(jù)產(chǎn)生的質(zhì)量。
3.突破習(xí)慣:讓AI滲透到習(xí)慣中
突破習(xí)慣是每個人都要克服的難題,甚至包括本身在開發(fā)AI的人。我觀察到一個很有意思的事情,我們做AI開發(fā)的先鋒們,開發(fā)AI的應(yīng)用,但代碼還是他自己寫的,沒有用AI。哪怕是最接納AI的人,都有一種習(xí)慣,覺得自己的直覺和經(jīng)驗更順手,可以快速去實現(xiàn)。
圖片
第二個要突破的是,我們總習(xí)慣把自己的價值放在自身的領(lǐng)域范圍內(nèi)。但凡一線的人要進一步去拓寬你的價值的時候,你要多走一公里的時候,往往要面對一個問題:你的語言別人是聽不懂的。
比方說,我們的研發(fā)同學(xué),有很強的技術(shù)能力,開發(fā)出了功能強大的產(chǎn)品。但是產(chǎn)品沒有賣好,你想多走一公里,加速技術(shù)變現(xiàn)。但是銷售實在聽不懂你說的。你用盡權(quán)利去描述這技術(shù)帶來的功能和優(yōu)勢,但是銷售想要的其實是"客戶收益"。
F.A.B prompt:
你是銷售總監(jiān),能幫助我把Feature的描述變成Advantage和Benefit。
#注意:請保持用中文回答;
#思考步驟:
1. 先把Feature的描述變成Advantage
2. 從Advantage中,分別研發(fā)、產(chǎn)品經(jīng)理、技術(shù)運維、質(zhì)量保障的一線員工或主管的角色去腦暴Benefit
3. 再用 MECE 原則會歸納,并用吸引眼球&打動人心的語言和精煉有力的短句的輸出
#功能描述:該功能叫熱點性能動態(tài)分析,程序會調(diào)用perf收集程序的熱點函數(shù)和熱點匯編,然后在我們的工具頁面中通過火焰圖和表格來展示數(shù)據(jù),并會自動分析數(shù)據(jù)給出初步的性能優(yōu)化建議
其他還有,當(dāng)測試想多走"一公里",如何用"研發(fā)的語言"讓研發(fā)更快解決;當(dāng)產(chǎn)品想多走"一公里",如何用"技術(shù)的語言"達成技術(shù)與產(chǎn)品的共振;這時,肯定離不開AI,因為AI是有世界知識的,它可以把你的語言轉(zhuǎn)化成別人領(lǐng)域能理解的語言,這是太自然不過的事情了。
圖片
接下來,我們怎么改變這種習(xí)慣呢?上表中,你會發(fā)現(xiàn)我們在數(shù)據(jù)分類里面除了文檔數(shù)據(jù)和流程數(shù)據(jù)之外,還有很多平臺,平臺上會有研發(fā)、測試等各個角色。他們在這些現(xiàn)成的平臺上已經(jīng)形成習(xí)慣了。我的思路很簡單,我們不急著顛覆,去改變原來的"習(xí)慣",我們要讓AI跟這些平臺伴生,去滲透AI的使用習(xí)慣。
因此我們開發(fā)了一個實驗項目,F(xiàn)ibona AI瀏覽器插件。(Fibona, 取自斐波那契數(shù)列的啟發(fā),希望表達的是讓AI和諧地融合到我們的工作習(xí)慣中)
下面有個小視頻,里面有兩段,一段演示的是在我們現(xiàn)成的騰訊云QAPM客戶端性能監(jiān)控怎么融合Fibona,我們可以不斷地添加線索到Fibona里面,然后它就會分析問題,最后分析到究竟是哪一個crash是主要成因。另外一段是,一個研發(fā)最難定位的線程安全問題,通過我們的插件,提供多方線索,最終直出解決方案。
,時長00:36
我的愿景是,這種伴生平臺會推展到公司內(nèi)的全部平臺,未來也會進一步商業(yè)化,比如伴生在某個DevOps的平臺上面,去幫助提供這種AI的能力。
圖片
所以這樣看來,我們并不改變習(xí)慣,我們通過這種伴生的方式來滲透AI的使用習(xí)慣。這里我們突破了三個非常重要的瓶頸,分別是:認知、數(shù)據(jù)、習(xí)慣。
四、我們更進一步看看
這里整體上聊到了很多場景,包括用AI來做數(shù)據(jù)分析,然后做缺陷的定位解決方案,怎么去通過Text2SQL幫助不懂SQL語言的同事去寫SQL語言,怎么用公司內(nèi)的AI模型給到CR的建議,此外還有剛才聊到的知識庫AI大師。
當(dāng)把這些場景全部放到一個表格里面來看,就會發(fā)現(xiàn)非常有意思的事情。
圖片
1.知識和經(jīng)驗平權(quán)
第一個維度,其實是很多AI書中寫到的,也是布魯姆教育目標分類法中提到的:記憶、理解、應(yīng)用、分析、評估、創(chuàng)造,這是不同的等級。我們大部分提問的問題其實都離不開這六個點。這六個點會對應(yīng)產(chǎn)生一系列的價值。
例如“理解”,以前團隊是做CVM測試的,現(xiàn)在突然要做異構(gòu)計算的測試,本身對英偉達的理解其實不多,那怎么辦?
圖片
GPT就能理解這個信息的,上圖是我們的一個Prompt,這個Prompt也很簡單,你是一個什么專家,讓它用Markdown格式來輸出。
這是團隊從0到1突破的一個例子,先不要想象著我能從1做到100分。通過利用GPT去快速地了解,在這個日志文件里面,其實可以暴露出有哪些可以做性能優(yōu)化的點。接下來只需要基于這個再進一步去提問就可以了。
因此,通過這個例子可以看出,突破已經(jīng)不僅僅是技術(shù)知識了,而是知識和經(jīng)驗的平權(quán)。比如在IaaS領(lǐng)域,每一塊知識都非常割裂,搞CPU的不懂搞網(wǎng)絡(luò)的,搞網(wǎng)絡(luò)的不懂磁盤的,當(dāng)下你可以快速學(xué)習(xí)理解甚至運用其他領(lǐng)域的知識。再擴大一點,比如HR不會編程,想自己做的程序來提升工作效率,就只能找程序員幫忙,現(xiàn)在我們可以找AI幫忙,用自然語言就可以幫你寫出程序。
圖片
所以我們通過知識和經(jīng)驗的平權(quán),嘗試去給團隊成員賦能,你有很特長的部分,例如寫代碼很厲害,其他的部分,比如溝通、匯報等能力通過AI來幫你補全。
比如郵件輸出,給到你一個AI的Prompt模板,給到基本信息,就可以用AI去生成,寫出來一個60分~80分的郵件。這就是知識和經(jīng)驗的平權(quán)的一個例子。
2.讓自動化更自動化
另外一個很重要的部分,就是突破自動化,讓自動化更自動化。這里提的更像是一個目標或者要求,讓AI這個自動化更自動化一點。
現(xiàn)在大部分AI都有一個問題:它好像做了什么,好像又沒做什么。比如:最經(jīng)典的場景是會議紀要,似乎是歸納了,但是又似乎有遺漏,就是不敢當(dāng)成郵件內(nèi)容往外發(fā)。
我的主張是:不強制團隊用AI,而且做AI、推廣AI的一定要說清楚AI生成內(nèi)容后,你的下一步動作是什么,是去修改它嗎?還是直接使用它?
舉個案例,下圖是我們生成的一張缺陷單,這是純粹用AI生成關(guān)于真實業(yè)務(wù)上的缺陷單。
圖片
每位測試人員的能力其實是參差不齊的,許多工具測完跑出來幾千條Benchmark的數(shù)據(jù),然后還要耗費4、5個小時去分析這些數(shù)據(jù),甚至還存在漏分析、漏提單的情況。
這是一個"腦熱"的需求,用AI去分析生成缺陷。當(dāng)時快速就出了一個版本,大家都很興奮。當(dāng)時我說,這個缺陷生成的下一步是"直接提單"嗎?當(dāng)時的回答是不能的。所以第一步,我們先設(shè)定我們的期待結(jié)果究竟是什么?然后開始打磨Prompt。實話說,比寫程序復(fù)雜多了,打磨了將近兩個星期才出來。除了要按照我們期待的格式和內(nèi)容輸出之外,還有三個難點——
第一,要從幾千條數(shù)據(jù)里面找到問題,沒有遺漏;
第二,還要去做聚合,避免重復(fù)提單;
第三,就是這個單要準確,可以直接拿來就用。這個時候“評估”就很重要了。一個訣竅就是在AI的Prompt中添加一個置信度的評估。經(jīng)驗上看,有了置信度的評價,再加上內(nèi)容的生成,往往效果就會更好些。
之后,我們就可以開始落地到流程中去進行下一步。這就是“比自動化更自動化”。
3.跨領(lǐng)域溝通
最后一點,跨領(lǐng)域的溝通很難,如何解決?大家通常會想到一個解決的方案:流程。流程的確能解決非常多的問題,比如上下游的信息傳遞等等。但問題就在于,流程中的不同角色之間,怎么去相互理解?這如何解決?
回到Text2SQL的例子。沒有Text2SQL之前,產(chǎn)品經(jīng)理用自然語言告訴我們要查一個什么數(shù)據(jù),然后告訴DBA,DBA幫它做一個SQL語句,檢索出來,告訴他怎樣就能搜索出來。
現(xiàn)在有了AI,我們期待的效果是:產(chǎn)品經(jīng)理直接自然語言告訴AI,SQL語句生成、數(shù)據(jù)查詢出來。
乍看起來讓人焦慮,它不僅消滅了溝通的屏障,而是直接把人給消滅了,不用DBA了?其實我們不妨換一個角度思考,正如前面多次提及的,它其實是通過人類的自然語言去調(diào)動了跨領(lǐng)域的知識。作為產(chǎn)品經(jīng)理,我不懂SQL語言,但他要寫一個很復(fù)雜的SQL語句難度太大。而AI這個助手可以幫助他做到這件事情。
那跨領(lǐng)域知識的價值是什么呢?就是“向價值多走一公里”。尤其是降本增效語境下,大家都在找自己的價值。技術(shù)團隊一定要多走一公里,比如:性能優(yōu)化能不能直接給出優(yōu)化的patch,提單能不能給出根因分析,性能測評的內(nèi)容能不能給到銷售去作為彈藥庫。當(dāng)團隊去多走一公里的事情的時候,肯定就會用到AI。
這里再舉例一個特殊的跨領(lǐng)域溝通的案例,戰(zhàn)略討論會。
圖片
首先大家懂不懂戰(zhàn)略,其次,我們能不能夠收集到足夠定義戰(zhàn)略相關(guān)的信息,就像我們在做產(chǎn)品的時候,PESTEL模型、波特五力的模型、核心競爭力分析的模型等等。模型都是需要信息和數(shù)據(jù)的,這些根本找不到,那怎么辦?
當(dāng)時我們用AI去生成。用AI描述完產(chǎn)品、定位之后,讓它給我列舉十種飛輪模型,我就有了一個討論的基礎(chǔ)。通過給AI看行業(yè)報告,把行業(yè)報告灌給AI,讓它按照B3C模型,看自己、看競爭對手、看環(huán)境、看客戶,模型里面都有非常標準化的問題,讓AI去輸出對應(yīng)的結(jié)果,并且用我們能理解的語言來輸出對應(yīng)的結(jié)果。
這時候,沒有學(xué)過戰(zhàn)略的程序員也可以坐在一起討論戰(zhàn)略了,而且不是空討論。而且在討論的同時,也會提出來一些問題,比如怎么去更好地了解我們客戶的訴求等等。
4.技術(shù)管理者追求的價值
在做流程管理、做分層結(jié)構(gòu)、做靈活用工的時候,管理者會發(fā)現(xiàn)團隊的成員慢慢變成螺絲釘、工具人,這時就值得反思。我能不能用AI賦能的方式、用知識平權(quán)、自動化、跨領(lǐng)域溝通的方式,去賦能給每一個技術(shù)人員,讓他們作為一個平凡但有特長的人,在團隊里面也可以發(fā)揮自己獨有的最大的價值。
圖片
這也是本人所追求的價值:自己要發(fā)揮價值,自己的團隊也要發(fā)揮價值。