Skip to main content

Home/ 互联网之'我的阅读'/ Group items tagged 规范

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
ocean wu

网站优化规范16条细则要求 - 0 views

proxyit4u.info/index.php

标准 网站优化

shared by ocean wu on 03 Jun 08 - Cached
  • （1）网站栏目结构合理，栏目设置不要过于复杂；（2）网站导航清晰且全站统一，通过任何一个网页可以逐级返回上一级栏目直到首页；（3）网页布局设计合理，网站设计符合用户浏览习惯；（4）重要文字信息尽可能出现在网页靠前位置；（5）字体清晰，CSS风格协调一致；（6）最多3次点击可到达产品详细内容页面；（7）通过网站任何一个网页不超过3次点击可达到站内其他任何一个网页；（8）遵照搜索引擎为管理员提供的网站优化指南，通过网站结构和内容等基本要素的优化为搜索引擎检索信息提供方便，不采用任何被搜索引擎视为垃圾信息的方法和欺骗搜索引擎的方式；（9）网站首页、栏目首页及产品内容页面均有一定的文字信息量；（10）每个网页有独立的、可概括说明该网页核心内容的网页标题；（11）每个网页有独立的、与该网页内容相关的META标签设计；（12）每个网页有独立的URL；（13）产品内容页面URL尽可能简短且体现出产品属性；（14）产品/企业新闻详细内容页面是独立网页不是弹出窗口；（15）对于产品品种多的企业网站，要有合理的产品分页方式；（16）网站内容保持适当的更新周期。
ocean wu

用户体验与产品管理(完整版)_深耕·生根 - 0 views

hi.baidu.com/...ff0772f04ba35baea40f52d2.html

ue 团队管理 档案 用户体验

