這些年基本都是從第一次聽到某個專案，不到一週就開始寫程式碼，寫到最後發現需求有異義的地方需要大改（以為是 A 理解，其實是 B 理解）。
不是責怪產品沒把需求講清，產品能不能把需求講清，取決於有多少時間。
所以忽然想，一個完整的從 0 開始的完整專案，大家一般是有多少時間去了解需求。
Total: 15
-
所以你的概要設計和詳細設計文件呢？ -
基本都是倉庫來了直接寫程式碼。。
-
原來公司大概給一週左右理解業務。
現在公司，大概兩到三天吧。 -
先把你要做的專案對標的其他產品自己使用下， 大致瞭解清楚你要做的是什麼。 然後結合需求文件開發。
-
邊做邊改需求邊加需求。需求都是不定的
-
至少 60%的時間。用來一邊設計，一邊挑需求的毛病。你這個時候不去挑需求的毛病，後面寫程式碼的時候就寫不下去。如果隨便糊弄糊弄上了線，就該需求來挑你的毛病了。
-
@xuanbg 真實。以前在外包的時候，專案下來就有個全體會議，設計、產品、開發、測試，一起找設計和產品的毛病，逐一解決，一次會議幾個小時的那種。正式實施起來的時候基本上都是小問題了。
後面遇到到公司，基本都省略了這個流程了，產品討論都沒有 😂 -
一邊下達需求，一邊做功能。連理解需求的機會都沒有
-
大概開兩次會就定了，當然坑肯定留了不少
-
我個人需求梳理與程式碼時間一般是 7/3 開。7 包括需求溝通、細節敲定、詳細方案、任務拆解。實際上前期做的好的話程式碼寫起來會非常非常快，基本就是把前期做的工作轉換成程式碼。
-
畢業後，一直呆在小公司。目前基本上新專案下來，需求很快敲定，之後先做出來個樣本出來，後續根據樣本在進行修改，完善。期待去大公司。
-
可以通過過程控制來避免，比如需求反講，測試案例評審。兩個環節和需求人員一起參與，可以再次確認細節和避免歧義。
-
這個因為產品，需求，設計等等存在非常多變數
一個成熟產品可能根本不需要時間瞭解需求，就跟寫 bug 一樣
新產品，可能前倆迭代都是瞭解需求 -
從改 bug 開始熟悉。。。至於介面文件啥的，肯定是沒有的拉
-
一開始不用花太多時間，隨做隨問。感覺一開始也不太可能把每個細節的需求都弄清楚。
Add a reply