我有些尴尬地拿着水杯，正对面坐着来访的王总，他是在别处打拼的人，这几年据说收获颇丰，见移动互联网如火如荼，自然也想着要进来干一场，尽管王总从事的行当也算跟IT沾边，但毕竟太长时间不接触技术，有些东西不太熟，总要咨询下我这个在一线开发混了十几年的老程序员，十几年的开发，有好几种可能性，不过这不是重点，所以暂时忽略掉这个细节吧。
　　我之所以尴尬，是对王总的需求有些不知如何回答，仿佛陷入了某种习惯性的沉思中。
　　王总站了起来，把手机递到我面前，说：&你看看，就这样一个APP。&他不太熟练地在屏幕上划了几下，我并没有很认真地看，因为我知道这个问题很难，那就是所有的开发者都会被问，并且可能是被问得最频的一个问题：&开发这么一个APP需要多长时间？&我很想说不知道，这可能是最直截了当和准确的回答，但面对王总这位老朋友，我要是这么回答估计有些失礼，所以这个时候，我除了大致思量了一下他所指的那个APP大致涉及到哪些方面之外，还要组织下自己的语言，如何用非常得体的话告诉他，这个事情我估算不出。&你看，就这么简单的一个APP&，王总继续在屏幕上拨弄了几下，然后带着几分期待的眼神看着我。
　　我谨慎地说：&坦白说，我说不准，我这方面经验也不是很足，尽管做过APP开发，但又跟这个很不一样，得具体分析好所有的逻辑，才能估算出时间。&
　　王总对我的说法似乎不以为然，他晃了晃手机，说：&我要求不多，其实比这个还简单&，他指着屏幕上某些地方，继续说：&这个，这个，这个都可以不要，只需要这么一个列表，里面有详情，可以查看修改&&&
　　我心里很自然地想到这是很典型的&想当然简单&的态度，我想我得让他认识到这个问题的复杂程度，我反问道：&需要登录吗？&
　　王总稍作停顿后，说：&那当然。&
　　&什么登录？用户名密码方式，还是手机登录，抑或像QQ，微博，微信这种可以借用的第三方登录？&
　　王总这回似乎想了一下：&作为移动互联网，我想手机登录肯定是要的，QQ，微博，对了，微信，微信最好也要&&哦，你前面说用户名密码，这个应该也是要的吧。&
　　我很流利地接着问：&那总得有注册，如果你打算用手机登录，那得找个短信平台，还有微信登录，你得先做好企业身份认证，对了，有登录，有密码，那密码找回功能也得有吧。&
　　&这是肯定的。&
　　&同时有多种登录途径，你必须要想出一种合理的逻辑来将它们&整合&，最常见的当然是账号绑定，例如给你的账号绑定手机号码，这样就能用手机号来登录同样一个账号，对微信登录也同理，但如今移动互联网的用户们都挺厌恶注册流程的，所以往往会要求直接手机登录或者直接微信登录，自动完成注册过程，那考虑这种情况，如果用户先用微信登录，然后再用手机登录，而不是绑定，那么就会产生两个不同的账号，而且无法将其再&整合&起来，我们得想出一套比较完善的方案&&&
　　王总对我所说的似乎有些缺乏耐心：&没必要这么复杂吧？你看看这个APP，这些不都有吗？&
　　&有没有我前面所描述的那个问题，你尝试过了吗？&
　　但王总似乎对问题并不关心，他只想知道做这么一个APP需要多长时间，当然要多少钱，这也是他关心的问题，他拿出了信心满满的语气：&有问题怕什么？困难算什么？这些我相信都能解决，但时间很要紧，得快，我们的竞争对手不会等我们，就这么一个东西，你想想看，要多久？&
　　看他的架势，像十足那种混得风生水起的成功人士，而我这种身份低微的程序员在他面前确实是有口难言，我本来还想继续告诉他细节的重要性，却被他打断：&不，不需要有多精确，你只需要估算一个范围，两个星期？或是两个月？&
　　我觉得我没必要再隐瞒什么了：&我真的不知道，也许一支优秀的团队两个星期就能做好（不过我自己可不相信有这么牛逼的团队），但我很明显不是那个能创造这种奇迹的人。&我心想其实就算说出了&两个星期到两年&这么一个开玩笑式的范围，也可能是错的。
　　王总似乎对我这样的回答很失望。但他是个执行力很强的人，想做一件事，就一定会行动，行动一定快，一定要有结果，这种雷厉风行的行事风格，确实，我挺欣赏，不过他的这个项目，我可真帮不上忙，但我还是出于礼貌，说道：&技术方面有什么问题，还是可以来问我的。&
　　&做一个APP需要多长时间？&这个问题估计比测一个人还能活几天还难，一个条件如此不充分的问题，如何回答呢？
　　总体来说，需求越是明确，团队越是成熟，估算出来的时间就越是准确。而软件开发这个事情，不管发展多少年，不管提出了怎样的方法论，都没办法像传统制造业那样把&工时&算得那么精确，其内部错综复杂的逻辑关系使然，软件工程，绝无可能量产。
　　用户看到的只是一个APP，如果他用的是iOS系统，也许他根本就不会接触Android，不知道开发者除了iOS版之外，还需要做一个Android版，（有没可能还有Windows版？这样工作量无疑更大）或者，网页版搞定一切？也许你真正动手做过后就不会这么认为，再说微信小店那种模式真能适用于所有场合么？而且，如果不是网络出现异常的话，一般用户也不会注意到服务器的存在，服务器总是那么默默无闻地为用户全天候地工作，它的开发难度恐怕也不亚于APP本身，而负责APP运维的还需一些人力，大了之后甚至需要组建一个专业团队，他们需要一个&后台&，能随时查看和处理数据，如果需要随时随地都能查看和处理数据，恐怕还得给后台专门弄个APP。
　　这个道理就有点类似：我们看到了战机在天上华丽地完成了歼敌任务，以为只是战机本身很牛，往往忽视了战机相关的那些配套，如果没有娴熟的飞行员、作战指挥中心、地面雷达、预警机、补给、机场或航母、地勤人员等等，那么战机将失去战斗力。APP也一样，它不是一个只要能跑起来就完事的东西，支持它的配套设施和维护工作丝毫不比APP本身简单。
　　除开这些大的方面，细节上也带有许多的不确定性，所以一支成熟的团队尤为重要，一个经验丰富的开发者会知道，至少大致知道这个开发过程会遇到哪些问题，哪些问题比较简单，哪些问题则可能需要耗费大量的时间，这得依赖经验。我有一句话常常挂在嘴边，那就是：&没做过的东西别轻易说简单。&&想当然简单&的态度对项目没有任何好处，如果自己不确定，那么去咨询一个有这方面经验的人，就算得不到具体的答案也有大致的方向，沿着这些方向研究一下，就能知道会面临的那些问题，当然往往还不是全部。
　　关于&低估了难度&这事情，我过去的公司有个经典故事，当时有个小项目，就是准备把一套已经在仪器上使用的只支持英语的程序增加多语言支持，程序并不大，涉及内容也不算太多，工程师一开始认为这只是个简单的翻译工作，顶多两个星期就能完成，但一做下去就发现不简单，首先翻译得找专业人士来做，自己做不好，我们没人精通欧洲各国语言，接下来还有单位换算，有些国家用公制，有些用英制，这个得考虑，包括日期显示格式也得考虑，一下子不知道多了多少工作，这些都差不多了之后又发现了德语单词过长，我们的仪器的屏幕显示不下，超出范围，于是再调字体，做精简，前前后后开会讨论了N次，最后想Release的时候发现这么一改，程序的Size变大了很多，有些仪器的存储器装不下，这下大家可都傻了，优化呗，精简呗，程序开始有些凌乱不堪了，最后勉强通过质控部检验，总算发布了，发觉足足搞了半年。不过如今想想之所以耗费了这么多时间，一个很重要的原因是经验不足，对多语言，国际化这块不熟，走了不少弯路，所以我前面也提到，成熟的团队尤为重要。
　　我们在估算项目时间的时候，往往只算了&写代码的时间&，而把那些和老板或客户扯皮，做需求分析，设计，测试，和修复bug的时间不考虑进去，而这些时间加起来通常比写代码的时间多出不少，我个人是不轻易为了讨好老板而把完成时间说得很短的，为啥？&&根本做不到嘛，干嘛要撒谎？如果一个需要一星期完成的新功能开发，我通常得把这个时间double，这已经算比较&不保守&的了。
　　即便只算写代码的时间，也往往会被低估，老板或客户对你开发的东西很可能不满意，或许你误解了他的功能需求，或者界面有点卡顿，或者这个图标颜色不好看，你是开发者，不是美工，虽然凑合可以当一下美工，但毕竟不专业，更重要的是做做UI设计，做做图这种事情，也得耗费不少时间，当你为&一个像素&焦头烂额的时候，是不是很渴望团队中有一名设计师？这时候得提醒下老板：你必须要在时间和功能之间，做点取舍。老板当然很不高兴，但也不得不在功能上做出了一些妥协。虽然这样做能让难产的项目早点上线，但却为来日项目的失败，给老板添加了一个很好的借口：我们的工程师太差了，没按我说的去做。
　　老板或客户除了会抱怨你做出来的东西不够好看之外，还会再提很多东西：这个界面能不能改成多选，能否增加通知功能，已读未读状态要有，界面能不能再流畅点，昨晚程序咋&闪退&了一次&&需求只管提功能，但没说具体这个UI要多美观，也没说程序稳定性要好，更没涉及到要达到多大的吞吐量，当然，可能更重要的&&安全性也没提，你心一惊：是啊，如果有黑客，不，只要稍微懂一点技术的恶意用户想刷爆我们的服务器，那简直太简单了，而这些防护措施我都没做！所幸的是项目名气太小，暂时无需考虑这个。（貌似大多数APP都活不到需要考虑这个的时候）
　　所有这些，你说功能也好，细节也好，稳健性也好，都不是能自动从土里长出来的东西，都得需要花时间去想，去做，有些甚至还是个&系统工程&，如果头痛医头脚痛医脚去做的话，系统里到处充满&飞线&，无疑会给将来的维护留下了许多隐患。攻城狮的你，都考虑了吗？更别说老板为了节省成本而给你购置的低性能电脑让你整天抓狂这些&无关紧要&的事。
　　话说王总告别我之后就以迅雷不及掩耳之势注册了公司，注册了域名，搞到了办公室，还一下子叫来了一帮子人风风火火地搞了起来，这种发展势头，这种干劲，我只有自叹不如。心底里真有些后悔怎么没跟他去干事业，不过这只是感性的一瞬间，理性又在接下来的几百毫秒里将我拉了回来：还是别去好，跟他沟通不来的。
　　王总的项目后来以一飞冲天之势迅猛发展，而他如今已经是一家估值几亿的公司的CEO，我嘛，越来越觉得自己是个Loser，独自坐在办公室里，还是拿着那个水杯，懊恼不已&&打住！这样是不是比较有戏剧性？可虽然一开始我就声明此故事&如有雷同，纯属巧合&，但也不能胡乱瞎编，真正的结局是：确实风风火火弄了几个月，后来就突然杳无音讯了，本来想打电话问问王总究竟怎样，无奈他变成了另一个超级忙人，再无心思跟我聊家常了。嗯，结局还是差不多，我还是那个继续苦逼地坐在办公室里的程序员，唉，别想了，开工吧！
验证消息：Admin10000
提示：常上QQ空间的朋友可关注，精彩内容不错过。
理智评论文明上网，拒绝恶意谩骂 发表评论 / 共2条评论
登录会员中心苹果 App Store 免费 App 排名的标准是什么？
我们做了一个 app，很诡异的在沉默了两天之后突然进分类排行然后爆发了两天。而我们什么都没有做。有哪位达人知道 App Store 的排名规则，分享一下吧。个人觉得不单是下载量，是不是和编辑也有关系？
按投票排序
AppStore排名＝当天下载量＊8＋（当天－1天）下载量＊5＋（当天－2天）下载量＊5＋（当天－3天）下载量＊2所以影响排名的只有过去4天的下载量，其中当天的下载量是决定作用的。来源：======================================================Update :据观察，Apple可能已经变动了AppStore的排名规则：除了单纯的下载量，应用的活跃度和Rating也会影响应用排名。来源：
张晨晖的答案是目前比较靠谱的算法，但收费软件的排名还要考察你的销售额，不仅仅是下载量，比如你一个软件买10刀，最近做降价或者限免，你会发现下载量上去了，排名却变化不大，因为销售额也下来了。有些价格比较贵州软件，虽然下载量不大，但排名很容易因为销售额比较大而排名靠前。
App Store 排名的具体算法，一直是一个未公开的秘密。开发者们推测，这个算法中可能考虑到了如下因素──总下载量过去几日的下载总量。（有说三日，有说五日，有说七日）过去几日的日新增下载量。因此，如果你的 iOS app 排名突然发生变化，那肯定是如下因素起到了作用──被 App Store 官方推荐了。（包括新品推荐、员工选择被用户量大的 app 推荐网站推荐了。（比如国内的 ）总而言之，被人推荐了。
新产品和新迭代，都有明显的排名增益效果。这完全是实战摸索得出来的经验。我们发布过腾讯新闻、腾讯爱看至少4个以上的版本，平时也关注排行榜，发现凡是新的产品和版本，在发布后的前几日内，排行榜上一般会排在前三名，然后再逐渐下滑。个人的判断是：新品会有N天增益，之后，则按周期下载量排序。
最近Apple调整了App Store的排名算法，据Flurry营销副总裁Peter Farago对Flurry平台的观察，以及Glu营销主管Mike Breslin对自己公司手游的排名分析后得出：应该是更多的考虑了月、日活跃用户数，也就是这些应用被下载后，被积极使用的程度。
苹果应用商店app store排名算法规则大揭秘App Store研究
哪些因素可能被app store排名算法因素？下面这些是我认为会影响第二天排名的一些因素，我以重要程度进行了排序：*****下载量：这个谁都懂；*****好评比例：今天有多少好评，好评占总评论量多少，这个也是可以当天获得的数据。**当天卸载率：这个数据itunes官方也很容易得到。*** 当天用户对该APP的使用时长。**用户下载及好评用的IP地址：这会影响APP所在地区的排名。
通过经验观察：（1）上线时间 （2）下载量
根据我的观察，App store不是仅仅参照下载量来排序的，至少目前的APP Store 不是。有时会看到个别价格极高的产品（$999）出现在TOP10，这往往是很冷门的程序，不可能有TOP10的下载量。我认为APP 的排序的原则应该是：按时间加权的单位时间为苹果带来的回报。即：单价×销量，再按时间做权重进行排序。
标准有：（1）昨日订单量（2）订单量与点击量的比值（转化率）（3）一周内订单增量（4）主题价格因素：使用方法为取主题的销售金额（订单量X主题价格），免费变收费时，实际订单量通过大盘收费与免费主题订单量的比值取得。（5）用户评论星级（1-5分）（6）官方编辑评分 （1-5分） （7）评论数量与订单量的比值：按求出大盘的评论与订单量的比值，做为阀值，超过这个值就不做惩罚，低于就加上惩罚因子（8）平均订单量权值公式：double salesAmountTaday = (Constants.BASE + todayPrice) * todayOrderNdouble salesAmountIcr = Math.min(salesAmountTaday / salesAmountYesterday, arguments.icr);double timeFactor = salesAmountTaday * Math.pow(0.5, i / arguments.halfLife);For(第一天到第七天){score.score += salesAmountIcr * timeF}double click2BuyRatingFactor = effectiveOrderNum / (themeScorePara.getClickNum() + 1);click2BuyRatingFactor = Math.min(200, click2BuyRatingFactor * 1000);// 映射范围：0-2click2BuyRatingFactor = Math.log((double) click2BuyRatingFactor + 1) / Math.log(4);// 编辑评星参数,映射范围：0-1double editorFactor = Math.log((double) themeScorePara.getEditorStars() / 5.0 + 1) / Math.log(2);// 用户评分参数,映射范围：0-1double userRatingFactor = Math.log((double) themeScorePara.getUserRating() / 5.0 + 1) / Math.log(2);score.score = score.score * (1 + editorFactor + userRatingFactor) * (1 + click2BuyRatingFactor) + commentNumF说明：BASE 是基数，todayPrice是主题包定价，todayOrderNum是下载量。那么对于免费的主题包公式就(BASE +0)*todayOrderNum.免费与收费主题包用同一权值公式，是因为有些主题包会不停的在收费和免费直接切换(可能为了刷人气或改价冲榜
)，便于兼容。时间因素：最近几天每天的权值Y是不一样的，与遇到的其他问题：马太效应，马太效应(Matthew Effect)，指强者愈强，弱者愈弱的现象。就是说对于新出来的主题包很少有人关注，排名会很靠后，导致更少人关注。。。。。。恶性循环中。。。。我们是通过引入半衰期来解决此问题。推荐一篇论文，通俗易懂，关键是对排行榜遇到的问题分享的很清晰。
肯定不是以下载量作为排序标准。活跃度和评分应该也是作为加权计算的标准。
用appannie查看一下你的应用，看看features里是不是多了很多places
确定不是在钓鱼吗，我所在的行业里有一个刷积分墙的，千万别好心做坏事
小结一下主要可导致排位变化的原因：Paid apps，按时间加权的单位时间为苹果带来的回报，即：单价×销量，再按时间做权重进行排序Free apps，排名＝当天下载量＊8＋（当天－1天）下载量＊5＋（当天－2天）下载量＊5＋（当天－3天）下载量＊2对于推荐、上线时间等一些细节可作为排位参考进行考虑。
我也很想知道，明明不是很好玩的游戏或者应用，都排在前几个，很郁闷