一群古惑仔，一隊民兵，一支軍隊，一個超級英雄團隊。

組織的演變是管理模式的不斷升級，如果管理跟不上組織進步的速度，那么團隊就容易亂。

一個人走的快，一群人走的遠。

怎么讓一群人向著一個目標遠行呢？我覺得需要靠義氣，利益，制度和夢想。

人少的時候，喝一頓酒，吃一頓飯，擼起袖子就干起來了。

慢慢的人多了，飯局難湊了，那么就需要利益的勾引，要談上升，要談工資。

接著人數再次上升，厲害的新人進來，熟悉的老人離開，開始有了熟人，陌生人，大家開始有了比較，干了這么多年，為什么他比我好，我比他差，這時，就需要制度，需要公平。

最后當人不在為了工作而工作時，就是實現自我價值的時候，這個境界我還不懂，就不多說。

曾經，我經常為了實現一個業務，發布一個功能，加班到很晚很晚，可當時一點都不覺得加班很苦，當時就是想著要實現討論好的內容，不能有bug，要對得起“朋友的專屬晚班車”，要對得起領導的一次次請客吃飯。這是我的系統，我要讓他更友好。

后來，來了新人，不能一個人干了，開始考慮怎么分配任務，怎么拆解任務，沒有需求，想需求，哪里不好，改哪里。我就是跑在前面的卒子，帶領著我的小兵跑，可跑著跑著，發現小兵不樂意了，總是做業務，總是做需求，總是在重復勞動，今天沒有我的發布，我還需要留守么？今天怎么又是改這些東西，有沒有有意思的任務？此時才猛然醒悟，人心是獨立的，帶人不光要考慮做事，還需要讓人有進步，有價值，有上升。我在努力的時候，得到了領導的認可，那么我的兵呢，他得到自身的認可了么？得到我的認可了么，得到公司的認可了么？認可和利益是綁定的，努力工作實際就是為了上升，為了利益。

我很感謝我的領導，他對我的認同讓我不知不覺就得到了自我進步和公司認可。

我也感謝我的組員，他的訴求讓我理解了作為一個組長，最重要的第二個特質。組長要帶人做事，更要帶人上升。

做人做事一定要有追求，只有追求，才能帶動自身的進步，如果只做自己能做的事情，并且甘于做自己能做的事，那么最后就會變得麻木，得過且過，然后工作沒法超出預期，自然而然就沒法有優秀的表現，沒有優秀的成果自然得不到公司的認可，接著就會開始自我否定，反正再怎么做，都是做不好，那么何必想那么多呢？當一個執行者吧，“他”說怎么做就怎么做。最后離開公司。

可是追求，也要講方法，錯誤的追求會讓事情變得很糟糕。

由于很多老的系統，都是我設計的，業務上的變更，我都是想著，基于老系統做優化，用最小的代價，做最滿足業務需要的系統。我拒絕產品的思路，拒絕屠宰式的系統重構，我天天跟產品吵架。

一個思維發散的產品，天天跟我說，我們不能照搬網頁那一套，做app要有app的思維，不能復制一個東西出來，要做大做強，超過支付寶。

我就納悶了，現app定位還不清楚，就開始想著怎么趕超支付寶，我們能不能先把地基打了？先把網頁有的功能移到app，然后根據業務發展，門店反饋，尋找app的定位，有準確的定位，才能做符合用戶的產品吧，輪子沒造好，跑那么快，會翻車的。我們是先驅者，是沒有借鑒的啊？我每次開會，都很慌，這個家伙想的太快，太遠，太高了，不敢做。

可能有人覺得這個時期，app一定做的很爛吧？其實不是，這一年里，app做的還是極其符合業務預期的。產品想的太快，但是我想的太短，我和他抵平了。

讓我認識到我想的太短視，是跟另一個產品對比出來的。

由于團隊的擴建，新來了一個產品。這是一個向上管理的產品經理。他能準確的把握住領導的意思，抓住領導的思路。他每次都拿這個需求是領導定的來壓我，逼我妥帖，逼我插緊急任務。我極其討厭她。他確實能夠把握住領導的問題，但是他的設計沒有條理，沒有邏輯，都是基于業務而業務，基于領導的解決方案而解決方案，每次問題，按照領導的這個做法做，那么以前這個業務怎么辦？他就說你自己想辦法，被我逼急了，他就說那就加個特殊判斷，先走通再說。能不能基于整條業務線，我們討論一個雙贏的方案？領導說的就是對的么？我需要的是一個邏輯思維，不是一句“領導定的”。這段時間配合不好，系統也做的不如人意。

后來調來一個新人，這個新人工作年限比較久，經驗是有的，但是最重要的是他很“聰明”。由于他是新人，不理解系統的老邏輯，每次產品經理拿著領導的“需求”，他們商量的都很和睦，沒有老系統的包袱，先按照領導的要求做，出了問題，再改就是。他們兩可以說是串通一氣，完美的互補，為了完成董需，想方設法。這個階段，他們倆深深的得到了領導的認同。他們兩做的系統模塊對業務的支持和發展也是真的有長足的進步。

