臨近年關，正在讀著蘇杰寫的《人人都是產品經理》，自己多多少少也做了幾十個專案（都是小滴了）。五味雜陳，很想倒一倒這其中的酸甜。對不對的地方，您就當聽戲了。
在開文之前，我先表明自己的身份。我是個後端，在小公司做php開發，現在基本上前後端兼顧。為了避免一些用詞的歧義，正文裡的一些專業英文詞彙我使用中文來代替，比如pm，
ui等。雖然我很菜，但不要以為我特別不專業。
一、誰是大boss
二，有問題該問誰?
開發人員是最終的執行人員，也就是最底層的了。在開發過程中有n個疑問，要去向誰討教呢，比如說，輸入姓名要不要檢查中英文，要不要限制字元長度，移動游標就檢查還是提交時檢查。
在說詞誰之前，先說說要不要問。大部分情況下不寫**的人考慮不了那麼細緻的問題。說不定，多一句提問就是給自己找麻煩，可是萬一人家真有自己的想法，或者在體驗了之後提出其他的方案那你就哭吧。所以，多問一句圖個踏實。如果到最後，領導白己改主意了，要求重寫，那就實在沒辦法了。
那麼回到原處，有了疑問需要問誰呢，如果還按誰給錢誰是老大的原則就是找抽了。老闆是花錢讓你解決問題的，可不是給你解決問題的。我提供兩個選項:a.問使用者/客戶，b.專案
經理/產品經理。說說兩個選項的不同吧，選a的好處是能得到直接的答覆，也能把自己的意見建議表達出來。因為客戶是
專案的受用人，所有的功能需求是為他們服務的，如果果客戶經由專案經理和產品經理轉答，那麼很可能做出來的東面不是客戶想要的，所以有了疑問應該與客戶直接進行溝通得到準確回覆嗎?起初我也這麼想，並且領導也支特，美其名日提公升理解力、溝通能力。可事實怎麼樣呢，你說的客戶聽不懂，因為客戶不懂技術。客戶的主觀意願你也get不到。另外，當你有疑詞的時候客戶不一定有時間，或者客戶很閒，他樂衷與你**技術，**使用者體驗、**產品運營，耗了一天，你的疑問還是沒有得到答案。因此產品經理多麼重要啊，他把客戶的意原轉化成具體需求，並且與專案經理與開發團隊商量後過濾掉不可行的部分，這是乙個聯通客戶和開發人員的
重要紐帶，不然，開發過程會異帶艱難，當然如果是很繁索的，又很明確的一些邏輯比如分配規則，可以與客戶直接對話:如果很複雜的部分，開發和產品可以共同與客戶進行溝通。其實，專案開始前，所有參與人員都會客戶有一次整個專案梳理的會議，涉及複雜的重要的流程環節是在幹始前就理清的。
三、開發團隊的目標一致嗎，
相對客戶而言，開發團隊的每一員都是在乙個陣營，都是為了讓專案在規定期限內完成交付。這就好於比乙個公司的員工與老闆是不是一家人，老闆經常這擇說，要把公司當家，視同事為兄弟，大家都是為了讓公司發展更好讓公司盈利，員工福利才會好。說的不能算錯，但是也不完全。老闆掙的是盈利、員工掙的是工資。老闆多掙幾倍，員工也就多吃一頓板，老闆虧了只要不是倒閉，員下工資不會少，甚至會感覺活少了工作更輕鬆。不過，應該沒人心這麼大，一旦設活幹了，就離走人不遠了。這麼說的意思是，人就是天性自私，不論做什麼，不論在什麼團隊在什麼公司。都是盼著錢多事少，做專案時也巴不不得這樣子。前面說了開發環節中的各個崗位。如果客戶在與開發人員的第一次溝通中就沒有任何問題，後期也沒有補充，專案理理和產品經理就等待開發就好了，坐享其成（事實上老闆肯定會找事兒的）。如果產品經理對設計的初稿就滿意，那設過肯定不亦樂息，反之則憤憤不平:如果測試不精挑細篩。那麼開發就絕不會精益求精。只要不背鍋
:誰願多幹活。換句話說，只要涉及不到自己，就都是吃瓜群眾。天塌下來，個矮的權當看戲、在設計一遍又一遍的返工時，前後端不會有異議
:當客戶的邏輯有變時，設計和前瑞絕不玩聲，如果即將上線的專案，要改樣式。前後端分離的專案前瑞哭，否則後瑞哭。客戶的目標是花小錢做無限功能，一輛自行車的鐵做一架飛機，產品和專案的標是客戶滿意，老闆滿意，所以在一定程度上，戶品經理也是希望做得越多，越快越好
:開發和測試人員，就盼著分到的工作越少越好，返工的工越少越好，背的鍋越輕越好。舉個例子，如果專案中，如果要生成訂單，客戶不要求，開發會把訂單生成做到最後一步，因為設計簡單
bug也少。但是產品會期望做成預提交，待支付訂單，待提交訂單，購物車，瀏覽商品等記錄；如果客戶不要求，開發可能不做軟刪除
:不做預統計，因為這樣不僅工作量小，而且能減少
bug少背鍋。有一次，產品跟我說在支付頁加個按鈕，我問什麼按鈕，他說打折按鈕、 然後，然後，我跟他**了折扣的**，使用限制，等一系列問題，然後加資料庫字段，加資料表，加操作日誌等。產品經理的錦上添花可能開發就要當牛做馬。但是換位思考。哪個崗位不是頭上架著一口大刀呢，有時候前端懶點後端就累死累活，後端懶點，移動端就流淚流汗。最好是相互理解吧。
四、合體亂象
前面說的都是外包公司，並且是標準開發團隊（相對我見過的）來說的。現實中是沒有標準的。比如乙個自有專案公司，提需汞的人是銷售和產品；給專案買單的的和給我們發工資的是同乙個人。我們暫且不用考慮緊張的工期，苛刻的交付環節。另外，還有各種各樣的職位合體就讓人眼花繚亂了。比如，運誰和後端合體，寫**和伺服器配置是乙個人；專案經理扣產品經理合體，跟客戶溝通跟老闆跟開發人員溝通畫原型分配資源的是乙個人；前編和後端合體，拿到設計稿就全部搞定；前場和移動端合體，h5頁面，
ios,android
一人搞定；設計和前端合體，自己造夢自己圓；後端和測試合體，自己的問題自己找並自己改；在我們公司，銷售、專案、產品測試是一樣的（很能湊和）；找還見過前後端，測試運維是一塊做的。反正五花八門，各種不專業就暴露了各種問題和矛盾，更有甚者全部合體就像個人站長。不管怎樣，不管怎樣的不專業，都要承認合體的關鍵優勢——省錢。現在網際網路競爭大，尤其林立的小外包，根本招不起
10幾個人的開發團隊，全棧才更受追捧。
五，不合理的需求
關於這點，就不多說了，技術公司肯定是聰明人多，所以不合理的需求最終會斃掉，只是這種現象無處不在。詳情在知乎上搜尋關鍵字。著急解決不了問題，心平氣和慢慢談，談不妥了再動手。
六，價值觀
說是價值觀，其實就是待遇，拿到的工資問題。工資有高有低，年終獎有多有少，有13薪，也有15，
16薪，有
996，也有朝九晚五，時間，金錢，身體，發展，哪個更重要呢。表弟剛畢業，去年在電商公司做售前客服，它工資
7千的時候，同學四五千，過了一年他沒變，同手們公升到了
1萬以上。每天簽到賺幾塊，接乙個私活乙個月幾千就有了；每天多學點新知識，跳槽工資能翻倍；給別人做個專案賺幾萬，別人用這個專案賺幾十個幾萬
......
是的，這沒有可比性，因為不去試過，不知其中艱難。但是始終該相信，遇到的最好的專案還是自己。
專案管理之我見
有一年多沒出去做專案了，回想起來前幾年在外奔波的日子，有心酸 有快樂，做的每個專案都歷歷在目，整體上就是痛並快樂著。專案管理是一整體的系列活動 實施前 實施中 實施後，環環相扣，但每個專案的情況不一樣，可能實施過程也不盡相同，下面就個人的切身體會談談我個人對專案管理的看法。一 實施前 1 專案經理要...
專案管理之我見
伴隨著我國資訊化的發展，專案管理越來越成為專案成功的關鍵問題。許多專案配備了足夠優秀的人手，仍然以失敗告終，根本原因就是沒有良好的管理，大家都在努力工作，但是每個人卻衝著不同的方向，結果可想而知。那麼如何才能有效的管理呢？首先，控制需求。採集需求的書多如牛毛，每個人都提出了自己的觀點。作者認為控制需...
專案管理之我見
談到專案管理，有很多問題，不是你技術好，原則性強就能把專案帶好的。我總結了一下最起碼要從以下幾個方面做起 1 熟悉team member的各自水平，極其擅長的領域，做到合理分工，注 想熟悉乙個開發人員的水平一是通過簡歷，二是可以當面找他聊天讓他對自己做乙個技術能力介紹，乙個懂技術的專案經理如果能經常...