作者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/cn.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