【7051】有关“资源、流程、价值观”

作为《创新者的窘境》的后续,前两天终于看了《创新者的解答》,一如既往的精彩。读书笔记都可以有好几篇,先说说书里提到的“资源、流程、价值观”。

 

资源包括人员、设备、技术、产品设计、品牌、信息、现金,以及与供应商、分销商、客户的关系。公司将资源投入转化为产品或更大价值的服务的过程中,组织也随之创造了价值。人们在实现这些转化中的互动、协调、沟通和决策时所采用的模式就是流程,流程包括产品的开发、制造方式和采购、市场研究、预算、员工发展,以及补偿、资源分配的实现方法。价值观(意愿)是员工的优先决策标准,他们以此判断一份订单是否有吸引力,某个客户是否比另外一个客户更重要,某个新产品的想法是否有可行性或不着边际等等。

 

资源和流程往往能决定了组织的能力范围——我们能做什么,而价值观往往代表限制——我们不想做什么。从价值观出发,可以派生出一个很重要的东西:产品原则

定义执行某项任务中操作流程可行性的同时也定义了该流程在执行其他任务中的不可行性。如果一个组织没有多次处理过某些特定任务,就很难指望它已经制订了完成该项任务的流程。企业在壮大的同时,实际上也失去了进入小型新兴市场的能力。创新总是没有大到令大企业感兴趣,且无法提高利润率。员工也会考虑绩效、晋升、组织耐心……

 

初创企业的成功,大多数依赖于资源(员工),随着时间的推移,组织的能力转向其流程和价值观。随着员工们一起成功地解决常规任务,流程开始被规定下来。随着商业模式的形成,便可清楚哪些类型的业务需优先考虑,价值观开始凝聚。企业的创新能力如果能成功地从资源转移到流程和价值观中,成功就会变得更容易。当组织能力主要在资源上时,改革容易,但能力升华到流程和价值观,尤其是当其植根于文化中时,改变会异常困难。

应用:如果一家企业的流程和价值观是其历史上成功的原因,那么让被收购企业独立运作,由母公司向其流程和价值观中注入资源,则是更好的策略。如果企业的资源是收购的主要目的,那么将之并入母公司自然无可厚非——这种将收购的人员、产品、技术和客户等融入母公司的运作流程,可视为对母公司现有能力的一种补充方式。

 

要好好理解“壁垒(有时候我们也会说:竞争优势)”这个词,一方面防住了别人进来,另一方面也挡住了自己出去

iamsujie的各种二维码
iamsujie的各种二维码

【3018】最近对项目管理的一些实践

最近,因为产品的需要,又开始做一些项目管理的工作,一直认为,各种管理工作都是手段,是为了产品服务的,所以切忌“杀鸡用牛刀”,本着够用就好的原则,和团队(10多个人,运营占了大半的奇怪组合,呵呵)一起边做边设置一些规则,下面是最近我发的一封邮件,加上点评分享一下。

首先,开发同学工作时间分配的共识:

a) 因为产品属于“二手房改建”,所以各种Bug和可优化的地方很多,开发很容易被各种零散需求占满,但产品还处于新生阶段,必须强制只留20%的时间给日常bug修复和优化,确保主要精力还是在做一些整块的需求,保证产品整体是在向前走的(产品进入成熟期,可以把大部分时间留给优化);

b) 因为团队结构里,运营人数很多,之前每位运营都会直接找开发提需求,把开发的工作计划打乱、碎片化,所以规定运营可以直接找技术,但只限于严重的问题,技术不接运营直接提的任何需求,必须走产品人员过一下(必须有人通盘衡量,运营人员通常会站在自己负责的一件事上,把自己需求的优先级无限提高);

c) 技术同学的评估,之前因为经验不足,会把“工作量”和“工期”混在一起,现在分开,并不是说工作量10人天,2个人做的话,就是5个工作日后发布(也是让团队所有人明白两者的不同);

其次,在公司里找了一个小系统,管理日常的Bug和优化(积累了几十条以后,用口头、邮件什么的管理都是不靠谱的),主要是写给运营了解的一些原则:

1 优先级判断

a) 1-urgent,系统大面积不可用,必须马上改,需要申请紧急发布;

b) 2-high,明显的bug,需要修改,尽量赶下一次发布;

c) 3-medium,不严重的bug,平时过掉;

d) 4-low,优化建议,平时过掉:优化可以用“严重程度”字段来表达重要性;

2 使用流程

a) 运营先提给产品,状态new

b) 由产品来确定优先级和指派给谁,确认方案,需要修复的,状态改为open,指派给开发安排,确定“期望修复时间”;

c) 开发修复完成,状态改为fixed

d) 产品验证后,状态改为closed

3 系统里的具体条目,产品平时和开发排掉,产品运营双周会上不讨论,需要特别说明的,请录入者在会上提出:

a) So,需要录入者会前自己review一下自己提出的条目(如果状态已经不是new,就说明已经安排了)

b) 平时,每个人都可以随时去系统里查看自己提出的条目的进展,有异议找产品沟通(前提是,我们团队有一个产品原则的共识,比如“目标用户有哪几种,他们的优先级排序,每个群体的需求又有哪几类,优先级排序……”);

4 UED也视为技术人员,给UED的需求也用系统管理;

大家批判着看啊,周边条件不同,做法一定不同,希望有启发就好。