自上世紀七十年代開始，“軟件危機”促使人們研究和改變軟件技術以及管理方法。自從進入軟件工程時代至今，一個軟件團隊已經發展到包含多種角色，甚至達到成百上千人的規模。雖然在一定程度上規範了軟件開發流程，但卻不會解決所有問題。
IT界的各路人馬總會拿出產品經理和程序員之間的故事來調侃，由此可見產品經理和程序員之間會在日常工作中摩擦出怎樣的火花，更不要說項目中其他需要對接的事情了。那麼，程序員怎麼做才能使得團隊效益最大化呢？我的主張是“退一步”。
與產品對接，要站在產品角度思考
程序員給人的固有印象往往是呆呆傻傻，不懂審美，不懂UI。很多人覺得程序員也就不必懂產品，懂業務了，其實這是大錯特錯。站在產品角度思考問題並不是為了與產品人員和諧相處，這恰恰是為了能夠讓自己參透業務以至於精簡開發工作量。
要記住，產品人員是最接近客戶的人，他們是最瞭解用戶想要什麼的人。但是，只有程序員才有可能是那個既懂業務又能將業務落實成代碼的人。
通過代碼實現業務是程序員的工作。但反過來思考，將用戶需求，現實中的業務抽象得出的邏輯恰恰就是代碼邏輯。將現實中的業務抽象的越好，開發就會越省力。
與架構對接，要從架構角度看問題
不謀全局者不足以謀一域，不謀萬事者不足以謀一時。
程序員每天只寫CRUD，同樣需要站在軟件架構的角度來看待問題。正所謂站得越高看得越遠，如果只看腳下，自己永遠會有一堆問題，一堆抱怨。比如，前端開發會抱怨後端提供的API不靈活，後端會抱怨前端事情多。每個人都看自己腳下，那麼工作時的溝通成本會變得相當高。
只有大家都站在一個高的層級上面協商開發中的問題，才能真正的把問題捋順，組內成員之間才能夠高效的推進開發工作。於此同時，從架構的角度理解自己手頭的工作還能讓自己的思維不受限制，能有更好的發揮。
自己閒暇時，要能夠擴展精進技術
通常一個團隊拿到需求都要評估可行性，那麼衡量可行性的尺度是什麼呢？Torvalds開發Git用兩週，如果開發Git的任務落在自己頭上用多久呢？
技術可行性的尺度是一直動態變化的，隨著時間的推移，自己技術實力的提升，原來不可行的需求也變得可行。切勿停止擴展精進技術的腳步，適當的也要去挑戰困難提升自己。今天一味的拒絕那些自己無法實現的需求，那麼明天什麼需求可能都輪不到自己頭上了。
擴展精進技術的另一個好處就是能夠為產品，為自己提供更多選擇，有了這種靈活才能夠面對市場的變化，使得自己不會被市場淘汰。
結語
“退一步”是給自己留出思考的空間；“退一步”是給自己留出傾聽的時間。只有這樣，在有爭議時才能夠理性表達自己的觀點，給出有建設性的建議，從而推動團隊向好的方向前進。
