想成為移動端架構(gòu)師需要會安卓和IOS應(yīng)用開發(fā)的能力嗎？

哲學(xué)家常思考的問題：" 我是誰？"" 我從哪里來？"" 要到哪里去？不只是哲學(xué)家，我想每個人都有自己對這三個問題的認(rèn)知。

如果我們要成為架構(gòu)師，我們自己要面臨的三大問題：

找準(zhǔn)自己定位：我是誰？在哪里？

怎樣做好架構(gòu)師：我要做什么？

如何搭建架構(gòu)師知識體系：我該怎么做？

這里面就是做事方法論：目標(biāo)（我要做什么），方法（計劃）（我該怎么做）, 執(zhí)行/行動

1、架構(gòu)師定義

什么是架構(gòu)師，這個聊架構(gòu)話題時永恒的問題。每個公司對架構(gòu)師的定位也有所不同，因為不同公司所處的階段，業(yè)務(wù)模式，應(yīng)用場景也都不一樣。對架構(gòu)的要求也不一樣。

在初創(chuàng)公司的野蠻生長階段：業(yè)務(wù)場景和需求邊界很難把握，有時候根本不需要架構(gòu)師，產(chǎn)品需要快速迭代和變現(xiàn)，需求頻繁更新，這個時候需要的是快速實現(xiàn)。當(dāng)然如果公司成長以后，這個階段就是欠下很多技術(shù)債，埋下很多坑，如果人員流動很頻繁，后期系統(tǒng)維護(hù)成本是非常巨大的。

在公司成長穩(wěn)定階段：業(yè)務(wù)模式和應(yīng)用場景邊界都已經(jīng)比較清晰，這個時候最需要架構(gòu)師需要架構(gòu)師能對線上業(yè)務(wù)進(jìn)行模塊劃分，系統(tǒng)拆分重構(gòu)，并做好相關(guān)高可用的措施，以保證系統(tǒng)的穩(wěn)定，安全、高效地運行。

不同的行業(yè)，對架構(gòu)師的要求也不同，比如電商業(yè)務(wù)和AI領(lǐng)域，從架構(gòu)到業(yè)務(wù)場景，完全是兩個物種。

在百度百科里面這么定義： 系統(tǒng)架構(gòu)師是一個既需要掌控整體又需要洞悉局部瓶頸并依據(jù)具體的業(yè)務(wù)場景給出解決方案的團(tuán)隊領(lǐng)導(dǎo)任務(wù)。具體來說是一個確認(rèn)和評估系統(tǒng)需求，給出開發(fā)規(guī)范，搭建系統(tǒng)實現(xiàn)的核心構(gòu)架，并澄清技術(shù)細(xì)節(jié)、掃清主要難點的技術(shù)人員。主要著眼于系統(tǒng)的“技術(shù)實現(xiàn)”。因此架構(gòu)師應(yīng)該是特定的開發(fā)平臺、語言、工具的大師，對常見應(yīng)用場景能馬上給出最恰當(dāng)?shù)慕鉀Q方案，同時要對所屬的開發(fā)團(tuán)隊有足夠的了解，能夠評估自己的團(tuán)隊實現(xiàn)特定的功能需求需要的代價。系統(tǒng)架構(gòu)師負(fù)責(zé)設(shè)計系統(tǒng)整體架構(gòu)，從需求到設(shè)計的每個細(xì)節(jié)都要考慮到，把握整個項目，使設(shè)計的項目盡量效率高，開發(fā)容易，維護(hù)方便，升級簡單等。

架構(gòu)師實際上就是軟件的總體設(shè)計師。打個通俗的比方比如某個工程總設(shè)計師，類似三峽工程的總設(shè)計師。

架構(gòu)師的形成一定是在實踐中積累起來的，而并非上了幾次培訓(xùn)班，讀了幾本書就可以成功的，架構(gòu)師是在工程實踐中培養(yǎng)出來的!

2、架構(gòu)師作用/職責(zé)

架構(gòu)師在整個軟件系統(tǒng)開發(fā)過程中都起著重要的作用，并隨著開發(fā)進(jìn)程的推進(jìn)而其職責(zé)或關(guān)注點不斷地變化。

