2012/04/18

[好文推薦] 產品經理和開發工程師的「功與防」

不論是開發工程師、視覺設計師、使用者經驗設計師或是任何專案的角色,常都會有跟產品經理(PM)「拉扯」「溝通」的不愉快經驗,雖然很多時候只是立場角度的問題,但怎樣讓專案是順的、溝通起來是愉快的?這可是門學問。

這篇寫的很不錯,推薦給大家~~

網址:http://www.css88.com/archives/4545

內文轉貼如下:(若不適合全文轉貼,請再通知我)


產品經理和開發工程師的「功與防」

時間:2012年04月16日作者:愚人碼頭查看次數:601 views評論次數:4

看andy 的《PM如何突破工程師心防?》和《工程師如何不被PM欺負》感觸了一下,歡迎拍磚,討論。
從團隊角度說產品經理和開發工程師應該是一條戰線上的兄弟,因為大家的目標是一致的。無論是產品經理和開發工程師大家都想把產品和項目做好,這裡我們可以說:「志同」。
但是產品經理和開發工程師因為在產品開發過程中所扮演的角色和工作內容不同,而且可能相互不了解工作內容,期間會有很多溝通的成本,溝通不是說話,而是改變行動。真正的溝通者關注溝通的效果。在溝通時,重要的不是你說了什麼,而是對方理解了什麼,所以對方的反饋非常重要。往往很多產品經理和開發工程師的溝通會出現「驢頭不對馬嘴」大家相互聽不懂的情況,甚至會導致小摩擦,這時我們說:「道不合」。
「道不同不相為謀」,必定導致意見不一,甚至帶來工作上心情不愉快的影響。不管是產品經理和開發工程師哪一方強勢,或者在「交戰」過程中哪一方「得勝」,勢必會給另一方造成消極影響,甚至頹廢。導致的結果總會是這個產品或者性能,或者其他方面總是會有不盡人意的地方。項目結束,考核績效或者項目總結的時候又會把責任推到對方身上,接下來就是大家相互抱怨,指責。然後產品改進時又是下一輪的「戰爭」;長此以往,造成的影響不是產品做不好,不是主要的後果,這個產品做不好,我們可以改進,可以做下一個產品。最嚴重的後果是,團隊分崩離析,一盤散沙,沒有凝聚力。沒有凝聚力的團隊是絕對沒有戰斗力的,是絕對做不出好的產品的。這對團隊和公司來說是致命的。
雖然很多人都明白這些,然而,這樣的「戰斗」或者產品經理和開發工程師的矛盾卻時時刻刻在發生!大家可以看看知乎上兩個問答:
1.《產品經理最討厭開發人員的哪些臭毛病?》 http://www.zhihu.com/question/19629183
2.《開發人員最討厭產品經理的哪些臭毛病?》 http://www.zhihu.com/question/19628273
如何解決這些問題,請看andy 的《PM如何突破工程師心防?》和《工程師如何不被PM欺負》,雖然在實際的過程中你未必能做到,但是至少我們可以從中得到一些啟示。
=================================================

PM如何突破工程師心防?

PM常常遇到一個難題,就是有好多東西想要做,到無奈什麼事都得透過工程師,沒辦法自己動手,於是因為和工程師不太美好的關系,最後實際的產品都沒有設計時看起來好。我這邊講的是「網路公司」的狀態,PM泛指那些規劃出產品的人。其他產業也許也有類似情形,以下這些「教戰手則」,提供給正在摸索自己生存之道的PM一些參考。

  1. 先弄清什麼做得出來、什麼做不出來:
常常有PM會提出一些天馬行空的idea,以致有時候讓工程師覺得合作起來相當吃力。這是由於並不知道什麼可以做什麼不能做。以網站來說,這其實很容易知道,不需要太多的學習和知識。如果有一個功能,你在兩、三個網站都看得到,99%它是做得出來的。例如你想要有一個頁面,填地址時選完「縣市」,下一個選單就會載入你選的這個縣市的行政區。如果你做些功課,就可以發現這樣的表單在很多網站都出現過。那99%就是做得出來。如果你想出一種呈現的方式,從來沒在任何地看過,那就比較有可能是做不出來的。在對工程師溝通時,假如你想做一個像這種選「縣市」的下拉選單,你最好請工程師去看別人的那個網頁,而不是用你自己的方式描述。工程師通常有不想輸的性格,如果別的網站做得出來,他不會想要自己做不出來。
  1. 永遠不要和工師辯論任何和技術有關的東西:
