PTT職涯區 / Soft_Job (軟體人)

[請益] 關於開發流程上的問題已刪文

看板Soft_Job (軟體人)作者 (GodCK)時間2年前 (2021/09/21 23:02), 2年前編輯推噓52(52推 0噓 187→)
留言239則, 38人參與, 2年前最新討論串1/1
9/22 更新 先謝謝各位前輩的建議，我每則都有看 然後我把這件事跟我的工程師朋友討論（他現在是小主管） 原本是想了解其他人是怎麼做的 沒想到卻意外拿到可能可以面試的機會，他說他滿清楚我的能力 要幫我推薦是完全沒問題的，就看我要不要投投看履歷 所以沒想到這件事意外讓我有新的面試機會 lol 沒意外的話可能真的會想去外面的世界多看看了.... -------------------------------------------------------------- 各位前輩好，小弟目前在某新創公司擔任前端 由於見過的世面不多，所以有些問題想請教前輩們 最近覺得公司在開發流程上真的越來越不順暢 像是設計稿上要顯示的欄位結果資料庫一開始就沒存 然後我們是先設計再出文案的，所以常常文案出來後排版又要再改 又或著是照著老闆開的規格開發，結果開發到一半發現一些 corner case 下會出問題 所以就有多來來回回的溝通成本 我們流程大概是 老闆發想新功能 => 找許多參考網站並融合自己想法找設計師討論並設計 => 設計完成後找工程師們與設計師一起開個行前會 => 然後就是後端、前端開始各自動工(我會先寫死內容，至少排版、RWD 先弄好)， 同時老闆會開始寫文案 => 後端開 PR 以後給老闆 Review，過了以後前端就會開始接 API 了 其實之前就覺得這種流程會出問題 只是功能不大的情況下還是可以運作 但最近要開發的功能真的很大，所以就爆炸了 最讓我覺得心累的是往往都是到了我這一關才會發現有這麼多問題 我常常心裡在想 阿設計稿這邊有問題這麼明顯，怎麼老闆就丟過來給我開發了 阿後端這邊欄位就不對怎麼也過了老闆這一關 那是不是如果我什麼都不說反正我就接 API，設計稿畫什麼我放什麼，產品上線就爆炸了 結果當然是不敢這麼做..... 我就變成了唯一(至少目前我是這麼覺得的)那個會仔細檢查設計稿、檢查 API 規格的人 因為我完全不信任丟給我的設計稿和 API 是對的 而且每次事實證明我都是對的，因為我每次檢查後都會回去委婉地問老闆說 請問這邊設計稿上畫的是對的嗎? 這裡可能會有點問題喔 請問這隻 API 這樣傳是對的嗎? 這樣的話這個畫面可能會有問題喔 結果老闆都是說 對，這樣會有問題，會請他們再回去改 當然以上都是由我個人角度出發看到的事情 我也不知道設計師跟後端甚至老闆各自可能遇到什麼問題 我只知道當我拿到兩邊的東西要整合在一起的時候有滿滿的問題 我想請問各位前端前輩們也會遇到跟我類似的問題嗎? 如果不會，我該怎麼建議老闆改善比較好 又或著是其實前端真的就是要這麼謹慎檢查? 我理想中是老闆應該要檢查後端與設計稿，至少在他那關要擋掉絕大部分的問題 剩下真的很細節的問題可能沒發現我覺得都還好 但我的體感是根本沒擋.... 我猜他可能是覺得等前端接了以後就會知道哪邊有問題了，到時候再解決? 但這樣就會搞到我心很累 PS.目前開發團隊是1前端(我)、1後端、1設計師 + 老闆(tech leader 兼 PM 這種感覺吧) 目前已經想開履歷去面試其他公司了 另外想請問想在面試階段就了解公司開發流程的話，大概會怎麼問比較好 先謝謝各位前輩的解答! -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 112.104.144.169 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1632236574.A.BDC.html ※ 編輯: a2643 (112.104.144.169 臺灣), 09/21/2021 23:05:12 ※ 編輯: a2643 (112.104.144.169 臺灣), 09/21/2021 23:11:04
推
09/21 23:06, 2年前 , 1F
直接問就好
09/21 23:06, 1F
※ 編輯: a2643 (112.104.144.169 臺灣), 09/21/2021 23:15:01
推
09/21 23:14, 2年前 , 2F
工程師原本就是溝通吃重的工作，只照著 spec 開發完全不
09/21 23:14, 2F
→
09/21 23:14, 2年前 , 3F
溝通那是碼農等級
09/21 23:14, 3F
推
09/21 23:18, 2年前 , 4F
小公司本來就是這樣 習慣就好
09/21 23:18, 4F
推
09/21 23:19, 2年前 , 5F
人數不夠就是你做阿
09/21 23:19, 5F
→
09/21 23:19, 2年前 , 6F
1.換工作 2.拿職位(PM)+提加薪 自己選一條吧
09/21 23:19, 6F
推
09/21 23:22, 2年前 , 7F
也沒幾個人 總有人要做整合
09/21 23:22, 7F
→
09/21 23:23, 2年前 , 8F
覺得薪水不夠就要加薪 加不了就走人
09/21 23:23, 8F
推
09/21 23:23, 2年前 , 9F
其實有一個解決方法 就是api和設計都自己來，給你參考
09/21 23:23, 9F
推
09/21 23:23, 2年前 , 10F
我覺得只是不夠敏捷 可以把大功能拆解
09/21 23:23, 10F
→
09/21 23:24, 2年前 , 11F
我也知道溝通很重要，但我覺得老闆應該要在他自己 Review
09/21 23:24, 11F
→
09/21 23:24, 2年前 , 12F
的時候就應該要發現一些問題然後退回去給設計師和後端
09/21 23:24, 12F
→
09/21 23:25, 2年前 , 13F
真的很細節的問題可能要等前端整合以後才會發現我就覺得
09/21 23:25, 13F
→
09/21 23:25, 2年前 , 14F
沒關係，這很難免
09/21 23:25, 14F
→
09/21 23:26, 2年前 , 15F
但我現在體感是，他可能只有大概看一下，就丟過來了
09/21 23:26, 15F
推
09/21 23:29, 2年前 , 16F
台廠日常：隕石式開發和通靈式開發
09/21 23:29, 16F
推
09/21 23:35, 2年前 , 17F
就是沒個pm吧
09/21 23:35, 17F
推
09/21 23:36, 2年前 , 18F
你怎麼會期待PM會好好review?
09/21 23:36, 18F
推
09/21 23:44, 2年前 , 19F
review 一直都是當事人做才能降低代溝，你該解決的是怎樣
09/21 23:44, 19F
→
09/21 23:44, 2年前 , 20F
的合作模式可以降低修改機會等。以 api 來說，是不是可以
09/21 23:44, 20F
→
09/21 23:44, 2年前 , 21F
反向變成你開 spec；以設計來說，是不是可以增加假互動畫
09/21 23:44, 21F
→
09/21 23:44, 2年前 , 22F
面的設計步驟來降低變更機會
09/21 23:44, 22F
推
09/21 23:49, 2年前 , 23F
SA/SD溝通上很重要，建議找主管出來扛個責任
09/21 23:49, 23F
→
09/22 00:03, 2年前 , 24F
所以最好的建議就是請老闆找一個PM來管事嗎XD
09/22 00:03, 24F
→
09/22 00:05, 2年前 , 25F
回 A 大，確實你說得對，但我的意思是像設計稿畫的東西
09/22 00:05, 25F
→
09/22 00:05, 2年前 , 26F
結果資料庫一開始就沒有，這種真的只要花一點時間檢查就能
09/22 00:05, 26F
→
09/22 00:05, 2年前 , 27F
發現事情，理論上應該不是到了我這邊才被發現
09/22 00:05, 27F
→
09/22 00:06, 2年前 , 28F
所以我才會說老闆可能真的只是大概看一下，就 pass api和
09/22 00:06, 28F
→
09/22 00:06, 2年前 , 29F
設計稿了
09/22 00:06, 29F
→
09/22 00:09, 2年前 , 30F
甚至在規劃功能的時候應該就要知道這件事了
09/22 00:09, 30F
推
09/22 00:11, 2年前 , 31F
個人經驗是只能靠自己多協調,讓設計的時候就考慮到
09/22 00:11, 31F
→
09/22 00:11, 2年前 , 32F
文案的問題
09/22 00:11, 32F
推
09/22 00:26, 2年前 , 33F
找PM協調是一種方案..但畢竟是新創
09/22 00:26, 33F
→
09/22 00:26, 2年前 , 34F
我覺得老闆設計師後端都要有更多的產品心態
09/22 00:26, 34F
→
09/22 00:26, 2年前 , 35F
關於需求這麼做會有什麼問題？
09/22 00:26, 35F
→
09/22 00:26, 2年前 , 36F
會有操作問題嗎？權限問題嗎？什麼樣的情境會遇到什麼
09/22 00:26, 36F
→
09/22 00:26, 2年前 , 37F
需求等等
09/22 00:26, 37F
→
09/22 00:27, 2年前 , 38F
看你例子設計師和後端
09/22 00:27, 38F
還有 163 則推文
還有 4 段內文
推
09/22 11:14, 2年前 , 202F
你們需要一個PM
09/22 11:14, 202F
→
09/22 11:15, 2年前 , 203F
以前也是沒PM 這樣的走法 現在弄了一堆債要救…
09/22 11:15, 203F
推
09/22 11:25, 2年前 , 204F
覺得後端居多 因為 DB 欄位不可能是 f2e 管的
09/22 11:25, 204F
推
09/22 11:33, 2年前 , 205F
（1）在前後端開始implement feature 之前先拿到api
09/22 11:33, 205F
→
09/22 11:33, 2年前 , 206F
contract（2）夠信任backend 的話就自己mock ui da
09/22 11:33, 206F
→
09/22 11:33, 2年前 , 207F
ta下去implement,不信任後端的話就請他們提供mock a
09/22 11:33, 207F
→
09/22 11:33, 2年前 , 208F
pi (3) 預留時間做integration test 和end to end t
09/22 11:33, 208F
→
09/22 11:33, 2年前 , 209F
est還有bug bashing
09/22 11:33, 209F
推
09/22 11:41, 2年前 , 210F
另外design doc 應該是feature開發前就應該寫好的？
09/22 11:41, 210F
→
09/22 13:32, 2年前 , 211F
沒有sa嗎，後端或你老闆要兼sa的工作吧
09/22 13:32, 211F
→
09/22 13:40, 2年前 , 212F
感覺後端比較雷吧，很難想像少欄位後端開發會不知道
09/22 13:40, 212F
小公司人力短缺 lol 這種短小精幹的團隊配置似乎真的每個人都要有點自我要求 才能成功地繼續跑下去
推
09/22 13:44, 2年前 , 213F
這種小公司最佳解就是兩個人都做全端 照功能分
09/22 13:44, 213F
推
09/22 13:48, 2年前 , 214F
流程沒問題 有問題的是人
09/22 13:48, 214F
※ 編輯: a2643 (118.168.141.91 臺灣), 09/22/2021 14:34:39 ※ 編輯: a2643 (118.168.141.91 臺灣), 09/22/2021 14:47:45 ※ 編輯: a2643 (118.168.141.91 臺灣), 09/22/2021 15:17:52
推
09/22 16:05, 2年前 , 215F
前端本來就算是一個橋樑的職位，加上是使用產品的第一
09/22 16:05, 215F
→
09/22 16:05, 2年前 , 216F
線
09/22 16:05, 216F
→
09/22 16:05, 2年前 , 217F
這種狀況在小團隊多多少少會遇到
09/22 16:05, 217F
推
09/22 16:40, 2年前 , 218F
我覺得你可以找老闆討論一下工作認知～因為這個「最終核
09/22 16:40, 218F
→
09/22 16:40, 2年前 , 219F
對，幫忙把關」是誰要負責做，其實沒有一定，老闆很可能
09/22 16:40, 219F
→
09/22 16:40, 2年前 , 220F
覺得你很棒都幫她做掉了，可是你卻一直覺得老闆沒把他工
09/22 16:40, 220F
→
09/22 16:40, 2年前 , 221F
作做好...結論就是和老闆討論，你其實不喜歡抓這麼多錯
09/22 16:40, 221F
→
09/22 16:40, 2年前 , 222F
誤，然後你們協調未來怎樣調整會是大家都開心，解法很多
09/22 16:40, 222F
→
09/22 16:40, 2年前 , 223F
種喔，選哪種是看你們這幾位利害關係人各自想要的和不想
09/22 16:40, 223F
→
09/22 16:40, 2年前 , 224F
要的是什麼，都可以談的，沒有什麼「應該」要誰誰誰負責
09/22 16:40, 224F
→
09/22 16:40, 2年前 , 225F
，我就列出幾個可能選項
09/22 16:40, 225F
→
09/22 16:40, 2年前 , 226F
(1)老闆了解你的痛苦、他也有時間，於是他決定以後審核
09/22 16:40, 226F
→
09/22 16:40, 2年前 , 227F
後端PR更嚴格
09/22 16:40, 227F
→
09/22 16:40, 2年前 , 228F
(2)老闆覺得他沒空看細部東西，他覺得你幫他看很棒，他
09/22 16:40, 228F
→
09/22 16:40, 2年前 , 229F
說服你把這部分把關的工作正式變成你的工作，並且他幫你
09/22 16:40, 229F
→
09/22 16:40, 2年前 , 230F
升職為team lead也幫你加薪
09/22 16:40, 230F
→
09/22 16:40, 2年前 , 231F
(3) 老闆沒空幫忙看，他其實也覺得你退回太多次，是這位
09/22 16:40, 231F
→
09/22 16:40, 2年前 , 232F
backend太雷，做事都不仔細，於是他換一個新的backend
09/22 16:40, 232F
→
09/22 16:40, 2年前 , 233F
(4) 老闆沒空看，他也認同這花你太多時間也讓你空等，也
09/22 16:40, 233F
→
09/22 16:40, 2年前 , 234F
讓backend要重做，於是他接受你的說服，決定從此以後再
09/22 16:40, 234F
→
09/22 16:40, 2年前 , 235F
多一個文件的步驟，backend在動code之間要先把db schem
09/22 16:40, 235F
→
09/22 16:40, 2年前 , 236F
a&api input output寫在document，並且開第二次行前會（
09/22 16:40, 236F
→
09/22 16:40, 2年前 , 237F
第一次行前會審ui流程，第二次行前會審backend&fronten
09/22 16:40, 237F
→
09/22 16:40, 2年前 , 238F
d後端設計）
09/22 16:40, 238F
→
09/22 16:40, 2年前 , 239F
不過如果你想走了也可以直接離職啦哈哈
09/22 16:40, 239F
‣ 更多 a2643 的文章
文章代碼(AID): #1XIVGUlS (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 a2643 的文章
文章代碼(AID): #1XIVGUlS (Soft_Job)