《创新者的窘境》

为什么成熟企业会延迟推出新技术?
在解释成熟企业为什么会延迟推出新技术时,经常被提到的一个解释是:担心现有产品的销售受到影响。
但如果新技术推动了新市场应用领域的出现,那么新技术的推出可能并不一定会侵蚀现有产品的销售。
但是当成熟企业等到新技术在新的商业应用领域逐渐发展成熟之后,才为了抵御自己的主要市场所受到的冲击推出相关技术产品时,那它们对市场侵蚀的担心就将发展为一个自我应验的预言。
新产品的障碍似乎并非来自工程技术部门,反对声音主要来自市场销售部门和管理团队。

为什么成熟企业会对破坏性技术置若罔闻?
似乎被它们的客户牵绊住了手脚

价值网络
即一种大环境,企业正是在这个大环境下确定消费者的需求,并对此采取应对措施、解决问题、征求消费者的意见、应对竞争对手的竞争,并争取利润最大化

成熟企业决策模式
步骤1:破坏性技术首先在成熟企业研制成功
步骤2:市场营销人员然后收集公司主要客户的反馈
步骤3:成熟企业加快对延续性技术的开发步伐
成熟企业改善现有产品,而不是对新兴企业从低端市场发起的攻击做好防备
步骤4:新企业已经出现,破坏性技术市场在反复尝试中逐渐成形
步骤5:新兴企业向高端市场转移
步骤6:成熟企业在维护客户基础方面棋慢一招

继续阅读《创新者的窘境》

项目管理案例讨论15—如何去开好一个复盘会议

项目复盘会,可以说是项目团队有意识地向过去的行为经验学习的过程。在项目或里程碑完结之后,项目经理会组织召集项目成员,一起回顾一下。

但是,现实情况经常是,项目一个接一个地做,没时间做复盘;或是为了复盘而复盘,逐渐地流于形式。今天,分享如何做好项目复盘,以及如何通过复盘去培养团队的持续改进能力。

一、复盘会的基调设定

我们都知道复盘很重要,但实际上,在复盘会之前,想清楚我们复盘的目的,设定好复盘的基调,其实更为重要。

要想让参与者真正进入集体反思区,会前就要设定好开放的复盘基调。

首先,我们自己要先进入反思区。在复盘会之前,可以跟部门/团队的负责人或成员,就部门中反复出现的各种问题,进行过多次深度沟通。把问题一层层地剖开来看时,我们就会发现很多问题背后的深层原因。

其次,在会议刚开场,就要展示出自己的开放与坦诚,给复盘会奠定基调:这次复盘不是来挑问题的,而是为了找到问题的根源并改进的。复盘会上,负责人可以先讲自己这一年来的深刻反思,这就带动大家敞开心扉,直面问题。会议结束以后,部门还可以发起一项“整风运动”,从增强用户意识的讲座,到用户调研方法的培训,再到激励与考核制度的挂钩,让复盘会反思的成果,逐渐渗透到了每个人的日常工作中。

继续阅读项目管理案例讨论15—如何去开好一个复盘会议

项目管理案例讨论14

A公司是一家经营纸产品的企业,近几年业务得到了成倍的发展,原来采用手工处理业务的方式已经越来越显得力不从心,因此,经过公司董事会研究决定,在公司推行一套管理软件,用管理软件替代原有的手工作业的方式。同时,请公司副总经理负责此项目的启动。

副总经理在接到任务后,即开始了项目的启动工作。项目经过前期的一些工作后,副总经理任命小丁为该项目的项目经理,小丁组建了项目团队,并根据项目前期的情况,开始进行项目的计划,表所示为初步项目进度计划表。

项目进行了一半,由于公司业务发展的需要,公司副总经理要求小丁提前完工,作为项目经理,小丁对项目进行了调整,保证了项目的提前完工。

【问题1】如果你作为项目前期的负责人,在接到任务后将如何启动项目?

项目的启动包括了以下几个主要活动:
1.识别需求
从投资方角度,识别需求是项目启动过程和整个项目生命周期的最初活动,在这个过程中,为项目的目标确定, 以及可行性分析和项目立项提供直接、有效的依据,为需求建议书的撰写提供基础。
一旦确定了相关问题和需求,并证实了项目将得到益处,投资方就可以开始准备需求建议书。

继续阅读项目管理案例讨论14

项目管理案例讨论12

某大型百货公司根据市场需求,拟进行电子商务系统的建设,以扩大销售渠道和优化现有的销售模式。经过专家分析,共有如下 4 种方式可以选择。
(1)企业自行从头开发。
(2)复用已有的构件来构造。
(3)购买现成的软件产品。
(4)承包给专业公司开发。
针对这几种方式,项目经理提供了下图所示决策树,供总经理选择建设方式。

继续阅读项目管理案例讨论12

20211209

今天考科三,太紧张,一次忘了手刹,一次忘了安全带,就挂了。记得科二也差点因为安全带挂,安全员在外面问我你准备好了吗,我说准备好了,他又说你真的准备好了吗,我这才一惊忘了系安全带。这次没人提醒,总要还的。。。

教练说你起步不看仪表盘的吗?起步的时候看仪表盘有没有红灯亮啊,还有转向灯

MySQL数据切分

数据切分,就是指通过某种特定的条件,将我们存放在同一个数据库中的数据分散存放到多个数据库(主机)上面,以达到分散单台设备负载的效果。数据的切分同时还可以提高系统的总体可用性,因为单台设备Crash之后,只有总体数据的某部分不可用,而不是所有的数据。

