程式開發的過程中，其實我們會發現有一些人是屬於很快就會了解程式的內容，還有某些模組的拆解方法，同時也會發現某些人可能比較擅長於快速開發和快速將一個雛形產生出來，有另外一種人對於新工具或者是新的技術可以很快的了解，應甚至是導入到團隊當中。

其實團隊每一種開發人員都應該要具備，同時最重要的是『俱備一個開放的心』，還有保持學習與熱情。

當然回到專案結構本身，其實還是需要找到原有的核心架構， 才能夠讓團隊和其他工作成員一起協同合作進行開發。

很多時候我們會覺得程式架構定義這件事情應該是『程式架構師』或者是『資深開發人員』來進行。

但是就自己的經驗來說定義程式架構這件事情，可以分成幾個階段來看，

『草創時期』

這一開始的時候，可能大家對於軟體開發並沒有太多頭緒，或者是對於產品本身並沒有太多的想法。

這個時候會建議，如果沒有足夠的經驗，或者是足夠的深度去了解自己適用於什麼框架的話，會建議從 github 開發專案，找一下適合自己的專業模式或者是專案內容。

畢竟 github 這邊充滿了許多大家已經搭建好的基礎架構，至少會讓自己省去探索的時間，直接進入到產品開發階段。

『小團隊時期』

當產品開始成形的時候，或者是人員開始招募進來，一開始會是以小團隊的方式進行工作。

這個時候身為先進人員或者是比較開發資深的人員，必須要試著將原本的產品進行分工。

這邊的分工是指讓人員之間可以分別進行工作項目，同時又不會巨大的影響到對方的進度。

接著人員和人員之間也不會有互相等待的狀態，當然在這段時間可能對於不擅長分工，或者是不擅長團隊開發的工程師，來說會是一個十分巨大的挑戰。

但是我會建議這個時候，身為核心成員或者是資深開發人員，必須要一肩扛起這個責任，帶領著小團隊合新進人員一起並肩作戰。

別讓團員們覺得有落單的狀況，或者是覺得重要的任務都在老鳥的身上，自己在這個團隊面並無輕重也沒有任何的著力點

『團隊擴編時期』

剛到了這個時候其實程式架構需要再來重新檢視，畢竟到了這個時候正式或者是軟體架構可能已經達到一個程度了。

我們會建議必須要重視自己的產品，還有去重新檢視框架的內容，甚至是去調整模組，必要的話還需要去改善之前所寫出來的程式碼。

相信這個時候對於程式的重構會是一個十分龐大的負擔，但是就以產品發展的狀態來講會是一個最健康的方向，當然這個時候專案管理人員必須要創造出來空間，還有時間，讓團隊可以進行重構和重新檢視整個程式的架構。

ＰＳ。前提是在允許的時間之下還有製造出來的空間之下，畢竟公司還是會有自己的壓力有新的需求會湧入也有新的業務需要去被執行。

回到架構本身，這個時候對於架構最清楚的莫過於實際開發的人員，反而這個時候我會建議透過開發人員得分享還有開發人員的經驗，才能夠找出最關鍵或者最核心最迫切需要被改善的內容。

和他們通常可以舉出十分完整的修改方案，還有調整方向，讓這個產品可以提高彈性架構還有提高接下來面對業務考量的挑戰，變化性。

所以到了這個階段大家必須要相信自己的成員，也需要去重用新進人員意見，這個時候的新進人員反而對於程式架構或者是系統架構的評估會更有建設性的幫助，新進人員可以從一個局外人的角度幫忙跳脫框架去進行破壞性的創新。

當然最後，還是希望身為專案管理人員，可以將程式架構這件事情分散出去給其他人，或者是專案的相關人員一起了解。

一個人如果對於架構很強，或者是架構十分熟悉，對於整體開發其實用處還是有限度。

如果全部的成員都對於架構或者是軟體的規模都十分清楚，那大家在開發的時候就會更有品質同時在進行程式調整的時候也將提高他原本的彈性。

希望大家都能夠保持一個開放的心態接受新的任務和新的挑戰，同樣的問題在團隊不同時其實會有不同的狀態，希望大家都能夠好好探索自己的角色位置，同時讓產品可以越來越好，讓自己的工作流程越來越順暢。