在家辦公的我，砍需求砍得更狠了
最近全民開始了在家辦公模式，目前看來這種模式還要持續(xù)很長的一段時間，至少要到3月份才能有可能回到公司辦公了。
其實，在哪辦公對于程序員來說其實差別并不是很大，無非就是在哪敲代碼而已。
時間很快，從在家辦公開始，一直想說點什么，但是一直都沒落筆，現(xiàn)在已經(jīng)兩周多了，是時候?qū)扅c什么了，這兩周給我最大的感受有兩點。
一、會議比以前多了
在家辦公之后，每天都是各種電話會議、視頻會議、語音會議等等。
在公司辦公的時候，只有有一些大事，如需求評審、設(shè)計評審之類的才需要開會，還有就是項目晨會或者團隊周會之類的。
但是在家辦公之后，每天會被拉著參加各種會議，以下是我某一天的會議日程：
從早上9點，到晚上8點，一直都有會議，甚至有時候還有很多會議時間是重合的。
這時候就體現(xiàn)出在家辦公的好處了，我就可以同時參加多個會議。釘釘視頻會議開一個，手機電話會議開一個。不需要我的時候我就把我的麥禁掉。
比如有些會議，我只是負責把相關(guān)人員拉在一起，大家討論下，最終得到一個結(jié)果，我發(fā)個郵件出來就好了。這種我就不需要發(fā)言，只需要聽著就行了。
還有的一些會議，如技術(shù)方案評審之類的，可能會議中只有一小部分是和我相關(guān)的，那么我只需要再討論這部分的時候開麥發(fā)言就好了。
如果是在公司開會，是不可能同時進行的，這反而大大提升了開會的效率。
二、砍需求砍得更狠了
我萬萬沒想到在家辦公帶來的一個變化，也不知道是好是壞，那就是：我砍需求砍得更狠了!
相信很多一線開發(fā)人員都和我一樣，每天都會接到各種各樣的需求，而給我們提需求的人也是形形色色。
而各種奇葩需求更是讓我們哭笑不得，但是大多數(shù)程序員在做過一些心理斗爭之后都會想辦法解決這個需求。
其實，所有需求都需要解決的，這沒錯，但是我還是給大家提一個建議：先用嘴解決需求，不行的話再用代碼解決。
在家辦公之后的這兩周，我負責的一個項目目前正處于聯(lián)調(diào)階段，但是這個階段還是會接到一些需求，這其中有些是產(chǎn)品經(jīng)理提出來的需求變更、新增需求等，還有些是合作方技術(shù)提出來的有些技術(shù)需求，如要求接口同步、要求多一次系統(tǒng)交互、甚至要求ERROR_CODE的格式等等。
因為我負責的這個項目是個新產(chǎn)品上線，完全初期，要盡快上線接收用戶檢驗，沒必要一開始就搞的特別復雜。所以對于這些需求，目前的狀態(tài)是能砍則砍，不能砍的先用最簡單的方式先上去。
所以這兩周來，我越發(fā)的發(fā)現(xiàn)我砍需求砍的原來越狠了，甚至有一次，我團隊的另外一個同學問我一個單據(jù)的狀態(tài)問題，我隨口問了下問這個干什么，他說產(chǎn)品經(jīng)理讓他實現(xiàn)個小需求。
我了解下來之后，就拉他和產(chǎn)品經(jīng)理一起開了個電話會議，然后動之以情，曉之以理，把"不合理"的地方都砍了，把"能優(yōu)化"的也都優(yōu)化了。
本來需要2-3個系統(tǒng)合作才能實現(xiàn)的一個查詢功能，經(jīng)過調(diào)整之后，變成只需要查詢一個系統(tǒng)就可以實現(xiàn)。這既減少了系統(tǒng)交互、降低了風險，又減少了用戶的理解成本。何樂而不為呢?
我始終認為，啥需求都接的程序員，一定不是個好程序員!但有些需求，總要有人先站出來砍!就算最后沒砍掉，我認為也是有好處的：
1、可以讓我們理解這個需求背后的東西。之所以最終沒砍掉，肯定是有很多原因在的，只有在討論的過程中我們才能更多的理解這些背后的原因。否則最后可能只是你毫不情愿的實現(xiàn)了一個你認為"垃圾"的功能，但是實際上可能這個需求背后有一些你不理解的原因。如合規(guī)風險、法務(wù)風險等等。
2、表達一個我們的態(tài)度。我覺得，作為一個程序員，態(tài)度還是很重要的。比如有些惡心的或者需求，我們可以"迫于壓力"去實現(xiàn)，但是我們還是有權(quán)利表達我們"不認可"的態(tài)度。而且這個表達的過程，也是你樹立話語權(quán)的一個過程。
我砍需求有很多考慮，但是減少工作量絕對不是最重要的。最近幾天砍需求，我大概總結(jié)了一下，用到的很簡單的幾個架構(gòu)設(shè)計原則：
- 1、Keep It Simple ， Stupid
- 2、Open/Closed Principle
- 3、Single Responsibility Principle
- 4、Minimize Coupling
- 5、Avoid Premature Optimization
簡單點，無論是系統(tǒng)功能，還是系統(tǒng)代碼，最怕的就是復雜。越復雜的功能用戶越不喜歡，所以，如果一個功能很復雜，那大概率是個垃圾功能。
系統(tǒng)實現(xiàn)上面也是，如果一個功能，實現(xiàn)起來很復雜，那大概率會存在很多問題。而解決這些問題最好的辦法就是提前減少復雜度。
除此之外，要明確知道系統(tǒng)邊界以及系統(tǒng)關(guān)系，實現(xiàn)一個功能可能有100種方式，但是到底由誰來實現(xiàn)比較合適?如何才能降低系統(tǒng)間的耦合度?如何實現(xiàn)才有更強的可擴展性和可維護性?這些都是要考量的。
還有比較重要的一點，在初期，不要過早的做所謂的優(yōu)化。記?。篋one is Better than Perfect，
我們?nèi)粘Ｒ拥男枨笾?，有一些是業(yè)務(wù)需求，還有一些是技術(shù)需求。那么，有什么好的原則或者辦法可以參考呢?到底哪些能砍，哪些不能砍?到底應(yīng)該怎么砍呢?
關(guān)于這些問題，我后面會寫一篇詳細的方法論，結(jié)合我工作中的例子，論如何砍需求。大家如果有更好的建議，或者對這個話題感興趣，可以給我留言，歡迎探討!
愿這個世界沒有需求變更!~