shared by ocean wu on 03 Jun 08 - Cached
  • 第一章 用户体验(User Experience, UE)专业人员正逐渐从商业角度对他们的工作感兴趣，在他们的核心观念中，UE的重点是理解用户需求并创建有用和易用的产品来表达这种需求。 UE人员常常在他们的研究、设计和创意没有得到相应的尊重时感到非常失落。差不多每个UE人员都有过与那些尽管缺少交互方面的需求和流程的知识，却根据他们的感觉或毫无道理的看法来驳回一个建立在研究基础上的设计的领导者打交道的糟糕经历。 很多UE人员逐渐意识到他们有经验和洞察力来运用权威性并在帮助构建的产品中发挥更大影响力，产品管理人员也对这些希望扩大影响以保证以用户为中心的产品开发顺利进行的交互设计师、信息架构师和易用性工程师等有了更多的兴趣。 对很多UE实践者而言，成为产品经理(Product Manager, PM)是一个合理的转换，因为两者往往需要类似的技能，特点和能力。此外产品管理是很多组织共有的角色，向这样一个已存在的角色过渡是较为容易的，只是信息架构师或交互设计师如果选择用这种直接方式来影响产品的话，他们还需要学会换位思考。
  • PM是什么? 传统意义上PM就是一个产品的主管，为了方便讨论，我们这里将产品定义为软件、网站、网络应用、局域网或技术产品。 作为一名领导者，PM将对整个产品的成功负责，这其中包括用户体验。对技术产品而言，用户体验是产品成功中非常重要的部分，当然还包括其他方面，像产品的销售、技术、法律、商业模式、定位、品牌和营销等。 PM应该扮演一个领导者而非独裁者的形象，才能保证产品的成功，并得到各方的支持。像总统会与负责防务、交通、农业等的官员共事一样，PM团队也包括营销、技术、财务和其他领域的人。与票选民主不同，PM对用户和客户负责，通过收入、利润、用途和其他市场驱动因素来实行决定民主。 产品管理中涉及的各项任务和领域使得PM必须精通业务的方方面面。
  • PM的职责 PM的基本职责是理解市场并推动适应市场的产品开发，由于UE人员往往已经熟悉了设计的用户需求也具备相应市场知识，因此他们具有成为优秀PM的潜质。 PM还有如下一些较高层次的职责: • 建立产品策略，重点是对产品的未来有长远和有说服力的眼光。 • 将策略转化为产品路线，有了清晰的远景和策略后，PM就要与管理层一起确认并执行策略。 • 撰写支持商业策略和市场需要的需求书，确定主要路线，然后细化特定的可执行的需求。 • 确定以合适的顺序，在合适的时间提供合适的功能特性(features)，以客户价值和市场的关联程度来划分这些特性。 • 确定与市场间有适当的沟通渠道，以合适的方式向合适的人发送合适的消息，并确认客户已了解到他们的产品。
  • ...8 more annotations...
  • 产品管理和用户体验的差异 尽管PM的职责很广也很有战略性，他们还需要负责在战术层面具化他们的战略。在一些细节上，PM可能存在与UE人员重叠的问题。正如Johathan Korman写道: 当我向那些不了解"交互设计"的人们描述我是做什么的时候，首先我说:"我观察用户的需要，确定哪类产品最适合他们，然后制定关于这个产品的行为规范，以此推动开发团队的工作。"人们常常回应说: 在我的组织里，我们管这个叫"PM"。 乍一看，用户体验的角色和产品管理惊人的相似。然而你仔细观察就会发现产品管理和用户体验在职责、重点和依赖度上是有区别的。 职责: PM负责整体成功，而UE人员负责界面设计使之满足用户需求并易于使用。UE人员同样应该像销售、营销、工程人员那样关注整体的成功，尽管并不负责这些方面。 重点: 当UE人员聚焦在界面与产品体验之时，PM会从市场整体反馈、特定市场规划、竞争力、技术、收益与损耗以及可调用的资源等方面来审视这些界面与产品体验。 依赖: 信息架构师(IA)、图形设计师、易用性专员等主要精力集中在界面上，他们需要依赖自身或类似角色的其他人一起来完成工作。PM则坚定地要求他人能执行其产品策略，他们更多地需要融合一些微妙的产品目标、策略、影响力、坚定和公平的决策等因素，这些要求多甚于UE人员。 或许Johathan Korman最好地诠释了PM与其他角色如UE之间的差异: PM负责产品应该做什么(What the product should do)，而其他角色负责产品怎么做(How the product does that)。
  • 产品管理与用户体验的冲突 最常见的UE与PM间的冲突就发生在该产品应该做什么与产品该怎么做的讨论上，双方常常争论谁应该负责定义产品的特性与需求。PM感觉应该由他们负责，因为他们管理产品，但是UE人员感觉应该由他们负责，因为是他们在花时间直接与客户和用户打交道，研究用户需求。 最终由于PM对整个产品的成功负责，他们也就成了决定产品做什么的最后仲裁者。好的以市场为重点的PM应能理解市场背景和客户需求，并在第一手经验和已有研究的基础上决定合适的产品特性与功能。 然而UE人员常常对此非常光火，因为他们认为自己更贴近客户和用户，理应负责产品的需求收集和定义。 好的PM应该象UE人员那样贴近自己的用户，否则就会脱离用户，只知道坐在办公室里开大会，让UE人员来做此类研究。 好的PM能深知用户体验这个角色并理解其重要性，重视他们的投入并利用他们的研究和建议来创造优秀的产品。正如总统需要从自己的内阁成员那里获得建议一样，PM也应该利用自己的"内阁成员" --- 用户体验、市场营销、技术等 --- 去做出决策。 从UE人员向PM角色的转换远不止去操作所有的界面设计，PM一项很重要也很有挑战的任务是负责确定产品的目标与策略，树立内在和外在的产品领导能力，创造商业模式及获得资本，从小事出发又能着眼大局，并协调市场、工程技术、财务、销售当然还有UE一起向成功迈进。 在第二章，我们将向你介绍迈向产品管理的方方面面，包括你在UE岗位上不可以做而在PM角色上需要做的事情、成为PM你必须做哪些准备、UE背景的人成为PM后常有的缺陷等，来帮助你作出这种转变。
  • 第二章 在前一章中，我们勾勒了PM的职责、PM与UE人员的差异以及为什么两种角色之间会产生冲突等。 现在我们来介绍当UE人员成为PM后其思考重点、职责与挑战将会发生哪些改变，离开UE工作岗位后你将有哪些收获与损失以及如何为这种转变做准备等。 在你向PM的角色纵身一跃之时，最好清楚这次跳跃对自身的影响。
  • 作为UE人员不可以做而作为PM必须做的事情 成为PM后，你每天的工作将会发生巨大的变化! 你必须运用你的全部知识投入到整个产品中。作为UE人员你也许能同样做到这一点，只是限于行政授权你未必需要和公司内的全部决策部门打交道，以下就是你的一些"新职责": 关注产品策略以及客户和终端用户的需求(这也是你做出转换决定的原因) 你必须长期地研究客户和用户，找出用户需求与商业目标的切合点，相应地了解这方面的知识并有意识地利用它。从产品的整体上确定用户的焦点，不光是设计。 沟通、政策以及定价都必须整合成为"客户体验"的整体，过去我们常常对这些方面的重要性认识不够，成为PM后你就必须对关乎产品体验的方方面面负责了。 平衡各方力量 确保你的产品重点是客户和用户需求非常重要，但是其他方面同样值得关注，包括但不限于: • 销售目标 • 市场/品牌目标 • 技术趋势 • 文档管理 • 预算管理 • 市场趋势 • 竞争力 • 商业模式与回报 (可能的人员浮动、变局影响、价格杠杆等) 做好一款产品需要在商业目标、用户需求和市场效应之间进行一系列权衡，作为PM，你就必须在各方之间努力做好平衡。 推广产品 你必须同时在内部(包括销售、市场、管理层、开发者等)和外部(包括客户、用户、业界分析员和媒体)间取得支持。仅仅开发出一款好的产品还不够，你还必须让人们知道它，推广它带来的好处。 向组织中的其他产品提供策略投入 如果你是一间中型或大型公司的PM，在这个位置上你还需要影响其他产品。你也会与其他公司内的其他PM交流，思考公司的全部产品线，并将你的产品融合其中。 你面临的挑战与压力 PM这个新角色会让你很有荣誉感和责权感，而且新头衔带给你的影响力可能会胜过其他，但它也是"带刺的玫瑰" --- 你同样必须应付挑战和压力。 作为PM，你的权力很有限 Guy Kawasaki形容PM是"一个背负全部职责却没有任何权力的人"。大部分为你的产品工作的人会向不同的管理层汇报，很少甚至没有人会直接受命于你。你必须梳理这些分散的资源，指导他们的工作 --- 尽管他们从各自的经理那里获得了不同的工作方向。
  • 你必须做出决定并对此负责，而不仅仅是建议 事实上你必须做出很多的决定并为此负责，不是所有人都会认同(你的这些决定)。当然如果你的工作干的好，你可以向他们证明你的决定是正确的，明确解释你的原则，其他人也就不会显得焦急或轻视 --- 但这并不容易! UE出身的PM会发现所创建的体验也许不是对用户"最好"的体验，因为还需要考虑其他重要的因素(如管理层的需求、商业策略、商业模式等)，让这些人理解作出这种或许有损用户，但最终有益于产品的决定往往需要时间。 你将经常处在利害分歧的中心 销售人员希望有不同的功能、开发人员将你制定的时间表往后推、财务人员需要新的后端功能、商业开发人员希望能为合作伙伴做一些产品调整、设计师希望更改一些功能的实现、用户希望增加一项你的竞争对手推出的新功能、管理层希望你的产品能与公司新产品进行整合... ... PM就处在这样不同的竞争中心，在一些公司中这样的处境是很不妙的。你必须调节好这些冲突的想法，制定相互之间的优先级以推动产品策略并保证皆大欢喜(至少不能让某个人动怒)。 成功的PM总是围绕着整体的目标和策略来平衡各方的要求，决定做哪些可以最大限度地支持这些目标。PM对目标与策略的理解越深，就越能做出权衡考量。有时候一点小的让步能够得到更多的收益，有时候则需要更好地梳理目标。 管理层需要从你这里得到关于产品的信息 PM不只是产品开发团队的一员，你是整个产品的象征。无论你把事情做好了或搞砸了，也无论你是否真的能驾御局面，你都必须为此负责。 作为UE人员可以做而作为PM不可以做的事情 从UE岗位转换到PM岗位的人会对新职责感到兴奋和有挑战性，与此同时，他们也会失去一些UE工作的一些方面: PM不必插手过多细节 这是很多之前习惯过问小事的人面临的最艰难的挑战。作为PM很多具体的工作都可以委派给其他人来做，一个花费太多时间去处理细节问题的PM注定没有做好他们的本职工作 --- PM需要关注的是战略层而不是战术层。 PM并不追求尽善尽美和理论上的完美 有一个针对UE的笑话是UE人员经常回答问题的时候说"这个取决于…"。对PM来说，也许它确实取决于某件事情，但这并不要紧的。这并不是什么理论上应该发生的问题，而是在此情况下我们马上要做什么以及为什么做的问题。 你必须习惯够用即可的观念，作出在用户看来未必完美但在有限的资源下很受用的决定。
  • PM对产品的核心问题不只是建议 这一点和上面的有点背道而驰，UE实践者们提出建议，而PM需要制定策略、较高层面的用户体验、功能设置、市场规划、定价及其他方面。之所以又提到这一点，是希望促成你进行反省。如果你只是习惯建议或很难做决策，你也许不适合成为PM。 PM不是艺术家或专家型实践者 PM并不专注与产品的某个部分，而是知晓全局。他们有点类似船长或教练去驾御局面。在这个层面上，PM需要保障一起共事的人能将产品目标反映到方方面面，例如营销策略、界面设计、版权书写等。 由于不是专家，在各个方面进行调节是比较困难的，PM就必须在后面的工作中不断学习如何领导其他专家向一个共同的目标努力。
  • 从现在起更好地配合你的PM 如果知道"幕后"产品管理，你可能已经动心了。有一条捷径能帮助你开始: 从现在开始更紧密和有效地配合你的PM! 这个办法即使对那些并没有这方面特质、技能或只是想成为PM的人来说都是值得一试的。作为一名UE实践者，更好地理解其他角色的同事所面临的责任与挑战可以帮助你调整与他人共事的方式，并且最终使你变得更有价值、更受尊敬、更有影响力。 有UE背景的人在某些领域是能够很好地与PM相处的，有些办法能很好地帮助你探路，而无论你是否迈出了这一步。 领导力 不要只知向PM或其他同事索要具体的研究和设计成果，在很多情况下，其他同事很欢迎你能有主动性和创意，不过同时他们也保留不同的观念，只要把事做起来就能迅速公开和集中地进行具体地讨论，总好过停留在理论和臆测层面。 向PM问清楚他们的产品目标是什么 问清目标非常重要，体现在两个方面：第一，PM自己有可能之前没有仔细想过产品目标，你这一问后，有可能让你成为最受信赖的顾问之一并帮助他们建立目标。 第二，如果PM已经有了目标，那么你也就能清晰地建立一系列的目标和预期。如果他们的目标存在问题，你还可进行澄清和确认，并决定怎样让它回到正确的道路上。 帮助PM评估设计的各方面因素 不要只是提出设计方案然后让PM做决定，要让自己准备好参与讨论特定设计选择的影响，向他人展现你的设计背后的原因已经他们在更广范围内与产品远景和目标的联系，聆听PM怎么说并搞清楚他们拒绝或认可的理由。 提出带有远期规划的强烈建议 你所能提供的一些证据和经验将支持着你更紧密地成为产品的一份子，而不只是一个辅助的参考者。你也能从纷繁复杂的因素中做出决定的过程中得到锻炼，如果你立志想做PM的话这些很有帮助。 展现你对工作的远期规划将使你能成为团队中最重要的成员之一，并且能展现你有担负更多职责的潜力 --- 不管你现在的角色是什么。 帮助PM走出办公室 PM不应该对客户和用户视而不见，尽管有人是这么干的。你应该通过询问他们最后一次见用户是什么时候来帮助他们，把他们带入到正式或非正式的用户研究中，或者给他们讲在用户访谈中的一些有意义的故事，邀请他们下次同去。如果被拒绝了，下次继续邀请。 如果PM能自愿去拜访用户，让他们带上你。除了了解用户需求之外，这也是一个你有时间向PM求教他们的观点、兴趣与目标的好机会。 如果你真的无法把PM带出办公室，那就把用户们带进来吧。在这种情况下，应该没有哪个PM(包括其他开发成员)能找借口拒绝和用户沟通。
  • 学习并准备成为PM 因此，你想成为PM? 不知道从何做起? 除了上面提到的以外, 你还应该增加你在产品管理方面的知识，从中找到你为这一角色转变所需要的东西。 想想你迈向UE之路时候所做的事吧: 书、博客、会议、小组讨论、各种组织以及导师等，它们都发挥了很大的作用。如果你想成为PM，这些方式依然有效。 成为PM最好的条件是通过培训和会议。差点忘记提了，我们在IA 2007峰会: 你想成为产品经理 上有一个预备会议，这个半天的训练营上将会集中讨论如何从UE向PM的角色转变，包括如何更好地平衡你现有的技能以及怎样避免潜在的不足等。
