分享 干货!Chongqing Hackup 精华分享

merlinran · 2015年03月19日 · 最后由 boyishwei 回复于 2015年03月26日 · 2525 次阅读

昨晚把首届 Chongqing Hackup 搞了。之前那个无人问津的召集在这里

还不错,畅所欲言。发出来,或许对大家有用呢?


今天聚会的各位 CEO 都如此成功了,还在拼命,小编怎么好意思偷懒?深夜加加班,把这些记录的精华发布出来。

产品排期和工作量评估

新晋创业者 Yeti,特别苦恼于新产品的进度。业务领域新,采用的技术也新,屡屡挖坑屡屡埋。难道没有更靠谱一点的办法吗?

两位对交付项目非常有经验的老大总结道:在技术路线和业务领域相对熟悉的项目,按照经验估计的值,再加上30% 的余量,就很靠谱了。当然,这是跟那些对 IT 有一定理解的客户。如果客户比较飘,思维发散多变,加个 100% 的余量也是可以的。而且,一定要重申需求变化的范围

如果是做产品,灵活度就比交付项目要高一些。可以确立小阶段内的整体目标,而非制定长期且固定的计划。小编所在的开源项目团队,是固定发布日期,按照紧急和重要程度,把需求/BUG 放入其中,算是暗合了 Scrum 吧。

打造牛 B 技术团队

要排期准确,就需要熟悉业务,也要熟悉技术领域里的坑。二者都需要长期积累。业务需要浸淫,而如何打造一支坚实的技术团队,咱们的阿苏老大颇有心得。

  • 每天的晨会

按照之前计划,当天要完成的事情,每位程序猿/媛来讲讲,准备如何去实现。如果想得不清楚,很快就会卡壳,团队就知道风险所在。有坑的地方,其他跌过坑的同事也可以指出来。

另外这也是一种形式的同行评议,评价采用的技术路线,每一次探讨,都是进步的契机。

  • 每周五下午的内训,大家轮流讲 topic。主要基于两点考虑:

    • 能做出来不一定懂,能讲出来才是。
    • 工程师都是寂寞的,他们们写出了牛 X 的代码,也希望被人赞叹,希望登高一呼,群山喝彩。这是尊重了人性的规律

如何鼓励大家主动分享,又不带来压力呢?

首先不要把时间定死,一个小组轮下来,就是俩月了。俩月的工作中,总能找到点儿东西分享的吧?

那些实在懒惰的程序员,给点惩罚咯。每天下午茶时间的零食,你就负责跑腿。

有负激励,也要有正激励。讲得好的同学,奖励纪念金币,可以兑换现金,放在桌上,那也是一种荣誉,可以显摆的啊!

一个牛 B 的技术团队,要鼓励每位程序员,努力成为全栈,或者在通往全栈的路上。

效率工具

现在各种专业的工具越来越多,程序员兴奋异常!一款称手的工具,将大大提高生产力。

团队协作工具,大家在使用的有TowerTeambition,相较于上一代的产品,比如 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 后员工的想法已经完全变了,庞大的团队,将给管理带来巨大挑战。做产品,是条艰难重重的道路,但也是必然的选择。

企业和个人的成功,极大地取决于运气。某总曾误打误撞进入国内技术的前沿,差一点就成为腾讯早期员工。与成为亿万富豪的机会失之交臂,可叹。但一朝展露头角,便可以进入圈子,资源共享和整合的机会就多起来,所以二次成功的机率就大大提高。


本期的干货就为您分享到这里。所以,可有兴趣一起玩?来跟咱们对对眼吧。

感谢梦林的组织和大家的分享!受益良多。

赞一个,收获颇丰

遗憾没看到,期待下次

CQ 的,一定要頂~~~

需要 登录 后方可回复, 如果你还没有账号请 注册新账号