9/22 更新
先謝謝各位前輩的建議，我每則都有看
然後我把這件事跟我的工程師朋友討論（他現在是小主管）
原本是想了解其他人是怎麼做的
沒想到卻意外拿到可能可以面試的機會，他說他滿清楚我的能力
要幫我推薦是完全沒問題的，就看我要不要投投看履歷
所以沒想到這件事意外讓我有新的面試機會 lol
沒意外的話可能真的會想去外面的世界多看看了....

直接問就好

工程師原本就是溝通吃重的工作，只照著 spec 開發完全不溝通那是碼農等級

小公司本來就是這樣 習慣就好

人數不夠就是你做阿

1.換工作 2.拿職位(PM)+提加薪 自己選一條吧

也沒幾個人 總有人要做整合覺得薪水不夠就要加薪 加不了就走人

其實有一個解決方法 就是api和設計都自己來，給你參考

我覺得只是不夠敏捷 可以把大功能拆解

我也知道溝通很重要，但我覺得老闆應該要在他自己 Review的時候就應該要發現一些問題然後退回去給設計師和後端真的很細節的問題可能要等前端整合以後才會發現我就覺得沒關係，這很難免但我現在體感是，他可能只有大概看一下，就丟過來了

台廠日常：隕石式開發和通靈式開發

就是沒個pm吧

你怎麼會期待PM會好好review?

review 一直都是當事人做才能降低代溝，你該解決的是怎樣的合作模式可以降低修改機會等。以 api 來說，是不是可以反向變成你開 spec；以設計來說，是不是可以增加假互動畫面的設計步驟來降低變更機會

SA/SD溝通上很重要，建議找主管出來扛個責任

所以最好的建議就是請老闆找一個PM來管事嗎XD回 A 大，確實你說得對，但我的意思是像設計稿畫的東西結果資料庫一開始就沒有，這種真的只要花一點時間檢查就能發現事情，理論上應該不是到了我這邊才被發現所以我才會說老闆可能真的只是大概看一下，就 pass api和設計稿了甚至在規劃功能的時候應該就要知道這件事了

個人經驗是只能靠自己多協調,讓設計的時候就考慮到文案的問題

找PM協調是一種方案..但畢竟是新創我覺得老闆設計師後端都要有更多的產品心態關於需求這麼做會有什麼問題？會有操作問題嗎？權限問題嗎？什麼樣的情境會遇到什麼需求等等看你例子設計師和後端都是需求來就解沒有很深入去思考可能的情景這種壞情況就是開發流程最末端那個人最倒楣

好像真的是有這樣的感覺，也就是設計師和後端應該都只是老闆說啥他們做啥，沒有往後想更遠導致

至於資料庫欄位和畫面對不上問題如果「後端工程師也有和設計師開會」那就是他的鍋..對 後端的鍋在新創的環境下後端本來就要有看畫面思考可能對應欄位的能力當然前後端也要討論溝通比較好

然後老闆也是只有看到表面上的東西，沒有仔細想過整合在一起會發生什麼事

覺得累就辭職，如果老闆是個明君，公司有前途，且你也有野心就繼續做。有天老闆會發現根本不能沒有你就成功了。

我最近也才比較有跟設計師聊天，她也是大概說一下沒有UX就直接設計她覺得很恐怖，沒看過這樣的流程聽起來設計師也覺得心累但我也不太懂真正好的設計流程應該是長怎樣，所以我也只能聽聽她抱怨而已

回到我前面說的產品思維的能力本來新創就是要思考各種潛在情境不管是什麼職位都是職位只是決定在電腦前產出的形式如果你是在有談到配股的新創可以用股東身份和老闆深入聊聊為了公司一起成長應該還算可以但如果你是沒股權的建議有機會就走

好的，謝謝建議，我是沒認股的，但薪資還不錯所以已經待了一陣子了

跟我以前做的事好像XD~這個就是公司的同仁沒有心...

設計師也待了一陣子，只是平常沒什麼私下交流，是最近真的很爆炸才開始關心工作狀況，才知道原來他也很不滿意開發流程….

mock資料先做好跟後端應該會好溝通很多。

長此以往會讓公司的士氣下降

我會做好mock資料，所以我過去前端先動工刻畫面後接api發現問題可以很快的跟後端和老闆說功能小的時候還可以，這次要做大功能以後我幾乎每個畫面都會把api退貨，因為欄位對不上…但退太多了心就會很累，我甚至上週幾乎都在發呆，因為我前端能做的都做了，剩下的都是在等被我退貨的api還有一部分原因是我發現 flow 有問題，回去問老闆該怎麼辦，結果老闆直接把規格大改..所以後端也整個大改我當時看後端聽到要大改規格的臉也覺得他很可憐..

