今天聚會的各位CEO都如此成功了，還在拼命，小編怎么好意思偷懶？深夜加加班，把這些記錄的精華發(fā)布出來。
新晉創(chuàng)業(yè)者Yeti，特別苦惱于新產(chǎn)品的進度。業(yè)務領域新，采用的技術也新，屢屢挖坑屢屢埋。難道沒有更靠譜一點的辦法嗎？
兩位對交付項目非常有經(jīng)驗的老大總結(jié)道：在技術路線和業(yè)務領域相對熟悉的項目，按照經(jīng)驗估計的值，再加上30%的余量，就很靠譜了。當然，這是跟那些對IT有一定理解的客戶。如果客戶比較飄，思維發(fā)散多變，加個100%的余量也是可以的。而且，一定要重申需求變化的范圍。
如果是做產(chǎn)品，靈活度就比交付項目要高一些?？梢源_立小階段內(nèi)的整體目標，而非制定長期且固定的計劃。小編所在的開源項目團隊，是固定發(fā)布日期，按照緊急和重要程度，把需求/BUG放入其中，算是暗合了Scrum吧。
要排期準確，就需要熟悉業(yè)務，也要熟悉技術領域里的坑。二者都需要長期積累。業(yè)務需要浸淫，而如何打造一支堅實的技術團隊，咱們的阿蘇老大頗有心得。
按照之前計劃，當天要完成的事情，每位程序猿/媛來講講，準備如何去實現(xiàn)。如果想得不清楚，很快就會卡殼，團隊就知道風險所在。有坑的地方，其他跌過坑的同事也可以指出來。
另外這也是一種形式的同行評議，評價采用的技術路線，每一次探討，都是進步的契機。
每周五下午的內(nèi)訓，大家輪流講topic。主要基于兩點考慮：
能做出來不一定懂，能講出來才是。
工程師都是寂寞的，他們們寫出了牛X的代碼，也希望被人贊嘆，希望登高一呼，群山喝彩。這是尊重了人性的規(guī)律。
如何鼓勵大家主動分享，又不帶來壓力呢？
首先不要把時間定死，一個小組輪下來，就是倆月了。倆月的工作中，總能找到點兒東西分享的吧？
那些實在懶惰的程序員，給點懲罰咯。每天下午茶時間的零食，你就負責跑腿。
有負激勵，也要有正激勵。講得好的同學，獎勵紀念金幣，可以兌換現(xiàn)金，放在桌上，那也是一種榮譽，可以顯擺的??！
一個牛B的技術團隊，要鼓勵每位程序員，努力成為全棧，或者在通往全棧的路上。
現(xiàn)在各種專業(yè)的工具越來越多，程序員興奮異常！一款稱手的工具，將大大提高生產(chǎn)力。
團隊協(xié)作工具，大家在使用的有Tower和Teambition，相較于上一代的產(chǎn)品，比如Microsoft Project和Atlassian的JIRA，它們雖然功能不那么多，但更加輕量，更適合小團隊的工作方式。
對幾個人窩在民宅里的創(chuàng)業(yè)團隊，最高效的就是白板了。大面的玻璃墻，寫寫畫畫和便利貼。未來的Facebook，未必不會從這里走出呢。
有一款人肉測試服務，把APK提交上去，兩天后給你把關鍵的點測得清清楚楚。不知道是不是testelf，反正他們是做這個的。
明瑋兄提到一個服務http://libraries.io 。它可以幫你跟蹤項目中使用到的開源包，是否有升級更新，是解決了什么問題，就不用一直盯GitHub了。
王老大遇到不少應聘的程序員，一門心思就想寫原生代碼，糾結(jié)于每一行代碼是不是自己拿手敲出來的（那不是打字員么？）。這種思維在兩類人群中比較常見：
做外包出身。之前都是找CMS改改就交給客戶，所以特別希望找找從頭寫代碼的感覺。
學院派。比如那些計算機競賽或者Linux的同學，覺得內(nèi)核、算法才牛B，越往底層越牛，恨不得拿代碼寫個CPU出來，看不起應用的人（小編當年狂啃C++時，也是這樣想的哦）。
特別明顯的現(xiàn)象是重后端輕前端，覺得JavaScript是啥嘛？玩都不屑于玩的東西，還好意思稱自己叫代碼？但其實，前端的未來可能更加光明。平行類比制造業(yè)，質(zhì)量多好、多高效，也許在過去的歲月、或者少數(shù)基礎產(chǎn)業(yè)非常重要，但個性化和極具設計感的消費級產(chǎn)品，才是更廣大的未來。
再往上一層，CEO已經(jīng)不做端茶遞水的工作了，他專注于解決團隊其他成員不能解決的問題，是什么呢？戰(zhàn)略（確定那不是懂事的長？）。
為什么上測試驅(qū)動，實因切膚之痛。小團隊很難找到專職測試，即便有，也難有充裕時間完整覆蓋。隨著代碼的增加，問題會越來越明顯。
測試的核心，是讓產(chǎn)品經(jīng)理參與。產(chǎn)品經(jīng)理規(guī)劃測試用例，寫TODO list，把需求列表轉(zhuǎn)化為可以執(zhí)行的斷言。JAVA自然用Maven，而OC就用XCTest。
我們知道，測試粒度有粗細，DAO - Service - Controller，每一級都可以引入測試。產(chǎn)品經(jīng)理只能關注到業(yè)務層面，所以至少要覆蓋Controller級。工程師在保證進度的前提下，可以自己在更小粒度上測試。
代碼質(zhì)量除了用技術手段和流程來把控之外，也事關工程師的責任心和榮譽感。在春節(jié)加班改完團隊的BUG之后，文藝老板迅疾組織討論，題目就叫《程序員的自我修養(yǎng)》。
從更高的視角看，按照墨菲定律，沒有檢查的地方，就一定會出問題。任何行業(yè)，關鍵地方一定要設立檢查點。
王老大高屋建瓴：測試驅(qū)動蠻好，敏捷開發(fā)蠻好，但關鍵在于，要在合適的時間做合適的事。在某個項目中，老大并未耽于代碼，而是在14天內(nèi)六易設計稿，讓客戶拍案驚嘆：這樣的提供商，豈能不用！創(chuàng)業(yè)者的勤奮可見一斑。而這做事的思路，與現(xiàn)今流行的精益創(chuàng)業(yè)不謀而合。
做外包的企業(yè)，幾年之內(nèi)就能看到未來成敗。有機會成的，一定會擴大規(guī)模，項目越做越大。但成于大項目，更可能死于大項目。尤其現(xiàn)在的時代，90后員工的想法已經(jīng)完全變了，龐大的團隊，將給管理帶來巨大挑戰(zhàn)。做產(chǎn)品，是條艱難重重的道路，但也是必然的選擇。
企業(yè)和個人的成功，極大地取決于運氣。某總曾誤打誤撞進入國內(nèi)技術的前沿，差一點就成為騰訊早期員工。與成為億萬富豪的機會失之交臂，可嘆。但一朝展露頭角，便可以進入圈子，資源共享和整合的機會就多起來，所以二次成功的機率就大大提高。
本期的干貨就為您分享到這里。所以，可有興趣一起玩？來跟咱們對對眼吧。
