做產品的這一年里,我都踩過哪些坑?

9 評論 3659 瀏覽 25 收藏 24 分鐘

本篇文章是筆者以自己的親身經驗為例,總結了畢業(yè)后一年做產品所踩過的坑,希望可以大家有所幫助,并且能一起討論學習。

前言

踏入產品坑一年有余,經驗尚淺,只有微信H5和小程序C端經驗,沒有App和B端經驗。但是筆者認為產品都是相通的,只是由于平臺屬性的不同,設計和運營策略也有所不同罷了。

由于畢設主題就是交互設計,于是對產品工作產生興趣。

我畢業(yè)之后就一直在做產品工作,沒有專業(yè)導師大牛帶路,踩過很多坑,比如原型考慮不周,理業(yè)務流程了解不深入,導致開發(fā)出來的產品達不到預期,運營和技術也稍有抱怨,根本原因都在于自己沒有屢清業(yè)務邏輯并呈現(xiàn)出來。

最終,在經過一年的摸索,有了一些進步,但是路途仍漫長。

由于近期的工作將告一段落,所以對這一年多的產品工作做一個總結。

由于各方面的經驗都不足,必定有不完善之處。本文僅是筆者對自己踩過的坑梳理一番,和大家共享一下。

一、常見問題

1. 問題考慮不周全

記得我剛開始接觸產品經理這個崗位時,一度以為產品經理就是畫好產品原型,能畫出高保真原型的都是牛逼大神,特別崇拜。但是產品經理的核心能力不是畫原型,而是業(yè)務邏輯能力。

我最常見的問題就是問題考慮不周全,經常有遺漏。當初我第一次拿到需求時,也是直接開始畫原型(略過了業(yè)務梳理、競品分析和用戶調研,更沒有對當前版本進行優(yōu)先級排序和做好版本規(guī)劃)。

原型畫好之后也沒有需求評審就直接丟給了開發(fā),直到驗收時才發(fā)現(xiàn)流程不完善的地方或者開發(fā)出來的和自己設想的結果大不相同。

更夸張的是,需求臨時變更也是常事(這其中也有我的問題,把控不佳),不知道是不是創(chuàng)業(yè)公司都有這個毛病。

最后造成延期返工修改的后果,或者當前版本改動成本比較大,只能放到下一個版本去修改優(yōu)化。

從而導致團隊工作效率極低,而且由于需求經常變動和不合理性,讓開發(fā)情緒波動大,為什么臨近上線才來改改改,早干什么去了,這是誰的鍋呢?

只能是產品的鍋,最嚴重的后果就是對往后工作的開展造成很大困難。

小結:作為產品經理,應該在繪制原型上要投入較少的時間,更多的時間和精力投入在前期的產品思考以及底層邏輯上面問題要考慮周全。

結合需求理清產品邏輯,把各個對象之間的關系縷清,從哪里來到哪里去,讓每個功能都能形成閉環(huán),最后才會有較少的修改;做好版本規(guī)劃,每個版本涉及什么功能,為后續(xù)迭代預留空間。

組織相應的開發(fā)人員,對當前版本進行評審,根據最終達成一致的想法落地成原型和文檔,以防出現(xiàn)后期被告知需求不能實現(xiàn)或者實現(xiàn)成本過高;溝通的時候保持同理心,增強團隊協(xié)作的信心,提升工作效率。

2. 沒有思考地照抄競品

競品分析是產品經理的常規(guī)工作,競品分析的目的是:從商業(yè)模式,迭代思路和運營策略等方面來對競爭對手做到知己知彼,從而提出針對性的策略來提高自己產品的競爭力;選取競品可借鑒的地方,對本品做出改進等等。

但是競品分析工作我很少做,由于在創(chuàng)業(yè)公司,也沒人要求我去做,因為需求本身就很多,沒有那么多精力去寫競品分析報告,不過我經常到各種論壇上看別人寫的競品分析,偶爾會動手寫,頻率不高,一般是兩個月1篇。