ocean wu

《数位之墙》Web 2.0 再思考（四）「私人财产」与「阶级不平等」 - 0 views

china.digitalwall.com/...display.asp

用户体验 社会化网络 网站架构

shared by ocean wu on 01 Aug 07 - Cached
  • Web 2.0 网站都是以形成社区为基础，而社区其实就是小型社会。想要社会得以发展，经营者必须注意人际互动方式的促进及规范。最终目标则是建立用户间的「关系链」，否则用户注定待不久。
  • 这正是Web 2.0 与 1.0之间的重大差异，然而却很少被提及。 1.0试图满足的是人类的「工具性需求」，而Web 2.0 试图满足的却是「心理性需求」，
    • ocean wu
      ocean wu on 01 Aug 07
       
      你可以在自己电脑上写日记，但你选择在网络上写；你可以在自己浏览器理收录书签（Bookmark），但你选择在网络上收集。承认吧，你其实想要被人发现。
  • 在一个社会中，人人都有向上攀爬的欲望。亦即马斯洛需求五层级中的最高层级，自我实现的需求。尽管成功者仅占5%，然而人人心中都渴望成功。 你如何获知自己成功？这是Web 2.0 的另外一个重点：迈向成功的过程必须要有累积，这个累积必须要量化而且要被展示出来让人知道：这就是「私有财产」的观念。其中，还可分为有形财产与无形财产。
  • ...3 more annotations...
  • 你写的Blog与上传的相片都是有形财产，无形财产则可带入「信用」的概念，亦即在一个社会中被认可的程度。例如，社区网站实行多年的积分及等级制度，就是一种被社区成员公认的个人信用。 一个用户在Web 2.0 网站中的活动必须要累积成财产，最后，除了在此地形成的关系链以外，用户还会因为这些虚拟财产的累积而再也无法离开。简单来说，「搬家」变得困难。 然而，这些制度大部分没有被好好运用，积分与等级仅是无关重要的数字罢了。经营者其实没有注意到，适当制造「穷人」以及「阶级不平等」才是一个社区网站进步的关键；而实体社会其实也是如此。
  • Avatar服务的成功关键，在于其展示机会要多。用户花钱买头像，就是为了展示自己。如果曝光度不足，购买的意愿就会降低。这就是「有钱，要让大家知道」的心理，经营者首先必须制造曝光机会。
  • 而经营者该做的事情是，定义出你的社区中，哪些是用户的虚拟财产，包含了有形与无形的。是所谓的活跃程度？关系链的多寡？还是被其他人推荐的次数？积分如何累积，如何变成等级？ 其次，等级与积分该如何被展示，被消耗，以创造真正的被拥有的价值，让用户自然的感觉阶级不平等的存在，适当的呈现这种不平等以促进整个社会（社区）向上的动力，进入正面循环？
