工作當中需要好好說話

在工作中我覺得好好說話特別重要，給大家舉個測試和開發例子。

測試想提個Bug，說我發現了一個Bug

開發立馬否認：怎麼可能，不存在！ 

測試：不信你過來看一下！ 

開發：不用看，好的呢~肯定你環境問題，動什麼東西了嗎？

測試：....... 你不看我已經提給你了嗎？

開發：看不出來什麼問題，你怎麼操作的？

也重現不了啊，你想辦法重現，重現了再叫我，我忙著呢

測試：…… 

經理問：什麼時候能上線？

開發說：不知道，看測試什麼時候能測完。

測試說：不知道，看開發什麼時候能改完。

長期這樣必定會互相心生不滿，就在前兩天某公司的產品經理與開發互毆的事情鬧的滿城風雨。產品經理瞭解技術，有助於和研發人員溝通。但瞭解技術後提需求時，會權衡需求和實現難度。有人說產品經理提需求時，只需要考慮使用者需求，不應該考慮技術實現難度，這樣做是否正確？

這個問題要從幾個方面看：

1、從產品本身來看需要你確定這個需求的價值，可以從KANO模型，ROI投資回報率上來對需求重要性排序，優先做有價值的東西，時間來不來的及。

2、確定了價值，下面就是需求實現的問題，一般來說需求是有多種實現方式的。不僅僅是技術上的，還有其他表現形式上的。

打個比方，使用者說要可樂，基本的需求是因為渴了，而你如果提供礦泉水其實一樣能解決問題，這個需要你從本質上理解使用者需求；

技術上，實現一個功能，可能寫一個工廠方法就可以簡化很多事情，而開發也可以己腦洞大開過度設計（這種對於入門沒多久又有理想的程式設計師是比較常見的）。

這個在提需求的時候，提給開發的需求更應該說使用者story，而不是描述解決方案：規定好他應該怎麼做。同時儘量找開發領導提前溝通需求，這樣有可能他會給你一種更加好的實現方案。

3、最後就是努力充實自己，物件導向的程式設計思維可以多瞭解瞭解。產品經理的UML工具其實就是物件導向的思考方式，你可以不用管這個方法具體是透過寫了多少行程式碼實現的，只需要想通中間的邏輯是怎樣的即可。

這樣又可以反過來促進你瞭解：你的設計中有沒有遺漏什麼，下一版功能可以往哪擴充；從整體邏輯的複雜性推算功能的實現時間，對整體開發時間的估算越來越有把握，避免被開發忽悠。

每一個產品都是貝，提方案時強勢的外表，卻住著柔弱的內心。

每一個開發都是海，程式設計時安靜的外表，卻藏著波濤的洶湧。

總結一句話，退一步海闊天空，忍一時風平浪靜！！

那麼如果出現問題如何有效溝通，這就是我們為什麼要求測試人員要懂一點開發設計思路。可以不用精通，只要懂就比不懂強。

最重要的就是工作當中好好說話。