2010-11-26 09:59
最后一条
2010-11-25 10:53
因为条数太多,所以显然很难成功!
2010-11-23 23:46
呃,我体会最深的一个问题就是,项目开发的过程中,成员之间的交流效率太差 。某人做了一个好用的工具函数,而其他人不知道,一直在做重复的工作,于是同一个功能被实现了成千上万遍。而某些公司,成员之间的交流基本靠吼 ,效率奇差。
2010-11-22 15:38

很好~ 贵在坚持~~
2010-11-22 10:44
哈哈~~打酱油去了,不看这些没用的东西
2010-11-22 09:55
瞎子算命一样。公式一样的话,套哪儿都合适。
2010-11-22 09:54
公理了。。呵。
2010-11-22 09:37

引用来自“奥特一点也不慢”的评论

8.尽快发布,经常发布。不要惦记着再增加一些其它功能。只要能达到可以用来收集用户反馈的最小功能集合,那就发布它。收集反馈信息,反复这个过 程,发布下一个版本、下一个版本,越快越好。如果你3个月才发布出第一版面向用户的产品,你拖延的太久了。如果3个星期才发布一次更新包,你拖延的太久 了。如果不能一周几次,那每周发布一次更新。每3周发布一次重大更新。

似乎很多觉得你频繁发布是不稳定的表现,用户很烦躁。

我倒是感觉这个应该是根据不同情况来看吧,我就是喜欢版本流派。。。比如google。。。以及我现在经常用的一些软件。我非常喜欢他们更新。。。
2010-11-22 09:14
8.尽快发布,经常发布。不要惦记着再增加一些其它功能。只要能达到可以用来收集用户反馈的最小功能集合,那就发布它。收集反馈信息,反复这个过 程,发布下一个版本、下一个版本,越快越好。如果你3个月才发布出第一版面向用户的产品,你拖延的太久了。如果3个星期才发布一次更新包,你拖延的太久 了。如果不能一周几次,那每周发布一次更新。每3周发布一次重大更新。

似乎很多觉得你频繁发布是不稳定的表现,用户很烦躁。
2010-11-22 09:05
其实大部份很难做到,尤其是最后一条。
回复 @
{{emojiItem.symbol}}
返回顶部
顶部