EP9播完了，就不防雷了
平匡的心就从第一集中，客户要修改系统那边看得出来
以他是软件工程师的角度来看
遇到什么事应该都会优先套用解bug的作法
原来是客户(美栗)一周来打扫一次
后来客户(美栗)要求要变成工作内容，所以有了契约结婚
然后有的时候客户(美栗)会提出要求
有的时候会回应客户(美栗)，然后会自己提出新提案
然后套用在第一集的客户(真客户)要求变更有20项次
如果契约结婚是项次1，皇家礼炮是项次20的话
那平匡就是在这1慢慢的debug到20，所以会有所成长
比如说第二次kiss是项次15的话，客户要直接跳项次20
那就会出现bug，所以平匡就说他无法
凡事都要先GOODLUCK(GOOGLE)过的他
这样看就觉得他会拒绝是很正常的
客户有要求的项目是：
聊天对象、男友、抱抱、一起泡澡
是平匡做那个也可以、确认喜不喜欢
大致上想到以下这些，也可以慢慢看出心境的变化
不过列一列就不只20项了@@
项次01：契约结婚
项次02：举办婚礼、互相的称谓
项次03：第一天同居
项次04：第一次请同事来家里玩
项次05：第一次互相睡闻对方在床上的味道
项次06：提出搬家的计划
项次07：增设恋人条件
项次08：跟同事一起去采葡萄，买葡萄送美栗
项次09：share事件(平匡说拒绝也没关系，没想到…)
项次10：提出交男朋友的需求
项次11：增设星期二抱抱日
项次12：第一次拥抱+摸头
项次13：员工旅游
项次14：第一次kiss
项次15：生日礼金、短信传情
项次16：开始放胆觉得美栗可爱
项次17：第二次kiss
项次18：客户(美栗)中离
项次19：聚会、便当反省事件
项次20：追去森山老家
项次21：加班想回家的心
项次22：系统重新建构提案
项次23：客户(美栗)生闷气、吃醋忌妒事件
项次24：确认互相的心意
项次25：35年皇家礼炮
一方面也算是客户(美栗)达成目标
一方面也算是自己成长
欢迎大家来补完

妈妈想抱孙子不知会不会增列在之后的项目XD

可以，这逻辑很平匡

要加一个与恋人庆生^^

平匡被美栗植入Bug(日文拥抱与Bug同音) 导致Pro单身破功

拥抱是hug（ハグ）只音似bug而已

项次25让我笑了！

推中肯分析！跳项次平匡真的会不习惯呢xd

庆生跟抱孙子应该都在25之后了吧，看EP10怎么演

推！很有趣XD

猜想你应该没有开发过系统吧，所以脑补的想法很奇怪。再不然就是没有写过大程式。

原来美栗是一步步的进攻平匡www

恩，我不是软件工程师，无法了解真软件工程师想法是用看戏的角度把这个写出来的，戏中平匡是这感觉

其实庆生可以跟礼炮合在一起....

不过EP9没有把要庆生这段演出来，可能要等到EP10

推～逐条列出好有趣

谢谢原po完成这个清单! 很有趣～

简单说就是你编了个不存在的想法，然后说平匡就是这么想，这么想像是没有关系，但你把这个当程软件工程师的想法就变成是完全在搞笑了。

不是软件工程司的粉丝看了觉得分析的不错

所以真正的软件工程师会怎么想啊？

对啊 真正的软件工程师会怎么想?

不是身在那个职业的话，无法了解那个职业真正的想法世上的职业无数，旁边者只能用推论(脑补)的方式来看啊，要打旁观者打错了

想知道真正的软件工程师怎么想+1

你好认真XDD这么一说真的蛮有道理的

工程师应该是会先全部写完跑一遍再从中找bug吧

只是看剧干嘛那么认真，还去探讨真正的工程师会怎么想...不用搞的自己这么累吧

是蛮有趣的遐想，但工程师也是正常人，不认为遇到感情会像这样思考耶

皇家礼砲XDDD

真正的软件工程师会全部写完再找bug，因为其实很多function写了就可以达成前面所有功能，例如7跟10的功能根本互冲，24写完前面的功能就全部失效了XD 这清单比较像宠物训练XD 真的用写程式方法去把妹会GG

不过ep1也是一项一项完成，不是一次全部20项一起做看了ep1才产生这样的推论的，也只是个趣味性推论

35年皇家礼炮XDDDD

EP.10终于来到转职的大日子！

以下有请竹科平匡来回