1）、按軟件開發(fā)過程維度來說：

需求階段：軟件架構(gòu)師主要負(fù)責(zé)理解和管理非功能性系統(tǒng)需求，比如軟件的可維護(hù)性、性能、復(fù)用性、可靠性、有效性和 可測試性等等，此外，架構(gòu)師還要經(jīng)常審查和客戶及市場人員所提出的需求，確認(rèn)開發(fā) 團(tuán)隊所提出的設(shè)計;

架構(gòu)設(shè)計階段：架構(gòu)師負(fù)責(zé)對整個系統(tǒng)架構(gòu)設(shè)計，制定開發(fā)規(guī)范、開發(fā)計劃，指導(dǎo)整個開發(fā)團(tuán)隊完成這個計劃。

開發(fā)階段：架構(gòu)師則成為詳細(xì)設(shè)計者和代碼編寫者的顧問，并且經(jīng)常性地要舉行一些技術(shù)研討會、技術(shù)培訓(xùn)班等;

測試和交付階段：協(xié)調(diào)做好相關(guān)測試和部署。

維護(hù)階段：軟件架構(gòu)師就開始為下一版本的產(chǎn)品是否應(yīng)該增加新的功能模塊進(jìn)行決策。

2）、按職能維度：

1 確認(rèn)需求

架構(gòu)師要懂得用戶需求，理解用戶真正想要什么，這使得架構(gòu)師必須要和分析人員不斷溝通，反復(fù)確認(rèn)需求規(guī)格說明書，以此來保證他精準(zhǔn)清楚用戶需求。

項目經(jīng)理劉先生在受訪時說：「架構(gòu)師會與很多人溝通，例如開發(fā)人員，例如我們項目經(jīng)理，有時甚至是用戶本身。架構(gòu)設(shè)計的目的很明確，目的是什么呢？挖掘用戶需求。」

2 系統(tǒng)分解

在架構(gòu)師認(rèn)可需求規(guī)格說明書后，架構(gòu)師已明確用戶需求是是什么，這時候便看架構(gòu)師的分解能力了。

系統(tǒng)分解包括縱向分解和橫向分解：

橫向分解是對系統(tǒng)分解成不同的邏輯層，確定層與層之間的關(guān)系。是指基于技術(shù)架構(gòu)層次進(jìn)行的人員角色分工和任務(wù)分解。常見的分層：

應(yīng)用層：主要負(fù)責(zé)具體的業(yè)務(wù)邏輯處理

服務(wù)層：提供可復(fù)用的服務(wù)

數(shù)據(jù)層：負(fù)責(zé)數(shù)據(jù)的存儲和訪問

分層注意事項：①必須合理規(guī)劃層次邊界和接口；②禁止跨層次的調(diào)用及逆向調(diào)用。

縱向分解是將不同的功能和服務(wù)分割開來，包裝成高內(nèi)聚低耦合的模塊單元，有助于軟件開發(fā)和維護(hù)，還便于不同模塊的分布式部署，提高網(wǎng)站的并發(fā)處理能力和功能擴(kuò)展能力。

3 技術(shù)選型

在系統(tǒng)分解后，架構(gòu)師會最終形成軟件整體架構(gòu)，接下來，架構(gòu)師的職責(zé)是技術(shù)選型。

前端到底用瘦客戶端還是富客戶端呢？數(shù)據(jù)庫是用MySQL還是MSSQL又或是Oracle呢？架構(gòu)師張先生在接受采訪時說，在了解用戶需求后，分解完系統(tǒng)后，技術(shù)選型是非常重要的環(huán)節(jié)，提出各個方向，我再進(jìn)行評估。不過，很多人都以為架構(gòu)師是有決定權(quán)的，其實不是，架構(gòu)師沒有拍版的權(quán)力，決定由項目經(jīng)理來做。

架構(gòu)師在技術(shù)選型階段會提供參考信息給項目經(jīng)理，項目經(jīng)理再從預(yù)算、進(jìn)度、人力、資源等各方面情況來權(quán)衡，最終確認(rèn)。

4 制定技術(shù)規(guī)格說明

