作者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://www.ptt.cc/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
推 shechiway: 推這篇，有時候換個角度想會不太一樣，雖然會很辛苦 07/07 11:19
推 ian90911: 推 07/07 11:26
推 LINGZ: 大推!您就是看到優點的人!!! 07/07 12:10
推 assai000: 謝謝大大的專業見解 在我能努力的範圍內我都會盡量讓 07/07 13:02
→ assai000: 我的開發流程舒適一點 像是整理共用的class、把常用的 07/07 13:03
→ assai000: deploy流程寫成批次 這是我能做到的 至於需求單位方面 07/07 13:03
→ assai000: 我會要求他們盡可能提供詳細的spec 我自已對流程的掌握 07/07 13:04
→ assai000: 也要熟悉 才能知道他們漏了什麼 我目前SOP還沒建起來 07/07 13:05
→ assai000: 才會覺得不適應 感謝大大提供的方向 我會努力試試看 07/07 13:06
spec 可能太難了，這東西可能連專業人士都不一定搞得定。
試著朝：『想達到什麼目的』跟 UI 的 mockup 開始，圖配合附著，具體化減少落差。
→ htury: 推這篇，這位是佛心來的 07/07 14:36
推 wildli0422: 謝謝大大分享 07/07 15:01
推 dreamnook: 這篇回答好健康 推XDD 07/07 15:35
→ qrtt1: devops 台灣的討論或活動分享可以加入 FB 社團看看呦:D 07/07 17:56
推 kewang: 推這篇！ 07/07 18:07
推 agnusdei0717: 推啊，自己把環境弄舒服 07/07 19:26
※ 編輯: qrtt1 (118.160.134.61), 07/07/2017 20:06:34
推 pttrAin: 推 07/07 20:07
※ 編輯: qrtt1 (118.160.134.61), 07/07/2017 20:27:17
推 vn509942: 感謝分享 也是選擇改變環境 07/08 08:07
推 Raymond0710: 推推推 07/08 09:03
推 wadxmjh: 推。解說清楚易懂。長知識了 07/08 21:01
推 landlord: 佛心有料就是推！ 07/08 21:10
推 akito117: 推 剛好碰到類似的問題 感謝 07/09 13:02
推 e2755699: 講的很不錯 07/09 15:01
推 gooddrink: 推！寫的很棒！ 07/09 17:00