雖說競品分析報告沒寫,但是競品還是會長期關注的。在產品設計的過程中千萬不能盲目照抄,應該是基于自己思考的前提,在理解競品定位和背后邏輯后再根據自己產品,設計出符合我們產品的功能。

記得我設計第一個產品時,某些功能和交互設計參考了競品。在寫原型PRD時,由于圖方便,直接備注XX交互參考XX產品,你猜UI和開發(fā)看到這樣的描述是什么反應?或許是這產品確定帶腦子了?現(xiàn)在回頭想起也是覺得自己特別傻!

比如電商商城的商品詳情頁的商品收藏和加入購物車兩個按鈕是否都要同時存在,別人家都有這2個功能,所以我們也要加上?

答案是:不一定。如果產品定位是二手電商商城,用戶發(fā)布的商品一般數量都是極少,一般是1件,收藏后商品已經送出了,有可能就是白收藏了,前期可以先設計購物車功能,后面業(yè)務需要的話再加上收藏,并不是每個產品都要做成京東、淘寶那樣大而全,也并不是所有公司的資源都能支撐你做很多事情,我們需要根據產品定位和業(yè)務需求來設計合適的功能,不能盲目照搬!

別人家的產品一定是出于他的業(yè)務需求和產品定位去做的,背后的邏輯和我們的一定有所不同,在你自己都沒有深思熟慮的剖析出別人家產品和自家產品的差異點,以及優(yōu)劣勢時就直接照抄,是非常不可取的。

雖說“天下文章一大抄”,但是要有自己的思考,抄出不同才是可取的。

我非常認同一句話:“好的產品,都是有靈魂的,做產品即做人,體現(xiàn)的全部都是人性”。

這句話伴隨我工作了一年,然而剛開始做的產品并沒有靈魂可言,就是畫原型僅此而已。

后來我慢慢發(fā)現(xiàn),無論你是不是真的參考了其他產品,在和別人溝通的過程中,一定不要說“參考XX產品”、“XX產品就是這樣做的”,因為一旦說出這種話,就暴露出你的不自信以及你對業(yè)務需求理解不到位,間接說明你的能力還不到位。

3. 溝通協(xié)作問題

產品經理在工作過程中,大部分工作都涉及協(xié)作問題,和運營、設計、開發(fā)等部門都需要保持密切關系。

首先,在產品設計的過程中,需要考慮拉新、留存、促活、轉化等問題,所以在開展工作之前,需要和運營溝通好需求,明確目的和意義,并不是一個人就能做好的事情。

一個功能的實現(xiàn)方式有很多種,目的不同,設計的方式就會有所不同。

其次,在業(yè)務需求梳理好之后,需要和開發(fā)溝通如何更好地去實現(xiàn),保證各方對需求的理解都是一致的。

尤其當自己并不是非常懂技術的時候,就更應該謙虛的去咨詢開發(fā)同事,最后給出最合適的原型設計給到UI和開發(fā)執(zhí)行落地。

切記,一定要和開發(fā)同事及時溝通好需求,不要想當然,天真的以為只要開發(fā)按著原型做就沒問題。你能保證你的原型沒有任何漏洞,完美到極致嗎?你能保證雙方的理解都是一致的嗎?

所以溝通不及時或者需求理解不一致都可能導致協(xié)作失敗,最嚴重的后果就是后期驗收的時候不斷地改改改,在開發(fā)眼里就是你不斷的變更需求。

對于你來說,只是換個樣式、調整一下順序或增加個字段而已,但是對于開發(fā)來講,他們要調用不同的接口,查n個表,增加n個字段,換一種算法才能滿足你當前的需求甚至是重寫,于是產品同開發(fā)的撕逼大戰(zhàn)就會開始。