如前文調(diào)查顯示，架構(gòu)師在項目開發(fā)過程中是「靈魂人物」，并且要具備協(xié)調(diào)組織能力和懂得人員分工。

在制定技術(shù)規(guī)格說明階段，架構(gòu)師要協(xié)調(diào)起所有的開發(fā)人員，架構(gòu)師通常會用技術(shù)規(guī)格說明書與開發(fā)人員保持溝通，讓開發(fā)人員能從各個視角去觀測、理解他們負(fù)責(zé)的模塊或者子系統(tǒng)，確保開發(fā)人員能夠按照架構(gòu)意圖實現(xiàn)各項功能。

3）、關(guān)注點：

?方向規(guī)劃：有想法和技術(shù)展望目標(biāo)，制定短期目標(biāo)

?架構(gòu)設(shè)計：集思廣益來設(shè)計，歸類總結(jié)，根據(jù)討論結(jié)果制定規(guī)范。設(shè)計不僅僅是技術(shù)相關(guān)（業(yè)務(wù)流程，業(yè)務(wù)方向，模塊劃分組合，框架設(shè)計，流程紕漏等），設(shè)計出來還是需要實施的。

?技術(shù)攻關(guān)：疑難技術(shù)點攻關(guān)，將問題集中化解決，提供平臺化解決方案以及選型決策。

?解決疑難問題：發(fā)現(xiàn)各類型問題（不僅僅是技術(shù)），通過規(guī)范，演講，繪圖等方式解決隱患。

?互動溝通：部門之間溝通，開發(fā)之間溝通，產(chǎn)品之間溝通，市場溝通，溝通后產(chǎn)出圖形化文檔及設(shè)計。

?關(guān)注點：秩序，統(tǒng)一，規(guī)范，穩(wěn)定，高效

架構(gòu)是要靠團(tuán)隊做出來的

?保持和架構(gòu)的溝通，架構(gòu)通過團(tuán)隊的溝通總結(jié)出方向

?隊員經(jīng)常提出自己碰到的問題，并分享給大家，思維碰撞促進(jìn)發(fā)展

?產(chǎn)品經(jīng)常提出設(shè)想和規(guī)劃，能夠使得架構(gòu)符合未來發(fā)展需求

?運維經(jīng)常提出隱患及分析，能使得架構(gòu)快速拆分模塊

?定期做總結(jié)歸納以此分析問題，解決問題

?團(tuán)隊成長、就是每個人的成長、每個人成長眼界自然增長

?團(tuán)隊的成功、就是產(chǎn)品的成功，產(chǎn)品的成功就是公司的成功

公司的成功可以給你加光環(huán)，但光環(huán)不代表自己的能力代表經(jīng)歷

3、架構(gòu)師分類

其實架構(gòu)師就是個title，每個公司稱呼都可能不一樣，和架構(gòu)概念一樣。

軟件架構(gòu)師：

軟件架構(gòu)師是軟件行業(yè)中一種新興職業(yè)，工作職責(zé)是在一個軟件項目開發(fā)過程中，將客戶的需求轉(zhuǎn)換為規(guī)范的開發(fā)計劃及文本，并制定這個項目的總體架構(gòu)，指導(dǎo)整個開發(fā)團(tuán)隊完成這個計劃。主導(dǎo)系統(tǒng)全局分析設(shè)計和實施、負(fù)責(zé)軟件構(gòu)架和關(guān)鍵技術(shù)決策的人員，比如這些架構(gòu)師的title可能是JAVA架構(gòu)師、Python架構(gòu)師、LAPM架構(gòu)師等等。

web架構(gòu)師：

web架構(gòu)師是網(wǎng)站系統(tǒng)、功能、模塊、流程的設(shè)計師，架構(gòu)師，好比是高樓大廈的設(shè)計人員，通常一座大廈在建之前，都先由設(shè)計師將藍(lán)圖描繪出來，包括其形狀、結(jié)構(gòu)、尺寸、材料等等，然后建筑工程師帶領(lǐng)工人們按照藍(lán)圖將大廈一層一層地建起來

架構(gòu)師也要看在什么樣的公司，中小公司很多架構(gòu)師都是全能的。通常公司規(guī)模和體系越大，分工會越細(xì)：大體可以這么分類：

