论迭代式的产品开发方法

2014-04-28  来源:本站原创  分类:产品  人气:1 

对基础构思的完善和原型化

一款游戏从创意到开发,抽象来看可以分为两大阶段:基础构思的阶段,和迭代开发的阶段。任何游戏在最早的时候都只是一个或者一组零散而不确定的构想,策划人员将这组构想加以整理,抽取其中相互联系的规则组成核心规则集,这就是产品最初的框架。譬如说俄罗斯方块最初的规则可能包括:方块连成一行就消除并加分;头顶随机掉落新的方块;方块可旋转,等。

一般来说,在这个阶段,游戏开发者会寻求利用这组核心规则建立一个简单的DEMO,用来验证游戏本身的可玩性。这个DEMO往往是缺乏美术效果和友好的UI的,但是其遵循的游戏主循环一般来说与后来的商业版本并没有太大的不同。

譬如说如果你在做弹弹堂,你可能会先搞一个只有一种炮弹、一个怪一张地图的演示版,虽然内容简单,但是回合规则与弹道公式是与后来的版本基本上一致的。

对于一个前期的产品构思来说,究竟要花多少时间和精力来做DEMO?又要花费多久来测试这个DEMO?不同的公司和团队,对这个问题的回答往往大相径庭。

在这里就出现了一个很有争议性的问题:缜密的构思加上完善的策划文档,是否能够替代对于DEMO的开发和评估?答案是否定的。

为什么要做原型呢?既然原型的代码基本上不可能被用在商业化的成品里,既然这只是给一小部分人看的演示,跳过去有何不可?

核心原因在于,作为人,我们的能力和经验从本质上说,是有限且不完备的。而游戏又是一种体验性的产品,一款游戏的可玩性,无法通过逻辑和数理的方式来验证,而必须通过一部分人员通过实际的游戏过程,主观的去感受和评判。而这也就是为什么说游戏设计是一门艺术的理由所在。

很多游戏策划人员骨子里对市场和运营是持反感态度的,他们说,游戏是一种艺术,游戏性是我追求的灵魂,这比庸俗的充值要重要。在原型的设计和评估阶段,他们是对的。

对于原型的评判,一般来说,是要看游戏的核心规则是否清晰容易掌握,同时根据用户的操作又能够得到各种不同的选择结果,再就是技术角度的一些基础性验证。譬如说,一个游戏可能规则复杂变幻叵测,但是需要一个月的时间才能上手;又或者一个游戏3分钟即可掌握,但是玩来玩去每一次的流程都差不多。这些,都是需要在原型化过程中去分析和判断的问题。

如果一个原型做下来,大家不觉得这个东西好玩,接下来该怎么办?

很简单,放弃。扔掉一切,重新开始设计。这里有一个很大的误区,一方面把游戏性不佳归结于DEMO的内容量不足,指望着内容量增加之后可玩性变好;另一方面以DEMO早晚会放弃不应当投入太高成本为借口,认为“这么小的DEMO能达到这样的水准,如果……的话,游戏肯定不错”实际上这都是自己给自己挖坑跳的思想和行为。

一款游戏,小到俄罗斯方块泡泡龙,大到魔兽世界天龙八部,本质上都是有自己的核心玩法的,大型产品的核心玩法构成可能更复杂,甚至是由一组相互关联的子玩法相互配合所组成,但是无论大游戏小作品,都是由一个个独立的玩法模块搭建起来的,一个大型的MMO,可能其中很多玩法并不特别出色也能获得成功;但是一个玩法模块很多、但是每一个都不算出色的产品,是不可能仅仅凭借功能比别人多来赢得玩家的。

就是说,成功的游戏不见得每一个玩法都精彩,但是没有至少一个比较精彩的玩法的游戏,一定会失败,无论多久、无论成本多高、无论程序美术策划多努力。实际上这是1和1后面的0的关系,没有1,则再多的0加起来也是0。

我讲过一个简单的理论:游戏的核心玩法是一款游戏的纵轴,而内容的增加是一款游戏的横轴,一个好的纵轴,可以支撑很广阔的横轴,就像弹弹堂或者疯狂的小鸟,基于自己的核心玩法,可以不断设计推出新的地图;而如果纵轴不够强大,横向的扩展越多,产品死亡的速度就会越快。这就像盖房子没有把房梁搭好就往上放砖,建的越快就塌陷越快。