以前我總是傻逼地認為市場上都能實現(xiàn)的功能,那肯定都是能實現(xiàn)的。

確實都能實現(xiàn),開發(fā)還放話:只要給時間,都能實現(xiàn)!但是能實現(xiàn)的背后不代表著實現(xiàn)好,更不能保證流暢度和體驗度都能和阿里騰訊媲美,不是每個程序員都能很牛逼,不然早去BAT了,來創(chuàng)業(yè)公司待著干嘛?

所以我忽略了這些,能不能做應該去和開發(fā)溝通過后再做決策,做產品首先是要考慮全局,需要考慮團隊資源情況、上線時間等個種因素,要學會衡量,做取舍,在合適的時間做正確的事情。

最后,原型落地后如何有效地和UI溝通?我們應該讓UI清楚地知道產品的定位,根據產品給出合適的風格,否則你讓UI自行去發(fā)揮,到最后跟你預想的不符合,又得開撕。

有時候,專業(yè)的事情就要留給專業(yè)的人做,特別是配色方面,如果你不擅長視覺,就不要亂指點。

更重要的是設計規(guī)范是一定要有的(比如色值,使用場景,布局,字號大小等),避免開發(fā)完后怎么看怎么都不對勁,但是又說不出具體哪里有問題,無法標準化,后期改了又改,UI和前端同學可是會發(fā)飆的,特別是有些組件是公用的,一改就不是一個頁面。

4. 身兼多職,專注度不夠

由于我們是創(chuàng)業(yè)公司,我剛開始進入公司的時候,主要是接觸運營方面的工作,幫助公眾號寫推文,后面幫助老大整理需求,將老大梳理好的業(yè)務邏輯和流程步步落實成原型文檔。

由于人手不夠,我除了做產品還做過很多事情,新媒體運營,社群運營,測試,我全都干過,就差不會寫代碼了。

我的CEO有一段時間一直把我歸類為運營體系,因為公司沒有產品部。

雖然身兼多職,我也沒忘記自己的初衷,我總是和我老大強調,我可以輔助運營工作,但是我的職業(yè)規(guī)劃是產品,后面我慢慢的專注于產品工作,但是前期做了很多事情,有新功能上線時,推廣文章都是由我自己來寫的,甚是無奈。

所以你要明確自己的目標,專注自己所想做的事情,雜事也無法阻擋你喜歡做的事,甚至會推動你成長,別人也才不會一直讓你做很不屬于你的事情,千萬不要忘記原來的初衷,否則你在雜事中將會無法脫身。

我離職后,公司也成立了產品部,認可了產品的重要性。

二、做正確的事,把握主動權

學會做正確的事情,平時要自己多思考產品的方方面面,將所有的流程全部放到腦子里過N多遍,盡量保證最后拿出的原型是完善的,不要給團隊埋坑。

在跟開發(fā)交流中,開發(fā)問你的問題,你都要清楚準確地回答,不能給出模棱兩可的答案,更不要輕易讓開發(fā)幫助你做決定。否則,在后期合作過程中,開發(fā)會容易按照他自己的想法來做,你就漸漸少了話語權,做產品要把握主動權才能推進項目。

我們公司開發(fā)前期是直接按照原型來開發(fā)的,甚至是1:1,分毫不差,這時候你要是真的由于某些流程考慮不周而導致延期返工,這就是你的失誤了。

如果開發(fā)非常了解業(yè)務,這就會好辦一些,他們還能給你一些反饋。所以無論何時何地都要做正確的事情,時刻主動關注開發(fā)進度,實時跟蹤,不斷地和開發(fā)進行溝通,才能使產品更加完善。

我之前在設計一個拼團領取免郵券的功能,自以為某些判斷開發(fā)會加上,但是開發(fā)并沒有加上,導致驗收時需要花時間修改,本質原因還是我沒能提前溝通備注好。雖然后面把坑填上了,我也是體會到了要學會做正確的事情,把握主動權。