而這時的我卻陷入在老系統邏輯里，為了兼容老邏輯，絞盡腦汁，精疲力竭。

業務的發展是極其迅速的，公司不會等著誰誰進步，該跑的還得跑。如果跟不上公司的進步速度，那么真的還不如換個位置。

業務和人員到這個階段后，向上管理人的弊端慢慢顯現，我的疲于奔命對系統也是心有余而力不足。

于是公司空降了一個新領導。這個新領導是一個大廠出身，方法論是真的多。他來的第一件事就是調整組織架構，在這個契機里，我被安排成了“技術售后服務”。

我本以為，我不負責系統開發工作，系統會亂，實際上，并沒有。

反而因為我的解放，業務和技術有了一個緩沖，我專職處理緊急的系統問題，在某種意義上幫助研發/業務抽出了精力，他們可以更大膽的去解決更多的運營規劃問題。

這段時間，系統做了很多有意義的升級工作，幾個重要的項目都在app落地了，app的定位也越來越明確。

回想起來，我對老邏輯的熟悉，限制了系統的創新，如果我沒有做技術售后，而是還在技術組長的位子上考慮兼容系統老邏輯，我真的就成了阻礙系統發展的攔路石了。我進步的速度沒有公司的速度塊，換個位置真的是更合適。

慢慢的，又過了一年，不知道從何時起，大家心里有了一個擔心，這個業務我不熟，我不知道怎么改？能不能問下產品。

產品說，這個業務有點復雜，有沒有人能給我講講，我再考慮下怎么改。業務方你能告訴我需要怎么樣么，我們按照需求去改。

業務說，我的需求怎么這么難排，我提需求的，產品能不能想全面一點，總是有漏，這種設計缺陷就是bug，我不想走排期，趕緊給我上，當bug修掉。

門店客服說，問題第一次遇到不會，講過之后會了，后面沒遇到 又忘了，業務問題就是階段性的。

四個角色，四種苦惱，實際上，就是一個問題，現在系統特殊邏輯太多了，沒人記得全，沒人說的清，沒人hold住。

以前大家都是務實主義，以最小的改動最大限量的支持業務，這造成了大量的基于現有業務改造，大量的特殊邏輯。現在體量大了，人多了，問題就來了。

我們現在就像印度超載的火車，有站人的地方，就可以先上車，然后車子說停就停，說晚點就晚點，并且還找不到停車的原因，找不到晚點的原因。

該斷得斷，以前是務實，現在需要務虛了，我們需要建立設計思維，定位標準和規范，把寫到代碼的死邏輯升華出來，讓架構清晰，讓代碼簡單，不能再讓寫死的邏輯，讓因為業務而業務的解決方案多下去了。短時間的快，長時間是快么？

如果某個會缺少誰，就定不了方案，如果某個需求只有那些人懂，那么人多了怎么培訓，新來的人怎么融入到集體，體量怎么更大。

需求不能只抓在少數人手里。如果只有少數人表現優秀，那么其他人怎么辦。

很多人都想把工作做好，做到讓公司認可，讓自己認可，可現實就是這么殘酷，制度，體制的問題，不是一個人能搞定的，多次的心有余而力不足，最后要么隨波追流，要么離開公司。

怎么讓需求不是只抓在少數人手里？

為什么一個新需求系統要從頭改到尾？

為什么一個需求評估影響范圍那么難？只有某個人能做？

為什么稍微修改個新功能都要一群人開會討論，稍微少了誰，沒有通知到位，系統就走不通？

為什么測試一個流程，要研發，測試從提測溝通到上線發布前？

稍微復雜的業務線，測試環境只能人為偽造數據去測試？沒有辦法像正常的業務一樣操作出數據？如果哪個部門的測試忙，測試流程就被卡住，測不過了？？？為什么測試這么痛苦。這么多無法復現。

還有協作，一個需求要三個，四個，產品線協作，大家怎么高效率的干活？本位主義是不可避免的，都希望自己少改，自己的業務穩定，所以推進問題就是那么慢，那么難。

在總結下，我們的改進方面。我們要減負，要建高鐵，要做基建。

我們需要一雙眼睛，看到系統的問題，服務器cpu監控，訪問量監控，日志監控等等，這些已經在做了，并卓有成效。

我們需要了解我們的身體，回歸冒煙測試，自動化測試，壓測等等，系統，這個還在嘗試中，不夠成熟。

我們需要知道我們的歷史，溫故而知新，這個我們有wiki，但是大家寫文檔，做設計的意識還在培養，很稚嫩。

我們需要武器，這個基本是石器時代，沒有開始。菜鳥有彩虹橋協調測試，拉卡拉有準生產環境可以真實還原線上場景（不像我們ut這種殘次品，啥都不敢干）攜程/阿里，有技術社區，公眾號，總結工作中遇到的問題，分享最前沿的技術。

技術服務業務，技術需要業務的滋養才能發展的更好，希望我們能窮則變，變則通。

公司五年隨想-袁聰