ocean wu

如何用正确的方法管理高效率的开发团队 - 0 views

www.duduwolf.com/...831.html

项目管理 文档 要素

shared by ocean wu on 10 Feb 09 - Cached
  • 1. 你们的项目组使用源代码管理工具了么？MVM：应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。 2. 你们的项目组使用缺陷管理系统了么？MVM：应该用。ClearQuest太复杂，我的推荐是BugZilla。 3. 你们的测试组还在用Word写测试用例么？MVM：不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。 4. 你们的项目组有没有建立一个门户网站？MVM：要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。 5. 你们的项目组用了你能买到最好的工具么？MVM：应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。 6. 你们的程序员工作在安静的环境里么？MVM：需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。 7. 你们的员工每个人都有一部电话么？MVM：需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。 8. 你们每个人都知道出了问题应该找谁么？MVM：应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。 9. 你遇到过有人说“我以为…”么？MVM：要消灭“我以为”。Never assume anything。 10. 你们的项目组中所有的人都坐在一起么？MVM：需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。 11. 你们的进度表是否反映最新开发进展情况？ MVM：应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。 12. 你们的工作量是先由每个人自己估算的么？MVM：应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。 13. 你们的开发人员从项目一开始就加班么？MVM：不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。 14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？MVM：不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。 15. 值得再多花一些时间，从95%做到100%好MVM：值得，非常值得。尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。 16. 登记新缺陷时，是否写清了重现步骤？MVM：要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。 17. 写新代码前会把已知缺陷解决么？MVM：要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。 18. 你们对缺陷的轻重缓急有事先的约定么？MVM：必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。 19. 你们对意见不一的缺陷有三国会议么？MVM：必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。
  • 20. 所有的缺陷都是由登记的人最后关闭的么？MVM：Bug应该由Opener关闭。Dev不能私自关闭Bug。 21. 你们的程序员厌恶修改老的代码么？MVM：厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。 22. 你们项目组有Team Morale Activity么？MVM：每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。 23. 你们项目组有自己的Logo么？MVM：要有自己的Logo。至少应该有自己的Codename。 24. 你们的员工有印有公司Logo的T-Shirt么？MVM：要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。 25. 总经理至少每月参加次项目组会议MVM：要的。要让team member觉得高层关注这个项目。 26. 你们是给每个Dev开一个分支么？MVM：反对。Branch的管理以及Merge的工作量太大，而且容易出错。 27. 有人长期不Check-In代码么？MVM：不可以。对大部分项目来说，最多两三天就应该Check-In。 28. 在Check-In代码时都填写注释了么？MVM：要写的，至少一两句话，比如“解决了Bug No.225”。如果往高处拔，这也算做“配置审计”的一部分。 29. 有没有设定每天Check-In的最后期限？MVM：要的，要明确Check-In Deadline。否则会Build Break。 30. 你们能把所有源码一下子编译成安装文件吗？ MVM：要的。这是每日编译（Daily Build）的基础。而且必须要能够做成自动的。 31. 你们的项目组做每日编译么？MVM：当然要做。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source control; 3. daily build。 32. 你们公司有没有积累一个项目风险列表？MVM：要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。 33. 设计越简单越好MVM：越简单越好。设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。 34. 尽量利用现有的产品、技术、代码MVM： 千万别什么东西都自己Coding。BizTalk和Sharepoint 就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文 本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。 35. 你们会隔一段时间就停下来夯实代码么？MVM：要。最好一个月左右一次。传言去年年初Windows 组在Stevb的命令下停过一个月增强安全。Btw，“夯”这个字念“hang”，第一声。 36. 你们的项目组每个人都写Daily Report么？MVM：要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。 37. 你们的项目经理会发出Weekly Report么？MVM：要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。 38. 你们项目组是否至少每周全体开会一次？MVM：要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。 39. 你们项目组的会议、讨论都有记录么？MVM：会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。
  • 40. 其他部门知道你们项目组在干什么么？MVM：要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。 41. 通过Email进行所有正式沟通MVM：Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。 42. 为项目组建立多个Mailing GroupMVM： 如果在AD+Exchange里面，就建 Distribution List。比如，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。 43. 每个人都知道哪里可以找到全部的文档么？MVM：应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。 44. 你做决定、做变化时，告诉大家原因了么？MVM： 要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于 是不是能access information/data，而在于是不是掌握资源。 45. Stay agile and expect changeMVM：要这样。需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。 46. 你们有没有专职的软件测试人员？MVM：要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。 47. 你们的测试有一份总的计划来规定做什么和怎么做么？MVM：这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。 48. 你是先写Test Case然后再测试的么？MVM：应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。 49. 你是否会为各种输入组合创建测试用例？MVM：不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚，你是否有时间去运行那么多test case。
  • ...3 more annotations...
  • 50. 你们的程序员能看到测试用例么？MVM：要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。 51. 你们是否随便抓一些人来做易用性测试？MVM：要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了，不方便的永久了也就习惯了。 52. 你对自动测试的期望正确么？MVM：别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能“矫枉必须过正”了。 53. 你们的性能测试是等所有功能都开发完才做的么？MVM：不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。 54. 你注意到测试中的杀虫剂效应了么？MVM：虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。 55. 你们项目组中有人能说出产品的当前整体质量情况么？MVM：要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。 56. 你们有单元测试么？MVM：单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了——可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。 57. 你们的程序员是写完代码就扔过墙的么 ？MVM：大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。 58. 你们的程序中所有的函数都有输入检查么？MVM：不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。 59. 产品有统一的错误处理机制和报错界面么？MVM： 要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。 60. 你们有统一的代码书写规范么？MVM：要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。 61. 你们的每个人都了解项目的商业意义么？MVM： 要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。 62. 产品各部分的界面和操作习惯一致么？MVM：要这样。要让用户觉得整个程序好像是一个人写出来的那样。 63. 有可以作为宣传亮点的Cool Feature么？MVM：要。这是增强团队凝聚力、信心的。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。 64. 尽可能缩短产品的启动时间MVM：要这样。软件启动时间（Start-Up time）是客户对性能好坏的第一印象。
  • 65. 不要过于注重内在品质而忽视了第一眼的外在印象MVM：程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。 66. 你们根据详细产品功能说明书做开发么？MVM：要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。 67. 开始开发和测试之前每个人都仔细审阅功能设计么？MVM：要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说“你看，当初我就是反对这么设计的，现在吃苦头了吧” 68. 所有人都始终想着The Whole Image么？MVM：要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。 69. Dev工作的划分是单纯纵向或横向的么？MVM：不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。 70. 你们的程序员写程序设计说明文档么？MVM：要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。 71. 你在招人面试时让他写一段程序么？MVM：要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。 72. 你们有没有技术交流讲座？MVM：要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。 73. 你们的程序员都能专注于一件事情么？MVM： 要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5 个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的 资源了。
  • 74. 你们的程序员会夸大完成某项工作所需要的时间么？MVM：会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。 75. 尽量不要用Virtual HeadsMVM： 最好不要用Virtual Heads。Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对 Resource Manager的。