解決方案架構(gòu)師：與客戶探討業(yè)務(wù)需求，將業(yè)務(wù)、市場，與技術(shù)、產(chǎn)品結(jié)合起來，為客戶提供解決他們需求的方案。比如阿里云針對大客戶都有解決方案架構(gòu)師。

系統(tǒng)架構(gòu)師: 也稱應(yīng)用架構(gòu)師。最終確認(rèn)和評估系統(tǒng)需求，并將業(yè)務(wù)轉(zhuǎn)換為技術(shù)，為研發(fā)人員制訂核心框架與技術(shù)規(guī)范 為研發(fā)工作澄清技術(shù)細(xì)節(jié)并掃清技術(shù)障礙 。服務(wù)器負(fù)載，可靠性，伸縮，擴(kuò)展，數(shù)據(jù)庫切分，緩存應(yīng)用

平臺架構(gòu)師:這里的平臺其實包括兩個平臺，一個是系統(tǒng)平臺，也就是負(fù)責(zé)搭建多個系統(tǒng)整合的系統(tǒng)應(yīng)用平臺；另外一個其實是基礎(chǔ)平臺，是專門負(fù)責(zé)搭建基礎(chǔ)技術(shù)平臺；兩者其 實區(qū)別蠻大，也經(jīng)常容易被從業(yè)人員混亂。舉個簡單例子，金蝶有平臺架構(gòu)師一職，但是金蝶BOSS應(yīng)用和金蝶中間件兩者招聘的對象和技術(shù)要求是截然不同的。

業(yè)務(wù)架構(gòu)師：業(yè)務(wù)架構(gòu)其實已經(jīng)開始脫離技術(shù)層面了，但是它要求架構(gòu)師有跨越多系統(tǒng)的大局觀，去整合和組織不同系統(tǒng)的技術(shù)平臺與交互模式。其實這個職位的未來也就是CIO了。 主要內(nèi)容：理解業(yè)務(wù)，梳理模型，設(shè)計模式，接口，數(shù)據(jù)交互。

網(wǎng)絡(luò)架構(gòu)師:過去，我們可能聽的最多的是網(wǎng)絡(luò)工程師。不錯，一個優(yōu)秀的網(wǎng)絡(luò)架構(gòu)師必須有足夠的網(wǎng)絡(luò)技術(shù)基底，并且它的關(guān)注點也是系統(tǒng)的基礎(chǔ)架構(gòu)。比如說如果搭建并優(yōu)化集群環(huán)境，如果構(gòu)建基于云計算的系統(tǒng)應(yīng)用與部署等等。它對于像淘寶、騰訊這樣的互聯(lián)網(wǎng)公司是極其重要的。

移動架構(gòu)師:移動互聯(lián)網(wǎng)的迅猛發(fā)展橫向和縱向都細(xì)分出了很多新的職責(zé)和崗位，移動架構(gòu)師的職責(zé)和作用日益重要，既要整體和全局考慮整個前后端的軟件系統(tǒng)架構(gòu)，又要重點深入移動客戶端的架構(gòu)設(shè)計的方方面面，既要有跨平臺思維，又要拿捏好原生和混合開發(fā)的尺度，另外移動應(yīng)用的特點，導(dǎo)致移動架構(gòu)師必須要比傳統(tǒng)系統(tǒng)架構(gòu)師更加注重非功能性的質(zhì)量屬性。

前端架構(gòu)師:這也是移動互聯(lián)網(wǎng)的迅猛發(fā)展而細(xì)分出來的新的職責(zé)和崗位，這里的前端特指網(wǎng)站開發(fā)中的前端，主要考慮前端呈現(xiàn)層的設(shè)計（HTML/CSS/JS/AJAX/RIA/…），跨瀏覽器設(shè)計等等。

大數(shù)據(jù)架構(gòu)師：比如某些公司做大數(shù)據(jù)處理，需要理解業(yè)務(wù)，并通過大數(shù)據(jù)相關(guān)技術(shù)來實現(xiàn)。

4、架構(gòu)師具備素質(zhì)能力

? 精通某項技術(shù)，能夠從本質(zhì)上類比，觸類旁通其他技術(shù)

