我平常是写内部系统用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就看不到。