ocean wu

当大数据遭遇深不可测的人性 - 0 views

tech.sina.com.cn/...pid_8459326.htm

数据挖掘 数据应用 数字化营销

shared by ocean wu on 03 Sep 14 - No Cached
  • Target建立了一个非常规范的大数据管理系统，它拥有一个数据分析团队，在查看准妈妈们的消费记录之后，找出了20多种关联物，通过这些关联物对顾客进行“怀孕趋势”预测，并寄送相应的优惠券，为消费推波助澜。只要有可能，Target的大数据系统会给每一个顾客编一个ID号。你刷信用卡、使用优惠券、填写调查问卷、邮寄退货单、打客服电话、开启广告邮件、访问官网，所有这一切行为都会记录进你的ID号。而且这个ID号还会对号入座的记录下你的人口统计信息：年龄、是否已婚、是否有子女、所住市区、住址离Target的车程、薪水情况、最近是否搬过家、钱包里的信用卡情况、常访问的网址等等。Target还可以从其他相关机构那里购买你的其他信息：种族、就业史、喜欢读的杂志、破产记录、婚姻史、购房记录、求学记录、阅读习惯等等。
  • 线上实时优化渠道
  • 因此在传统营销时代，品牌经理经常都会质疑他们的代理商的一个问题是：“我知道我的广告费有一半是浪费掉的，问题是我不知道是哪一半”，从Target的故事来看，大数据可以非常精准地锁定甚至预测用户的下一个消费行为，这让在传统营销时代摸不清用户需求的品牌经理拥有了一个利器。
  • ...22 more annotations...
  • 通过什么渠道(in which channel)、对谁(to whom)、取得了什么效果(with what effect )，这三点在传统营销时代无法解决的问题，似乎可以迎刃而解，因为大数据营销的本质是影响目标消费者购物前的心理路径，它主要应用在三个方面：1、大数据渠道优化，2、精准营销信息推送，3、线上与线下营销的连接。在大数据营销应用的影响下，营销环节中最难解决的一个问题——如何精准地预测目标用户的需求并提供解决方案，这也是大数据营销所存在的价值
  • 一、to whom？——大数据能精准锁定目标人群。
  • 借助大数据技术，营销者可以无限的接近、近乎准确的判断每一个人的属性。一些企业通过收集海量的消费者信息，然后利用大数据建模技术，按消费者属性(如所在地区、性别)和兴趣、购买行为等维度，挖掘目标消费者，然后进行标签层的分类，再根据这些对个体消费者进行营销信息推送
  • 1，属性标签层
  • 2，行为标签层
  • 3，目标人群层
  • 二、in which channel？——大数据能实时优化传播渠道。对于公开的媒体资源，为了覆盖尽可能多的受众，创造与受众的接触机会，广告主往往需要跨媒介传播。但是预算如何分配呢？大数据此时是最佳决策参考，基于海量用户数据，在营销渠道的投放比例分配上进行调整，获得最优的投放组合。
  • 大数据可以通过抓取微博、人人网以及各种论坛的数据，获取到消费者对品牌对产品的即时的看法和态度
  • 线下实时获取反馈
  • 拉斯韦尔模式是广告传播模式的最基本模式，它是1948年由美国政治学家、心理学家哈罗德·D·拉斯韦尔提出的一种具有代表性的线性模式，又简称“5W模式”，广告信息传播过程包含的五大要素是：谁(who)、说什么(say what)、通过什么渠道(in which channel)、对谁(to whom)、取得了什么效果(with what effect )。
  • 三、with what effect？——大数据能实时反馈效果，大数据是一种实时分析引擎。根据投放过程中的实际数据、如受众行为、流量构成及其他实时投放数据，找到广告目标受众最集中的时间点，找出受众反应最好的创意版本，确定竞品深度用户，挖掘新进潜在消费者等，对广告进行及时的判断和调整，而以上的过程是动态的、实时的。
  • “大数据”营销者近乎实时的各种传播效果反馈数据，信息详尽，并具有跟踪性
  • “说什么(say what)”，恰恰就是大数据营销不能解决的最后一个难题。因为“说什么(say what)”是取决于对消费者真实需求的洞察，而这种洞察是源自于对消费者人性的探测，这不是机器和程序在现阶段所能取代人力的经验的。
  • 能实现5W传播模式大数据营销闭环的行业是电商行业，因为像电商这类广告主将其大部分数字媒介预算通过程序化购买，是完全合理的。因为这类公司主要投放效果广告，关注消费者看了广告后的转化率，即是否会立刻在线购买。程序化购买可以获得更便宜的广告位，通过优化算法达到更多的目标人群。　　然而对于以产品、服务等核心的品牌而言，大数据营销并不能帮助他们解决品牌建立的问题
  • 对于非电商类产品而言
  • 它们最重要的工作除了销售之外，就是持之以恒地建立并保持与消费者之间有意义的关系，这种关系就是我们所熟知的“品牌的建立和维持”，它正是源自于对人性最深层次的洞察，而非其他冷冰冰的数据分析和程序筛选。
  • 线上线下协同实现效果闭环
  • 而潜藏在消费者潜意识里他们说不出来却又驱动他行为的因素，就是消费者洞察，这是品牌跟消费者建立“有意义”关系所不可或缺的一个环节，大数据无法取代人力进行。绝大多数消费者洞察不是来自于量化的研究数据和书面的研究报告，而是来自于与消费者的直接、深度接触中，比如街头暗访、消费行为的观察、与目标人群的谈话等等更接地气、更原始的方法，而非一串串冷冰冰的数码符号、人群标签所能替代的。
  • 大数据营销并不能取代基于人性的消费者洞察，但是可以改变广告公司过往几个星期做一个创意的工作的节奏，大数据基于实时的数据挖掘技术推动广告公司创造与热点相关的内容，传播公司可以根据表现不断更换创意。
  • 根据消费者在社交媒体上的热点话题创作出一个新创意，而确定延展哪个话题的创意，则是由从渺如烟海的社交大数据中挖掘出来最热门的话题。
  • 为了建立忠诚持久的良好消费者关系，广告主必须回归到传播的本质，即旨在创作有价值的、创新的品牌信息，这也是移动互联网传播中被人所津津乐道的“内容营销”，内容的创造也就是5W传播中最重要的say what
  • 大数据营销大潮中，广告公司必须学会如何地合理使用大数据这个非常好用的工具去触达目标人群，并通过智能化的方式把这些信息传递给用户，以深化同消费者的情感关系。