不要以為開發(fā)清楚就不備注,除非你和他強調過這些,不然開發(fā)有時候也會忘記的,有時候忙著上線,任務重,并不是人人都能面面俱到的,要互相體諒。

三、發(fā)現(xiàn)問題,要及時提出并解決

在產品工作中,我們會遇到各種各樣的問題,發(fā)現(xiàn)后就要及時提出并解決,問題越早發(fā)現(xiàn),解決越簡單,如果一直棄之不理,后面有可能是個定時炸彈。

我們需要具備解決問題的能力而不僅僅是提問題的能力。問題的來源有很多,主要有如下:

1. 因為自己的疏忽沒能考慮到,開發(fā)過程中或者驗收時才發(fā)現(xiàn),提出來可能會被大罵一通,但是自己的失誤就要勇于承擔,自己踩的坑,就算哭也要填上,這是工作態(tài)度問題。

我第一次接觸UGC時,只考慮了一般用戶的正常流程,而忘記了發(fā)布者本身,忽略了不同角色的商品詳情頁面的操作按鈕需做不同判斷。

那時候沒有任何人指出這個問題,我是測試時才發(fā)現(xiàn)問題(公司沒有測試,所有的測試都是我們自己來)。

于是后來我就直接告訴開發(fā),這是我的問題導致的,修改所有bug之后麻煩幫我加上判斷,所幸我態(tài)度比較好,開發(fā)幫我加上了,也及時上線了。

2. 因為上級或老板非常嚴格,一心堅持自己的想法,提出的建議經常被批評或者否決,于是選擇默不出聲,完全按著領導說的做。

如果你的目標不是做好一個執(zhí)行者,而是想做決策者——你可以準確的把握時機,合理清晰的闡述自己的觀點,該決策的學會拍板,決策不了的就表明自己的觀點,也可以組織團隊討論給出最后決策,但是最后的決策還是在老板手里,我們說到底還是搬磚的。但是我遇到的老板是很好的,當你可以提出比較好的方案時,他會認可你的方案并同意執(zhí)行。

剛開始工作的時候,某些想法不是特別成熟,也有可能是表達能力欠缺,沒有很好的將自己的想法勇敢地提出來。

在做拼團功能時,老板說在拼團頁面,新用戶通過分享鏈接進入,直接彈出新人福利彈窗,這樣的流程其實是不友好的,因為這樣會被分流,用戶看到彈窗就會進入新人福利頁面,可能到達不了拼團頁面,也就達不到拼團助力的效果了。

其實可以調整為在拼團助力之后再彈出新人引導彈窗,達到拼團助力也同時起到新人引導的作用,在用戶拼團助力過后還能領取額外的獎勵,這個用戶體驗才是比較友好的。但是當時我可能是沒有完全想好,所以沒提出來,導致測試時發(fā)現(xiàn)體驗度非常差,后來還是決定在下個版本進行了優(yōu)化。

3. 有些問題和我們關系不大,但是為產品好的,我們都應該提出來。我們不要怕得罪同事,就事論事,不針對個人,這樣做出來的產品才不會讓你抑郁。

比如視覺界面設計時,我看UI怎么看怎么不順眼,但是我在這方面并不專業(yè),于是我去看了其他大廠的設計基本規(guī)范,一般配色都只是一個主色調,一兩個輔色,而我們的顏色卻過于豐富。

我沒有直接質疑UI,而是把規(guī)范文檔發(fā)給她之后,后來在和UI協(xié)商過后,進行了修改。

如果當時我認為那是UI的工作,不關我的事,那最后成品不佳也是有的責任,還是自己的工作不到位。

只要本心為產品好的,你愿意提出你的建議,你才是真正的產品人。

在整個產品周期里,從產品→設計→開發(fā)→上線,產品經理就擔任著非常重要的角色,要實時跟進,更要對自己的產品設計進行檢查。

