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

应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的这个决定毋庸置疑是非常正确的：

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

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

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

@李文强