本來就要有一個能掌握全體系統架構的角色一般公司在前後端上面會配一個SA/SD做整體規劃如果沒這個人就看前後端哪邊要坦另外我覺得你可以在現職磨練一下並向老闆提出接手整體系統規劃與把關會思考是一件好事

我們確實沒這兩個角色，但我以為理論上應該是老闆坦…畢竟產品一開始是他自己開發的，只是現在找了我們擔任他的手腳，他轉為規劃產品走向與開出產品規格的角色

老闆在忙著生錢 角色轉換的技術脫節是很正常的

沒有 user story？

所以綜合上述，我感覺好像沒什麼東西能建議老闆lol

上線前連 sanity test 都沒有？

只能祈禱同事慢慢學會 push 自己，要不然就是我跟老闆推薦自己下去幫忙做系統規劃

是不是未來公司CTO就看這波了

回 c 大，當然會測試，所以我那段什麼都不說直接照錯的設計稿接也沒人發現是自己心裡開玩笑的，我當然不敢這麼做，實際上是我這關就會發現很多問題並回報了所以老闆最後上線前測試的時候有越來越懶惰的趨勢lol 因為他滿信任我的東西，他知道我整合的過程就會解掉很多問題了，而且也都有找他討論目前在線上的東西都蠻穩定的，流量跟營收是穩定成長中，所以可能以老闆視角出發會覺得我們團隊 run 得很成功吧但他可能不知道我們已經開始心累了，甚至想開履歷了

你覺得公司有未來性嗎?未來三年有大幅成長的空間嗎?假如給你十個人 有沒有辦法大幅優化或做技術突破?有想法就找老闆談 薪水是談出來的

老實說我不知道有沒有未來性耶，因為我終究是別人的手腳，產品未來三年會怎麼走我真的不曉得，我們老闆想法迭代的很快，一直在嘗試不同的mvp至於技術突破應該也不行，我自認我的程度還在 junior，我們要做的東西根本上技術不難，只是商業邏輯複雜需要好好規劃規格，然後我只是比一般人細心而已，很會抓漏洞

你們老闆都自己跟市場接觸 沒帶人一起嗎?不然你自告奮勇跟老闆一起出去聊聊 說要改善UX感覺在你們公司純前端你已經沒有突破空間了如果覺得還想繼續做純前端技術的可以開履歷了

老闆要做新的mvp的時候當然都會跟我們說明為什麼要做啦但我每次聽完也沒什麼感覺XD 無法預知會不會成功就變成反正老闆要啥我做啥，至於會不會成功上線了才知道

那MVP做出來是到哪裡pitch?

我們有一個主平台，mvp就是一些新的服務，上線了以後我們主平台會有地方 promotion ，另外還有行銷團隊

那上線之後市場是怎麼給feedback的?

那我們定義的成功大概就是這個mvp為我們主平台帶來一波新的流量與營收，當然也有很多上線以後乏人問津的

你們產品缺乏從使用者行為了解MVP改善空間的回饋機制還有怎麼越看越像博弈啊 錯覺嗎

不是博弈喔，但確實市場 feedback這塊我們好像很弱，目前大概就是用 GA看流量和營收成長當基準吧…

Feedback設計這塊是前端往產品與架構走的關鍵

我好像曾經聽到我們行銷團隊的人問老闆說，怎麼知道平台這樣改對我們是好的。當時老闆回答更多時候他是相信他自己的判斷，從那以後我發現老闆可能也是靠直覺做事的lol

開履歷吧

XD….這個夜晚受益良多，感謝各位前輩這篇文可能也不敢放太久，我怕被老闆或同事看到，雖然沒打名字但感覺從很多事跡上來看可以猜出是我打的lol

什麼職缺做什麼事 你要逾越 這件事以後就是你的工作

放心，還有100家公司是這樣做事的流程是為了解決人太多溝通困難而產生的，你們才4個人，根本還用不到流程，真正有問題的是人

因為沒人想當壞人不然就是廢，你們才4個人，我覺得廢的可能性比較高

很單純，就是後端太菜，沒有把資料庫的table欄位都記得，才會有這樣的問題

其他人可以不管 但是跟後段一定要溝通通常帶頭檢查的應該是後端才對

你們需要一個專職PM 很多小公司都老闆兼PM 殊不知其實PM溝通的工作量超大的，被PM放生就是這種感覺，大家都會很痛苦，看老闆有沒有意識到吧

