因為沖著產品的新功能,這段時間我?guī)缀醵荚诔怂X外,就一直在開發(fā)修復BUG、產品的打磨優(yōu)化。
藍泡這款產品從0到1,我看到有網友留言,希望看到我們的誕生故事,所以我今天開始開一個專欄,通過每周不定期的分享這款產品的打磨記錄,將那些肉眼可見的經驗總結為一些心得,分享給那些打算從0到1做產品的同學、或者創(chuàng)業(yè)者同行。
1.多個開發(fā)工程師不等于翻倍不少產品經理、創(chuàng)業(yè)者,會以為當你的開發(fā)工程師翻倍后,開發(fā)的效率也會翻倍,實際上不是這樣的。如果沒有開發(fā)協(xié)同標準,可能2個人等于1人,最多1.5個人。
開發(fā)協(xié)作首先是按照功能模塊分工,比如我們做藍泡創(chuàng)作有5個TAB,包含了首頁、素材庫、我的數據、我的原創(chuàng),不同的開發(fā)按照這幾個TAB進行區(qū)分。
如果沒有協(xié)同標準,那么代碼合辦造成功能丟失
我們經常會遇到,版本發(fā)布代碼合并造成功能缺失。原因就是某個功能沒有開發(fā)完成,其他功能的工程師就已經提前合并了,就會導致寫的部分被覆蓋了。
造成了新版本的功能并不全,要重新再合并代碼打包。
這也就是沒有協(xié)同標準造成的,尤其是多個開發(fā)在推進同一個產品,就算是不同功能,因為在同一個項目里。容易導致代碼合并出現這類問題,造成了每次提測功能不全。
2.全局交互提示不統(tǒng)一全局交互包含了產品的toast、按鈕、頁面布局、和搜索框等組件,而我們遇到最多的問題,是產品的一些彈窗提示toast不統(tǒng)一。
比如操作成功、失敗、加載中相關提示,在藍泡創(chuàng)作里,因為不同開發(fā)在開發(fā)不同的功能,就會用不同風格、甚至是類型文案的提示。
▲開源組件
前端開發(fā)組件 2個原因,第一個是每個開發(fā)沒有規(guī)范,自己只完成功能就可以,沒有UI的地方就自己發(fā)揮了;第二個是某些功能選擇開源,導致和現有的不是一套,自然就出現了toast、彈窗不一致的情況。
解決這個問題。產品經理提前和前端開發(fā)找到一套適用的框架,就可以確定其相關全局樣式。
這類問題比較集中在數據可視化上,比如市面上有非常多的數據可視化組件,入螞蟻等,這類可視化組件不需要UI設計師再去設計,產品經理直接確定字段就可以了。
3.操作沒有反應、或跳轉錯誤還有一些比較集中的BUG,就是跳轉錯誤或者操作沒有反應。比如藍泡支持設置公眾號封面,但是點擊封面設置卻沒有成功。
▲點擊操作沒有反應
這類的問題原因,要么是BUG,要么是因為加載速度過慢,用戶等待時間過長,讓測試人員誤以為也是沒有反饋。
解決這樣的問題,最好的是通過前期系統(tǒng)性的需求講解,來定義這類操作的前后結果。
4.UI還原除了前面介紹的全局交互,還有一大問題就是UI樣式還原。只要是產品經理出身做0到1產品,都非常關注這類問題,因為和UI設計圖不一致,就代表了需求沒有還原,產品沒有開發(fā)完成,產品經理是不能忍的。
造成這個問題的原因是開發(fā)團隊沒有嚴謹的前后端分離開發(fā)。一個全站開發(fā)喜歡先完成功能,再去調整UI還原。
這樣做的好處是開發(fā)速度夠快,壞處就是產品的完整度不夠。因此在大廠工作里面,我們才會將開發(fā)區(qū)分為前端、后臺開發(fā),增加了效率。
5.實際上線了,才發(fā)現的優(yōu)化需求還有一些不屬于BUG,屬于稱產品設計層面的問題了。
比如在保存模板上,我們允許用戶保存公眾號的文章作為模板,但是卻忽略了用戶模板的自定義問題,否則保存下來就是一篇文章,這樣會和我們已經有的采集文章有沖突。
▲圖文模板
所以上線后,我們針對模板的自定義名字進行了優(yōu)化。
造成的原因是前期沒有經過深入、細節(jié)的需求評審,就產品經理靠著自己經驗完成了,導致產品都被研發(fā)出來才發(fā)現有問題。
如何避免以上問題
1.需求評審與需求研究
上面的問題如何避免,我們可以通過前期團隊的需求評審、以及需求論證來避免。
但詳細的需求評審,容易造成把需求搞復雜了或者延期了需求的時間,因為越完善的需求,越需要花時間和成本,本質落地上也逃離不了更多的研發(fā)成本。
2.主動、提前深入到技術溝通
前面提到的全局交互和UI還原問題,都是需要在產品設計環(huán)節(jié)深入到技術層面去,和開發(fā)團隊一起技術框架,如果只是提出需求,什么都不管,那自然就容易出現后期的全局交互不統(tǒng)一問題。
以上就是最近我們做產品的一些心得,相信也是你也會遇到的。
今天的分享就在這里。
看完覺得寫得好的,不防打賞一元,以支持藍海情報網揭秘更多好的項目。