我平常是寫內部系統用Java的，有很多內部才懂的know how商業流程
平常工作就寫ticket上的任務，不懂就問資深前輩算工作順利愉快
這點真的很感謝前輩
如果再不會就問問user這裡的邏輯
但是對系統的理解就是比較破碎，
就是只懂ticket解過寫過的東西
也沒有什麼內部文件可以讀跟上課，就解ticket自己看code遇到問題後發問
但大主管最近突然要我們做投影片報告對team上整個系統的介紹跟系統與商業流程說明，
但是光是平常解ticket累積的知識根本不夠
不能代表系統的全貌
只能額外利用下班時間自己讀code再發問
長官就是希望我們很懂業務流程邏輯,
不然怎麼跟user溝通
也說不要提程式碼, 他們沒興趣, knowhow比較重要
最近就是不斷的上班工作, 下班研究商業邏輯
不知道大家有沒有遇過這種情況
還是單純我真的不適合這類工作?
或是這種就是業界常態, 我做不來就只能轉行?

當初整個專案誰架構的叫他出一份報告阿

可能已經不在公司了才會這樣

我也想知道 有些沒有文件只能讀code 有點難受

不能干預的業務流程乾碼農什麼事大主管是不是沒技術面~？

其實就講幹話而已，沒文件誰知道流程怎麼跑

業務邏輯直接跟user搞熟問他們最快看code或文件反而是最沒效率的

這種不是讀code，是要問人尤其當初設計的人啊

通靈

正常至少要有個人能跟你講清楚，那個人已跑了就問主管吧

讀code只能告訴你碰到這種情形的時候會採取什麼動作，但不能告訴你為什麼要採取這個動作

看看ac和ut，有寫的話馬上就懂

一堆要通靈的主管 有些東西你光看程式邏輯、版控紀錄最好知道當下為什麼這樣調 很多東西都是要跟使用者需求方進行訪談開發文件有些調整會議也不會詳列很多真的只能靠當時設計那些人去回想

大主管希望基層了解業務流程，和你上班沒時間做這件事是兩回事，你先想清楚你想問的是哪個部分？

長官自己懂嗎？ 講幹話很厲害

看起來你長官是想讓你sa 到pg 統包

如果流程很複雜，直接找內部的user來說明還比較快

說不定pm 也要讓你幹

沒文件就是一個不正常的常態，你能做的就是根據現有資源，也就是根據程式碼來畫流程圖，理解流程後再用白話的方式去報告 如果老闆有意見，你就叫他自己下來看

客製化的最麻煩…

原PO懂的話就能自己開公司了，我猜當初草創期的人都跑了，原PO主管才會這樣想透過code反推回去

想到之前一堆人都說程式碼就是最好的文件真的笑死

你直接問user平常這功能在幹嘛比較快如果沒人知道/在用 剛好可以砍掉

推FXW11314

因為他們都不懂，所以叫你懂阿

我想問這種工作大部分都這樣嗎，還是被我剛好遇到

專案這東西一手過一手 連需求方接手的也換好幾人 還有使用者會來問你為什麼要這樣設定文件沒有齊全 遇到問題真的很麻煩而且一堆公司真的沒在寫有些大公司是很重文件 有的為了應付稽核還是認證 這些就很重要 有沒有齊全對開發人員有時就是額外負擔

不正常吧 需求不是都PM談的？頂多拉上主管 SA 然後主管拆成ticket 交到RD手上時都剩碎片了 如果是複數RD也沒cowork不就gg?

看公司it 規模 有些根本從頭管道尾

懂流程又懂技術你怎麼不自己開公司寫套裝軟體，還要看人臉色程式三不五時改來改去？很想賞這種只會講幹話的主管2巴掌…你怎麼不你主管説你怎麼不去學張忠謀把公司管理成台灣市值最高獲利薪資福利最好的上市櫃公司？

拿一手啤酒去找使用者聊聽他抱怨

很正常吧。軟體開發本來就是工具，讓業務流程更方便，更有效率才是真實價值。 透過解決商業流程效率的問題，才是真正有高薪價值的地方。別把自己真正當碼農了。不要以為寫程式有什麼價值的，就是搬磚塊的工人而已，真正有價值的是設計，提升公司效率的邏輯，不是做事的工人。工程師與碼農的差別就是，一個懂怎樣讓程式有商業價值，也就是懂業務流程優化。一個是只會複製別人程式碼，其他都不會。另外，別花時間研究商業邏輯。跟懂公司商業邏輯的人請教比較快。另外一堆人跟你說不用懂，PM才要懂？不管有沒有PM，最後工程師不懂商業流程，能寫正確的程式？不可能吧。

