海贼王和创业团队

一个同事在知乎提了一个问题 如果把草帽海贼团比作一个创业团队,这个Team的组织架构是怎样的?有哪些优势,又有哪些不足?

201604/onepiece.jpg

这个话题很有趣,作为追了多年的 fans ,又是身处互联网创业团队的我要来强答一记。

海贼王的世界很大,富有个性的角色和团队也很多,恰好可以和显示世界中的互联网创业团队进行对比。 柳传志讲的好,做大事,要「建班子,定战略,带队伍」,我们就着金句来看看草帽这个团队怎么样。

more ...

技术之外

这是一天一本书的第二次执行,这次选了一本比较薄的书,上周的书看了一天,脑仁疼。


在我组织团队新兵训练营(入职之后一段时间内容集中的培训)时候, 经常和新同事聊到一个词:软实力。 我将其描述为专业技能之外的能力。每个人都这种能力的解读可能会不一样, 我将其拆解为:「对工作的热情;观察力和反思能力;做计划和决策是否周全」。

这种拆解是不全面的,「多年」以后,我意识到,硬实力考衡的是专业的能力, 而软实力则是考衡人的因素。这种晚来的意识让我在一段时间里面, 将自己的工作陷入困境,并且得不到解药。

Google 的两位工程师 Brian W. Fitzpatrick 和 Ben Collins-Sussman 写了一本书极客与团队,通过他们的视角, 告诉大家想要在团队中获得成功的另一面。不要被书名误解,我觉得「开发者和团队」是更好的名字, 虽然没那么酷。

s26354473.jpg

more ...

带理想的执行者 - 柳比歇夫的一生

作为战斗民族的俄罗斯民族,不但能在热带风暴级的灿鸿中进行正常起降, 历来也盛产各种奇葩人物。 最近我有看到一本描述一个科学家的如何生活的书,叫「奇特的一生」。 让人拍案称奇。

201507/liu_bi_xie_fu.jpg

主人公是一位名叫柳比歇夫的科学家,想必他在「回首往事时候没有因为虚度年华而悔恨」, 因为他将自己的一生都精确的奉献到分类学、地蚤研究上面。 他的工作投入,不是单纯激情洋溢投入,而是精确到分钟级别的投入, 是奉献完整一生的投入。

除了学术上面的成功,他的时间记录法也很牛逼,甚至让苏联科学院进行研究。怎么描述他的牛逼呢?如果他生活在今天,大致会这样写:

今天我 19:00 - 19:25 看了新闻联播,感受到社会各阶级在党的领导下面获得令人振奋的成绩

19:25 休息了一会,避过无聊的天气预报时间

19:30 - 20:30 学习了「XXX 的讲话精神研究」

附加工作:20:35 - 20:40 小解,顺便刷了一会朋友圈作为今天的娱乐放松,评论了隔壁老王老婆的出行照片

看到没有,他精确的记录了自己的时间使用记录 ...

more ...

《项目管理修炼之道》笔记

项目管理修炼之道

随着团队规模的变大,成员之间合作的模式逐渐由单打独斗变成协作开发。 这时候会遇到很多意想不到的问题,项目管理的重要性也就显现出来了。 项目管理修炼之道 是一本讲技术类项目管理方法和实践的书。 从业者可以从这本书获得了有益的指导。 我在 Kindle 上面翻了好几遍,感觉受益匪浅,就把读书笔记拿出来供大家参考。

1、内容

核心内容是项目管理的生命周期和每个阶段的交付物:

  • 项目章程
  • 日程规划
  • 开发(控制节奏)
  • 结束项目,项目回顾

其他内容:

  • 如何和投资者沟通
  • 管理会议
  • 控制项目节奏
more ...

从 SVN 到 Git,找回丢失的历史

前段时间在将公司的 SVN 项目迁移到 Git 上面去,遇到一个很少见的问题: 有一个小伙伴使用 git-svn 做 rename 操作时候,将一个目录 svn mv 了, 导致新目录只存了最近几个月提交历史,丢失了历史信息。对团队开发而言, 历史提交是非常宝贵的财产,我们想了一些办法,把这些数据提取出来。

more ...

读《人件》

事情起源于动态语言和静态语言之争,最后争论焦点转移到:「相信人本身的能力重要, 还是通过语言/工具来约束人重要」。 我认为项目开发中最重要的是个人能力和团队协作能力,工具只是加分项。 如果代码质量差、监控难、性能难以优化,解决根本问题的关键还是在人身上。 并不是静态编译和工具检查就能搞定了。

我愤愤的在 QQ 对话框中写道:

