第一次開始開發產品時，包括我和開發團隊都是第一次接觸敏捷開發。相較於傳統的瀑布式開發，這種開發方式強調快速反饋和不斷調整，以降低開發風險。所以開發團隊需要更緊密合作，不斷迭代和優化產品。
然而，這也帶來了一定的時程壓力。我們需要在短時間內完成多次設計和開發的迭代，以避免延遲產品上線的風險。
在這個過程中，透過和產品經理的密切合作，如何在時間壓力下做出更好的決策，並選擇最優的方案來推進產品開發。我們也學會了如何在不斷迭代的過程中保持產品的品質和一致性。
由於敏捷開發強調快速反饋和迭代，因此通常不會花太多時間在開發前期的規劃上。因此初期並未花太多時間做 flow chart 與工程端確認、但產品經理會確保團隊成員皆能了解每個代辦項目的目標與實行方案。在開完會後確認設計稿沒有流程或邏輯上的錯誤後便進入開發。
討論 → 設計 → 開發 → 實機測試 → 反饋（循環）
剛開始，我們將目標族群定為台灣中小企業的辦公族群，團隊為了分析目標使用族群的行為模式制定了Persona人物誌。
這份人物誌含有4個虛構角色，這些角色代分別為在中小企業可能會接觸到我們產品的角色，例如HR主管、會計主管、經營者、年輕的創業者。我們在制定這些Persona時，考慮了他們的人物特徵、職場角色、需求、價值觀和行為模式等方面的特徵，以此來更好地了解他們的需求和使用習慣。透過這份人物誌，我們能夠更好地設計和開發出符合中小企業需求的產品，並更好地了解他們的使用行為和習慣，以便優化我們的產品。同時，這份人物誌也能夠幫助我們的團隊更好地理解我們的目標使用族群，進而更好地協作和合作。
由於後台系統多為表格呈現資訊，如何設計表格保持系統的一制性會是很重要的議題。除了考慮到易讀性之外也需要設計不同資訊排序以及篩選的方式，在設計表格時也會考慮到後端資料庫的問題。因此在開發前期會非常頻繁的與團隊溝通，以確保系統的一制性和團隊共識。
由於開發時程受到壓縮，產出 MVP 的時間僅有一年，因此如何快速的掌握商業邏輯與評估需求是本次開發最重要的部分。
這不是我第一次從0-1開發產品，但卻是我第一次完整體驗從設計到開發再到上線的完整流程。雖然過於龐大的需求導致產品無法準時上線，但團隊在短時間內扛住壓力一起完成開發的經驗也讓我學到不少。
由於產品的功能過於複雜，除了原本就有相關資歷的PO 能快速入門，但相對於開發團隊，有許多流程細節在一開始並不完全了解。因此在設計前期，如果能先讓設計師與其他PM釐清設計的流程、與高層、利害關係人釐清產品開發的目的，針對市場需求能做足事前研究，後續開發會更加順利吧！