一個標準的機能，假設一共需要八天的話，那麼內部設計計劃用四天，編碼用四天。
而實際上，編碼四天不夠的，正常應該六天才能做完。那為什麼要計劃成四天呢?
原因就是當時有一個理論，UML的工具功能比較強大，用UML工具，畫完類圖之後，可以直接把類圖導進編碼工具中，這樣就會把編碼前期的框架直接生成，所以能夠減少兩天的時間。
而現在的問題是，大家編碼能力都不錯，但UML多數人不熟悉，隻有徐希田以前用過，相對水平高一些。所以很多人連UML做圖用4天，都不敢保證能做完，到編碼階段，設計也經常有變更，一邊編碼，一邊再去改UML，整個進度就一拖再拖。
而且這種交叉工作，弄的大家心理上也疲憊不堪，士氣越來越差。
這個係統，將來預定是葉奕凡和文連夏長期做維護的，也就是說，這是他以後的飯碗。
如果項目失敗了，餘信會受到很大牽連，葉奕凡不得不找其他飯碗，而其他人無所謂，再換個項目就可以了。所以為了自己的飯碗，也為了餘信能立住，葉奕凡是必須讓這個項目成功的。
他以前稍微接觸過UML，記得這個工具非常強大，可以把很多種語言的代碼導進去後，生成相應的各種圖。
於是就找徐希田討論這個問題，正好他以前也這麼用過。葉奕凡就讓他演示一下，發現這個步驟簡直太簡單了，而且速度快，一個功能十來分鍾就可以把圖作出來。
可能需要手工調整一下位置保證美觀，但半個小時也足夠了。
半個小時，完成計劃中需要4天的工作量，這是多大的突破啊。於是在當天的項目會議上直接提出了自己的觀點，就是讓大家先做編碼，再反向生成兩個圖。
沒想到的是，自己話音剛落，就被莫升否定了。“哪有先做編碼，後作內部設計的。”
張瑞比較迷信莫升，基本上以他的意見為意見，看莫升反對也就跟著反對了。
其他大多數員工，也反對，顧天明等少數人沒有說話。
大家反對的理由，並不是說這樣做有什麼問題，而是最讓葉奕凡無法接受的理由：
“以前沒見過這麼幹的。”
有反對的，有沉默的，就是沒有讚成的，這個意見還沒討論就被否決了。
餘信始終沒有說話，葉奕凡知道他的處境，他是疑人不用，用人不疑，雖然他覺的葉奕凡說的話肯定會有道理，既然用了莫升做ITA，這方麵的事，就得由莫升來拍板。
這一下討論就進行不下去了，事情暫時放置了起來。
又過了幾天，葉奕凡偶然看到徐希田做完類圖之後，並沒有用類圖自動生成代碼的框架，而是在編碼工具上，重新把所有的元素手工輸入一遍。
這一下不淡定了，馬上問徐希田：“你為啥不自動生成代碼，還要用手工輸入呢?”
徐希田看著葉奕凡，想了想，露出一個苦笑的神情：“不習慣啊。”
徐希田是這些人中，對UML最熟悉的，連他都不習慣，哪能指望別人能節省兩天的時間了，也就是說，每個功能兩天的時間，是結結實實的浪費了，就算往死裏加班，別說追趕進度，這兩天的時間都不一定能趕回來。