專案 Demo 前的準備、細節、技巧
你費盡千辛萬苦與夥伴完成了這份專案,明天就是展示你們成果的時刻!但如果你在 Demo 前忽略了這些細節不但會影響發表的成效,如果發生嚴重意外甚至會影響到你的考績與年終;為了確保每次 Demo 的水平,這篇文章會列出筆者過往 Demo 時遇到的問題及解決方案。
TOPIC ・ 主題
Teamwork
帶團隊、做專案、跟人協作的實戰心得:溝通、設計思考、專案管理,以及在職場上最常踩的坑。
共 60 篇文章
你費盡千辛萬苦與夥伴完成了這份專案,明天就是展示你們成果的時刻!但如果你在 Demo 前忽略了這些細節不但會影響發表的成效,如果發生嚴重意外甚至會影響到你的考績與年終;為了確保每次 Demo 的水平,這篇文章會列出筆者過往 Demo 時遇到的問題及解決方案。
如果公司的專案很多,README.md 又沒有寫好,那後續接手的人會非常痛苦;如果公司專案的規模很大,README.md 又缺乏維護,那這個專案已經半隻腳踏進棺材。
前幾天跟擔任 Engineer Manager 的朋友聊天,在任務分配上他給我提供了一個全新的觀點:「給 Junior 工程師進階的任務,讓 Senior 工程師做基礎的任務。」這個違反常理的任務分配讓我十分不解,因為這樣的安排容易導致專案交期的延宕,甚至 Bug…
Archive全部文章
在多人協作的開發過程中,我們通常會需要透過 Merge Request 來進行 Code Review。 但這時會遇到一個問題:「每個人對專案的認知有差異,且文字表達能力不同。」 這會導致 Code Review 的人需要花更多的時間來理解程式,甚至浪費寶貴的時間在溝通上。
很多人在接案時,會覺得專業能力與報價應該成正比。 但實際上,在累積一定的接案經驗後,繼續提高專業能力,並不會增加你的議價空間。 因為大部分的客戶並沒有那麼高的要求,你也許有 90 分的實力,但客戶只要 70 分的結果。 那麼在遇到瓶頸後,我們可以用哪些方法提高報價呢?
說到管理,很多人都覺得這是主管才需要學習、考慮的課題。 但其實不管團隊、專案還是作品,都是需要被管理的。 如果一切都靠本能去做,那麼團隊沒有方向、專案延遲交付、作品四散各地…這些可說是必然發生的悲劇。 就算為了減少自己的加班頻率,我們都該對「管理」有更深一層的認知。
說到「設計」,大家第一直覺可能都是想到「視覺設計」,所以要好看。但有時設計是為了「解決問題」而誕生,因此這篇文章想透過業界的實際案例,從不同角度跟大家做個討論。
只要是人,都有他過去的歷史、情感、困惑、強項… 面對不同意見時,許多人並不是用「引導」,而是要對方「按造自己」的想法做事。 若涉及自己的專業領域,我們更容易選擇後者,但話說出口前,我們不妨思考幾個問題…
我的本職是工程師,然後斜槓作家/講師/部落客。 我學設計的初衷並不是為了成為一名設計師,而是在培養自己對美的觀察力,以及與設計師溝通的能力。