? 對等所有技術(shù)，只有合適和不合適，沒有喜歡和不喜歡。

? 視野開闊，了解不同技術(shù)的優(yōu)缺點。知道使用某項開源技術(shù)實現(xiàn)某項業(yè)務(wù)需求，能夠辨別重復(fù)造輪子。

? 精通設(shè)計模式，但又不泛用。

? 把系統(tǒng)拆分成多個子系統(tǒng)或模塊。模塊之間盡量松耦合，使得原先串行的開發(fā)任務(wù)變得可以并行發(fā)展。

? 能清楚系統(tǒng)的瓶頸在什么地方， 不斷定位技術(shù)難度，開發(fā)進(jìn)度，性能，內(nèi)存等個方面的瓶頸。不斷調(diào)整骨干力量解決瓶頸，在風(fēng)險爆發(fā)之前消除隱患。

? 能做好前瞻性設(shè)計，預(yù)判到需求可能產(chǎn)生的變化。

架構(gòu)師團(tuán)隊內(nèi)做的事情

?溝通能力：各個方面都要了解，人人想法及規(guī)劃都要知道，了解產(chǎn)品思想，用了什么方法實現(xiàn)的

?組織能力：組織推動各種技術(shù)的改進(jìn)及功能的完善

?談判代表：左右兩難的時候的調(diào)解人

?設(shè)計模塊及業(yè)務(wù)：通過圖形化設(shè)計發(fā)現(xiàn)開發(fā)后才會發(fā)現(xiàn)的業(yè)務(wù)問題

?成本規(guī)劃：通過過往經(jīng)驗評估成本及步伐

?愿望收集：不斷收集建議及愿望，一步步實現(xiàn)

?傳播布道：不斷參與行業(yè)交流，提高理論及技術(shù)知識科普分享團(tuán)隊

5、架構(gòu)師職場攻略

《大型網(wǎng)站技術(shù)架構(gòu)+核心原理與案例分析》總結(jié)：

架構(gòu)師需要處理好個人、團(tuán)隊、公司的利益。需要不斷的在工作中發(fā)現(xiàn)問題，解決問題，提升工作經(jīng)驗，知識技能和核心競爭力。擴(kuò)大自身影響力，達(dá)成工作績效。

1、發(fā)現(xiàn)問題，尋找突破

即使在一流的技術(shù)團(tuán)隊，也有數(shù)不清的問題，團(tuán)隊人員已經(jīng)習(xí)慣這些積重難返的問題，而且解決問題投入產(chǎn)出比不大。例如：

1）數(shù)據(jù)庫線程池存在安全漏洞。

2）版本管理混亂。

作為一個新人，從局外旁觀者的視角看待，自然發(fā)現(xiàn)很多問題。如果新人急于表現(xiàn)自己，證明自己，往往是事與愿違，四處碰壁。因此新人要先融入團(tuán)隊，和團(tuán)隊共進(jìn)退，等熟悉情況，了解問題深淺，再尋找突破口，擇機(jī)而動。

2、提出問題，尋求支持

1) 把“我的問題”表述成“我們的問題”：

人們都不喜歡問題，問題意味著麻煩。當(dāng)人們聽到你說，“我遇到一個問題的時候”，下意識的遠(yuǎn)離你的問題。 如果需要他們的支持，就想辦法把你的問題變成他們的問題，是他遇到了問題，而你來幫忙解決。

既然你也是團(tuán)隊一員，問題表述為“我們的問題”。

1) 給上司提封閉式問題，給下屬提開發(fā)式問題：

上司一般是做決策，因此給上司提問需要給出建設(shè)性的方案或者建議，然后希望得到他的支持，給上司提問：“你覺得A和B哪個方案更好？”

給下屬則相反，用開放式的問題啟發(fā)他去思考，尋找創(chuàng)新的解決方案。“元芳，這個問題你怎么看？”

3) 指出問題而不是批評人:

如果遇到問題，不要責(zé)問他為什么出現(xiàn)問題，而是說問題的緊迫性和解決的優(yōu)先級。

4）用贊同的方式提出問題：

如果人們遇到：“你這里有問題”可能會本能自我保護(hù)而拒絕你的建議。

