事情是這樣子的，我們打算迭代開發這個功能，添加5個功能點，頁面算是重做，添加兩個狀態。所以我打算重構這個功能，原因有二，其一因為之前版本代碼臃腫，不適合查找問題，而且存在許多使用問題；其二因為修改的東西有點多，所以得重構，用之前的代碼無法完成和修改使用。由于關系到公司隱私問題，這里不貼出相關設計原型，并沒有各種文檔。

當然，重構后的代碼還是滿意的，畢竟減少了接近2000行的代碼，功能分類，相關備注都有

下面我會通過：工作實際時間、加班時間、存在的問題、問題解決方案、開發流程和我的開發流程設想、以及開發過程中的小插曲來進行分析這次的任務

工作實際時間和工作

我的工作實際時間和工作

第一周	1.完成總進度的百分之50，總體頁面框架和實現，以及其中的流程功能操作
第二周	1.其他項目插入 2.完成總進度的72%
第三周	1.前兩天半時間其他項目介入，完成。 2.完成總進度的92%。 3.第三天下午討論新增功能點，項目流程大改，并且pc端顯示頁面重畫。 4.由于個人為了讓幾個展示頁面格式和顯示風格統一，未按照需求頁面開發，重新編輯代碼
第四周	1.完成總進度的99%。 2.并且討論流程控制需求，未記錄
第五周	1.測試并且修改bug和優化顯示，由于之前討論結果沒有及時保存，只能通過我寫開發流程編輯草稿式的測試用例
第六周	1.過產品驗收確認，優化，加需求和修改需求，有幾個流程控制中途討論結果未及時更新，導致返回討論前的需求，pc端審核頁面沒畫。 2.開啟另一個小任務并且完成
第七周	1.優化和新需求，其他項目幾個小bug，周五還在加需求，并且還有一個小需求未完成下個版本迭代。 2.產品驗收。
第八周	功能上線...

加班時間（這里我采用未加班加班的時間，以九點半以上為準）

未加班時間（周記）

第一周	周一、周三
第二周	周五
第三周
第四周	周二、周五
第五周
第六周	周一、周四、周五
第七周	周一、周五
第八周	...還沒到

通過每周執行和加班的時間分析存在的問題：
1.沒有一個明確的研發流程
2.產品設計不夠詳細，功能點不明確
3.頻繁修改和添加需求
4.討論沒有做記要，導致測試和驗收流程不吻合
5.研發人員有模糊功能未按照產品設計原型開發
6.測試用例未及時整理
7.測試人員提需求未記錄保存，與產品驗收沖突
8.產品人員未和測試及時溝通需求，測試用例有偏差
9.研發人員細節修改未記錄


針對以上描述的問題，我的解決方案如下：
1.產品設計的詳細設計應該和開發人員，測試人員，市場人員共同確認，編寫詳細開發文檔，測試用例，市場描述文檔
2.需求和文案修改或者新增，消息聯動，產品，市場，研發，測試。并且記錄在下一個版本迭代翻案中
3.對于研發時需求修改，如果是特別需求必須在研發過程中修改或者是發現重大問題下，可討論并且記錄下來，然后代碼調整。并且修改需求記錄下來，測試和市場文檔修改
4.對于研發人員，不可直接修改需求和設計，需要修改的地方開會討論或者下個版本迭代。功能邏輯理清
5.對于產品設計，設計人員盡可能詳細的描述功能點和操作，相關人員必須明白這個功能干啥的，這個標志放到這里的作用，甚至可以細致到顏色和像素的描述
6.對于測試人員，測試用例文檔應當在研發結束之前應該出來；測試人員不能直接修改需求和添加需求，有問題及時反饋，研討這個需求是及時修改或是下個版本迭代
7.對于前端人員，我的前端工程師是最棒的，改？小意思給我一首歌的時間。


下面是針對開發流程的分析和我的設想：
現在的開發流程：

產品設計～產品評審～開發（改需求）～測試（改需求）～改bug（改需求）～產品驗收測試（改需求）～最終改bug（提需求）～產品上線

1.這里我們可以明確的發現幾個問題，就是在開發過程中不斷的提需求改需求，夾雜這產品和測試的需求，這樣大大的延長開發時間；

2.有時候會因為產品和測試提的需求沒有及時把消息傳遞到整個團隊和原型設計里面去，導致測試和產品的的需求有出入，所以產品驗收的時候已產品設計為標準；

3.需求設計未明確所以開發延長開發周期；

我建議的開發流程：
產品設計～詳情設計（包括產品的細節設計，產品協助測試寫好測試用例以及細節，運營人員寫好使用說明文檔和宣傳文檔，研發人員的用例圖和代碼設計和數據庫設計）～開發～測試和產品驗證～產品上線

所有的修改需求和添加需求下個版本迭代，除非有特別涉及到影響使用流程的需求。影響流程的問題提早發現會減少開發時間，問題發現得越晚，修復時間越長。產品迭代的需求以及優化部分，需要詳細的記錄以免忘記自己的設想，可以通過訪問客戶建議以及團隊討論方式開啟迭代方案（需要參與人員：開發人員，測試，產品，市場人員以及運營人員），最好要有市場調研結果（這個可以省略，但是涉及到操作習慣或者流程發生改變的情況下這是必須的），做好會議記要。

為什么要迭代？在這個網絡研發暴漲的年代，速度決定生存，先開發出一個版本，雖然它不夠漂亮，雖然它不夠成熟，但是它可以隨著用戶的反饋和不斷的完善自己，他會是一個非常好用且得到用戶信賴的產品。
我的敏捷開發，快速迭代的方針主要適用于，用戶量達到一定，為解決一系列問題快速開發，收納用戶建議和大家的使用體驗快速迭代升級產品，使之達到成熟，從而擴大市場和用戶量


對話小插曲（笑岔氣）
產品：這個大概什么時候可以搞完
me：半個月。。。
產品：emmm，太久了，用戶等不了那么久，急著用，這是一個特別好的功能
me：一周半
產品：這樣吧，一周，我相信你的
me：…（一剪寒梅，傲立雪中。。。）

測試：這么多bug，我感覺周六加班
me：別怕，我今天可以干掉十個，哼，都是些小bug
測試：我就看你這種臭不要臉，還死撐
me：呵…
晚上…
me：咳，九個，極限了（吐老血中…）

產品：你覺得這樣改如何
me：還行，我感覺還少了點什么
產品：這樣，我們問問前端
前端：要不在這兒加一個這個吧
嗯，可以
良久…
產品：我還是覺得那個版本好一點，要不改回去
前端：行吧（我..what..what the f***）

產品：這個需求你看看
me：為什么不直接顯示，一定要彈出來嗎
產品：其實你的想法和我的一樣的，他們說這樣做用戶的眼睛聚焦在上面的文字內容上面……
me：哦（聚焦？數碼像雞？他說的啥）？？？可以啊，就按照這么來做吧
產品：要不要前端協助下
me：不用，我可以搞定（侮辱誰呢，我的前端可是干大事的，這種小功能分分鐘）

寫在最后：我經常跟我的產品說的一句話就是：功能什么樣的都可以實現，只是實現復雜度和適應架構的問題，這個功能要做考慮的地方在于用戶使用情況和系統損耗是否利大于弊。
既然把這個功能交給我就請相信我，不會的我可以問我可以學，因為我對學習愛的深沉。
希望和大家交流心得，同時還望各位不吝賜教，下方留言討論

總結

以上是生活随笔為你收集整理的开发后的思考与分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。