Articles tagged '项目管理'

Excel,熟悉又不熟悉的项目管理工具

Aug 13, 2014 excel 项目管理

本文转载自风车官方博客

如果有人在市场上做个调查,目前使用最广泛的项目管理工具是啥,我估计结果不是 Microsoft Project,不是 Jira,不是 Redmine,而是 Excel。在做风车的过程中,接触到不少团队,包括一些跟互联网很近的技术创业公司,都在使用 Excel 管理项目,也有一些用户问我们如何能从 Excel 管理平滑地迁移过来。所以,风车在首页特别跟 Excel 做了对比,我们也的确有不少客户是从 Excel 管理转到风车。这篇文章就来谈谈用 Excel 做项目管理的利与弊。

要了解 Excel 管理项目的利与弊,得先了解如何用 Excel 来管理项目,Excel 能做什么,怎么做。项目管理,从本质上就是两件事情,计划安排和进度跟踪。计划安排包括计划和安排。计划是确定要做什么事情,并分解成一个个任务,比如在 Excel 里面按照 WBS 来做计划。而安排就是根据分解任务确定谁做什么事情以及什么时候做什么事情,比如在 Excel 里面制作甘特图来做安排。进度跟踪包括进度和跟踪。进度是了解项目的进展,哪些已经完成,哪些有待完成,比如可以在 Excel 里面绘制燃尽图来展现进度。跟踪是及时了解团队每个人的状态,某个任务完成度如何了,这里更多的是通过沟通来更新到 Excel 中。

关于具体可以怎么用 Excel 来做项目管理,我做了一个例子,在这里下载,有兴趣可以参考,基本上涵盖了我上面提到的这些事情。

Excel 不是专业的项目管理工具,但是 Excel 又无所不能。在我心目中,Windows 并不是微软最成功的软件,Office 才是。使用 Excel,有下面这几点好处。

  1. 普及,群众基础扎实。可以说,Office 在很多人眼里就等于电脑,你去外面配个电脑装个机都能在系统之外附赠一个 Office。这也带来了 Excel ...

......

Read more →

Deliver Better Product (I)

Jul 09, 2014 创业 MVP 项目管理

Most Products Fail!

是的,大多数的产品都会死掉,一个黑暗的事实。就如很多人认为现在团队协作工具出来这么多,很不看好风车一样。但是就如风车诞生的初衷一样,我们希望风车能够帮助创业团队更好的成长,更快地发布更好的产品,很欣慰现在风车真的帮助到了不少产品团队,让我能更有动力去改进产品和提供更好的服务。之所以我相信风车能真正帮到用户发布更好的产品,是因为我坚信对于一个创业团队来说,采用正确的做事方式和合适的工具能大大降低失败几率。

一个产品的成功,也许需要天时地利人和1,但是要做到不失败相对就容易的多了。我想分享一些我们做事的方式,希望能帮助到你。这里没有互联网思维,这里没有成功学,有的只是真正的工作实践心得,甚至有些也许都是很笨的,但是希望这些分享能给你带来一点点的启发,并且还能付诸于实践。

上图是对 Scrum 敏捷方法不同角色的职责的很好诠释,即使是对于不采用 Scrum 的团队来说,我们也应该这样去做产品。做正确的事情,正确的做事情,并且快速的做事情,这样一个团队,最佳情况就是总是能在正确的时间用正确的方法做正确的事,非常完美。对于这个系列的计划,我希望能涵盖产品的整个生命线。本文开篇,主要介绍如何做产品远景和形态探索,后面的文章会涉及如何做用户角色分析,如何做用户故事、如何做计划评估、如果做迭代计划、如何协作执行、如何做回顾测试、如何做用户访谈等2

Great Product starts with Vision

正如我在「你是否关注过消费者心理?」 所写,优秀的市场营销者,会先去传递产品的使命,然后才是与使命匹配的具体需求实现。对外如此,对内同样需要如此,不然团队事情会做的很茫然。为什么我们要做这个功能,为什么我们不做那个功能?为什么我们现在需要做这个,而不是那个?回忆一下,曾经你有没有问过自己这些问题,...

......

Read more →

实用 Git 工作流

「让代码审核成为你的团队习惯」 一文中,我们分享了我们团队做代码审核的一些经验心得,在微博上引起了热烈的讨论,引出了一些非常有意思的工作流介绍,比如下面的几点。

<p>我们有 master-dev 分支,比较大的功能才会新开 branch,小功能都是直接到 dev 上的,再加上团队在一起开发所以固定时间看昨日的代码,效果还不错。我们同样没有 QA,自己做的 ticket 也会找对方来做测试,但多是功能的完整性上的测试了。<cite> - <a href="http://weibo.com/iamroody" target="_blank">@iarmroody</a></cite></p>
<p>我们团队小,每个开发人员一个 git 分支,基本上工作不会互相打扰。我们的分支策略是,对于新功能,从主干开一个功能分支,然后每个开发在功能分支上开个人分支。合并时,先 BI(Backward Integration),,再 FI(Forward Integration)。每周四定期合并,合并时 review。之所以放在周四,是因为如果合并出错,周五还有时间修复。<cite> - <a href="http://weibo.com/u/2128792480" target="_blank">@施懿民</a></cite></p>

每个团队都在寻找最适合自己团队的工作方法,希望能提高工作效率和团队协作。我们也是,这也是为什么我们除了代码审查之外,还需要过程审查这类的执行过程。像上面提到的两种方式,肯定也是在各自团队推行中觉得效果不错的,但是个人觉得在过程上在效率上还是有改进空间的,具体理由看下面,可以对比我们的目标和相应方式。目前我们使用的这一套 Git 工作流,是我们这几年不断的过程演进而来,目前 4 个人做 Fengche.co 在用,之前 10 个人做...

......

Read more →