昨晚把首届 Chongqing Hackup 搞了。之前那个无人问津的召集在这里。
还不错，畅所欲言。发出来，或许对大家有用呢？
今天聚会的各位 CEO 都如此成功了，还在拼命，小编怎么好意思偷懒？深夜加加班，把这些记录的精华发布出来。
产品排期和工作量评估
新晋创业者 Yeti，特别苦恼于新产品的进度。业务领域新，采用的技术也新，屡屡挖坑屡屡埋。难道没有更靠谱一点的办法吗？
两位对交付项目非常有经验的老大总结道：在技术路线和业务领域相对熟悉的项目，按照经验估计的值，再加上30% 的余量，就很靠谱了。当然，这是跟那些对 IT 有一定理解的客户。如果客户比较飘，思维发散多变，加个 100% 的余量也是可以的。而且，一定要重申需求变化的范围。
如果是做产品，灵活度就比交付项目要高一些。可以确立小阶段内的整体目标，而非制定长期且固定的计划。小编所在的开源项目团队，是固定发布日期，按照紧急和重要程度，把需求/BUG 放入其中，算是暗合了 Scrum 吧。
打造牛 B 技术团队
要排期准确，就需要熟悉业务，也要熟悉技术领域里的坑。二者都需要长期积累。业务需要浸淫，而如何打造一支坚实的技术团队，咱们的阿苏老大颇有心得。
- 每天的晨会
按照之前计划，当天要完成的事情，每位程序猿/媛来讲讲，准备如何去实现。如果想得不清楚，很快就会卡壳，团队就知道风险所在。有坑的地方，其他跌过坑的同事也可以指出来。
另外这也是一种形式的同行评议，评价采用的技术路线，每一次探讨，都是进步的契机。
-
每周五下午的内训，大家轮流讲 topic。主要基于两点考虑：
- 能做出来不一定懂，能讲出来才是。
- 工程师都是寂寞的，他们们写出了牛 X 的代码，也希望被人赞叹，希望登高一呼，群山喝彩。这是尊重了人性的规律。
如何鼓励大家主动分享，又不带来压力呢？
首先不要把时间定死，一个小组轮下来，就是俩月了。俩月的工作中，总能找到点儿东西分享的吧？
那些实在懒惰的程序员，给点惩罚咯。每天下午茶时间的零食，你就负责跑腿。
有负激励，也要有正激励。讲得好的同学，奖励纪念金币，可以兑换现金，放在桌上，那也是一种荣誉，可以显摆的啊！
一个牛 B 的技术团队，要鼓励每位程序员，努力成为全栈，或者在通往全栈的路上。
效率工具
现在各种专业的工具越来越多，程序员兴奋异常！一款称手的工具，将大大提高生产力。
团队协作工具，大家在使用的有Tower和Teambition，相较于上一代的产品，比如 Microsoft Project 和Atlassian的 JIRA，它们虽然功能不那么多，但更加轻量，更适合小团队的工作方式。
对几个人窝在民宅里的创业团队，最高效的就是白板了。大面的玻璃墙，写写画画和便利贴。未来的 Facebook，未必不会从这里走出呢。
有一款人肉测试服务，把 APK 提交上去，两天后给你把关键的点测得清清楚楚。不知道是不是testelf，反正他们是做这个的。
明玮兄提到一个服务http://libraries.io 。它可以帮你跟踪项目中使用到的开源包，是否有升级更新，是解决了什么问题，就不用一直盯 GitHub 了。
程序员的思维模式
王老大遇到不少应聘的程序员，一门心思就想写原生代码，纠结于每一行代码是不是自己拿手敲出来的（那不是打字员么？）。这种思维在两类人群中比较常见：
做外包出身。之前都是找 CMS 改改就交给客户，所以特别希望找找从头写代码的感觉。
学院派。比如那些计算机竞赛或者 Linux 的同学，觉得内核、算法才牛 B，越往底层越牛，恨不得拿代码写个 CPU 出来，看不起应用的人（小编当年狂啃 C++ 时，也是这样想的哦）。
特别明显的现象是重后端轻前端，觉得 JavaScript 是啥嘛？玩都不屑于玩的东西，还好意思称自己叫代码？但其实，前端的未来可能更加光明。平行类比制造业，质量多好、多高效，也许在过去的岁月、或者少数基础产业非常重要，但个性化和极具设计感的消费级产品，才是更广大的未来。
论 CEO 的三种境界
- 第一种 CEO，身后背着一群团队成员，勉力前行。
- 第二种 CEO，和团队并肩作战，同吃苦共受罪，就差大被同眠。
- 第三种 CEO，团队在前面跑着，自己紧跟在后。前面说，来箱子弹，递上去；前面又说，口渴了，赶紧端茶递水。
再往上一层，CEO 已经不做端茶递水的工作了，他专注于解决团队其他成员不能解决的问题，是什么呢？战略（确定那不是懂事的长？）。
论业务层的测试驱动
为什么上测试驱动，实因切肤之痛。小团队很难找到专职测试，即便有，也难有充裕时间完整覆盖。随着代码的增加，问题会越来越明显。
测试的核心，是让产品经理参与。产品经理规划测试用例，写 TODO list，把需求列表转化为可以执行的断言。JAVA 自然用 Maven，而 OC 就用 XCTest。
我们知道，测试粒度有粗细，DAO - Service - Controller，每一级都可以引入测试。产品经理只能关注到业务层面，所以至少要覆盖 Controller 级。工程师在保证进度的前提下，可以自己在更小粒度上测试。
代码质量除了用技术手段和流程来把控之外，也事关工程师的责任心和荣誉感。在春节加班改完团队的 BUG 之后，文艺老板迅疾组织讨论，题目就叫《程序员的自我修养》。
从更高的视角看，按照墨菲定律，没有检查的地方，就一定会出问题。任何行业，关键地方一定要设立检查点。
王老大高屋建瓴：测试驱动蛮好，敏捷开发蛮好，但关键在于，要在合适的时间做合适的事。在某个项目中，老大并未耽于代码，而是在 14 天内六易设计稿，让客户拍案惊叹：这样的提供商，岂能不用！创业者的勤奋可见一斑。而这做事的思路，与现今流行的精益创业不谋而合。
行业发展
做外包的企业，几年之内就能看到未来成败。有机会成的，一定会扩大规模，项目越做越大。但成于大项目，更可能死于大项目。尤其现在的时代，90 后员工的想法已经完全变了，庞大的团队，将给管理带来巨大挑战。做产品，是条艰难重重的道路，但也是必然的选择。
企业和个人的成功，极大地取决于运气。某总曾误打误撞进入国内技术的前沿，差一点就成为腾讯早期员工。与成为亿万富豪的机会失之交臂，可叹。但一朝展露头角，便可以进入圈子，资源共享和整合的机会就多起来，所以二次成功的机率就大大提高。
本期的干货就为您分享到这里。所以，可有兴趣一起玩？来跟咱们对对眼吧。