而如果這么說“我非常贊同你的方案，但是我有個小小的建議”。

3、解決問題，達(dá)成績效

在解決我的問題之前，先解決你的問題：

適當(dāng)?shù)奶颖軉栴}：比如我去開個會，回來再回答的你問題。

做好以下幾點，基本離你說的移動架構(gòu)師不遠(yuǎn)了

選，Java后臺還是客戶端開發(fā)？

Java跟C、C++、PHP、Python等一直較勁，在當(dāng)前的現(xiàn)實中，也穩(wěn)坐編程語言榜首

面向?qū)ο蟮乃枷朐趹?yīng)用開發(fā)領(lǐng)域占主導(dǎo)，Java往往成為其代名詞

Java技術(shù)的人多，一直以來也有大公司資助，所以發(fā)展一直不錯，進(jìn)入了良性循環(huán)

從企業(yè)的角度來說，找Java后臺的人相對比較容易

后臺被認(rèn)為是技術(shù)核心，而客戶端，被認(rèn)為技術(shù)含量不高

貪省事，讓Java后臺的架構(gòu)師順便來一下客戶端幾個人就好了，這可能是有些企業(yè)負(fù)責(zé)人自然而然的想法

客戶端技術(shù)和后臺技術(shù)的側(cè)重點完全不同，連編程語言都不同。Java能統(tǒng)一后臺開發(fā)；但是從目前的趨勢看，雖然客戶端也在強(qiáng)調(diào)統(tǒng)一，不過語言肯定不是Java

Java后臺的人跟用戶離得太遠(yuǎn)，與產(chǎn)品人員溝通，那真是雞同鴨講

如果產(chǎn)品真的是為了給用戶用，那么選客戶端背景的人員做移動架構(gòu)師要好一點。

客戶端是IOS，android，還是JS，根據(jù)企業(yè)喜好來選吧。根據(jù)本人經(jīng)驗來說，當(dāng)然是IOS啦。智能手機(jī)這么熱，是誰帶起來的？從編程體驗，程序美感來說，誰的最出色？只要干過移動開發(fā)的人，這幾個問題都是不言而喻的

作為移動架構(gòu)師，要重點注意的三個問題

架構(gòu)師作為中層管理，直接領(lǐng)導(dǎo)一般是總監(jiān)了。技術(shù)加管理的綜合職位，在技術(shù)和管理上面的思路，跟總監(jiān)要保持一致。這方面是最重要的。如果這點做不好，趁早換地方，不讓對自己，對總監(jiān)，對企業(yè)都不好。有兩種情況需要注意：一種是跟總監(jiān)合作很好，但是總監(jiān)自己要換地方；這里，最好和總監(jiān)一起走，能遇到一個好領(lǐng)導(dǎo)不是一件容易的事。另一種是空降一個總監(jiān)過來，但是兩人想不到一塊去。這個時候就有點糾結(jié)，離開嘛，感覺舍不得，前面的付出要泡湯；留下嘛，感覺又很別扭。這種情況，需要加強(qiáng)溝通，調(diào)整自己，努力使合作更順利一點。否則，還是要走，畢竟胳膊擰不過大腿，估計大家都懂的。

跟周邊部門的合作要做好，特別是產(chǎn)品和測試，運營也要注意一下。否則，將會導(dǎo)致很多稍大公司的部門墻。

跟具體的開發(fā)人員也要搞好關(guān)系。管理的本質(zhì)是自己不干活，但是團(tuán)隊的整體效率要更高。這點如果做不好，最直接的影響就是團(tuán)隊的績效不高，團(tuán)隊缺乏凝聚力，團(tuán)隊氣氛壓抑。這在很多公司都有發(fā)生。

如何與總監(jiān)CTO合作好？

從思想上認(rèn)識到，兩者是利益完全一致者。總監(jiān)為架構(gòu)師拓展上升空間，而架構(gòu)師將總監(jiān)的規(guī)劃切實落地。

保證足夠的溝通，可以約定一個固定溝通機(jī)制，比如每2周一次。讓雙方在思想上保持同步和一致。

