传统创业 vs. 精益创业:看板告诉你为什么项目经理已经名存实亡

标签: 创业心得 | 发表时间:2015-08-07 07:28 | 作者:朱佰添
分享到:
出处:http://www.techxue.com/forum.php

本文英文版来自海外著名的产品博客"MindTheProduct", 中文版由天地会珠海分舵进行编译。

开门见山的说吧:我喜欢看板。但主要原因并非人们常说的那一套:既不是因为它是一个可视化的管理工具,也不是因为它能帮我们更好的对进度进行把控,更不是因为它所谓的自我管理的优秀特性。我喜欢看板的主要原因其实很简单,就是因为它让我在我的产品打造团队中根本不需要引入额外的项目管理的角色。

我曾经担任过项目经理这个角色,深知项目管理是个很复杂的活。在传统的方式中,客户常会问我拿项目进展的甘特图,而事实上是我们根本搞不清楚它们的里程碑是怎么回事;我经常要处理的是项目管理的风险,而事实上我们更需要关心的应该是客户成功(Customer Success);在项目管理中我们更看重的管理者认证水平,而在精益管理中我们更需要看重的是管理者为产品和公司所带来的增值。

就拿我们的 Resultados Digitais这个产品为例,通过高效的运用看板,意味着我们根本不需要项目经理这个角色的存在。但这不意味着我们不相信“项目” -- 只是为了将其与传统的项目管理意味中的”项目“区分开来,我们将我们的“项目”称作“史诗(Epics)“。

那么使用看板究竟能给我们带来哪些好处呢?

项目 vs. 流程

相对于项目管理,我更喜欢看板的主要原因之一就是,项目管理关注的是项目,而看板关注的是流程,是程序。

流程作为精益管理巨大的优势之一,翻译到如看板等工具上面就是,它强调的是打造并维护一个可以允许不同的“包(Pakcage)”以相同的质量进行通过的流程。这里关注的改进之处永远都是在流程方面,所以在这个过程中所获得的经验和教训都必须是可以应用到整个流程上面,而不仅仅是当前正在通过该流程的某个特定的项目,某个特定的“包”上面。通过这种方式,你在持续改进方面所付出的努力将会在任何时候都能体现出效果。

看板流程的下面这三个重大组成部分,至少在我看来,已经宣判了项目经理这个角色的死刑。

完成的定义(Definition of Done)

"完成的定义“是每个阶段的目标。这是”内部客户(比如,下一个阶段)“希望前一阶段所交付的内容。这是你在你的看板流程中为每个阶段进行角色设计的一个方法,且,更重要的是,它保证了通过看板流程的所有“包”的质量。“完成的定义”为在项目的进展过程中大家究竟需要瞄准什么样的目标提供了指导方针。它定义了团队在看板流程的每个阶段中所要努力达成的目标,却又不对完成该目标的方法进行限制。

对于打造一个伟大的产品,发现问题并正确的理解该问题是至关重要的。事实上,没有正确的对问题进行认识往往是一个产品所以失败的主要原因之一。所以,作为一个不断迭代循环和改进的过程,我们在每个项目中进行学习,对每个阶段的“完成的定义”进行改进。通过这种方式,每个“包”通过这个流程时所给我们带来的知识,都能应用到所有紧跟着的“包”上面来,以确保同样的错误不会出现两次 -- 这又是另外一个精益管理上非常重要的因数。

流程的持续改进

说起来天下第一,做起来有心无力!针对流程而非流通这个流程的“包”进行突破,这听上去是非常反直觉的,但是在精益管理上面,这对你的产品又是至关重要的。

举个例子,在发布一个新功能的过程中,你发现大量的用户生成了大量的需要客服支持的凭证,抱怨说他们不知道如何运用这个新功能。那么因为一次用户教育的失败,这就有可能会影响到用户的参与度(engagement)。此时你的技术支持团队应该已经开始着手帮助这些客户解答他们的疑问,同时你的开发团队应该也在动手提供一个针对性的更新。但正重要的是,精益管理会迫使你去找出究竟哪个环节出了问题,然后迫使你对这个流程进行改进,这样才能避免同样的错误不会在其他地方(项目,功能,增强,“包”,等等)再次发生。比如,在内测环节?易用性测试环节?还是在早期的解决方案设计环节?

持续改进是确保其他项目不会犯同样的错误的关键,所以请记得将其应用到你的流程上面去。

流程

流程,就是你打造你的产品或完成你的项目的方式。流程的设计很大程度表示了你的团队如何开发你的产品,同时它也反映了你的团队及你的公司所宣扬的价值取向。

世上并没有一个统一的标准来告诉你该如何定义你的看板流程,但根据你的产品的需要,倒是有着不少来自其他地方的值得借鉴的优秀实践。同时,随着你的生意的成长和你的产品的日催成熟,你的看板流程也会相应的跟着改变。我们为我们的产品打造MVP时候所用到的看板流程,和现在我们在用的看板流程已经相去甚远。回首当年,我们那时对产品的的认知还相当有局限性,且我们当时是一个只有10个人的团队(相比我们现在,可以说是个小团队了),随着我们对产品的深入学习和认识,团队成员也随之达到了200多号人,所以我们面临的挑战也是不可同日而语的。

