有頭驢，它的任務就是一天到晚的推磨，這一天主人要求它把一麻袋黃豆磨成豆麵，
它磨了半天，終於在中午前磨完了。本以為中午能休息一下，但這時壞訊息傳來，主人
不打算用豆麵做吃的了，想改為用小麥磨麵做麵條。這時驢的午覺時間泡湯了，馬上又
要開始磨小麥了。
看完這個故事，讓我想起《澡堂老闆家的男人們》中的
大兒媳婦
，她在片中有一句經
典的不能再經典的話來形象她一天到晚在家裡不辭辛勞的勞作：「
我就像是一頭上了磨的
瞎驢」。的確，看了上面的那個故事再對比一下這句話，真是太貼切了。我想大家此時也
會很感慨的。
當需求（方）發生變動，甚至是天翻地覆的變化時，就意味著我們要修改甚至推倒重
來已有的設計架構方案了。而這無疑是很痛苦的。即使我們使用了不少「手段」（比如：
模式，架構等等）來響應需求的變化，但遇到了需求發生根本變化（需求分析出現重大
人為失誤）時，同樣會顯得那麼被動或無用。
如同我在之前一篇文中所說的，越早投入編碼，**死的越快。而越來提出需求，
需求變更的也會越快。這需求的變更一方面是市場的變化，一方面是人為因素。前者我
們無法準確預知，而後者卻可以通過一些方法部分加以控制。比如專業的諮詢分析，科
學的彙總，充分的調研論證，而這都是對人自身能力，行業背景，工作經驗的考量。現
在公司招的人五花八門，經常是專業不專業都招進來，然後通過短期培訓就上崗了。如
果這些人之前就有相關行業的工作背景那還好說，如果是新手，並且恰恰是新手來給你
提需求，要求你這樣那樣的話，那就真把我們當手他們的「練手工具」了。
當然，公司內部可能還有專門的部門主管來有效的規避這種情況的發生，當然如果
你能直接找出這些新手工作上的瑕疵起不更好，起碼你就不會那麼被動的在他錯誤的思
想指引下設計編碼了。所以這裡我會贊同下面文中所說的觀點，即「技術也要插手產品」：
想起了c++之父：產品與技術都要互相尊重對方的專業性
如文中所說，這是需要公司有乙個比較開明的「激勵和體制」，讓這些有產品業務
感興趣的開發者也能參與到產品的需求分析設計中來，而不是在編碼時才想到他們。
同時當開發者知道他們的開發出來的東西會提供給什麼樣的客戶，以及客戶對他們
產品的看法時，開發者也會第一時間了解到，而不是技術支援和服務部門打**來告之
他們（要知道資訊在傳遞過程中會有雜訊的），雖然這會新增開發者的工作負擔，但事
情是有兩面的，這裡面的好處相信大家也能體會的到。
說到這裡就要提到乙個非常重要的人物，就是"產品經理"，他是乙個要在公司內部
上上下下，左右逢園的角色，特別是在有技術主管（或經理）的公司，往往他不會有直
接管理的手下，而他的那些資源不管是人力，財力，行政還是市場，技術支援等都是要
努力爭取申請才能獲得，所以他要在各部門之間水平協調溝通，從而最終形成合力，把
產品做出來，推出去。這裡要求要本身要有行業背景，了解市場，熟悉技術（可做為參
考），更重要的就是：善於溝通。
其中在那篇文章的後半部分就討論了如果處理產品與技術之間關係的問題。當然這
裡我更傾向於將文中「產品」理解為「需求提供方」，也就是提需求的人。其時還是那
句話，產品和技術之間要相互理解，團結合作，最終把產品做好，贏得更多的口碑，掙
更多的錢。而互相理解的前提就是要對別人的工作先要理解，甚至插手（這裡不是為了
顯擺或干涉，而是真誠的參與）。
tags: 產品經理,產品,技術,溝通
**:
思考的技術與藝術
總的來說 1.人類的思維充滿著各種各樣的捷徑，每一條捷徑都是一把雙刃劍。一方面，它降低了大腦的認知複雜性 籠統的看乙個問題要比細緻的分析簡單得多 有助於迅速做出絕大部分時候都正確的判斷 但另一方面，它也常常導致人們把大部分情況下成立的法則當成了放之四海而皆準的。可以說，有多少捷徑，就有多少條謬誤。2...
與技術有關的生活思考
三年多了，作為一名老程式設計師一直很熱衷於技術，而奇怪的是對技術感興趣並不是從大學開始的，大學四年除了讀書玩遊戲就很少關注過it技術，在校期間也只是在02年net剛興起的時候參加過幾次宣傳講座，那時vb正火，但是參加過講座後覺得c 很牛，但就是這樣也沒能勾起對技術的熱衷，給個不很適合的理由吧 功課很...
20120809 對技術與產品的討論
趁著中午的休息時間，整理下昨天與同事的一些討論，昨天的討論收穫不小，也重新認識到工作的定位與價值。1 關於技術路線還是產品路線？同事與我應該都屬於先從事技術出身 到專案管理 再到網際網路的產品運營這樣幾個階段。近期由於在研究chromium的開源專案，在 研究的過程中非常枯燥 乏味，由此也帶來自己的...