ocean wu

时隔10年，综合医院建设标准将迎大修订！ - 0 views

www.iyiou.com/83331

医疗

shared by ocean wu on 17 Oct 18 - No Cached
  • 10月9日，国家卫健委发布了《关于征求综合医院建设标准（修订版征求意见稿）意见的函》（国卫规划基装便函〔2018〕95号）
  • 旨在推进健康中国建设，规范综合医院建设，提高综合医院建设项目决策和工程建设管理水平，合理确定建设规模，满足综合医院功能需要，充分发挥投资效益，提高医疗服务能力。
  • 第一个突出特点是床建筑面积大幅度扩大。按照综合医院中急诊部、门诊部、住院部、医技科室、保障系统、行政管理和院内生活用房等七项设施的床均建筑面积指标，修订版比原版大幅度增加了设置标准。 比如原版对400~500张床位的建筑面积指标规定为83㎡/床，修订版则规定400～599床位的建筑面积指标为115 ㎡/床；原版1000张床位的建筑面积指标规定为90㎡/床，修订版则将900～1199床位的建筑面积指标提高到了113 ㎡/床。
  • ...5 more annotations...
  • 压缩门诊，扩大急诊
  • 压缩医技，增加保障部门，仔细看主要是减少了很多临床已经淘汰的检查设备。
  • 修订版普遍大幅度增加了预防、科研、教学区人均面积。修订版中关于综合医院内预防保健用房应按编制内每位预防保健工作人员规划预防保健用房的建筑面积，由原版20平方米，增加为35平方米。 承担医学科研任务的综合医院，应以副高及以上专业技术人员总数的70%为基数，增加科研用房每人由32平方米增加到50平方米。
  • 开展国家级重点科研任务的综合医院，按照国家级重点实验室每个3000平方米增加相应的实验用房
  • 这次修订版主要是适应新形势需要，在一定程度上是与时俱进，所以修订版明言：合理确定建设规模，而不是严格控制建设规模，其目的是满足综合医院功能需要
ocean wu

写字楼白领的这碗饭，为什么不好卖？ - 0 views

36kr.com/...5151474.html

商业模式 用户体验 餐饮

shared by ocean wu on 03 Sep 18 - No Cached
  • 没有公司食堂的白领来说，工作餐处理方法可大可小：都市生活节奏快，点份外卖对付一下成为不少人首选；而如果对均衡营养、就餐环境有特别需要，决策起来就没那么容易了。
  • 售饭机属于智能售货机细分领域，在线下零售场景应用多年。但比起友宝、友饮咖啡等动辄以万、千计落地台数，前者渗透速度明显慢很多，企业线下投放量普遍在几十到数百台左右。以饭美美为例，上线两年多，其售饭机品牌“饭饱宝”在全国仅部署约600台机器。“之前之所以没快速扩张，是要总结经验。要把供应链、中央厨房等环节的坑都总结清楚了，避免未来再踩。”
  • 气调冷链鲜食技术在国内外鲜食市场属于成熟工艺。相比之下，外卖盒饭里的食物处于裸露状态，常温自然降温，时间久了会滋生大量细菌，健康度难做保证。
  • ...18 more annotations...
  • 三全鲜食COO杨志曾表示，6个月是“品牌遗忘周期”，售卖机在此节点瓶颈明显，销售额会大幅下滑。消费者口味遗忘周期更短，仅为23天左右，因此十分考验产品研发和供应链管理能力。
  • 悠米盒子为热链预配送模式，每天11点左右将午餐通过恒温配送物流，配送到智能售货柜中。11点半售卖，到下午一点半结束，两点之后销毁剩余餐品，用户取餐后不需要加热。乐栈生活则为热链中转柜模式，智能柜包含多个小格子，可以实现0~60℃不同温度选择，消费者现场预订或者APP预订，配送员按照送餐时间，将餐品送至提货柜。
  • 二者在上游菜品研发上均采用轻资产运作模式：悠米盒子菜品强调自身工作餐供应平台定位，每台智能售饭机每日仅提供四种口味产品，且均为名厨拿手菜，并与多个名厨供应商合作，限制单个名厨菜品数量，以保证菜品丰富度；乐栈生活则将菜品以及智能柜对餐饮品牌全面放开，提供给餐饮店、外卖平台，提供全面餐饮食品定制化服务。
  • 冷链转热链，物流成本做减法；上游菜品开源，产品做加法；这两家企业的迥异打法，最终也没有成功跑通
  • 主要原因在于热链模式与终端消费场景匹配难度过高。
  • 共享厨房采用合规、标准化厨房运作，少量共享上游供应链资源，实现规模化采购，以降低菜品成本。租金、水电燃气费甚至物业服务费等均按一定标准分摊。某种层面上来说，几乎可以实现“拎包入驻”。因此，这一模式尤其受到对于轻度落地有刚需的外卖品牌青睐。
  • 运营成本高，餐品更新慢，靠自己的餐品肯定不行，需要社会化运营。
  • 做餐做餐最关键的点是要么换人，要么换餐。“固定地点，产品不断创新。但在旅游景点就可以做，因为客流会不间断更换。
  • 场景多样化是当下智能售饭机另一大思路，除写字楼外，高铁、医院等流量型场景也成为售饭机玩家们争抢点位。
  • 做智能售饭机不能太贪心。前期应该做固定人流的市场，因为固定人流教育市场成本比较小，可以产生复购。针对医院这种流动性比较大的地方，实际上还是要选取相对固定人流区域去教育，产生相对稳定的复购。如果只是“一走一过”的人，在机器不普及的情况下，教育成本比较高。
  • 如果就是做诸如罗森、7-11的家常菜、快餐，必然会面临创新压力。而如果是经典菜系餐饮企业，本身主打固定爆款，用户认可度会高很多。
  • 除智能售饭机外，共享厨房和外卖店是另外两个创新场景。外卖店很容易理解，由品牌专门为外卖业务而设的近场景餐饮店，并开放性对接外卖平台。共享厨房则更像是外卖店的集合，将在单车、租房等领域的成本共享理念，应用到餐饮市场来，市场玩家诸如食云集、熊猫星厨等，这尤其受到外卖品牌青睐。
  • 热餐本身对取餐时效要求更强，一旦错过最佳赏味期，就餐体验会大打折扣。从这个角度来说，外卖骑手人工交付优势明显。加上外卖平台持续补贴战，对于资金有限的新平台来说，拉新和运营成本必然居高不下。
  • 食云集除共享空间硬件服务外，还会提供相应赋能的软件服务以及基于流量和数据的上下游撮合服务。通过订单线路的重合，大幅降低物流配送成本。
  • 熊猫星厨，同样面向外卖餐饮品牌，提供包括软硬件及上下游配套或撮合服务。按照计划，他们预计在一年内会将线下门店增至 200 家。
  • 不过共享厨房模式同样面临餐饮证照问题、平台运营能力等诸多考验。一位餐饮从业者表示，共享厨房模式企业，拿的餐饮执照多是总部证照，会出现一证多用情况，食安问题并未解决。该位人士甚至悲观地预测，“共享厨房模式未来在某个时间节点，可能连牌照都拿不到，很多楼宇餐饮证照都被取消。”
  • 外卖店的风险则更为直接，失去了线下门店流量，仅为线上订单做供应的话，订单稳定性尤其关键。外卖平台竞争激烈，对于打折、促销等依赖程度较高。外卖专门店面临决策：如果参与打折，短期内能带来大量流量，但沉淀十分有限，难以做持续性经营；而如果差异化经营，运营能力及品牌号召力仍是大考。
  • 崎岖坎坷的白领工作餐市场，出现明显分化：智能售饭机一定程度上解决了即时性、健康度的问题，但新品研发和冷链成本并未找到合适解决方案；共享厨房和外卖店亦然，同样面临着来自各方的压力和挑战。至于谁能最终跑出来，或许还有待观察和验证。但一个共同的特点是，在白领工作餐这件事上，标准化、规范化以及上下游的轻资产平台运作，成为行业共识。