所以,在游戏的初期,对于核心玩法和DEMO的反复修改不断锤炼,是决定了这个产品能走多远的基础和地基,打个比方你能设计出疯狂的小鸟或者植物大战僵尸的核心玩法规则,那接下来要做的无非是找一堆美术和关卡外包干活罢了。这在网页游戏和社交产品领域同样是成立的,就像傲视天地的推图和战斗系统,都应该是在早期就开始勾勒并且贯穿了整个产品开发始终的东西。

迭代式开发的核心思想与理念

好了,接下来,把艺术的感性收起来,我们要进入迭代式开发的阶段了。
何为迭代?盛大以前有一句很形象的形容,叫做小步快跑。

以下文本来自百度:迭代式开发。在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。实际上,我们经常遇到的问题是需求在整个软件开发工程中经常会改变。迭代式开发允许在每次迭代过程中需求可能有变化,通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险,而且每个迭代过程以可以执行版本结束,可以鼓舞开发人员。

其实中国还有一句老话,叫做走一步看一步。本质上,迭代式开发承认开发者当前对于用户需求的了解和把握是欠完备的,开发者并不追求对产品需求进行一次性、全局的理解和把握,而是针对每一个产品细节,收集用户行为和反馈,提出可能的解决方案,加以实现并验证是否解决了问题,然后再迈向下一步的一种循环。

可以这么说,迭代式开发的起点,是从一个版本的发布开始:版本发布,通过数据统计和分析,以及直接的用户调查和问询,得到用户行为的直接反馈;基于反馈分析原因并提出可能的解决方案及验证方法,开发完成这一解决方案,观察用户的行为是否有所改善。如果没有得到改善,那就去尝试另一个解决方案,重复这个循环;如果经过证实得以改善,那就继续接下来的开发流程。

一个典型的迭代式开发过程中,有三个关键原则:尽可能短的迭代周期、明确的效果验证方法、低成本的修正方案。

在不对用户和运营产生过大困扰的情况下,迭代周期越短越好。这就要求把一个比较大的版本规划切分成若干个小版本,分别针对某个特定的问题。本质上每一次的迭代循环,相当于开发人员与用户/市场之间的一个对话周期,而对话进行的越频繁,对市场的了解和把握就越深入。一对每年只通话一次的朋友,关系一定比不上每个礼拜都一起吃饭的朋友亲密,而开发者和市场之间关系越疏离,距离成功的道路就越遥远而不可见。

明确的效果验证方法。这是绝大多数产品开发过程中会犯的错,就是有意无意的省略了对效果的验证。发现产品中的一个问题,譬如某个高流失率环节,讨论,提出了某个改善方案,制作完成上线。然后……没了。

实际上我一直在强调,迭代式开发的潜台词就是承认我们对用户和市场的无知。只有经过了验证的方法,才能称为一种“经验”,而这种经验的积累,代表了游戏团队水平和竞争力的提升。仅仅满足于提出或者完成某种改善方案,这本身没有任何特别的意义。因为你压根不知道,这个改善方案到底是对的,还是错的?

我们往往以成本和工期为理由,用自己或者领导的想当然,来替代繁杂但却可靠的运营数据和用户行为分析,并且振振有词说这就是我的水平,其实这只导致了一个结果,就是曾经犯下的错误,必然在未来某个时间点重复再犯一次。工期越长、时间越久,这种差距就越来越大。就像同样是成立5年的公司,zynga真正比我们强悍的地方,其实在于每过一年,他们做一个新产品的时候所需要犯的错误就少一些,而我们5年前犯的错和今天做一个产品犯的错有可能是一样多的。

低成本的解决方案设计。这意味着当我们发现某个环节有待改善时,应当首先评估那些实施成本最低的方案。因为每一次方案的提出和实施都是一次风险投资,在目标明确的前提下,投入越少,性价比越高。低成本的方案往往也意味着更迅速的开发时间和更短的迭代周期。有趣的是,虽然理智上我们很容易支持这一点,但是许多时候这样的要求,和作为开发者本身的人性是相违背的。

作为产品的创造者,我们经常会在发现产品的种种不足之处时,提出一个“全新的、更好的、一揽子的”解决方案,并且认为那就是完美的答案。这可以称之为一种“创新冲动”,但也可以叫做“创新性的陷阱”。实践证明,这种看起来很完美的方案,经常只是因为其细节没有被考虑充分罢了。大多数时候,在现有的方案上稍加调整,就可以解决问题的90%,这时候优先选择的一定是成本更低的解决方式。

有人会问为什么不投入更大的精力,追求产品的完美?这经常是一种很有冲击性的提问方式,就好像我们是在裹着裹脚布走路的小老太太,被五四青年当街质问一般。