但愿大家都能少踩坑,發(fā)現(xiàn)問題能馬上解決的就趕緊解決了,當前版本改動太大,就記錄下來放到下個版本去解決。

四、做產品還是要懂技術的

我是電子商務專業(yè),學過一些基礎的技術知識,但是只能勉強考試及格,實際操作還是不太懂,更不會寫代碼,我記得當時的html5和C#的作業(yè)考試還是從網上東拼西湊完成,很多原理都不太清楚。

我剛開始的時候甚至聽不懂“打印”、“寫死”這些技術黑話,因為不懂技術,我也經常被開發(fā)懟過,甚至被質疑腦洞清奇。

編程學習成本很大,但是基本的技術知識,我們一定要懂,否則在溝通交流時會很吃力,開發(fā)告訴你不能實現(xiàn),你不知道為什么?

我記得當時我有一個很好笑的回答:“為什么別人就能做出來,你們卻實現(xiàn)不了?”開發(fā)直接回懟:“那你找他們去呀,找我干啥?”

如果產品懂技術,就不會有以上對話。

為什么產品經理要懂技術?因為這樣我們在提產品需求時可以有一定的同理心,能用開發(fā)思維去考慮問題,減少自以為實現(xiàn)很簡單而頻繁改需求的情況。

比如我們公司產品主要是微信小程序,我就需要搞清楚微信小程序開放的接口是否支持我想要設計的功能;兼容性是不是支持視頻播放,能實現(xiàn)的話用戶體驗如何?每個字段參數代表什么,可以獲取什么用戶信息(地理位置,微信頭像昵稱、微信運動步數等),數據從哪里來?模板消息如何發(fā)送?

說實話,我一開始真的不知道小程序的formID的有效期只有7天,而且是觸發(fā)一次只能發(fā)一條,導致后面開發(fā)說通過這種方法并不能保證每條消息都能發(fā)送給用戶。

除此之外,還需要了解的是有什么微信組件可以為我們所用,不需要重復去設計。

比如地址可以直接調取微信地址,不需要設計,如果想提供更好的體驗,可以同時提供自己設計的地址功能和調用微信地址。但是前期項目比較趕的話,可以直接用現(xiàn)成的即可,

另外,由于建立在第三方平臺,你要時時刻刻關注微信小程序規(guī)則,例如微信分享機制有變動,不能直接獲知用戶是否分享完成,也無法在分享后立即獲得群ID等;獲取用戶授權信息必須通過點擊事件觸發(fā)等等,這些我們都要清楚地知道。

如果這些只有開發(fā)知道,你卻不知道,那在產品設計上就會不符合規(guī)則,后面則要返工修改。

這些還好,如果是產品給到開發(fā)的需求和定義不清晰,模棱兩可,那才是要命的。

沒有用開發(fā)思維去思考問題,停留在前端問題上而忽略了實現(xiàn)邏輯,脾氣好的開發(fā)還會找產品經理反復確認,但是有些開發(fā)為了節(jié)省時間就會直接按照自己的想法去做。

比如你想按照狀態(tài)來區(qū)分,鏈接是同一個,而前端有可能做成兩個頁面而并非按照你想的來做,這些你在前期就要和開發(fā)同學交待清楚,包括新用戶的定義和其他條件定義等。

所以說產品還是要懂一些技術的,這樣有利于溝通交流,更好地實現(xiàn)需求。

產品經理是一個極具挑戰(zhàn)的崗位,只有你不停地學習和思考,才不會落后。尤其在互聯(lián)網下半場,除了懂技術,你更要懂運營。

產品這個崗位是要為公司賺錢的,流量是運營的基礎,不斷地學習,才能跟上社會的步伐。

做產品的這一年里,感觸頗多。產品這條路對我而言還是很漫長的,不忘初心,努力成長,希望能有和各位產品朋友有交流互相學習的機會,萬分感謝!

 

