tags: 網頁開發流程討論事項

網頁開發流程討論事項

1. 軟體開發流程必須要大家有一個共識, 要不然barry會一直用硬體的思維去思考軟體開發, 這樣會一直重工or先後順序不對

2. 軟體界資深的朋友討論, 他們都一致認為我們公司是硬體廠思維, 沒有軟體開發思維很有問題一定要調整

3. 帶領公司從硬體轉到軟體思維, 這會有一個陣痛期, 昨天跟資深軟體工程師討論他們公司的狀況, 不瞞你說他們是科技硬體大廠, 他們也要做軟體轉型, 他們公司投資在轉型這件事已經10年了, 他們的優勢是他們資金夠大可以慢慢調整, 但缺點是因為太大所有轉型雜音很多備受質疑, 但達翔的優勢在於公司規模為中型, 所以調整可以比大型公司較快較有彈性, 但缺點是資金要用在轉型可能資源會比大型公司來得少, 也是因為這樣我想知道barry了解這些背後資源運用跟轉型的痛點到什麼程度？還是說他了解跟實際層面的有落差

---

3. 畫面的東西沒有跟RD討論就修改, 也不知道對不對的做法會有做白工與溝通上的問題不斷地產生 這點必須要跟PM溝通清楚

• 修改前會跟RD討論再修改

4. PM外出事務太多會有無法真實討論畫面問題, 需要與PM討論都找不到人, 並希望PM統一修改畫面而不是大家分著畫, 這個問題點會有多頭馬車，亂掉的問題, PM要明確列表告知RD修改的部分(分成幾點項目這樣), 可以節省掉RD要全部再重新看過設計稿修改也容易造成沒注意到的修改部分(WEI)

• PM修改畫面後會列表修改哪些項目

5. UI/UX畫面邏輯, 資料邏輯, PM需求規劃要明確, 一開始就要定義好,不要突發性的增加需求,然後與RD討論技術是否能夠做到, 能做到什麼程度, 哪些需要survey？(WEI)

• 可以

6. 時間排程需要PM與RD討論才訂時間, 要不然達成機率也不高(WEI)

• PM討論需求回來要問RD能不能做, 以及需要多少時間再回報PM

7. 討論會議目的要明確, 開會前告知開會內容, PM要有會議紀錄並且要寫結論(WEI)

• 開會資料會提前一個禮拜給RD消化內容

8. 有任何改動(畫面, 邏輯, 需求)後要給RD時間(大致上3~4天, 因為RD手上也有進度在進行)了解修改內容, 不要開會前才通知要討論異動(不要改完前5分鐘or 10分鐘才說要開會, RD根本就來不及消化修改內容)

• 開會資料會提前一個禮拜給RD消化內容

9. 對報告內容有共識, PM對專案掌握度要高, 可以依照notion當報告依據, 如果需要RD報告則在前一天開會要先通知準備以利進行

• 同 7.會在會議前一個禮拜給RD

10. 資訊不對等問題, 與議題相關的人員需要被通知到

• 比方說討論的議題有前後端, 則需要讓前後端人員事先知道

11. 開一個專案group

• 任何資訊可以同步(延遲會議, 畫面, 邏輯)
• 可以

12. 看別人的展覽軟體做到什麼程度？

• 打給內部人員直接拿廠商證