如果CTO也是客戶端技術(shù)出生，那么架構(gòu)師可以多探討一些技術(shù)經(jīng)驗，將CTO的一些技術(shù)構(gòu)想落到實處，同時自己也能在技術(shù)上獲得提升。

如果CTO是Java后臺技術(shù)出生，那么CTO盡量授權(quán)，架構(gòu)師側(cè)重在設(shè)計思路，技術(shù)可行性，技術(shù)風(fēng)險等較高的層面內(nèi)容。

架構(gòu)師應(yīng)該帶著方案和CTO溝通，講清楚AB方案的優(yōu)缺點。可以讓CTO來下決心，就算是架構(gòu)師下決策，也要獲得CTO的認(rèn)可。

如果意見出現(xiàn)分歧，最好的方式是先擱置，等條件成熟了，很可能意見會趨于一致。如果不能等，只要CTO的意見不是太離譜，還是按照CTO的意見執(zhí)行比較好。如果有十足把握，自己的方案更好，那么也要得到CTO的許可和諒解，否則千萬不要這么做。

如何與周邊部門合作好？

產(chǎn)品經(jīng)理一般不懂技術(shù)。架構(gòu)師的作用就是幫他解決這個問題。在理解了需求之后，要進(jìn)行技術(shù)可行性分析。從技術(shù)的角度，提出改善意見。在不改變整體方案的前提下，修改設(shè)計，方便實現(xiàn)。這就需要產(chǎn)品經(jīng)理和架構(gòu)師的合作。

與后臺架構(gòu)師搞好合作，從后臺到實現(xiàn)，整條鏈路太長，一個人管不過來，需要兩人好好合作，共同把好技術(shù)關(guān)。

測試，要當(dāng)作開發(fā)的朋友看待，是自己人。可以考慮讓測試人員在“自測”階段介入，幫助開發(fā)人員提供測試案例。

運營，關(guān)系稍微遠(yuǎn)了一點。關(guān)鍵點是及早介入，不然，到臨上線了，要加入一對的運營需求，就可能影響產(chǎn)品投放時間了。

總之，和周邊部門，應(yīng)該以合作為主，及早溝通，將風(fēng)險消滅在反生之前。

如何與團(tuán)隊成員溝通

移動開發(fā)團(tuán)隊人數(shù)不多，但是角色和開發(fā)語音多。有IOS，android，還有JS和Java網(wǎng)關(guān)。

如果一個角色超過3個人，那么就應(yīng)該設(shè)置一個TeamLeader，進(jìn)行授權(quán)

對于自己擅長的技術(shù)，要分一兩個任務(wù)給自己，和兄弟們一起戰(zhàn)斗。中層人員需要在一線。

對于自己不擅長的技術(shù)，可以采用“結(jié)對編程”的方法，逐漸進(jìn)入角色。程序基本是相同的，還是能夠理解和參與討論的。

對于幾個Leader，要重點溝通，在大方向上保證思想一致，給他們空間，協(xié)助他們做出成績。

重點注意團(tuán)隊的正能量以及活躍的氣氛，人不是機(jī)器。和諧的氛圍比冰冷的制度和懲罰要好得多。

記好團(tuán)隊的功績和成果，提高團(tuán)隊成員集體榮譽感，將奮斗目標(biāo)引導(dǎo)到“自我實現(xiàn)”上來。

關(guān)于技術(shù)

整體上是一專多能

以IOS技術(shù)為主，跟上蘋果的節(jié)奏，隨時學(xué)習(xí)新技術(shù)。深度技術(shù)按照需求來。

Object-C為主，畢竟在用，并且成熟度高。

Swift也要學(xué)，這是蘋果的未來。

Java要優(yōu)先學(xué)，android和后臺都要用到

JS也要學(xué)，最近H5勢頭比較猛

總之，架構(gòu)師是一個綜合素質(zhì)的體現(xiàn)，打鐵還需自身硬，能解決問題，或者能帶動周邊的人解決問題，才是關(guān)鍵，至于職位、位置，這只是一種職業(yè)稱謂，你牛逼了，還在乎別人稱你架構(gòu)師，還是其他的嗎，技術(shù)是硬實力，情商是軟實力，君子性非異也，善假于物也。自個體會。