開發人員喜歡什麼樣的架構師【轉】

某SE從國內某著名電信IT企業空降過來，而且在C++領域 有着10幾年的開發經驗。估計是作電信軟件的，經驗豐富，電信軟件那一套高可靠性，高性能玩的很熟。來了以後作JAVA項目，但JAVA畢竟不是C++，咱們的領域也不是電信，這一套武功所以失去了大半功力。

 

在C++領域，絕不客氣的說，不少人的視野偏窄的，這根C++項目長久以來的穩定性有關係，在電信業需求更爲固定，尤爲是平臺層，需求多基於協議；但在行業軟件開發中，需求不少狀況下不明確，並且需求分析師這一神聖職位不少時候被SE兼任，因而SE就用他專業的眼光梳理需求，創造需求，和曲解需求。

 

開發人員欣賞的SE的技術眼光必定是要廣博，尤爲是要有至關的技術儲備，緊跟行業趨勢，瞭解最新的框架，開發思想等，不能臨時抱佛教，查百度，這樣才能給開發人員指導，輸出的規格也能更加貼合實際。

 

除了技術眼光，SE在本領域內的業務也須要是專精的，在某種程度上，要更加劇要於技術水平，技術的問題開發人員能夠解決，但在需求，場景上，因爲着眼點的不一樣，開發人員很難窺得系統全貌，這時須要SE理清需求，理清思路，咱們詢問SE，固然不但願聽到「這樣吧」，「我認爲」，「先這樣了」這些模凌兩可的答案，開發人員更但願獲得肯定的，自信的答案，這也是咱們信任SE的關鍵。

 

在溝通上，某些SE每每走向兩個極端，在面對項目經理及其餘SE評審多接受；面對開發人員的質疑，多采用壓制態度。根據個人觀察，採起壓制態度的SE會致使更加頻繁的設計變動， 由於開發人員提出的問題每每是細節的，甚至是繞不過的。

 

某些SE喜歡把規格寫的無比詳細，具體到類，方法，甚至參數，其實在規則中的東西，真正能進入開發人員意識的並很少，尤爲是長篇大論的場景式描述，關鍵信息淹沒文字中，你們都是成年人，閱讀能力沒有問題，開發人員應當熟悉場景，但不該該分析場景，場景的分析和具體化，應該由SE給出的。咱們但願見到的規格是：場景描述+AR點。

 

規格評審完畢，SE BOSS贊成了，或者是厭倦了；開發人員明白了，或者是乾脆不想明白了，總之，項目進入了開發階段。這時候，SE還債的時候到了，之前沒有想到的，或是規格中沒有描述清楚的，或是先後矛盾的，會有開發人員頻繁的過來澄清。爲何叫澄清，這個詞太好了，由於本來是渾的。

 

另外，好的SE是必定要帶有光環的，相似於升級遊戲，或者叫作信任疊加。

 

後記，該文轉自園子裏面一位哥們的，做爲一個SE，以爲其中部分的見解有些許道理，轉過來，自勉一下。

轉自：http://www.cnblogs.com/jiyuqi/p/3165185.html