寫到後面都在通靈啊，你沒有對你寫的東西有基本認知怎麼能知道上面給你的規格有沒有出錯

我也到了不要提程式碼我沒興趣的年紀了程式碼裡面大多是自己挖自己埋的坑 除非code review

要介紹系統流程你又不是從頭到尾處理整個案子

不然提出來給上層看根本是浪費時間

大主管畫外音：都來多久了還要一天到晚請教資深前輩，這個人是只會寫程式，從來沒想過應該要了解商業流程獨當一面嗎？應該來安排一個報告釘一下看你會不會主動了解流程，反正也差不多快到每年例行性新陳代謝的時候了

寫內部系統就一條龍 上半把戲演好，這份文件也不用太仔細，點到為止，因為每年大主管的腦都會變

傻傻的 只會coding你再過十年拿什麼去跟新鮮的肝競爭打算刷題刷一輩子?

從老闆角度是很合理的要求，直接找user聊天問吧

通靈啊

給個不同意見,老闆有可能只是要你把整個程式架構先看懂看熟,下次有改動需求可以比較快想到從何改起,你可以偷試探一下是不是真的要你反向推導出整個"商業"邏輯

這種的很難搞，要從code反畫出整個系統的行為跟架構。要是沒文件告訴你是為什麼只能從結果來解釋現在系統的行為，例如快取是怎麼建立的，通常有幾種方式。

老闆才沒興趣聽你說快取這種事情..都說簡報系統架構了抱歉說錯了，不是系統架構，是系統介紹與商業流程就是這個系統是做什麼用的，能提供哪些功能，使用者應該如何使用它，可以帶來什麼效益你不去問user平常怎麼使用的，code看到死也不會有結果只理解解ticket需要的小範圍知識卻不知整個系統的資料流起點過程跟終點是原Po的問題，從來沒想過自己主動好好理解自己在做的產品是什麼嗎？要求原Po做簡報卻沒有給足夠時間跟資源則是公司問題要去理解這些東西是正常的，需要用下班時間自己看code研究是不正常的

這算是滿基本的要求，目前公司面了很多講不出自己在現有公司到底做了些什麼的，大都是沒去了解真正的商業邏輯，這種的沒有半個會過關

舉例而以，這種東西就只是行為（緣由）>前端>後端內容換成自己要用的就好，而且都懂了商業流程，畫出系統結構也不是難事了，還能順便跟老闆講哪裡可以改善不是很好？

程式碼就是最好的文件前提是寫好 公司內勾心鬥角肯定不會好工具有分好壞 得到結果不同 並不是工具不重要 除非你是出嘴寫程式 而成本被底下的人吸收了工程師要了解業務邏輯 但PM要主動確認與解釋工程師把PM事情給做了? XD通篇看下來就是主管想要轉嫁成本如果上面的人是好人那還好說

樓上，很多公司是沒有PM的

問題中的[業務流程]是公司內部業務銷售流程嗎？？商業流程是標準進銷存流程、財務應收應付流程或是從研發生產到銷售維修的全部流程？商業流程你只能知道大約的架構，細節還是要Key User來定義。懂流程是應該要的。但是常常碰到一種人要IT先把系統寫出來，他再來看這個系統流程對不對，這種千萬不要傻傻做。

直接向上報告你們目前的形勢。如果時間壓得很死上班根本沒時間了解整套運作，那就直接要求報加班或者解問題的工作減量，再不行就考慮離職上面說得好：希望了解業務流程和上班沒時間做是兩議題更了解業務情境有利理解需求，但如果平常解問題解到沒有餘裕了解業務全貌還得下班做，那就是工作量太大了

去user端打工幾天，這要問user才能學會

講到去User端打工讓我想到個鬼故事這也聽來的，中部有某間小小小銀行招後端工程師，跟你說一開始你要先在櫃檯待過然後跑外務、外務有業績壓力都Run過一遍流程，大概需要半年？以上然後考試通過後才回來寫Code

沒寫過c++?,從main 開始啊

有沒有PM都改不了底下人要承擔的事實

如果程式的確照著業務流程，你一定可以向業務或相關使用者問出原因，只是你需要畫event storming,來確保你聽到的流程沒有缺失

這種一定問人吧...讀code反向推導? 老闆是這意思?

看公司有沒有像是ISO 9001這類的標準化文件。沒有的話，就從系統權限表找實際操作系統的同事訪談。看他們部門有沒有規範。很多時候應用程式只是商業流程的一部分，人工作業、第三方軟體上的操作，你看Java code就看不到。