所以問題根本是資源少、然後同事不夠細心、老闆又沒時間管我們嗎lol

資源少不少不知道，只是產品一大就會發現PM有多麼重要，可能前面都小產品開發，幾個人工作分一分可以過得去，現在明顯看起來就是力不從心，可能無力分或也不想分了雖說新創是個很好可以練自己的機會，但我一直不提倡工程師花太多時間處理PM的事情，本職還是要回到好好開發

我說的資源就是人力意思啦XD 因為我只是闡述開發團隊遇到的事情，我們還有行銷、業務等等，他們人比我們還多lol

否則工作上會很沒有成就感，一直覺得自己在做份外的事情

其實我覺得你們流程看起來沒啥大問題啊

沒名沒份的搞不好同事也不感謝，心理上會很受打擊，對工作的心理健康很不好，很多人都忽略了心理健康這點

你講的這些問題你行前會沒發現嗎

喔對啦，這樣算的話就是沒人力沒錯

擺爛或放大問題(拖開發時間) 老闆受不了自然會出來解決

行前會的時間點是設計完成並且老闆 review 過後沒問題才開的，那既然老闆都看過了我當然都會預設設計稿不會有什麼大問題，就算真的有也是很細微的那種

內心戲不要那麼多，就事論事直接講就好，老闆也不會希望專案出包

做好你份內的工作啊,有錯就回報,但這些問題點要記錄下來之後可能會有檢討大會,如果被說時程延誤,就可以拿來保護自己

沒有最好的流程 只有最適合的流程

只是隨著被雷的次數增加，我現在確實在行前會的時候就會一邊開會一邊自己仔細看設計稿，至於後端的問題..就不可能在行前會知道了吧lol 行前會的時候大家當然都是說好好好，但最後欄位怎麼給才是真的

你們聽起來後端蠻重要的耶，為什麼一開始不把後端叫來開會啊?

4人團隊溝通起來跟40人一樣…你們看起來就是每個人對目標的理解不一致 看看跑敏捷會不會改善吧

1. 文案應該在 kick off 前就確稿2. Api format，應該由後端+前端與設計開會決議，並請後端先提供 api mock data docs

有個問題是為什麼api有問題你不直接跟後端講，而是要經過你問老闆老闆再要求後端這個流程？問題搞不好是流程太多，四個人搞得跟四個部門一樣

你們需要一個PM以前也是沒PM 這樣的走法 現在弄了一堆債要救…

覺得後端居多 因為 DB 欄位不可能是 f2e 管的

（1）在前後端開始implement feature 之前先拿到apicontract（2）夠信任backend 的話就自己mock ui data下去implement,不信任後端的話就請他們提供mock api (3) 預留時間做integration test 和end to end test還有bug bashing另外design doc 應該是feature開發前就應該寫好的？

沒有sa嗎，後端或你老闆要兼sa的工作吧感覺後端比較雷吧，很難想像少欄位後端開發會不知道

這種小公司最佳解就是兩個人都做全端 照功能分

流程沒問題 有問題的是人

前端本來就算是一個橋樑的職位，加上是使用產品的第一線這種狀況在小團隊多多少少會遇到

我覺得你可以找老闆討論一下工作認知～因為這個「最終核對，幫忙把關」是誰要負責做，其實沒有一定，老闆很可能覺得你很棒都幫她做掉了，可是你卻一直覺得老闆沒把他工作做好...結論就是和老闆討論，你其實不喜歡抓這麼多錯誤，然後你們協調未來怎樣調整會是大家都開心，解法很多種喔，選哪種是看你們這幾位利害關係人各自想要的和不想要的是什麼，都可以談的，沒有什麼「應該」要誰誰誰負責，我就列出幾個可能選項(1)老闆了解你的痛苦、他也有時間，於是他決定以後審核後端PR更嚴格(2)老闆覺得他沒空看細部東西，他覺得你幫他看很棒，他說服你把這部分把關的工作正式變成你的工作，並且他幫你升職為team lead也幫你加薪(3) 老闆沒空幫忙看，他其實也覺得你退回太多次，是這位backend太雷，做事都不仔細，於是他換一個新的backend(4) 老闆沒空看，他也認同這花你太多時間也讓你空等，也讓backend要重做，於是他接受你的說服，決定從此以後再多一個文件的步驟，backend在動code之間要先把db schema&api input output寫在document，並且開第二次行前會（第一次行前會審ui流程，第二次行前會審backend&frontend後端設計）不過如果你想走了也可以直接離職啦哈哈