APP延期、股權糾紛、不合理需求·別再坑程序員、CTO了好么！

文 叨叨

「我有一個改變世界的IDEA，就等你來寫代碼了，不談錢，給你股份！」

「我已經談好機構願意投資我了，就差app跑數據了，你照那誰抄一個就行！」

「在新頁面上加兩個按鈕，很簡單的，今天能搞定吧？」

「我有了個新想法，絕對顛覆傳統商業模式，咱試試唄！」

「剛聽朋友說了，咱的APP用XXXX框架就行，你那套不行了！」

「這五版都不好，還是改回第一版吧！」

……

程序員不易，CTO更苦，那些擺在技術面前的坑，正在變著花樣的洶湧而來，總有一款適合你。

1.

延期？你以為我想！

「新需求」相信已經成為技術研發不得不面對的十宗罪之首了。

改完bug新需求來了，新需求做完發現了bug……無限循環，相信這是很多程序員的現狀。沒有準時下班，沒有雙休，如果捎帶手做了運維，那就是7*24小時的命，所以，別總說我們沒有妹子了。

在創業環境下的用戶需求是多變的，尤其是一個全新的產品、服務。需求的驗證和迭代過程，在一個有計劃、頭腦清晰的CEO手中是可以快速推進的，但在一個完全不懂技術、聽風就是雨的CEO面前，那就是一場噩夢了。

他們還總是用代碼提交的數量作為評價工作量的標準，要知道，有時候一個關鍵問題的解決或是一個隱秘bug的篩查，可能會花費大量時間，說不好一天就搭進去。如果真的說「提交多少代碼=做了多少工作」，那研發個自動提交代碼的程序對於技術來說不算難，這麼互相騙下去，雙方都有損失，為什麼不能多一些理解和溝通呢。

所以，請不要單純拿延期和工作量來評價技術研發工作了。

2.

需求不是你想加，想加就能加！

——「新加個導航功能，就百度地圖那樣的，下禮拜能上線么？」

——「sorry，不太可能~」

——「這麼簡單都不行，抄你都不會？」

——「簡單你來？」

——「我要會還用你！」

——「……」

新需求，可以說是技術的日常，不是不能加，而是要加的合理。

你以為加一個按鈕是UI設計好、改改界面就能搞定的？一個簡單的調整可能牽一髮而動全身，影響了前端不說，甚至連後台邏輯都要改。

舉個栗子，做平台鏈接供需雙方，想加一個聊天功能，雖然界面看上去是一個按鈕的事兒，而且聊天功能現在很多產品都實現了，開源也有，但是否能直接拿來和現有業務邏輯合并？是一對一聊，還是多人群聊？每換一個或加一個人進來，之前的記錄是否保留？如何避免雙方聊上之後互換聯繫方式最終跑單等等，需要非常全面的考慮，不是說拿來copy一下就能直接上的。

最恐怖的是，老闆想加一個搜索功能，需求就是「要像百度一樣」……

不懂技術沒關係，不了解背後的邏輯和複雜程度也沒關係，但新需求能否溝通下再做結論？別讓技術總是最後一個知道，連產品經理都蒙逼，連需求文檔都沒有的情況下，就讓技術去實現，這可真不是晚上加會班的事兒。

什麼？下禮拜上線？呵呵噠~

3.

用人不疑，略懂代碼，

不意味著可以指手畫腳

用人不疑，相信是很多老闆掛在嘴邊的原則，但是否能落實到行為上就另說了。

不怕一無所知，就怕一知半解，自以為懂點技術就指手畫腳，聽風就是雨，看到刷屏級H5就想複製一個，看到外面有人說react混合開發成本低就想試試，看到小程序流行就想追個熱點摻和一下。

這還是外行想要追求新突破提出的建議，一般內部交流、討論下就能說服老闆，但就怕遇上一知半解自以為懂代碼恨不得自己下手寫的。

CEO的本職是什麼？找錢、找人、搞定公司發展，為未來謀劃，而不是把那些細枝末節都強加在自己身上。

的確，有的技術可能真的不如CEO專業，能力差的可以替換，有潛力的可以培養，否則強的只是CEO一人，於整個團隊無益。

一個人做不完所有事，兼顧不了所有細節，CEO要有包容的胸懷，信任他就交給他去做，可以提出建議、方法，但不要過分介入、干涉。比起直接干預，可以請個外部技術大牛，換一個角度幫助團隊發現問題、解決問題，會令所有人都信服。

4.

論CEO要不要懂點技術

既然專業事交給專業人去做，那CEO還有必要懂點技術么？

叨叨曾遇到過為了與程序員交流更順暢而去學習技術的CEO，精神可嘉，但更重要的，還是看心態。

很多被技術坑過的CEO都會想懂些代碼，但一方面做個全面的創業者，另一方面學習技術並實踐，對於非技術背景的CEO是不現實的。但基礎的了解還是有些必要，最起碼的要知道PHP和JAVA是不同語言，分析師、架構師、IOS/Android/PC端、運維、前端、後台、測試分屬不同專業領域、有著不同崗位職責，不要一股腦以為有個CTO就夠了。