你的流程进行设计和改进应该源于你此前的学习成果,但也需要正确的反映你的公司的价值取向。确保你对你的生意,你的雇员,以及公司的价值取向有正确的认识。通过以提升和加强你希望在你的团队和产品中看到的价值取向的方式来使用你的流程。这同时还会是一个传播你的企业文化的非常强大的工具。

以上提到的这些好处只是看板所带来的众多好处的冰山一角。看板的使用以及精益管理的原则,对于产品开发以及团队的持续交付来说,都有着极高的价值。所以我们应该从今天开始尝试在你的产品打造过程中应用上看板流程,并且确保不断的在学习的过程中改进你的看板流程。

同时欢迎大家将你的看板 - 精益管理的应用心得在评论中提出来,以便同行们进行讨论和学习,让我们一起进步。

相关 [传统 创业 vs.] 推荐:

传统创业 vs. 精益创业:看板告诉你为什么项目经理已经名存实亡

- - 互联网分析沙龙
本文英文版来自海外著名的产品博客"MindTheProduct", 中文版由天地会珠海分舵进行编译. 开门见山的说吧:我喜欢看板. 但主要原因并非人们常说的那一套:既不是因为它是一个可视化的管理工具,也不是因为它能帮我们更好的对进度进行把控,更不是因为它所谓的自我管理的优秀特性.

响应性网页VS移动App,创业者该选哪个?

- - 创业邦
  到底是设计一个各种设备都可以使用的响应性网页还是创建移动App. 这是一个让许多企业家和创业者都很苦恼的问题. 深入研究时就会发现不管是哪种选择,都同时显现出了优缺点并且均需纳入衡量范围中. 这也是为什么很难做出选择的原因.   自去年起,零售方面App的使用占据了消费者27%的时间,这体现出移动设备App对于线上用户的影响十分强大.

转 redis vs memcached

- - 数据库 - ITeye博客
传统MySQL+ Memcached架构遇到的问题.   实际MySQL是适合进行海量数据存储的,通过Memcached将热点数据加载到cache,加速访问,很多公司都曾经使用过这样的架构,但随着业务数据量的不断增加,和访问量的持续增长,我们遇到了很多问题:.   1.MySQL需要不断进行拆库拆表,Memcached也需不断跟着扩容,扩容和维护工作占据大量开发时间.

NOSQL数据库大比拼:Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase

- - 博客园_Ruby's Louvre
话说,尽管 SQL 数据库一直是我们IT行业中最有用的工具,然而,它们这样在行业中超过15年以上的“转正”终于就要寿终正寝了. 现在,虽然关系型数据库仍然无所不在,但它越来越不能满足我们的需要了. 但是,各种 "NoSQL" 数据库之间的差异比当年众多关系型数据库之间的差异要大许多.

普通 vs 文艺 vs 二逼

- 貝殼 - The Only Exception

服务发现:Zookeeper vs etcd vs Consul

- - 企业架构 - ITeye博客
服务发现:Zookeeper vs etcd vs Consul. 【编者的话】本文对比了Zookeeper、etcd和Consul三种服务发现工具,探讨了最佳的服务发现解决方案,仅供参考. 如果使用预定义的端口,服务越多,发生冲突的可能性越大,毕竟,不可能有两个服务监听同一个端口. 管理一个拥挤的比方说被几百个服务所使用的所有端口的列表,本身就是一个挑战,添加到该列表后,这些服务需要的数据库和数量会日益增多.

学界 vs. 商界

- Yuli - 科学松鼠会
汉化: Oicebot & Ent. 0x5f375a86来自一个传奇算法,出自John Carmack开发的《雷神之锤3》的3D引擎. 这个引擎的源代码里包括一个反平方倒数的算法,其速度要比标准的牛顿迭代法快上几十倍,而其中的关键是一行神秘的代码和一个莫名其妙的数字:[ i   = 0x5f3759df - ( i >> 1 ); // what the fuck.

颈椎vs坐姿

- nanoac - 小步的漫画日记

李阳vs李安

- iaotin - 流浪者的乡愁
  李阳家暴事件占据了很多天的娱乐版头条. 关于李阳这个人我不太了解,只知道他是“疯狂英语”教学法的创始人,而他的教学法南桥同学多有微词. 放下疯狂英语的问题不说,李阳与妻子Kim的家庭问题倒让我想起了李安与林慧嘉这对伉俪.   李安在《喜宴》与《卧虎藏龙》之前是个名副其实“吃软饭”的男人. 李安于纽约大学毕业后一直找不到电影界内的就业机会,埋头在家读书写剧本,经济支柱全靠微生物学博士出身的太太林慧嘉支撑.