其实答案很简单,因为你我这一刻所认为的完美方案,往往一点都不完美。人经常陷入一个思维误区,就是对某个特定方式的非理性推崇和崇拜。进而认为所有不同意这个方式的人都是品味或者能力有问题。然而一两个礼拜之后,就发现其实全然不是如此这般。之前的完美方案之所以看起来如此诱人,只是因为我们只是一厢情愿的看到了其优点,而不愿意面对其不足。

当一个方案真的在各方面都远胜从前的时候,我们自然应当勇往直前将其付诸实施,据我的经验,这种情况一般来说只占十分之一的比例。一段时间的沉淀、替代方案的讨论以及广泛听取周围人的意见,有助于我们去判断哪些东西是真金,哪些东西是空包弹。

一句话:为解决问题而提出、并且经过了事实的验证被证明有用的创新,才是有效性的创新,而一系列有效性的创新的累加,就是一款成功的商业化产品。

所以总体上,当我们面对一堆版本反馈和数据的时候:1、首先要做的,是提取其中对产品的进一步改善有显著标示性的片段;2、针对这些片段,提出关于其原因的假设和潜在的修改方案;3、通过逻辑性和既往经验,去掉部分可能性和可实施性较低的方案;4、然后,针对剩下来的方案,设计对其调整的有效性的验证方法;5、在成本允许的情况下,尽可能尝试所有的方案,寻找效果最好的一种,固定下来。

相对于拍脑袋,这是个辛苦得多的过程。而这个辛苦的过程所带来的,就是我们和真正一流的研发公司之间的巨大鸿沟。

另外一个很现实的问题是,当一款产品还没有推出到市场上的时候,应当如何实现有效的需求迭代?目前来看,有几个方法可以参考:首先,尽量压短前期开发时长,让产品可以更早的面向至少一部分的用户群;其次,在有限范围内寻找参与者,典型的譬如公司内的自发性组织和测试,也包括受控制的小范围封闭测试(这几乎是最常见的做法之一);最后,记住一件事:对于开发团队来说,真正的开发周期是从产品上线那天开始算起。这可说是一种超越了具体方法本身的价值观。
我认为,丰富的原始创意/敏锐的市场嗅觉、对既往成功产品(包括市场上的流行产品)成功做法的分析和总结/模板化、迭代化的开发思想/强大而迅速的执行能力,这若干项的合理组合,就是一家成功的游戏开发公司内在的基因所在。诚然,对今天的我们,这些要求很遥远也很难达到,但,这起码告诉了我们未来的方向。

一些哲学层面的提升

如果我们仔细研究人类的思维方式,你会发现,任何创新的点子在被酝酿出的一瞬间,都是基于一个特定的市场假设模型的。这个模型存在于我们的脑海里,且相互之间不可复制。譬如说我脑子里可能出现一个点子:加了芥末的酸辣黄瓜会大卖。这里的大卖,就是我基于我脑子里对顾客的理解和认知,模拟出来的一个餐饮市场的模型,我把自己的主意放到这个模型里,然后发现计算结果是“十分乐观”,接下来该怎么做?马上改行当厨子去?

且慢。首先我必须问自己一个问题,我了解餐饮业么?作为一个从来不做饭的人,我是否可以仅仅凭借自己脑子里的臆测,就认定一种产品会成功与否呢?

如果你仔细阅读了之前的文字,这里你就会明白,实际上我头脑中的市场模型并不完备。顺带你也可以懂得,其实没有任何人脑子里的模型,是与市场完全等价的。本质上,我们对于现实世界的了解,永远是局部、片面并且带有主观倾向的,这是一种常态。当然,经常去了解和分析市场的人,其模型的偏差程度,会比我这种外行要小,所以他们的判断相对更可靠一些;而我们基于对市场的不完备理解,所设计出来的解决方案,本质上也必然是有欠完美的。这是一种非常哲学化的思辨,但在产品开发过程里,这几乎可以当成警句来使用。

我们对用户的需求不够了解 >> 我们设计出来的方案充满缺陷 >> 缺陷的方案提交给不够了解的用户,必然会产生意料不到的偏差
这几乎是一种宿命的悲观论调。如果我们推演下去,不完备的方案进而会影响和改变用户原有的需求,那这基本上是乔治索罗斯著名的“反身性原理”的游戏开发版。