数据的切分(Sharding)根据其切分规则的类型,可以分为两种切分模式。一种是按照不同的表(或者Schema)来切分到不同的数据库(主机)之上,这种切可以称之为数据的垂直(纵向)切分;另外一种则是根据表中的数据的逻辑关系,将同一个表中的数据按照某种条件拆分到多台数据库(主机)上面,这种切分称之为数据的水平(横向)切分。

一、数据的垂直切分
数据的垂直切分,也可以称之为纵向切分。将数据库想象成为由很多个一大块一大块的“数据块”(表)组成,我们垂直的将这些“数据块”切开,然后将他们分散到多台数据库主机上面。这样的切分方法就是一个垂直(纵向)的数据切分。

一个架构设计较好的应用系统,其总体功能肯定是由很多个功能模块所组成的,而每一个功能模块所需要的数据对应到数据库中就是一个或者多个表。而在架构设计中,各个功能模块相互之间的交互点越统一越少,系统的耦合度就越低,系统各个模块的维护性以及扩展性也就越好。这样的系统,实现数据的垂直切分也就越容易。

继续阅读MySQL数据切分

MySQL Innodb性能监控

我们可以通过执行“show engine innodb status”命令来获取比较详细的系统当前Innodb性能状态。

1、BACKGROUND THREAD
后台线程,可以看到活动线程,停止线程,空闲线程

2、SEMAPHORES
这部分主要显示系统中当前的信号等待信息以及各种等待信号的统计信息

3、TRANSACTIONS
这里主要展示系统的锁等待信息和当前活动事务信息。通过这部分输出,我们可以查追踪到死锁的详细信息

4、FILE I/O
十个IO线程,一个更改线程,一个日志线程,4个读线程,4个写线程

5、INSERT BUFFER AND ADAPTIVE HASH INDEX
显示插入缓存当前状态信息以及自适应Hash Index的状态

继续阅读MySQL Innodb性能监控

MySQL Innodb数据及索引文件存储格式

Innodb存储引擎的数据(包括索引)存放在相同的文件中,这一点和MySQL默认存储引擎MyISAM的区别较大,后者分别存放于独立的文件。除此之外,Innodb的数据存放格式也比较独特,每个Innodb表都会将主键以聚簇索引的形式创建。所有的数据都是以主键来作为升序排列在物理磁盘上面,所以主键查询并且以主键排序的查询效率也会非常高。

由于主键是聚族索引的缘故,Innodb的基于主键的查询效率非常高。如果我们在创建一个Innodb存储引擎的表的时候并没有创建主键,那么Innodb会尝试在创建于我们表上面的其他索引,如果存在由单个not null属性列的唯一索引,Innodb则会选择该索引作为聚族索引。如果也没有任何单个not null属性列的唯一索引,Innodb会自动生成一个隐藏的内部列,该列会在每行数据上占用6个字节的存储长度。所以,实质上每个Innodb表都之少会有一个索引存在。

在Innodb上面除了聚族索引之外的索引被成为secondary index,每个secondary index上都会包含有聚族索引的索引键信息,方便通过其他索引查找数据的时候能够更快的定位数据位置所在。

继续阅读MySQL Innodb数据及索引文件存储格式

MySQL Innodb存储引擎优化

Innodb存储引擎和MyISAM存储引擎最大区别主要有四点,第一点是缓存机制,第二点是事务支持,第三点是锁定实现,最后一点就是数据存储方式的差异。

一、Innodb缓存相关优化
1、innodb_buffer_pool_size的合理设置
Innodb存储引擎的缓存机制和MyISAM的最大区别就在于Innodb不仅仅缓存索引,同时还会缓存实际的数据。所以,完全相同的数据库,使用Innodb存储引擎可以使用更多的内存来缓存数据库相关的信息,当然前提是要有足够的物理内存。

innodb_buffer_pool_size参数用来设置Innodb最主要的Buffer(Innodb_Buffer_Pool)的大小,也就是缓存用户表及索引数据的最主要缓存空间,对Innodb整体性能影响也最大。无论是MySQL官方手册还是网络上很多人所分享的Innodb优化建议,都简单的建议将Innodb的Buffer Pool设置为整个系统物理内存的50%~80%之间。

2、如何分析MySQL内存使用
假设是一台单独给MySQL使用的主机,物理内存总大小为8G,MySQL最大连接数为500,同时还使用了MyISAM存储引擎,这时候我们的整体内存该如何分配呢?
内存分配为如下几大部分:
a)系统使用,假设预留800M;
b)线程独享,约2GB=500*(1MB+1MB+1MB+512KB+512KB),组成大概如下:
sort_buffer_size:1MB
join_buffer_size:1MB
read_buffer_size:1MB
read_rnd_buffer_size:512KB
thread_statck:512KB
c)MyISAM Key Cache,假设大概为1.5GB;
d)Innodb Buffer Pool最大可用量:8GB-800MB-2GB-1.5GB=3.7GB;
假设这个时候我们还按照50%~80%的建议来设置,最小也是4GB,而通过上面的估算,最大可用值在3.7GB左右,那么很可能在系统负载很高当线程独享内存差不多出现极限情况的时候,系统很可能就会出现内存不足的问题了。而且上面还仅仅只是列出了一些使用内存较大的地方,如果进一步细化,很可能可用内存会更少。

继续阅读MySQL Innodb存储引擎优化