當PM能學一點點網頁的概念是好的,但跟工程師合作,你可能常常會聽到「這很難做」的feedback。它可能代表幾種不同的意思。可能代表真的很難做,也可能代表他不想幫你做。如果是第二種,有很多種方法可以讓他妥協。但戳破他和找他辯論絕對是最差勁的方法。當他說這個技術上有困難時,絕對不要跟他說「這個只要… 就可以了呀!」這樣也許讓自己看起來比較聰明,但你們的關系已經完蛋了。而且工程師的性格容易有非常強的自尊心,所以千萬別這麼做。而且,technical的領域,你可能永遠也辯不贏他。很多「這個不能做」的問題,不是來自於理性,而是來自於不想、不願意、覺得這個沒意義、或真的很花時間。真的要做的話,99%的東西大概都可以做。因此當這種看起來由technical角度來拒絕你的狀況發生,如果你真的很想堅持你的想法做下去,請試著脫離technical的討論,你該了解他所提出technical的障礙,但絕對不要和他在這個領域上辯論。因為你辯贏或輸都沒有任何好處。
  1. 工程師喜歡你去求他:
工程師很容易有某一種性格,是坐在那邊希望大家都去拜托他。所以你不難想像要讓這種人幫你做事的方法就是你要放低你的姿態。你要讓他覺得是你需要他,不是他一定要幫你。即使你心裡一直想「公司付你錢來上班本來就是要做這些的…」放低姿態。也許身為PM的你,在每個project有進展的時候和卡住沒進展的時刻,拿飲料點的menu去問工程師要喝什麼是個好方法。
  1. 把所有credit歸給工程師:
在公司裡,因為很多產品是由PM規劃的。因此project的成功,大家很容易覺得是PM的功勞。請努力在任何公開的場合、email,把這些credit歸給和你一起合作的工程師。同樣一個spec,一個心情好的工程師,可以把它做成100分。一個心情不好的工程師,可以把它做成60分。兩個都可以100%符合你的spec,但是一個可以爛到有無數問題。因為軟體不是事前可以想清楚的。所以一個不開心的工程師,可以看到許多問題但「視而不見」,也不主動來跟你說,那你就完了。所以一定要讓全公司的人都覺得這些成就屬於工程師的。你把credit拿走一次,下一次你就完了,因為沒有人想為你賣命了。
  1. 不要輕視「工程師的project」
你合作的工程師可能說他現很忙,因為他正在「重寫一些function」或是「讓資料庫的速度快一點點」。很多PM在聽到這些的時候,並沒有很知道他們在做什麼,於是表現出來的會是對這些project沒那麼在乎或什至不覺得他們重要。通常工程師最喜歡做這種隱性的project。因為他們可以不用聽PM的指揮。對於一個健康的公司來說,一定會有一定比例的資源投在這些project。要不要做通常是由老板,或更懂得這些東西的人來決定。但你一定要在工程師的面前讓大家覺得你看起來對這些非常認同。
  1. 姿態放軟,但不能失去主導權
雖然前面說你姿態要軟,但你絕對不能把你的project交給工程師後,你就失去了主導權。因為這樣會讓你在老板面前,看起來變得沒有太多價值。你最少要繼續掌握你project的「時程」和「內容」。也就是你一定要維持你的「主導權」,對該堅持的東西繼續堅持,對一些東西妥協,但不能全交給工程師決定。
  1. 不要finalize所有設計後,再交給工程師
絕大多數的工程師對這樣的流程很反感,所以請想辦法在設計階段,就去請教一下工程師的意見。他也許說他很忙,你想就好。即使只是得到這句話,都有很大的價值。這表示他放棄了他未來因為你在project早期沒找他先過過,以致他責怪你的權利。

總之,因為工程師的心情很難捉摸。所以「情緒」的處理問題,可能比「技術」、「功能」上的討論都更為重要。如果你喜歡這篇文章,也許你可以再讀一讀這篇的「相反版」:工程師如何不被PM欺負?

=================================================

工程師如何不被PM欺負


老師教我們怎麼寫程式,但從來沒告訴我們在公司裡,會有個叫做PM的人每天分派作業給我們,還逼著我們趕快做完。這是許多軟體工程師進入職場的第一個驚喜。隔了不久,還會發現,這些可能把你壓得死死的PM,多半一行程式都不會寫。於是我們會面臨一種很矛盾的心情,有時候會是一種有點被欺負的心理。這篇文章是前一篇文章PM如何突破工程師的心防的延伸,我們討論的是工程師在這樣狀況下的生存之道。

