前言

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

背景

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

面臨一些問題

我對B系統不熟悉

對團隊人員不熟悉

對公司的框架不熟悉

反正就是干

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

砍需求

團隊合計了一下，按照初版的需求，即便過年加班也做不完，不能保證3月初上線，于是我們還是和需求方討論，把非核心的需求一個個砍了，砍到最后我們覺得還比較輕松了，但實際的工作量仍然很大。 我們往往在拿到一個需求的時候，第一反應都會低估它帶來的工作量。 因為細節還未完善，很多事情在開發過程中才會發現、溝通、解決。 當我們把零散的功能和頁面做完，最后整合直到完全跑通整個流程，這期間也會花費很多時間。 無論如何，項目千萬不能延期，要延期也不能是因為前期估算不準導致的，一旦估算時間定了，跪著也要如期上線。

思維轉化

最開始，在某些方面，自己都有一點缺少主動性。 當時幾個同事在旁邊不遠討論B系統需求的時候沒叫上我。 也是因為才來，其他同事對我不熟悉，我自己包括大家都沒有意識到我是項目負責人，我對自己的邊界也有點模糊，我認為主要還是技術負責人。 看到他們在討論，自己覺得好像沒叫我，應該沒我什么事，領導看到了，說我是負責人，那么多人討論我得去聽。 到后來，我也就明白了，涉及到負責的項目不管是什么事情，我都得站出來，否則怎么能稱之為負責人，同事也不會信服這樣的負責人。

當一個技術人員，開發了一個系統，并且更全面的了解需求的時候，那他對整個系統的理解應該是超越產品的，我認為。 在項目開發過程中，我和產品發生了小小的分歧，其實就是一個文案的問題，那個文案可能會造成混亂或者誤解。 從產品的角度，是我們太程序員思維了，作為銷售渠道是能理解的，從我的角度，雖然能理解，但是概念有重合，需要思維轉化，不直觀，容易造成系統使用錯誤。 不糾結這個細節，問題在于我的矛盾，因為我平時做事想的多，提的多，但也知道自己的想法不一定都是對的，又出現了雙方都不能說服對方的情況。 我后來想了下，如果對方已經把理由說清楚了，自己覺得自己的方案還是更好，那自己又有拍板的權利，就拍板吧。 如果對方有那個權利，就讓對方拍板吧，否則就太浪費時間和精力了。 拍板之前至少要思考對方的想法，不能完全自己專斷，同時也要時刻對自己保持懷疑。

加班

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

市場部溝通

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

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

變化

迭代了幾個小版本后，現在因為公司戰略需要，團隊被分散到其他項目做支持，項目迭代會暫停一段時間。 但是項目依舊要運營，B系統還會迭代，B系統的迭代需求可能和我們的系統沖突，或者造成bug。 所以B系統一旦有迭代，我都得了解他們的需求，評估對我們系統是否有影響。

結語

業務是飯碗，業務做不好，其他什么都別談。 兩年多以前有一個項目，因為自己的問題，導致了延期，對自己各方面的影響都非常不好，于是決心再也不能犯同樣的錯誤了。 對于任何人而言，個人原因延期都是職場大忌，犯不得啊～ 對于初中級前端要想有更大的提升，業務方面的能力要達到游刃有余才行，否則飛上去也會摔下來。 做好業務的標準是什么呢？我也不知道，列出一些我能很快想到的點吧：

是否延期

是否了解整個系統和細節

是否在寫代碼以前就能預見到細節問題

核心邏輯能否一次性思考完善，不出邏輯漏洞

帶動其他同事，推動整個業務前進，正能量

同樣的錯誤最多只犯一次

產品思維，關注用戶體驗

合理的時間，可持續性，工作量飽和

及時匯報