项目管理之摸着石头过河的那些日子


应Worktile团队之约,撰写了此文。我从来不喜欢敷衍了事,于是准备良久,回顾了这些年的点点滴滴,才成此文,以此祭奠那些年,项目管理之摸着石头过河的那些日子。

首先介绍下自己:

本人IT屌丝一枚,人称“程序猿”,目前已经在这个行业摸爬滚打6年左右。

曾经是一名文艺青年,现代诗人,以为会成为文坛上的冉冉新星,结果却成为了码界的猩猩——《跟我学C#程序设计》、《跟我学ASP.NET》的作者,《SharePoint 2013开发高级教程(第四版)》的译者。

性格上拥有理想主义和完美主义情节,热爱编程(目前主要以业余编码为主),致力于为中国开源社区做贡献(开源项目有:https://github.com/magicodes/Magicodes.NET)。一直拥有很多想法,是一个追逐梦想和兴趣的人,喜欢思维碰撞,喜欢技术交流,喜欢设计与规划软件(含游戏)产品。

上过两次梁山(创业过2次,刚出来的时候蛮干过一年),都被招安了,目前是第三次。当过游击队(接私活),揽过技术活,带过团队,做过各种软件和网站以及企业业务系统开发,玩过SharePoint,做过微信APP,现在在业余学习Unity3D。目前在公司担任产品经理&技术总监。

以我这么多年的码农生涯来看,IT行业比其他行业更加需要项目管理工具,更加依赖项目管理工具,也更加愿意使用项目管理工具。一路走过来,说多了都是泪,下面就分享下,这些年我在项目管理上跌倒过的坑。

摸着石头过河砸到脚的日子

前两次创业都没有团队的概念(持续一年),所以更谈不上项目管理了。一个人一杆枪挑起全部,做完一个仿淘宝的电子商务网站(叫汽配通),然后继续编写了客户端管理软件(类似于管理汽配的进销存),总之一个人从设计到编码到测试全部搞定。偌大个项目,加上老板,就我们俩(之前有个老程序员,干了半拉子走了)。就这样一直坚持了差不多一年,直到厌倦了这种生活。于是告别了第一段创业,然后匆匆结束了第二段创业生涯(IT培训,坚持了不到一个月),来到了上海,开启了一段暗黑的旅程——从旁观者,到成为团队Leader,从开发者,到项目经理的艰苦蜕变。

在这里第一个项目是做XX加盟店系统,一个失败的项目,我是被当做壮丁抓过来的。曾经有几个月天天晚上2、3点回家,打的费多的一个月报了2000多。给我的节奏就是——加班,赶进度,再加班,再赶进度。由于需求没控制住,所以做到后面,项目自然死掉了——公司和客户撕破脸,直接结束。我作为Coder的感受是——项目管理=需求分析+需求设计+需求把控,另外一个收获就是——我推动团队使用了源代码管理。

接下来,开始带队开发是某某银行项目,拉了几个壮丁,直接宣布开战。很多小公司到现在为止都是这样的——谁技术强,谁就来带团队。这种方式是存在不少问题的,但是这个项目是相对比较完美的完成了——虽然中间被另一个部门的项目经理投诉了一把,但是客户一直对我念念不忘、“关怀备至”。这个项目的成功主要有几个原因:项目并不复杂,业务理得比较清楚,银行客户需求确认比较彻底,客户项目管理的意识比较强,当时每周都要发周报,恶心死我了。那时我得经常安排任务,大家按期交工就OK,Delay就加班,有问题就讨论,没问题就大家看小说(没办法,写个代码都得层层远程服务器编写,还没网,没事的时候,除了盯着手机就只剩下睡觉了(不过被客户盯着,不大好睡觉)),总之还是比较和谐的完成了工作。

完成了这个项目,领导很赞赏,于是开始了带队开发某某移动项目三期,于是最黑暗的日子就来了。首先,项目很宏大(7、8个子项目),人员多而且杂而不精。我既要做项目管理,又要担任核心开发,而且需要谈需求,确认需求,安排计划,任务,带队开发,做测试,督促部署,应付客户投诉(这个是那个时候经常要兢兢战战应对的事情,国企的人貌似都喜欢这样)等等——一大坨杂事,想想都是醉了。刚开始还信心十足,到后面已经疲于应付了。每次领导到现场都是——我与你们同在,我请大家吃饭,然后你们继续加班……

因为事多又杂,我想过很多方式——起初是靠脑子管理,然后模仿上面XX银行的周报制——没坚持下来;也曾靠过本本,纸撕得一张一张的,而且有时忘桌子上了,另一天来时,说不定就被大妈拿去擦屁股了。也曾祭出过Excel神器,甚至用过Project,最后都不了了之。最终,项目最终还是凄惨落寞了——我感觉身心俱惫,疲于伺候那帮孙子,于是递交了辞职书(当然后来没批)——不过最终是我留下了,团队成员都走了。这次经验也让我身心受创,事后我也进行了反思:

  • 主要原因是公司资源有限:如人手不够、缺乏骨干;
  • 次要原因是项目管理存在太多问题,比如不能很好地开发迭代,测试把关不足导致Bug反复出现(经常没有测试角色),需求没有控制住(好不容易你这边控制住了,那些孙子打电话给领导,然后领导又拍板了),开发人员没有得到最佳利用等等。
  • 当然作为一名技术宅,我当时觉得还有一个关键的点——缺乏一款好的项目管理工具。在我的理想中,项目经理在系统上安排计划和任务,开发人员在系统上查看自己任务,更新任务状态,然后测试人员测试并提交Bug,然后项目经理继续安排任务,就这样不断地迭代。为什么有这种想法,因为Excel用的我快吐了。浪费时间还浪费精力。

总之,那是一段摸着石头过河的日子,不过最后砸到自己的脚了。

###真的是项目管理工具的问题吗?——敏捷开发

基于第三点,我开始反思项目管理。那时公司也组织过项目管理考试,虽然就上了一次课,以我天资绝佳的资质——自然没过(也许要上两次课才行,哈哈)。于是在这个项目的尾期,我开始有意识的学习其他团队的项目管理经验,然后了解了敏捷开发,并且使用了TFS的敏捷开发模板。当时看到的第一眼就是——那不就是我苦苦找寻日思夜想的玩意儿吗?!要知道,技术宅都比较容易激动。于是为此争取到了领导的支持,买了台服务器部署,并且在开发部门进行了一次敏捷开发的培训——我当讲师,虽然当时我也是半罐子水,但是当你晃了这么久的时候,你也就习惯了。

敏捷开发确实是一种不错的而且也很先进的理念,它是以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。因为现在软件项目基本上都会经历需求变更,而敏捷开发是适应这个需求变更的。TFS2012的敏捷开发模板则将其应用到了实际开发当中,可以添加需求、任务、Bug、风险、测试用例等等,而且提供相应的流程,并且能够配置无限的迭代以及工作区域。此外,还提供了很多客户端,比如集成VS,能够在签入代码时与工作项挂钩,提供了测试管理器和反馈管理器,能够录屏、截图甚至生成自动化的测试用例来提交TFS,总之是一款针对软件项目的非常强大的管理工具。


可是当那次培训过后,我的心立马就冷下来了,放弃了开始在公司推广这个工具——此玩意儿只应国外有,小公司用它太复杂。尽管微软在敏捷开发流程方面,围绕开发和测试做得很细致,但是在中国大部分小公司小团队根本行不通。

原因有以下几个:

  • 很可能团队角色都凑不齐,测试和美工经常是痛脚;
  • 测试不愿意学习这些工具,宁愿纯手工测试(这不是主因);
  • 增加了很多工作量,并且大部分项目经理基本上不具备这个素养(这是根本原因),不愿意带着团队来使用这个工具——这是我开会直接得到的心声(如果我推广,那就是众多项目经理的罪人啊)。首先对项目经理的要求很高,而且工作量的增加是很庞大的,尤其是前期。从上面的截图可以看出,可以添加需求、任务、Bug等等,也就是相当于把软件开发管得死死的,项目经理不但需要这种规划的意识,还需要将以前只要邮件往来的内容都要整理添加到上面来,而且有些还有不少流程,比如审批,还得将每个任务详细的分配给开发人员,所以基本上项目经理都会潜意识的排除。相对开发人员而言,首先是源代码管理工具需要用TFS,工作项等更改或者查看在开发工具中就能够查看与修改。而对于测试人员来说,首先需要学习测试管理器,以前只要简单截截图,QQ往来的或者邮件往来的,现在则要使用这么一个高端工具,自然也会有些排斥
  • 只管理到了软件项目的生命周期(不过人家目标就是这样);
  • 不够灵活。因为敏捷开发模板都规范好了,自然不能更改,但是中国领导大都是不规范的。他们不会从上到下来推动规范的东西,很多时候他们只会横插一脚,把你绊倒。

因为其模板太细,太规范,一般人都坚持不下去,而且我既是项目经理,又是开发骨干,很难及时去梳理需求和任务以及Bug,遇到工作繁忙时,就忽略或者简化了,最后我也没能坚持下去,但是在使用的过程中,感觉从敏捷开发中学到了很多理念(比如我知道了针对需求变更,还有这么一种先进的理念,其实后续的项目管理中,我或多或少都用到了这种理念),受用不浅。

不过这次培训倒是帮公司开发部做了一点贡献——大部分项目组开始用源代码管理工具了,哈哈,你现在终于知道有些开发团队有多落后吧!之前采购的那台服务器被我装了N个虚拟机,除了放TFS,还部署了SVN和SharePoint。

照例,我也进行了一次反思,我觉得敏捷开发太重,项目经理需要很多,工作量也比较大,是否可以考虑一些轻量级的工具呢?

###轻量级的管理工具——SharePoint?

在这种迷茫中,又做了一些项目,客户使用了Redmine之类的管理工具,功能简单轻量,还比较好用。虽然使用情景比较有限,但是有时候也够用了。

再后来,我又上梁山了,这次准备不占魔都不罢休,谁都不要来招安我!哈哈。

这次我担任了产品经理和技术总监的重任。因为是创业公司,从0到有,历经了项目(产品)管理的9*9=81难。

基于之前的经验和教训,在产品伊始,我就开始寻找适合的项目管理工具。TFS的敏捷开发流程自然被我放弃了,按照我的想法,我需要一个轻量级的项目管理工具,于是我决定使用SharePoint列表来承载这个重任(其实一开始我是拒绝的,因为当时我不知道Worktile,也实在找不到合适的工具)。当然,SharePoint其实也是可以用的,比如:

很多可以选择的列表模板:

开发任务列表(视图可以定义(比如排序和筛选)):

日历:

文档库:

Wiki页:

在没使用Worktile之前,我们一直是基于其进行产品管理的,包括目前还有部分信息仍在上面。

虽然使用SharePoint管理产品以及项目是满足我的需求的,但是它仍然有很多不足:

  • 用户体验不够好。
  • 并不是专门的项目管理工具,缺乏很多规范与机制,难以有效的规范的利用。
  • 我需要定制SharePoint工作流来推送通知。
  • 团队成员上手难,需要培训。
  • 由于我部署的是内网环境,因此在外面的时候不方便沟通与查看。
  • 没有手机端,每次都需要我去催办。

当然在这个阶段的尾声,我已经意识到了——并不是工具不行,而是人不行。当然好的工具能带给最佳的辅助。

###痛定思痛,蜕变——从敏捷开发到产品(项目)管理

曾经在2013年12月20日的时候,我无意中发现了Worktile,当时试用了一下,感觉眼前一亮,但是我并没有应用到项目管理中。

直到今年1月份,回顾过去的一年,我觉得是时候该有点变化了——新年的锣鼓敲出新的钟声,而我已经准备好了新的红内裤。回顾去年一年,产品在需求的抨击下犹如暴风雨下的孤帆,而我们是那被困已久的憔悴的船夫。作为所谓的产品经理,我该肩负起历史的责任了。痛苦的思考了很长一段时间,不断地反思,不断地讨论和交流,我意识到了敏捷开发不是产品管理,我意识到了我需要更好的梳理和管理产品的每一个环节,让其规范可控合理。因此,单纯的计划+任务的模式不是解决此问题的神器,我必须从开发者身份跳脱出来,真正回归到产品管理的角色上来。意识到了,就要行动,我一直是一个执行力很高的人。于是背负了所有,放弃了编程的冲动,全身心的投入到产品规划和梳理中来了,同时我将Worktile作为此次蜕变的工具。

说做就做,我开始根据产品情况定制了很多管理模板,比如 RodeMap、计划、反馈、研发、CRM、招聘、项目 等等,我从这些方面挨个梳理,不断地考量,经过这几个月的努力,我感觉产品终于回到了正轨,亦有了一种尽在掌控之中的感觉——只有此时,我才觉得我是一个真正的产品管理者。因此,敏捷开发不是产品管理,亦不是项目管理,从一开始,我就没有走对。

下面是我对公司产品管理的一个规划:

RodeMap示例:

研发的模板与流程:

CRM:

下面是某些方面的应用场景。比如检查项的:

类似于Wiki页的:

当然还有很多,这里就不一一列举了。

从这段时间用下来的感受来看,我觉得迁移到Worktile的这个决定毋庸置疑是非常正确的:

  1. 从上面很多功能来看,都可以看住SharePoint功能的升级版,比如Wiki,日历,任务列表,Web Office App等等;
  2. Worktile用户体验相当不错,团队成员上手简单。而且我开始带动所有可能的人来使用。因为其用户体验的优越性,大家都并不排斥,也不会出现账号忘了的情况(都使用的企业邮箱)。包括现在,销售和业务我都纳入了使用者的范围;
  3. 敏捷开发不是产品管理,当然也不是项目管理,只是项目管理的一部分,产品管理的一小部分。产品管理应该包括以下内容:产品RodeMap,产品计划(包括市场计划),需求、Bug,研发,CRM等等,这是我下决定迁移的最重要的原因。因为基于Worktile的列表和任务组合模式,我可以很灵活的管理这些。轻量灵活却不失功能,这就是我想要的;
  4. 手机端的支持。我现在要求每一个成员每天上班都优先打开手机端,只要状态更改了便有通知,方便及时沟通,省却了很多跑路和沟通的时间;
  5. 沟通很便捷。基本上大部分功能模块均支持讨论或者评论功能;
  6. 免费。创业公司能省就省;
  7. 轻量灵活却不失功能,就如第3点后面所说;
  8. 很便于梳理事情、任务和问题。你可以讨论,可以发布Wiki,也可以使用检查项陈列,你还能用列表做个小流程,总之,你可以用很多方式来呈现和表达。
  9. 一直在不断的迭代进步,而且在使用过程中我提了很多建议与意见。
    ###写在最后

产品管理和项目管理是一条很漫长的路,也许你们也会有我这样的经历,也会如我一般历经种种伤痛。时间总是一堵不可逾越的墙,总是证明我们过去是错的。那么,我们只要确保我们每一天都在前进就行。就如今天开会时,一个团队成员说,今年最大的变化是,我们有产品经理了,我是欣慰的。

最后,希望Worktile越做越好,也希望你们都找到自己的路,而我将继续一往无前。

@李文强