(1)提高自己的能見度
在非常多的公司,上層的老板或公司的大老板只看得到一個project的PM,而看不到背後辛苦的工程師。也就是說,你的努力和成果,被遮敝了。我一直相信在職場上,讓自己在老板或其他同事前有「能見度」是重要的。能見度除了在很多狀況下(會議發言、討論…)可以顯現出來外。提供一個我有個朋友很厲害的一招給各位參考。身為一個工程師的他,在每個大的project進行完後,都會「不經意」的寄出一封「謝謝信」給參與這個project的每個人,順便cc給本來根本不知道他在做什麼的大老板。信裡面一一點名感謝每個人給他的指導和這個project的協助。這種信每個人看了都很高興,最重要的是最後大老板也對他有了深刻的印象。

(2)不要每天只埋頭寫程式:
工程師大部份很喜歡埋頭寫程式,因為這是自己最擅長,也是最不花力氣的事情。但如果你每天100%時間寫程式,我保證你會自我感覺良好,但是所有人都不知道你在做什麼。所以也許該換換策略,讓自己的時間有多一點的部份是用來「表現自己」。「表現自己」不代表做一些表面功夫浪費時間。而是以你的角色,來參與討論,給出有意義的建議。工程師很喜歡只用電腦和其他人溝通,想要進度都用一個系統來追蹤,想法都用email來討論。在職場上,很重要的是你要學習少用email,多走過去和那個人說話。也許走過去多花了1分鐘,但是你和其他人互動良好,會讓你在職場上過得比較順利。

(3)站在老板的角度想事情:
工程師由於角色的關系,非常容易會站在「技術」的角度想事情,但往往常被主管否決而覺得灰心。公司的想法通常和PM的想法比較接近,都是站在公司的利益想事情,極少用「技術」的角度想事情。你要試著跟他們想的一樣,你的日子才會過得快樂。舉例來說: 假如我們公司現在要輸入10000筆資料。有兩個方案,方案A是「手動輸入」,方案B是「用程式自動匯入」。方案A要請10個工讀生,一筆一筆輸入幾乎都沒有差太多的資料。方案B是支無敵厲害的程式,你開發一天,程式跑3秒鐘就全部完成。但評估起來方案A的總體成本比方案B還要低。我相信極大多數的公司經營者,都會願意找來10個人,做著重復的事情,一筆一筆key in資料。如果你以工程師的角度來想,你可能會覺得「這個這麼簡單,一支程式就好了」,然後開始覺得老板選擇方案B真迂腐。你要試著讓你的大腦跟公司的利益sync,這樣會讓你好過很多。因為絕大多數的PM都知道他們的大腦要怎麼跟老板sync。在老板面前讓自己顯得比PM聰明的方法只有一個,那就是大腦和公司利益的sync做得比PM還徹底。

(4)用PM害怕的弱點有效去爭取更多開發時間
PM很喜歡每個東西都如期上線,如果提早上線就更好。很多人會因為deadline而跟PM翻臉,這是不智的。回到我那位工程師朋友的例子,他會和顏悅色的對PM說「我可以每天熬夜來把它做完,有可能可以如期上線,但我知道它會出現很多『我們』現在都沒想到的問題,那可能會讓老板(或客戶)覺得我們很不仔細。但如果你可以幫我爭取多一點時間,我可以讓它品質好很多。」對PM來說,除了要「快」以外,東西如果出來很爛,也打到了他的痛點。我的工程師朋友用這個方法幫自己爭取到了比較長的開發時間,和更好的睡眠。

(5)用PM的語言和他溝通
很多工程師會習慣用自己的語言和PM溝通,於是造成溝通不良。我們得試著讓自己對他們的談話,是世界上任何一個人都聽得懂的語言。盡量少提技術的術語,盡量少讓PM覺得你用你的技術優勢在打壓他。因為PM不可能學會工程師的語言,所以你們唯一能溝通的可能,就是你學會用PM的語言。

(6)變成工程師團隊裡面最受PM們歡迎的人
你會發現,如果叫PM們投票,從最喜歡合作的工程師,排到最不喜歡合作的工程師。大家的清單常常非常一致。而且你會發現,在清單名列前矛的人,通常在職場上容易步步高升。所以,想辦法變成那個人吧! 因為PM們對你的評價,往往在公司裡,和你的工程師主管對你的評價同樣重要。

(7)上班前三個月,不要試著改變公司任何東西
公司的系統、公司的project、流程,所有的東西。會是現在這個樣子,都必定有它的原因。有理性的原因,也有不理性的原因,也可能它的原因就是沒有原因。但絕大多數的公司找你進去,是想要你把一個東西,在他「現在的架構」下開發出來。在前三個月,如果你覺得大家用的開發環境很爛、測試的流程很爛、任何平台很爛。請先忍耐一下,因為除了非常非常open minded的主管和同事,絕大多數的人不會對你剛進來就想改變一切的想法太歡迎。