ocean wu

维文：政府有责任对物联网业者制定公开标准 - 0 views

www.channel8news.sg/...3985950.html

物联网 网络安全

shared by ocean wu on 27 Mar 18 - No Cached
  • 主管智慧国计划的外交部长维文说，物联网方案必须建立在开放平台，任何人都触手可及。维文在本地举办的《亚洲物联网研讨会》上致辞时说，如果业者采纳封闭式的物联网平台，完全掌控产品和服务的经营运作，政府无法介入监管。因此，政府有必要明文制定准则，并提供基础设施，以确保业者的产品和服务符合业界水平和规范。此外，业者必须确保产品或服务推出前，不会出现网络安全问题。维文指出，业者在开始设计产品和服务时，就必须把网络安全融入其中，而不是在推出产品或服务后，发现存在安全缺陷，才寻找解决方案。
  • ocean wu on 27 Mar 18
     
    政府有必要明文制定准则，业者在开始设计产品和服务时，就必须把网络安全融入其中，而不是之后。
ocean wu

"你我您"联合创始人刘振洋：社区团购将向门店化、前置仓迭代"_36氪 - 0 views

36kr.com/...5172943.html

社区营销 电子商务

shared by ocean wu on 19 Jan 19 - No Cached
  • 社区团购的命门，供应链体系建设
  • 社区团购平台的普遍特征——围绕家庭生活场景，以生鲜品引流、以微信小程序为载体，通过以小区为单位的团长+社群形式，线上购买、线下自提。平台负责输出成套的商品供应链、管理、物流系统。
  • 平台将重点从三个方向进行供应链建设：第一是全品类扩张，第二是直采直供的供应链体系搭建，第三则是自有品牌商品的开发生产。
  • ...18 more annotations...
  • 生鲜水果由采购团队从农产品基地进行源头直采，快消品通过与品牌商和供应商的战略合作实现从商品源头的集采和分拨，2018年12月，“你我您”已经同联合利华达成战略合作。
  • 自有商品开发方面，“你我您”倾向于选择一些生产能力比较强的合作方进行OEM（代工）生产合作，以期形成供应链壁垒。目前自有品牌的品类围绕食材以及浅加工商品为主，已推出食品品牌“知为”，未来在日化百货用品方面也有相关规划。
  • 在物流环节，“你我您”同样选择了“产地源头——城市仓——终端小区”的三级流转形式，城市仓配则通过自营模式来保证交付体验。
  • “你我您”目前覆盖的社区平均为500户以上规模，每个小区日均成交40单，客单价约50元，用户平均月复购8次。整个平台的月活用户数约在400-500万之间。 
  • 价格战在社区团购体现为两方面，其一是平台给团长的分成比例，其二是消费者端的价格补贴。
  • 消费者一端，由于社区团购走性价比路线，其用户对于平台和品牌忠诚度较低，价格敏感度较高，造成前期竞争中利用低价爆款商品引流成为常态。
  • 利润空间十分有限，业态较为分散，边际成本效应不明显
  • 社区团购瞄向的二三线家庭生活场景，在消费者日常活动中占据的时间比例更高，而且是用户的最后一个时间节点；其次，基于弱社交的商品推荐更容易形成群体效应。再者，社区团购的商品供给瞄向家庭消费的刚需高频用品，能够支持高转化的购买行为；此外，社区团购省去了最后一公里的物流成本，是个比较健康的财务模型。
  • 标品价格相对透明，规范程度也更高，在利润空间上没有太多操作空间。而生鲜等非标品，尽管社区团购消费者对品类认知远高于品质，不同产地、不同渠道的生鲜品价差明显，但价格与品质的对应性依然存在。长久以往，消费者对性价比的追求会超过对低价的追求。
  • 社区商业环境中线下连锁店、O2O到家等多样化业态的夹击之下，社区团购的未来还有许多不确定性。
  • 社区团购的未来可能是“美菜”+“美团”模式。
  • 社区团购主要优势在于高质量、高留存、高转化的流量获取能力，基于这种能力，未来可能衍生出很多新的形态。
  • 之一是社区团购的线下实体化，由业务流程中的线下自提点演化而来。
  • 另一类则是业务规模扩充后的个人团长，利用社区团购的供应链来开设实体门店。以“你我您”平台为例，目前社区与团长的比例为1：1，平台为团长设立了月销售额3万元的考核指标。从规则上来看，全职团长会有更多的优势。
  • 平台的团长人群中，宝妈与小店主的比例约为7：3，业绩较好的城市，团长平均月收入可达4000-5000元。随着收入的提升，加之平台的品类扩充和供应链体系建设之下，许多团长选择了落地线下店
  • 除门店化之外，另一个可能的方向则是自提点演变为前置仓，在社区团购的时效性和到家服务职能上进一步增强。
  • 不排除未来社区团购会和现有的社区商业的小店和电商平台产生直接竞争，这取决于用户在将来的消费需求变迁。
  • 社区团购尽管是一个电商范畴的行业，但其本质和底层逻辑无限趋近于传统线下零售，同样需要有足够高的密度、足够高的单点门店坪效，以及足够稳定的客流。对于平台而言，竞争壁垒无非就是团效。先发优势和扩张速度并非不重要，但单点的小区模型和城市模型更为关键。