本文由 @從小吃米飯 原創(chuàng)發(fā)布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協(xié)議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 寫得好好,受益匪淺

    來自天津 回復
  2. 深有感觸,不忘初心,努力成長。

    來自山東 回復
  3. 請教下,有沒有比較適合產品經理的技術類書籍可以推薦,相對比較淺顯一點的。

    來自湖南 回復
  4. 作為半路出家的產品經理,并且完全不懂技術的人,我來說幾句吧。
    1、看到樓主講述的經歷,自己也是略有感觸,對于不懂開發(fā)技術的人來說,確實很依賴開發(fā),所以好的開發(fā)人員,公司應該多珍惜,想辦法留住人。我之前從事手機行業(yè),現(xiàn)在轉戰(zhàn)物聯(lián)網行業(yè),做智能設備,接觸的軟件開發(fā)不僅僅是APP,還有FAE、WiFi模塊開發(fā)等,每次搞都是三方聯(lián)調,比做純APP苦逼多了,任何一方出現(xiàn)問題都會導致所有人停工。。。之前公司用的是某外包平臺公司,開發(fā)質量呵呵呵,好在現(xiàn)在的APP開發(fā)用的是虛擬團隊,可以理解為有幾個大神專門給我們做項目,實在是省心到不行,都是30K以上的月薪級別大神,我從來不需要擔心技術問題,從來不需要擔心開發(fā)會搞出簍子,反而他們做事得心應手,對于產品經理提出的東西,都能夠理解透徹,所以說好的開發(fā)人員,對于項目開發(fā)是十分重要的。我只能說樓主前東家開發(fā)不怎么樣了,不是說技術不行,也許是心態(tài)問題。為啥別人可以做,你不能做,這個問題是可以問的,開發(fā)可以說出原因,我覺得大家有什么問題都是可以溝通的,當然問的時候,也要改變下,例如為啥別家實現(xiàn)了這個想法,咱這邊是因為什么限制,導致不能實現(xiàn)嗎?可以這么問,畢竟開發(fā)才真正知道原因,當然他也可以忽悠你。取決于人。與開發(fā)合作,注重溝通!注重溝通!注重溝通!足夠尊重!足夠尊重!足夠尊重!
    2、關于需求:其實并不是所有的項目都要完完全全寫好BRD、MRD、PRD、DRD什么的整套,主要看實際需求,如果我只有一個星期來處理需求,我是不可能全部都寫好的,需求寫完之后,還得驗證,我個人習慣是使用表格方式寫功能需求,每個模塊下有什么東西,什么功能,加上功能說明,可以寫的非常清晰、明了,開發(fā)一看就知道你這個有啥東西,配合高保真原型圖和交互說明,基本2個文檔搞定。如果對后臺了解,可以在表格中把后臺需要的東西也標注上,一般后臺開發(fā)喜歡看Word文檔,我個人超級討厭寫Word文檔,我覺得不僅浪費時間,看的還特別煩,開發(fā)都不一定看完,明明簡簡單單幾個功能,寫完之后自己都懵逼。。。我習慣原型圖與功能需求同時進行,原型圖可以把需求具象化,讓我更好理解功能、交互、排版及使用。
    我認為需求文檔是給開發(fā)看的,所以只需要寫清楚你開發(fā)這款APP是為了干嘛,都有哪些東西,用于哪些場景、怎么使用、通過什么方式實現(xiàn)即可。還有更重要的是:便于閱讀理解、便于迅速了解功能結構、方便查詢。文檔的作用就是為了讓其他人明白你要干嘛,就是這么一回事,至于形式、格式、用什么寫,都不是特別重要。
    3、關于原型圖,我所搞過的項目中,無論是外包,還是自己的團隊,都認為我寫的需求非常詳細、清晰,我是通過電子表格來列出功能的,需求其實就是多個功能的組合,來滿足某個需求,用電子表格來寫也沒有什么問題,反而功能共容易量化,對于開發(fā)評估、外包報價都是非常方便的。
    原型圖畫的約詳細、越清晰,開發(fā)對功能的理解就會越透徹,經驗豐富的開發(fā)只需要看到你的圖,就知道你想干嘛了,或者能夠對需求了解七七八八了。原型圖要盡可能畫完整,可以不夠精細,但是絕對不能少,原型圖也可以把業(yè)務流程體現(xiàn)出來的,還有就是UI有可能因為你少畫了原型,就不畫漏的界面了,跟外包接觸過,我深有體會,你后面想再加,就特么按照新需求,要收錢了。所以我不同意樓主說,不應該在原型圖上浪費太多時間這個說法,在我自己的經歷中,反而原型圖帶給開發(fā)的幫助非常大。我之前做過UI設計師,所以我出的原型圖都是達到UI的水準,即使UI設計師沒能及時完成設計,開發(fā)也可以按照我給的高保真原型進行開發(fā),后期再更新UI,也是很方便的。
    4、身兼多職,專注不夠,這個確實有影響的,我在上家公司,身兼產品、UI、交互身心疲憊。。。當然到了現(xiàn)在這家,也差不多。。。不過重點還是在產品這塊,平時也得做做設備引導GIF圖什么的,時不時還得自己修改UI設計。。。不過身兼多職也是有好處的,我相信你自己也能感受到。
    5、關于抄襲,互聯(lián)網產品還好,物聯(lián)網產品就比較普遍,為啥?因為APP功能都是根據硬件來定的,大家大同小異,我自己就把主要精力放在視覺、交互、用戶體驗上面,至于運營啥的實在接觸的少。不管是什么產品,有時候為了策略,適當的也需要抄襲的,像你說的,不能盲目抄襲,這一點我是同意的,出發(fā)點不同,同樣的功能,也會存在實用性不同。但是目前產品同質太嚴重了,有重合的功能也是很正常,正確看待這個問題即可。
    5、老生常談,產品要不要懂技術:當然懂更好啦,我要是會敲代碼,我還做個屁產品,3~5年開發(fā)工資高了去了,我朋友后臺服務器開發(fā),3年經驗,24K稅后工資,還是搞技術的混飯吃長久。說真的,問問自己,真的會做一輩子產品經理嗎?我其實對自己也是抱著懷疑的態(tài)度的。
    懂技術可以更好的開展項目,至少你知道哪些功能可以實現(xiàn),不需要再跟開發(fā)溝通,當然不懂技術就不行了嗎?不是的,不懂技術就需要多跟開發(fā)溝通,我個人就很喜歡跟開發(fā)聊這些問題,雖然我不懂,但是他們也很愿意跟我聊,我認為你抱著學習、尊重的姿態(tài)去跟他們溝通,其實他們還是很樂意跟你聊得,畢竟誰不喜歡被崇拜?對吧。一個團隊的工作氣氛融洽,工作效率也會高很多,同樣的溝通成本也會下降,溝通也會更加順利。
    個人經驗,有什么不對的,歡迎指正,希望也能告訴我正確的方式,讓我有所成長。

    來自廣東 回復
    1. 我也和外包接觸過,那個原型圖還真的要寫全,不寫全的后果除了撕逼不說,是真的要加錢?。。?!原型圖花少點時間,并不是說不寫全,業(yè)務邏輯梳理清楚之后會畫的更快。另外由于我們都是通過原型去溝通,該寫的都寫得寫,否則有遺漏就是自己的鍋了。感謝你的分享,有一些經驗深有同感??

      回復
    2. 以后多多交流,互相學習,哈哈

      來自廣東 回復
    3. 本小白看完以后~覺得很受教~很贊

      來自廣東 回復
    4. 大家都是互相學習啦,多分享點坑,啊哈哈

      來自廣東 回復
  5. 挺好

    來自北京 回復