可是另一方面来说,正因为缺乏完美的解决方案,才导致了市场上各种游戏设计思路都有其机会,没有完美答案所以每个人都可以提出自己的方案,然后在市场中竞争并测试其有效性。生产钢材的完美方案只有一种或者几种,所以新的创业者基本上无法去开个炼钢厂。做出好游戏的思路千变万化,所以我们每个人就都有了自己的机会。

相关文章
  • 论迭代式的产品开发方法 2014-04-28

    对基础构思的完善和原型化 一款游戏从创意到开发,抽象来看可以分为两大阶段:基础构思的阶段,和迭代开发的阶段.任何游戏在最早的时候都只是一个或者一组零散而不确定的构想,策划人员将这组构想加以整理,抽取其中相互联系的规则组成核心规则集,这就是产品最初的框架.譬如说俄罗斯方块最初的规则可能包括:方块连成一行就消除并加分:头顶随机掉落新的方块:方块可旋转,等. 一般来说,在这个阶段,游戏开发者会寻求利用这组核心规则建立一个简单的DEMO,用来验证游戏本身的可玩性.这个DEMO往往是缺乏美术效果和友好的U

  • C++11(及现代C++风格)和快速迭代式开发 2013-11-05

    过去的一年我在微软亚洲研究院做输入法,我们的产品叫"英库拼音输入法" (下载Beta版),如果你用过"英库词典"(现已更名为必应词典),应该知道"英库"这个名字(实际上我们的核心开发团队也有很大一部分来源于英库团队的老成员).整个项目是微软亚洲研究院的自然语言处理组.互联网搜索与挖掘组和我们创新工程中心,以及微软中国Office商务软件部(MODC)多组合作的结果.至于我们的输入法有哪些创新的feature,以及这些feature背后的种种有趣故

  • 迭代式开发进度控制 2014-02-11

    计划 计划定义的是项目的目标是什么,为什么?在这个职能的执行中,项目开发组的任务.目标.具体目标和战略被确定. 即使在软件开发领域之外,人们对于事物的处理总有惯用的思路.我的定式是:"我的目标是什么?我的起点是什么(包含拥有的资源)?从起点出发需要经过哪些途径可以达到目标?"这个自觉的思维模式非常有效,无论项目大小,它包含了朴素的管理思想. 公司资本雄厚,对于EC产品的战略构想是,1为地域分散(可能是全球)的分销企业提供提高业务管理效率的软件产品:2该产品的应用是基于Internet:

  • 使用Scrum来做产品开发 2014-04-20

    传统的软件开发 各类大中小型企业所运用的传统软件构建方法,即是众人皆知的"瀑布"型开发方法.此模型存在很多变体,但其典型性是在开发初期制定详细的计划,在计划中最终产品己被仔细研究,设计,并且一切详细资料都记录在案.任务已设计制定,并且在工作中使用如Gantt (根特)图表等工具和Microsoft Project 项目管理软件.开发团队预计开发项目的时间是以累计其相关每一步骤而得出的.当项目管理者(stakeholder)全面审核开发计划并表示赞同,开发团队即时开始工作.团队成员完成他

  • 解析精益产品开发(三)--面向价值的可视化 2014-02-18

    用户故事图谱和任务看板.版本和迭代燃尽图,可视化已经成为敏捷和精益产品开发必选实践.可视化真的重要吗?我们将从一个真实团队的实践开始,探讨可视化的作用,以及如何让可视化发挥效用. 1. 一个团队实例 这是一个50人左右的团队,做企业级存储和数据管理产品,他们通过实施产品开发中的价值.技术风险和价值流动过程的可视化,促进了团队的沟通.决策.自我管理和持续改进. 1.1 可视化价值 图1是团队使用的用户故事图谱,它集成了产品目标.产品功能项以及产品的发布计划. 图1 用户故事图谱实例 图中左上部的两

  • [8044]敏捷开发方法 2014-12-27

    一句话评论:复习一下敏捷的12条原则,然后看看,Marty如何理解产品经理在"敏捷团队"里的角色定位. Marty Cagan 发表于2009年6月1日,原文地址,译者:蒋彬 / 审校:周舜莉 徐定翔 许多产品开发机构都尝试过所谓的"敏捷软件开发"方法,其中最为流行的是"极限编程"(XP),此外还有其它一些敏捷方法,比如Crystal.Adaptive.Scrum和Pragmatic Programming等. 在使用这些敏捷方法时,产品经理常常

  • 小团队网站项目开发方法探讨 2011-06-28

    最近在做实验,看怎么样才能够提高小团队的的项目开发效率.我碰到的场景,相信很多互联网公司也会碰到,在有限的时间.有限的资源情况下完成一个项目,并且在一定时间范围内升级功能达到具有竞争力. 这里定义的小团队是有一个项目经理,1-2个程序员,1个网页设计,测试则是不同项目组交叉设计. 原来存在的问题: 1 团队之间口头沟通多,书面沟通少,项目开发到后期发现会遗漏一些重要功能或者出现原来想到的问题. 2 页面设计和程序开发发生死锁,导致进度受到影响. 3 功能设计描述不清,造成页面设计和程序开发理解上

  • 培养产品开发及创业人士的创造性问题解决能力(Creative Problem Solving) 2014-01-07

    创造力是孕育创新的重要载体.然而,我们的文化一直对于批判性思维的过于强调,这在无形中抑制甚至抹杀了"创造力"的发展.尽管如今的商业模式仍然受到复杂的全球化运营模式和商品化进程等因素的主导.然而在信息时代产业不断壮大的时代趋势引领下,创造力再一次获得了人们的关注与重视.而今,创造力被认为是信息产业成功与否的最关键因素.与此同时,有专家指出,在未来的几十年中,创造力将会成为企业获取成功背后关键的动因(*1). 哪些是构成创造性思维的重要因素?广泛学习.扩大思维界限,以及培养图形化思维,简单

  • 调查:敏捷开发方法 Scrum最流行 2014-05-23

    毫无疑问,敏捷开发方法正在大举进军今天的企业,但是通往敏捷的道路却是崎岖的.它更像是一条多车道的高速公路,各种类型的司机们都在选择各自适合的路线向目的地进发.最近,某网站组织了2008年敏捷趋势调查,结果数据显示,瀑布式开发方法并非总是到达目标的捷径. 在本次调查中,Scrum成为所有敏捷技术中最受欢迎的,选择Scrum方法的高达41%;其次是极限编程(XP),占到15%.另有14%的被调查者选择了混合使用Scrum和XP,13%的人使用自定义或其他类型的混合敏捷方法.Crystal和动态系统开

  • Hadoop 迭代式计算框架 Guagua 2014-07-30

    Guagua 网站 : https://github.com/ShifuML/guagua Hadoop 迭代式计算框架 Guagua 是 PayPal 的一个开源机器学习框架 Shifu 的子项目.Guagua 主要解决了模型训练的分布式问题.同时 Guagua 并没有将自己局限在分类模型,Guagua 是一个基于 Hadoop 的迭代式计算框架,几乎任何基于迭代的算法都可以利用 Guagua 为其添加分布式功能.此外由于Guagua对分 布式的良好支持,我们以前许多想做又不能做的工作比如模型

  • 虚拟化--互联网时代的产品开发加速器 2014-12-23

    高技术高竞争的互联网时代,对产品的交付时间逐步变短,而对交付质量的要求逐步提高,各种新创意.新产品层出不穷,市场允许的产品推出周期也越来越短,传统的软件开发模型已经无法跟上当前的需求,高效.便捷.可迭代的产品开发模式也越来越为人们所关注,虚拟化技术正是体现这种开发模式最重要的工具. 从功能上讲,虚拟化的优势一是提高资源的利用率:二是提供多样化的配置管理:三是提供快照的保存和恢复功能:四是提供产品动态扩展的能力,这些也都是互联网产品开发模式所需要的重要特性. 我通过一年前的项目经历和目前应用虚拟化

  • 腾讯研发项目总监王晶:互联网产品开发中的"快"字诀 2014-04-19

    作者王晶,腾讯R&D项目总监.敏捷教练.从事通信.互联网开发.项目及研发管理多年,目前负责腾讯多个业务线重要产品的项目管理,探索并推行适合腾讯的敏捷研发及项目管理,从产品.运营.技术.管理四个方面,诠释了腾讯互联网产品研发中贯彻的价值观--"快". 当今互联网的发展,已不是大鱼吃小鱼的时代,而是快鱼吃慢鱼的时代.互联网产品的制胜原则就是一个字--"快".在各种形态的产品研发中,我们始终贯彻如一的价值观之一就是"快",我们应该如何来理解和诠

  • 响应式Web设计(三):响应式Web设计的方法 2013-05-06

    介绍完响应式Web的背景和概念之后,是时候该介绍具体的实现方法了,其实响应式Web设计的方法很简单,就是利用CSS3的媒体查询Media Queries和Viewport来解决问题的. 首先我们一起来看看Media Queries,这里我只会对其做一个简单的列举介绍.(有兴趣深入的同学可以参考:http://www.w3.org/html/ig/zh/wiki/CSS3%E5%AA%92%E4%BD%93%E6%9F%A5%E8%AF%A2) 通过媒体查询的设置,我们可以根据屏幕宽度.屏幕方向等

  • 敏捷开发方法XP的12个最佳实践 2013-05-17

    极限编程(eXtreme Programming,简称XP)是一种轻量级.高效.低风险.柔性.可预测的.科学的软件开发方法,其特性包含在12个最佳实践中. 1. 计划游戏 ( Planning Game ) (1)快速制定计划.随着细节的不断变化而完善: (2)详解:要求结合项目进展和技术情况,确定下一阶段要开发与发布的系统范围.当计划赶不上实际变化时就应更新计划. 2. 小型发布 ( Small Release ) (1)系统的设计要能够尽可能早地交付: (2)详解:强调在非常短的周期内以递增

  • yongtree吐槽:互联网产品开发乱象 2013-07-08

    从工作几年后,自己慢慢的觉得自己喜欢互联网领域的开发,这个领域能让我保持对技术高度的警觉性,能给我带来很多的新鲜感,所以一直在研究互联网领域的开发模式和特点.从企业应用领域转到以互联网为主的领域也差不多两三年了吧,这几年我明显感觉到找到适合我的发展之路,因为有兴趣所以让我不知疲倦的学习,成长.但是这几年也深深的体会到,互联网领域的开发不是一帆风顺,总有一种怪怪的感觉,如鲠在喉不知所然,我认为最大的问题在开发过程中的理解不统一,新观念和旧传统存在着激烈的斗争,不同的思路难以融合. 作为大多数的管理

  • MapReduce的组合式,迭代式,链式 2014-11-12

    1.迭代式mapreduce 一些复杂的任务难以用一次MapReduce处理完成,需要多次 MapReduce 才能完成任务,例如Pagrank,K-means算法都需要多次的迭代,关于 MapReduce 迭代在Mahout中运用较多.有兴趣的可以参考一下Mahout的源码. 在MapReduce的迭代思想,类似for循环,前一个 MapReduce的输出结果,作为下一个 MapReduce的输入,任务完成后中间结果都可以删除. 代码示例: Configuration conf1 = new

  • Symbian^3产品开发工具包 2010-07-08

    Symbian^3产品开发工具包 网站 : http://licensing.symbian.org/ 该项目简称 PDK,是 Nokia 为 Symbian ^3 提供的开发工具包,基于 EPL 协议发布. PDK 3.0.0 包含 Symbian^3 中所有的API,and is the first release to support a full UI ROM execution on ARMv5 platforms. 授权协议: EPL 开发语言: Java C/C++ 操作系统: S

  • 编写php应用程序实现摘要式身份验证的方法详解 2013-10-27

    本篇文章是对编写php应用程序实现摘要式身份验证的方法进行了详细的分析介绍,需要的朋友参考下 通基本身份认证一样,也可以使用PHP网页处理HTTP请求报头字段来匹配摘要式身份验证信息.例如下边的代码使用header()函数要求客户端使用Digest验证,它在HTTP消息报头中增加了一个WWW-Authenticate字段: header('WWW-Authenticate:Digest Realm="MyRealm",nonce="47alf7cf25ce7",al

  • php可应用于面包屑导航的迭代寻找家谱树实现方法 2014-04-21

    这篇文章主要介绍了php可应用于面包屑导航的迭代寻找家谱树实现方法,涉及php迭代的技巧与应用方法,非常具有实用价值,需要的朋友可以参考下 本文实例讲述了php可应用于面包屑导航的迭代寻找家谱树实现方法.分享给大家供大家参考.具体实现方法如下: <?php echo "<pre>"; $area = array( array('id'=>1,'area'=>'北京','pid'=>0), array('id'=>2,'area'=>'广西

  • 苹果产品开发的绝密工作流程 2015-01-05

    长期以来苹果产品开发流程在很多方面都笼罩着一层神秘的面纱,而在Adam Lashinsky新发行的<Inside Apple: How America's Most Admired–and Secretive–Company Really Works>一书中对这些流程有所涉及.这本书同时谈论了苹果公司各个不同的方面,包括其理念.招聘流程以及传说中的秘密等等. 苹果始终坚持同一产品开发流程,这也是其多年魅力不减的原因所在.在接下来的这些要点中,有些可能是我们已在其它地方见过的,而有些却是新的.以