ocean wu

佰特教育TTT体系简介 - 认证体系 - 上海百特教育咨询中心 - 0 views

en.bebetter.org.cn/index.php

商业模式 教育

shared by ocean wu on 10 Aug 17 - No Cached
  • 佰特教育TTT体系简介 2016-12-28 14:35:14        上海佰特教育咨询中心于2009年7月在上海浦东民政局注册成立，国内第一家致力于青少年经济公民教育的非营利性组织；CYFI国际儿童及青少年金融教育联盟、WISE世界教育创新中心、AVPN亚洲公益创投联盟的成员。数年财商教育经验，专注为儿童青少年提供高附加值的财商教育服务。      培训是佰特教育理念传播的重要途径，师资则是佰特教育课程推广的主要源泉。讲师/培训师主要通过参与佰特教育财商课程的学生班授课及教师班培训工作，与佰特教育共同促进经济公民教育在中国的发展。我们在培训的过程中激发并挖掘高质量的教师和参与者，经过不断打造最终成为佰特经济公民教育的关键人物。   感谢在经济公民教育的路上，一直有内外部培训师同行。随着佰特教育影响力和服务人群不断扩大，需要更多的佰特培训师，也需要佰特TTT培训认证管理方法，让我们一起走得更好，行得更远……   佰特培训认证管理方法是对和佰特一起成长,用自己的行动践行佰特理念，服务更多人群的所有人员的支持和管理。佰特培训认证管理方法适用于佰特教育内部（全职）及外部人员（“佰特培训志愿者”）。       目标   打造一支理解并认同佰特经济公民教育的理念和价值观, 熟悉佰特经济公民教育课程内容,灵活掌握参与式教学,并能够面向佰特的受益人开展经济公民课程授课工作的讲师/培训师队伍。 佰特教育内部人员无论其岗位时什么，都可以参与佰特培训认证，其技能和实施项目要求同佰特培训志愿者。外部人员纳入佰特教育志愿者评级体系，是对参加过佰特讲师／培训师工作坊系统、规范、专业培训达到规定的技能的认定，也是对不断参与到佰特组织举办的符合佰特理念的培训活动,在实践中不断成长的鼓励。 为什么要成为佰特培训志愿者？ 1.      参加佰特的培训 2.      践行经济公民教育 3.      受邀参加佰特组织的全国性活动，如研讨会，嘉年华等 4.      志愿服务证书和志愿者晋级（外部人员） 5.      讲师／培训师认证证书（唯一编号）   佰特培训师志愿者职责   1.有义务协助佰特在全国推广经济公民教育理念 2.协助佰特进行全国教师队伍的建设和发展 3.成为佰特认证培训讲师后，外出开展相关培训应向佰特报备，培训结束后及时完成反馈信息 4.尊重佰特的知识产权，不得私下用佰特的课程对外进行营利性开课，如经核实，佰特将取消其认证资格   晋级与认证路径   【佰特培训志愿者按层级分为五个晋升层级】 1. 注册志愿者－注册登记 2. 初级志愿者－参与讲师培训 3. 铜章志愿者－首次认证讲师 4. 银章志愿者－再次认证讲师，首次认证初级培训师 5. 金章志愿者－第三次及以上认证讲师，再次认证初级培训师，首次认证中级培训师 【志愿者晋升层级与培训师认证】
ocean wu

https://mp.weixin.qq.com/s/TSkg5xGmA1OApAMKTlydeg - 1 views

mp.weixin.qq.com/...TSkg5xGmA1OApAMKTlydeg

shared by ocean wu on 17 Jul 19 - No Cached
  • 中国房地产走过20年历程，全国性普涨只有三次：第一次是2004年到2007年，第二次是2009年到2010年，第三次是2016年到2018年上半年。
  • 三轮大普涨，不难发现，每一轮普涨都需要货币之水的支撑。
  • 货币之水的边际效应越来越弱，想要再支持一场全国性的普涨，所需要的能量，恐怕不是宏观经济所能轻易承受的。 未来，楼市普涨，将会是小概率事件。
  • ...19 more annotations...
  • 三四线城市，并非降准降息推动，而是来自于PSL贷款所支持的棚改货币化。
  • 当经济进入新常态，人口红利不复存在，而大水越来越遥不可及之时，城市之间必然出现分化。
  • 大多数三四线城市在棚改退潮之下，逐步步入调整。
  • 三四线城市需要直面成世界经济的基本面。谁的基本面良好，谁能获得大城市群的辐射，谁就能在新的楼市格局离里得一席之地。
  • 房地产行业再一次遭到了“釜底抽薪”式的调控。先是银保监会严控资金违规进入房地产，房地产信托应声而落。接着发改委出台文件，规范房地产海外发债，要求新增外债，仅能用于置换一年内的境外债务。相反，各城市的抢人大战如火如荼，越来越多的城市开启了“零门槛落户”。
  • 因城施策正在成为主流，大热必有调控，遇冷则有松绑。
  • “一城一策、因城施策、落实城市政府主体责任”。
  • 长周期来看，楼市逻辑早已不同于过往，在经济、人口和城镇化三大长期影响因素里，只有城镇化还有一定空间。
  • 从短周期来看，房地产始终是经济的从属工具，一切的核心都在于经济。 经济稳则房地产处于抑制状态，经济波动则房地产必须要稳，经济大波动则房地产要成为最后的定海神针。 这就决定了房地产的逆周期性特征，同样也决定了楼市调控与经济形势的负相关性。
  • 从短周期来看，房地产始终是经济的从属工具，一切的核心都在于经济。 经济稳则房地产处于抑制状态，经济波动则房地产必须要稳，经济大波动则房地产要成为最后的定海神针。 这就决定了房地产的逆周期性特征，同样也决定了楼市调控与经济形势的负相关性。
  • 分化时代到来，对我们有何警示？
  • 分化时代到来，对我们有何警示？
  • 其一，未来十年，比房价更重要的是安全性和流动性。
  • 其一，未来十年，比房价更重要的是安全性和流动性。
  • 其一，未来十年，比房价更重要的是安全性和流动性。
  • 那些过度依赖外来投机、基本面一塌糊涂、楼市失去流动性的城市则要当心。
  • 其二，没有人口流入的城市要谨慎。今年，发改委首提收缩型城市，说明城市收缩已经相当普遍。
  • 其三，不要将资产过度配置于房子上。
  • 将资金全部投注于不动产上的风险越来越大，不要再蒙眼买房，也不要再豪赌。
‹ Previous 21 - 31 of 31
Showing 20▼ items per page