(8)歸功給PM:
EQ好的PM會把project歸功給工程師。但做為工程師的你,如果EQ夠好,應該再把它歸功給PM。不要因為這是你寫的code,就認為這是你自己做出來的。因為這樣除了自己感覺良好外,對職場生存沒有幫助。想辦法「言必談PM」。把自己和PM當成一個team,這個project是我們一起做出來的。雖然很多PM會戲稱自己是在旁邊幫忙打雜的,但是他會很感謝你很體貼的把一些功勞歸於他。

(9)不要為了enjoy自己的成就感,浪費公司的資源
很多工程師喜歡把公司當lab,去試驗一些新的技術。如果這對公司「真的有幫助」的話,那當然很好。在做這些事或提議前,請試著用老板的角度想,在公司利益最大化的前提下(而非個人學習或成就感),他會不會打從心裡支持你做這樣的試驗。如果不會,那就千萬不要做。因為在你做的很開心的同時,別人可能覺得這只是在浪費公司資源。

(10)變成一個更像PM的人
在技​​術上你應該向你其他工程師同事看齊,但在「性格」或「行為」上,通常你應該去模仿PM team的人。請相信我,在絕大多數公司,「性格」和「行為」近似於PM的工程師,在公司裡是最吃香的。

寫這篇文章,也許還會再得到一些批評。但我只是單純善意的,想告訴工程師們。我們應該提高自己的能見度,適度的讓其他人看到我們的表現。以及讓自己變成一個外表看起來像PM的工程師,通常在公司裡會過得蠻好的。很多工程師會覺得自己被PM欺負,但PM通常不會欺負長得和他們一樣的人。如果你喜歡這篇文章,也許你可以再看看這篇: PM如何突破工程師心防?
聲明: 本文采用 BY-NC-SA 協議進行授權 | WEB前端開發
轉載請注明轉自《產品經理和開發工程師的「功與防」

你認為使用者瀏覽器與解析度的偏好,已經落伍了!

你的產品用戶體驗中有考慮到境的改變嗎?
你認為使用者瀏覽器與解析度的偏好,已經落伍了!

來自網路分析公司StatCounter的最新統計數據顯示
從2012年3月開始,1366×768已經成為世界范圍內最受歡迎的螢幕解析度。在此之前的三年裡一直都是1024×768這一尺寸,因此可將其視為一種標志性的改變。

1366×768已經超過1024×768成最流行的螢幕解析度,絕大部分的原因是該規格是硬體出廠的最大宗,而不一定是user最喜歡的尺寸。

同時特別注意是,前幾名螢幕解析的加總,其實寬度1280的部份是最高的,
在做設計的時候,要記得把這點考量進去。

Source: StatCounter Global Stats - Screen Resolution Market Share




另外在瀏覽器版本,請停止再只做限定IE的功能與設計了!IE的比例已經只剩下1/3,不要排擠掉你重要的2/3的客人:
  1. IE             34.81%
  2. Chrome   30.87%
  3. Firefox     24.98%
  4. Safari      6.72%
  5. Oprea      1.78%

Source: StatCounter Global Stats - Browser Market Share

2012/04/17

[書摘] Web表單設計:點石成金的藝術 (美)Web Form Design Filling in the Blanks

表單設計有多重要?

  • 許多表單經過再設計,完成率往往提高10~40%
  • 如果表單填寫完成代表著「完成新銷售」、「獲得新用戶」
    改善表單設計 = 提高利潤

 

如何設計表單?

1.建構對話

用自然的、統一的對話,確保溝通一致性,適時適切的給予回饋。

2.內容組織有意義

問題盡量簡潔。
(必填的放主要步驟,選擇性的營銷問題用選填放最後)

3.歸納區別

用最少的視覺訊息,保持焦點在表單內容而不是形式。

4.清晰的視覺動線

5.別的表單/流程,不一定適合自己


詳細內容請見我的ppt



延伸閱讀:

2012/04/04

[好文] 把資訊架構當作是網頁設計的延伸

資訊架構是網頁設計的延伸,設計師佔有很多優勢,
將頁面群組化、替繁瑣的資訊定義類別並分類它們,進行框架設計。


 ---------------------------------------------------------------------------------------------------------------

把資訊架構當作是網頁設計的延伸




創意殺死創新?!

「創意、創新」並非與需求目標脫勾, 是能滿足基本需求、解決現有問題、在一定程度的學習轉換門檻下, 提升感受、實現令人有共鳴的點子。 如同業務在做創新服務、提供附加價值,成交是最基本重要的目的,如專注如何驚艷客戶確沒阻礙交易,就本末倒置了。


江湖有此一說:創意殺死創新