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

看完這集我只能說,軟體工程師不會這樣想,只有平匡..

平匡在第十集正式成為獨一無二的...笨蛋

畢竟才剛轉職沒多久，還是會以魔法師的心態看世界