談程序員如何作好業務

前言

　　技術能作兩種事情，經過技術實現業務和經過技術支持技術。咱們大部分時候作的是前者，養活咱們的大部分也是業務。  近兩個月，做爲項目負責人角色從0到1經歷了新項目的幾個版本迭代，跨入了部分新領域，也有必定收穫，對如何作好業務也比之前有了更深的理解，因此做此博客記錄項目中經歷的事情，和本身對業務的認識。

背景

　　從原公司轉到兄弟公司，負責一個要求快速產出的新項目，團隊人員也是從其餘項目組過來支援的。  臨近年關，2月初開始開發，3月初上線，中間還有過年的時間。  公司很重視，不能延期。  事態緊迫，研發部門領導綜合考慮，過年加班才能遇上進度，所以在一開始就找到願意過年加班的同事，而且向公司上層申請了加班獎金。  技術方面，須要申請兩個公衆號，公衆號申請須要時間；涉及和另外一個系統打通，須要對方支持和開發對接模塊，文章後面稱之爲B系統。

面臨一些問題

• 我對B系統不熟悉
• 對團隊人員不熟悉
• 對公司的框架不熟悉

反正就是幹

　　不熟悉的均可以很快熟悉起來，同事也能夠協助本身。這種境況下，是一種挑戰，也是能逼迫本身去更快融入環境。不慫～

　　

 

砍需求

　　團隊合計了一下，按照第一版的需求，即使過年加班也作不完，不能保證3月初上線，因而咱們仍是和需求方討論，把非核心的需求一個個砍了，砍到最後咱們以爲還比較輕鬆了，但實際的工做量仍然很大。  咱們每每在拿到一個需求的時候，第一反應都會低估它帶來的工做量。  由於細節還未完善，不少事情在開發過程當中纔會發現、溝通、解決。  當咱們把零散的功能和頁面作完，最後整合直到徹底跑通整個流程，這期間也會花費不少時間。  不管如何，項目千萬不能延期，要延期也不能是由於前期估算不許致使的，一旦估算時間定了，跪着也要如期上線。

 

思惟轉化

　　最開始，在某些方面，本身都有一點缺乏主動性。  當時幾個同事在旁邊不遠討論B系統需求的時候沒叫上我。  也是由於纔來，其餘同事對我不熟悉，我本身包括你們都沒有意識到我是項目負責人，我對本身的邊界也有點模糊，我認爲主要仍是技術負責人。  看到他們在討論，本身以爲好像沒叫我，應該沒我什麼事，領導看到了，說我是負責人，那麼多人討論我得去聽。  到後來，我也就明白了，涉及到負責的項目不論是什麼事情，我都得站出來，不然怎麼能稱之爲負責人，同事也不會信服這樣的負責人。

　　當一個技術人員，開發了一個系統，而且更全面的瞭解需求的時候，那他對整個系統的理解應該是超越產品的，我認爲。  在項目開發過程當中，我和產品發生了小小的分歧，其實就是一個文案的問題，那個文案可能會形成混亂或者誤解。  從產品的角度，是咱們太程序員思惟了，做爲銷售渠道是能理解的，從個人角度，雖然能理解，可是概念有重合，須要思惟轉化，不直觀，容易形成系統使用錯誤。  不糾結這個細節，問題在於個人矛盾，由於我平時作事想的多，提的多，但也知道本身的想法不必定都是對的，又出現了雙方都不能說服對方的狀況。  我後來想了下，若是對方已經把理由說清楚了，本身以爲本身的方案仍是更好，那本身又有拍板的權利，就拍板吧。  若是對方有那個權利，就讓對方拍板吧，不然就太浪費時間和精力了。  拍板以前至少要思考對方的想法，不能徹底本身獨斷，同時也要時刻對本身保持懷疑。 

 

加班

　　也是爲了保證進度，今年過年團隊部分同事，咱們只休息了3天，公司放假是9天。  犧牲了假期，可是在上線後，咱們確實也獲得了相應的獎金。  領導說到作到，公司也體恤員工，這樣的加班至少對我來講也是值得的。  加班這個事情，對咱們團隊來講，是一直保持一種可持續化發展的態度。  996是底線，通常都沒有打破過，大部分的時間不會達到996的水平，  通宵就更少了。  可是團隊的戰力並不差，我以爲這樣的狀態剛恰好。

 

市場部溝通

　　在項目初版本上線之後，咱們很快開始規劃第二版，此次我和產品同事參加了和市場部門的需求討論。  市場部門的需求通常要求快快快，他們面臨業績壓力，天然這種壓力也會傾斜到咱們研發部門。  你們應該也知道一些段子：銷售出去賣產品，給客戶說一週之類就能搞定，而後簽了合同，最後告訴研發部門，合同已經簽了，預訂金已收，時間就這個點，剩下一堆想離職的程序猿......  開個玩笑，固然咱們沒有出現這種事情~  總之咱們須要和市場部門的對接人保持緊密溝通。 此次咱們是和市場部門領導溝通的需求，連着幾天拉着過需求，整體還算順利，梳理的也仍是很清楚。  其實和對方部門領導直接溝通，算成本比較低的。  若是說對方領導派一箇中間人來對接的話，這對咱們的工做量、時間安排、心理壓力都會增長不少，畢竟他不能拍板，需求也不是直接來自於他。  

　　由於和B系統強相關的緣故，市場部門給B系統提需求的時候，不知道涉及到咱們系統，在一次溝通中，發現了一個須要和B系統對接的新需求問題，慶幸的是當時B系統的新需求和咱們的新需求都沒上線，因此還沒形成嚴重的生產事故，此次之後，B系統有新需求我都得了解了，要避免系統間的風險。

　　

變化

　　迭代了幾個小版本後，如今由於公司戰略須要，團隊被分散到其餘項目作支持，項目迭代會暫停一段時間。  可是項目依舊要運營，B系統還會迭代，B系統的迭代需求可能和咱們的系統衝突，或者形成bug。  因此B系統一旦有迭代，我都得了解他們的需求，評估對咱們系統是否有影響。 

 

結語

　　業務是飯碗，業務作很差，其餘什麼都別談。  兩年多之前有一個項目，由於本身的問題，致使了延期，對本身各方面的影響都很是很差，因而決心不再能犯一樣的錯誤了。  對於任何人而言，我的緣由延期都是職場大忌，犯不得啊～  對於初中級前端要想有更大的提高，業務方面的能力要達到遊刃有餘才行，不然飛上去也會摔下來。  作好業務的標準是什麼呢？我也不知道，列出一些我能很快想到的點吧：

• 是否延期
• 是否瞭解整個系統和細節
• 是否在寫代碼之前就能預見到細節問題
• 核心邏輯可否一次性思考完善，不出邏輯漏洞
• 帶動其餘同事，推進整個業務前進，正能量
• 一樣的錯誤最多隻犯一次
• 產品思惟，關注用戶體驗
• 合理的時間，可持續性，工做量飽和
• 及時彙報

 

　　都看到這裏了，要不點個贊～