另外，了解一些技術並不是為了干涉程序員的具體工作，而是能夠從更全面的角度分析產品，避免提出那些不合理的需求，提高團隊工作效率。其實對於「懂點技術」，更多的可以是對產品經理的要求。

比如騰訊，非常提倡技術出身的產品經理，一方面善於發現、篩選用戶需求，另一方面懂得在技術實現與用戶需求之間找到平衡點，比如騰訊創始人，他就是這樣一位技術出身的產品經理，還做了CEO。

5.

程序員不是修印表機的，謝謝!

聊完專業的，再聊聊日常。

程序員的日常和電腦有著不可分割的密切關係，但這並不意味著技術就會修電腦。有多少技術沒幫助運營妹子修過電腦、裝過軟體？開始可能會樂此不疲，但時間久了也是會煩的，更不用說在梳理邏輯的時候被打擾，真的是@#￥！&*#￥&@*

不只是程序員，被誤解最深的恐怕就是CTO了。

很多不懂技術的老闆對CTO的定位就是「萬能魔術師」，彷彿一個好的IDEA只要有了CTO的加入就能改變世界、改變全人類。

但事實上呢？

知乎上「程序員pilot」的回答很有意思，「頂著CTO的名頭干著技術組長兼打雜的事情，包括但不限於招聘，裁員，拉網線，查機房，裝系統，重裝系統，討論方案，推翻方案，談合同，簽合同，哄手下，罵手下，被老闆哄，挨老闆罵，確定進度，拖延進度，重新定進度，取悅老闆，揣摩老闆，寫畫餅郵件，寫辭職郵件等工作，工作內容一般不包括編碼。」

所以，對老闆而言，只要他們認為目前技術團隊不夠好，不夠給力，不夠預期，就認為自己缺CTO。

6.

一談就心碎的坑——股權、技術合伙人

還記得那篇刷屏的7年技術合伙人被坑一毛股份都沒拿到的文章么？

創業 7 年，眼看著公司展到 150 人，當他想起要和 CEO 確認當初承諾過的股份時，CEO早就通過新公司將股份全部轉移到自己一人名下，只給了他兩個選擇：凈身出戶，或留下來拿死工資。

在創業團隊，股權、期權已經成為吸引、留住技術必用的激勵機制，相當於提供了不可馬上支取的未來的股票。前有曹政與蔡文勝，後有馮大輝與丁香園，因為創業的不穩定、沒有明確協議，股權、期權成為無法兌現的承諾，也讓越來越多的技術不再相信。

其實，當你接受一家公司的股權或期權時，就代表了你願意用自己的青春和才智去支持這家公司的成長，榮辱共擔，利益共享。而這個過程中的一些坑，是不得不提前預判的。

幾點建議，供大家參考：

1.一紙協議永遠比承諾更靠譜。不要覺得股權無所謂，該爭取的不要礙於情分、面子而覺得不好開口，要知道，只有明確了利益歸屬，才好綁在一起加油干。

協議中要明確約定公司協議主體和性質、股權比例、出資方式和期限、回購條款等等，這類注意事項搜一下都能找到，不再贅述。

2. 警惕公司改革。那位被坑了7年的技術合伙人就是在不知不覺中被CEO將股份轉移至自己名下，所以，和誰簽的協議一定要明確，並且信息可以在工商備案中查到具體信息。

3.明確退出條件。無論項目上市、被併購，還是中途離開、被離開，都要明確你會得到什麼、如何得到、各自的前提是什麼。

4.明確工作成果的所屬權。相信沒人願意最終對簿公堂，但萬一出現這種情況怎麼辦？當對方一口否認工作成果屬於你，將你貶得對公司毫無價值怎麼辦？所以，必須留有「證明工作成果屬於你」的證據，比如在你開發的代碼、軟體裡面埋幾個彩蛋，只有你自己知道彩蛋的出現方法，前提一定是不影響業務正常發展、不惡意留後門。友情提示：翻牆證據無效。

至於其他的坑，比如重構別人代碼、鑽到N年前別人寫的代碼里修bug、和蘋果審核撕逼、舊系統沒有源代碼等等，篇幅有限，下次再聊。

程序員的坑雖多，但遠沒到絕望的程度。

更絕望的是，明明知道是坑，卻還是要努力完成它……

向每一位戰鬥在代碼一線的程序員致敬，祝早日找到妹子！

*叨叨是技術外行，若文中有技術bug，請各位GG輕拍~鞠躬~(?￣???￣??)

THE END

對於創業的各種吐槽，

歡迎在留言區叨叨哦~

叨叨的大本營：niudao-pro

互聯網專業領域的翻譯官

讓CEO和專業之間沒有鴻溝

叨叨在這裡安家啦

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！