作者qrtt1 (有些事,有時候。。。)
看板Soft_Job
標題Re: [請益] 該不該換工作
時間Fri Jul 7 10:35:18 2017
※ 引述《assai000 (七逃郎)》之銘言:
: 小弟剛進這家公司不到三個月
: 已經有離職念頭了
: 簡單敘述這間公司,是小公司,工程師含我共三人
: 其中一位將要離職,含其他行銷營運等別部門的人約3X人
: 此公司優點:
: 1.錢給得多,比我第二高的offer年薪多了65K,年薪快70
: 2.coding自由 想裝什麼套件或什麼技術都不會管
[----------------------------]
沒有人管的話,最好要有內部工作準則。
至少同事間有個默契,像是常見的避免 GPL
或是避免使用專案活力太小的套件
: 缺點:
: 1.工作流程混亂,誰都能向工程師提需求,沒有統一窗口
: 提需求的人沒專業知識,常常臨時增加需求,偏偏系統都規劃好了
: 只好破壞程式結構的穩健性來達成需求
: 對需求的時程規劃也很糟糕,每個人提的需求時間都擠得很近
往好處想,只有 3x 人需要被教育,
人數少一個一個慢慢泡茶,總是聊得完的。
另外,你沒有特別提到目前是什麼樣的需求記錄流程
若還沒有 issue tracker 請一定要導入,並且人人都可以看到內容
(可以互相嘲笑對方的需求有多瞎!?)
有些 issue tracker 也有像 trello 的顯示方式
就放個大螢幕(不要太長),超過可視區外的不在討論範圍
大家可以視覺上知道工作內容有多少,並且自己的需求被排在哪個順位
你也能在與需求討論後,寫上需求不合理的原因
或是需求配合系統的架構因修改為..
或是系統需要修改才能配合需求...所以需要額外多幾個人日...
: 2.因為公司性質,程式跟資料表都是用一次就丟,
: 例如某日期舉辦某某活動,網站路徑取叫20170710_xxxxx 資料表也取叫20170710_xxxxx
: 程式跟資料表無法重覆使用,因為每次都會有稍微不一樣
[--------]
有具體 UI 的東西要重用比較花心思,
但在 UI 之後的 data model 與操作行為
經過幾次的觀察後,有沒有機會把『稍微不一樣』的部分抽化
若不行,那有沒有機會做成 generator ?
就像我們用 IDE 建出新專案的模版那樣,
反正是拋棄式的,generator 聽起來不錯
若上面的建議不可行,
那回頭看看選用的語言與 web framework 夠不夠有生產力
: 3.部署流程混亂,常常上正式機了要修改,隨便測一下又再上正式機。
: 大概一天能發佈好幾個版本到正式機,常常發生文案字打錯圖片給錯的情況
: 我是後端工程師,一天寫到的後端沒幾行,都在處理html修改跟部署
: 改前端就算了,後端也是改一改就上正式機,有夠抖的
至少得有最基本的 deploy 基礎建設,現在 CI tool 太多了。
最低限度,你得能做到指定某個 revision 後,就上成那個版本。
即使你沒有測試,沒有良好的工作環境,至少 deploy 很快
就用速度來補足目前信心的不足。
雖然『正規來說』你的信心要來自確實的 test case 與 test coverage
但近期內你無法生出它們,至少 deploy 快,
你不用擔心修好後要麻煩的手工 deploy,然後又放錯檔案而一直的 deploy
: 4.on call
: 因為部署流程很亂的關係,出事了只好馬上修。
只要你有 deploy tool,出事了就先回到上一個穩定版本就好
(理論上 db 結構沒有變的前提下,這是沒什麼問題的)
除了 deploy tool 之外,你還需要 staging 環境,配置幾乎與 prod 一致。
即使公司沒有多的資源,現在還有 vagrant 或 docker 可以使用。
現在你沒有 QA,那就叫提需求的人,
自行上 staging site 操作看看有沒有問題。
: 綜合以上幾點,我是很想馬上提離職,
: 雖然我還沒加過班,也還沒on call過,
: 但想到未來就覺得有點不安全
如果還撐得下去,先不要躁動。先參加一點 devops 社群,
聽別人聊聊經驗,設法改善自己的工作環境。
你現在公司人少,一進去就變老鳥了,想要改善它不用經過太多人
『需求』管理的部分,得想辦法由需求方供應一個 PM 的角色。
這樣的優點是,開發方只需要教育 1,2 個人就好,不用個別去溝通。
工作流程上,先試著改善一些流程上的痛點,讓你稍為舒服點。
至於網站微妙的不同,衍生多種版本,可以拿實例出來研討。
在這個版或程式相關的版應該都很人有興趣。
Soft Job 只是大家的 domain 用得不太一樣,但技術解法常是共通的。
先不要太專注在心理上的痛苦,把問題拿出來研究唄。
: 參考了其他公司的工時/薪水
: 像是這兩個網站
: https://www.goodjob.life/
: https://goo.gl/kwYB1L
: 又覺得我好像算是幸福的,
: 不知道是不是我太草莓
對環境敏感不能說是草莓啊。
工作環境太差,如果你很麻木那反而奇怪吧。
感覺起來是個修煉場所。
引《淘寶技術這十年》:每個牛 B 的人物,都有一段苦 B 的過去。
: 各位會建議我繼續待嗎
: 還是寧願領少一點呢
: 因為我可能無法拿到跟這間一樣的薪水了
大方向是不建議繼續待,
但如果你能改工作環境改得舒服點,那待下去會很快樂。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.160.134.61
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1499394921.A.760.html
※ 編輯: qrtt1 (118.160.134.61), 07/07/2017 10:37:25
※ 編輯: qrtt1 (118.160.134.61), 07/07/2017 10:43:38
1F:推 shechiway: 推這篇,有時候換個角度想會不太一樣,雖然會很辛苦 07/07 11:19
2F:推 ian90911: 推 07/07 11:26
3F:推 LINGZ: 大推!您就是看到優點的人!!! 07/07 12:10
4F:推 assai000: 謝謝大大的專業見解 在我能努力的範圍內我都會盡量讓 07/07 13:02
5F:→ assai000: 我的開發流程舒適一點 像是整理共用的class、把常用的 07/07 13:03
6F:→ assai000: deploy流程寫成批次 這是我能做到的 至於需求單位方面 07/07 13:03
7F:→ assai000: 我會要求他們盡可能提供詳細的spec 我自已對流程的掌握 07/07 13:04
8F:→ assai000: 也要熟悉 才能知道他們漏了什麼 我目前SOP還沒建起來 07/07 13:05
9F:→ assai000: 才會覺得不適應 感謝大大提供的方向 我會努力試試看 07/07 13:06
spec 可能太難了,這東西可能連專業人士都不一定搞得定。
試著朝:『想達到什麼目的』跟 UI 的 mockup 開始,圖配合附著,具體化減少落差。
10F:→ htury: 推這篇,這位是佛心來的 07/07 14:36
11F:推 wildli0422: 謝謝大大分享 07/07 15:01
12F:推 dreamnook: 這篇回答好健康 推XDD 07/07 15:35
14F:→ qrtt1: devops 台灣的討論或活動分享可以加入 FB 社團看看呦:D 07/07 17:56
15F:推 kewang: 推這篇! 07/07 18:07
16F:推 agnusdei0717: 推啊,自己把環境弄舒服 07/07 19:26
※ 編輯: qrtt1 (118.160.134.61), 07/07/2017 20:06:34
17F:推 pttrAin: 推 07/07 20:07
※ 編輯: qrtt1 (118.160.134.61), 07/07/2017 20:27:17
18F:推 vn509942: 感謝分享 也是選擇改變環境 07/08 08:07
19F:推 Raymond0710: 推推推 07/08 09:03
20F:推 wadxmjh: 推。解說清楚易懂。長知識了 07/08 21:01
21F:推 landlord: 佛心有料就是推! 07/08 21:10
22F:推 akito117: 推 剛好碰到類似的問題 感謝 07/09 13:02
23F:推 e2755699: 講的很不錯 07/09 15:01
24F:推 gooddrink: 推!寫的很棒! 07/09 17:00