站在產品調研角度

只要產品經理做好了足夠的需求調研，而且假設產品需求已經足夠詳細，那麼只要著力於需求實現就可以了。而問題在於，產品需求沒有絕對的詳細，在一定程度上，我們甚至可以說今天早上使用者剛提的需求，到了下午就被使用者自己否決了。
那麼我們該如何避免在實現使用者需求中不斷出現的坑，由此來紀念一下過去幾個月從零開始接觸使用者需求調研到程式碼實現的過程。
首先，最開始使用者自己也不知道想要怎麼樣的介面設計以及具體的功能實現，比如我是使用者，這時候我提出了要實現上班考勤的需求，如果產品調研工程師只記了一條上班考勤需求，然後帶回去通知自己的開發兄弟們說，使用者今天說要實現一個上班打卡需求，讓我們開始愉快地實現功能吧。扯淡呢這不是，你沒被開發兄弟們打死就算不錯了。因為使用者只有一個模糊的功能需求，你應該用你的產品思維逐漸引導使用者的具體需求。
比如上面使用者提出的上班考勤功能，在記錄該功能點的同時，還應該再多問幾句，比如你們的考勤組是要使用者自定義還是每天都是固定的時間，考勤的報表彙總是一個月一次還是一個星期一次，考勤需要設定提醒嗎，如果要的話那是在考勤時間提前十分鐘還是提前半個小時提醒使用者別忘記打卡…總之需要問的問題還有很多，比如網頁呈現效果，需要通過考勤狀態這個篩選條件進行篩選嗎，只顯示當天的考勤情況嗎。
當你掌握了以上的需求資訊之後，通知你的開發兄弟們開始做這個需求，那麼至少不會把你打死了，在盡力滿足使用者需求的前提下做一個試用版給使用者體驗一下，之後你就會發現比較挑的使用者還是會提出整改需求，不過在有了試用版的前提下，使用者就有了比較，提出來的需求就會更加明確和具體。

站在開發者角度

有時候針對產品調研的結果，開發者需要作出的判斷是從一開始的能不能實現，到後來採用什麼技術實現，在此過程中需要不斷地評估技術難度和時間節點。對於產品經理佈置的研發任務，你首先要詢問自己是否真的理解了產品經理的需求。因為產品經理已經是經過使用者過濾的第二道傳達了，而到達開發者這邊就已經是第三道了，產品需求難免會出現偏差，如果你連產品經理的需求都沒有聽明白，那麼可想而知你距離使用者的需求會出現何種角度的偏差。最終產品成效，你需要通過的第一道難關也是產品經理，只有產品經理點頭了你才能下班(所以一般沒幾個人能正常下班)，當所有產品需求都達到了產品經理的預期，最後才有底氣向用戶進行彙報。

題外話

我遇到過的產品經理有一些是懂技術的，有一些是不懂技術的，現在很多人都說懂技術的產品經理才是合格的產品經理，但是從另一方面來說，從我的角度出發，我覺得未必是這樣的。我見過不懂技術的產品經理能夠把產品做得相當完美，也見過懂技術的產品經理最後把產品做砸了，這就要說到產品經理的個人魅力，溝通能力和理解能力了。首先需要能夠和手下的開發打成一片，而不是像網上那樣經常出現和開發打架的新聞，這就是個人魅力，你要信任你的開發能夠按時完成你佈置的開發任務，而不是經常去指手畫腳地指導開發該怎麼做。之後就是溝通能力，因為跟使用者之間的直接溝通是要通過產品經理這一道，最後才能到達開發，所以你作為中間傳遞者，你的溝通能力至關重要，你要使得使用者與開發之間的關係鏈完全打通。最後是理解能力，你要理解開發實現功能的難度和時間，也要理解使用者最終想要的產品結果。
總之，我很懷念實習時光跟第一位產品經理扯皮的日子，現在才發現產品經理其實是最不容易的那一個，前提是那個產品經理是優秀的。

System.out.println("Hello World!");