"软件工程师怎么想"->是指工作方式是不是像原po写的这样还是会不会以工作方式处理生活问题呀？如果是指工作方式的话,一定会先确定的是客户的需求(规格).期限及能运用的资源(人力/设备/经费…)然后将客户的需求分解成细项,依照相关性进行分组,不同组的工作如果无前后关系就可以同时做(人力许可的话),否则就要排先后顺序,再依分组定细部的工作内容. 如客户的需求可分成B/C/D三大功能,A是基础功能BCD都会用到,E是最后的整合跟测试,那大概就可以定出这样的流程A(1->2)->B(1->2->3)+C(1->2)+D(1->2->3->4)->E(1->2)其中B/C/D是可以平行做,但是要等A先做完才能开始，E则是要等BCD做完才能进行以原po举例的1是契约结婚,20是皇家礼炮,在我看来这两个没有必然的关连性,工程师通常不会收到1的要求就自已推论会做到20(事实上当时也没有),否则每个专案都会做不完(时间有限),比较常见的方式是收到2的需求,会看看1可以延用多少,是要重建整个系统还是局部修改就可以..另外印象中EP1的客户是个会计系统,很像工作清单但是看不出项目间的关连性,我的感觉是不一定循续完成,而且其中几个项目还重复(我记得最后第19跟20项内容一模一样,都是显示总金额),所以我是觉得不用对那张表太认真...天啊我在干嘛...

谢谢楼上解说 XD

d大专业到我看不太懂阿(⊙＿⊙)

谢谢d大认真说明

其实这种流程比较可能是PM开的，工程师不会这样跑没错

比方说契约婚先分成 (规划) -> (执行). 规划包含财务,工时, 草约, 与计画后面的执行细项。规划完。执行假设有婚礼和搬家。其中婚礼包含提亲, 仪式, 登记。搬家则是拦截行李, 整理房间, 分配房间等等。由于拦截行李这个有急迫性必须先做, 但是去到美栗家还可以同时执行提亲的部分。所以去过美栗家拦行李后, 婚礼(33%), 搬家(33%)。后面的仪式因为需要两个人力与两方亲友同时进行, 所以先切成连络跟订位吃饭。联络跟整理分配房间不冲突，所以就是美栗搬家那边与联络同时进行。婚礼(就两家人吃饭啦, 50%),搬家 (100%)。之后执行两家人吃饭, 婚礼(100%)。婚礼,搬家完成收尾就是各种文件的整理, 包含契约还有住民票变更...都做完就是契约婚 (100%)...好像写得太多...

楼上大大软件工程思维太强大了，专业推～

然后接下来客户新的需求(share), 分析一下发现契约必须修改(恋人条款) 剩下可以通用, 美栗工时必须重分配。抱抱日这个因为客户(百合)需求不明确, 所以除了初期完成火曜抱抱日后, 还历经两次的规格变更 (百合来袭, 野餐)才完成任务 (应该算 delay 吧...)。kiss 是平匡在温泉旅行后自己追加的需求。基本上就是估狗后决定执行的时机与执行的方式...但是kiss后美栗追加的滚床单需求因为是规格外的大功能, 所以...不好意思, 感觉越掰越歪了...不好意思再掰下去...XD

楼上专业推www

A大专业推XD

D大与A大都非常专业

d大很认真但我也还是无法理解，或许太专业了......

A大 太专业 规格外的大功能 平匡当机XDDD

原来我的解说太专业呀(打击)..应该是我火候还不够,无法解

A大的是套用在剧情上面，可能会比较容易理解

释得更浅显易懂..

最后一项XDDDD

A大太强了

回归原po的例子好了,当美栗提出爱爱的要求后,软件工程师并不是15项跳20项所以不行这种想法,而是当成全新的需求重新评估,平匡或许是因为担心无法完成美好的爱爱让客户失望,进而失去客户所以拒绝了这项工作

原来是这样，还以为是还没GOOGLE到不知道怎么做

d大正解! 平匡就是怕失败会让美栗对他失望啊

人家只是单纯的抱抱睡觉而已啦 哪有开礼炮XD

太好笑了啦

看到最后我才晃然大悟皇家礼炮是什么

哈哈哈 平匡逻辑啊 真的好可爱

raye888是指dpball大的流程是RD思維,原PO比較像PM開的嗎?

这样说好了，原po提出的流程的确是传统PM会开出的文件，专有名称叫瀑布式开发，但是这种开发流程实务上RD很没效率，很难插入规格变更，一遇到客变就会像EP1一样全部门大爆炸XD以RD的角度来看，其实PM用什么方式开规格都无所谓，重点是要有完整的规格文件(虽然RD自己最不爱写文件XD)，所以可以看到平匡最在意的都是那份契约，还有火曜抱抱的规则，一直到EP9还在纠结系统再构筑要怎么写到文件上XD比较有趣的是，看平匡写契约其实他是很习惯琐碎文件的人，可能跟他们公司开规格的方式类似，但是美栗开出的规格(产生新婚感，火曜抱抱之类)反而比较像近年软件工程提倡的User story一样简短，就成功让平匡内心的开发速度加快了XDrz

楼上形容的好有趣阿，专业推

C大专业，可惜不能推XD

顺便提供一个逃耻无用小捏他，平匡他们公司外观虽然是横滨的大楼，但是内部是在sakura internet东京支社拍的，所以窗外风景其实看得出来是西新宿而不是横滨XD

看完这集我只能说,软件工程师不会这样想,只有平匡..

平匡在第十集正式成为独一无二的...笨蛋

毕竟才刚转职没多久，还是会以魔法师的心态看世界