我工作第一年痛苦于开发流程,阅读了《人月神话》,就开始坚信软件工程的哲学 后来痛苦与代码质量,阅读了《重构》,开始坚信代码质量决定产品质量 现在痛苦于人和语言的冲突,动态和静态的冲突,我想读《人件》了

人件

人件已经绝版,只能在找线上版,我花了两个星期把它读完。 书中给了我一部分答案,另外还有一些意外的收获。

more ...

软件开发中的角色扮演

说到软件开发的过程、环节等等,我印象里只剩下一大堆术语和一些流程的大概,但是因为缺乏正规开发的经验,所以并没有对软件开发中每个人的角色有深入理解,今天在周末 检查Delicious Temp标签时候,看到 圆木菠萝头 的这片文章,收获颇丰,现在转载与大家分享。

原文链接: 软件开发中的角色扮演 - 软件开发 - 圆木菠萝罐&nbsp_place_holder; (我稍微调了一下格式,没有修改文章内容 ^_^)

××××××XXX分哥线XXX×××××××

&nbsp_place_holder;商业软件开发并不是只有一个编程的人,而是可以分为不同的角色。

不同的软件公司因为规模大小性质各不相同,所以围绕软件的角色也各不相同。这就好比在重点学校里面分级很明确,每科有个老师,每个年级每个班级都有各自的老师,也有主 任书记校长支持角色。而在电影《一个都不能少》级别的学校里面,往往一个老师兼职从语文教到体育,年级从一年级到六年级。类似的说,一个大型的软件外包企业 ...

more ...

用户权限设计的问题

问题

用户权限设计这一块,一直是一个我觉得比较难解决的问题。

以前我用了「伪继承」,虽然管理员继承了普通用户,但是数据库却是分开设计的。又或者压根没有继承关系,是两个不同的实体。

解决方案

这次在贴吧系统,有三个用户角色:普通用户、吧主、管理员,想设计的符合OO,但又要利于数据库的实现。就有几个问题需要解决:1.需要继承么;2.数据库怎么设计; 3.Hibernate怎么映射。最后参考几篇文章,设计成如下。

使用User类,Roll类,User具有一般用户属性,Roll负责角色,他们是1对1关系,最好在数据库有一张User- Roll的对应关系表。来标明这个User具有哪个Roll。

在我这个系统,Roll类有三种,分别对应三种角色:普通用户,吧主和管理员。

这种独立出Roll角色类的方法被称为基于角色的用户权限设计方法。

[caption id="attachment_12439" align="alignnone" width="300" caption="User Roll ...

more ...

用户界面设计黄金原则

在《用户界面设计要素》一书(1997)中,T.Mandel提出了3条「黄金」知道规则:

  1. 让用户驾驭软件,而不是软件驾驭用户。那种在给用户的操作加上许多约束和限制的界面虽然设计容易,却往往难学难用。
  2. 尽可能减少用户的记忆。为此可建立易记的快捷键(例如Ctrl+p启动「打印」);采用演进形式显示「提示」信息,以免要用户一次记忆大量信息。
  3. 保持界面的一致性。例如在同类产品中使用相同的设计规则;尽可能不改变用户已熟悉的操作功能键(例如用Ctrl+S保存文件);设定界面的缺省状态。 最近停下了贴吧的下一步开发,恶补软件工程,为下一步开发做理论基础。

一边啃Rober C.大人写的《敏捷软件开发》。白天都浪迹在考研自习室(很是安静啊),更新变慢,勿怪。

more ...

软件自然理论

所谓软件自然理论,就是说:一个优秀的软件,他的功能模块设计,应该与用户在完全没有接触过这个系统时候所想要的功能设计一致,用户觉得他想要的功能在什么地方,应该 怎样实现,那么这个功能就是应该在那里,就是应该这样实现。

这么说感觉上会很绕口,那么举个例子。Office就是一个比较优秀的软件,如果一个用户完全没有接触过Office(当然,必须具备基本的电脑使用水平),如果该用 户想对字体进行设置,那么他就觉得字体设置属于格式,就应该在格式菜单里面,用户去点击这个菜单,就找到了自己需要的功能。

其他的,比如WinRAR,IE浏览器,都是出色的软件,他们的模块设计也都是符合用户的想法的。

如果一个软件功能过于复杂,或者说功能的安排有很多方案,那么用户往往会难于在短时间内找到自己想要的功能,就会产生对该软件的「惰性」,也就是不想用这个软件了。比 如说AutoCAD,3DMax,如果想熟练使用,往往要经过一段时间的学习的。

ps:这个理论你肯定找不到的,Google也不会有,因为....这是我編出来忽悠继烨、道哥的....很不幸,他们纷纷上当....

more ...