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

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

首先介绍下本身：

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

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

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

上过俩次梁山（创业过2次，刚出来的时候蛮干过一年），都被招安了，目前是第三次。当过游击队（接私活），揽过技术活，带过团队，作过各类软件和网站以及企业业务系统开发，玩过SharePoint，作过微信APP，如今在业余学习Unity3D以及编写Magicodes.NET。目前在公司担任产品经理&技术总监。

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

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

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

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

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

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

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

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

总之，那是一段摸着石头过河的日子，不过最后砸到本身的脚了。

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

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

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

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

缘由有如下几个：

1. 极可能团队角色都凑不齐，测试和美工常常是痛脚；

2. 测试不肯意学习这些工具，宁愿纯手工测试（这不是主因）；

3. 增长了不少工做量，而且大部分项目经理基本上不具有这个素养（这是根本缘由），不肯意带着团队来使用这个工具——这是我开会直接获得的心声（若是我推广，那就是众多项目经理的罪人啊）。首先对项目经理的要求很高，并且工做量的增长是很庞大的，尤为是前期。从上面的截图能够看出，能够添加需求、任务、Bug等等，也就是至关于把软件开发管得死死的，项目经理不但须要这种规划的意识，还须要将之前只要邮件往来的内容都要整理添加到上面来，并且有些还有很多流程，好比审批，还得将每一个任务详细的分配给开发人员，因此基本上项目经理都会潜意识的排除。相对开发人员而言，首先是源代码管理工具须要用TFS，工做项等更改或者查看在开发工具中就可以查看与修改。而对于测试人员来讲，首先须要学习测试管理器，之前只要简单截截图，QQ往来的或者邮件往来的，如今则要使用这么一个高端工具，天然也会有些排斥；

4. 只管理到了软件项目的生命周期（不过人家目标就是这样）；

5. 不够灵活。由于敏捷开发模板都规范好了，天然不能更改，可是中国领导大都是不规范的。他们不会从上到下来推进规范的东西，不少时候他们只会横插一脚，把你绊倒。

由于其模板太细，太规范，通常人都坚持不下去，并且我既是项目经理，又是开发骨干，很难及时去梳理需求、任务以及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做为这次蜕变的工具。

说作就作，我开始根据产品状况定制了不少管理模板，好比roadmap、计划、反馈、研发、CRM、招聘、项目等等，我从这些方面挨个梳理，不断地考量，通过这几个月的努力，我感受产品终于回到了正轨，亦有了一种尽在掌控之中的感受——只有此时，我才以为我是一个真正的产品管理者。所以，敏捷开发不是产品管理，亦不是项目管理，从一开始，我就没有走对。

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

roadmap示例：

研发的模板与流程：

CRM:

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

相似于Wiki页的：

固然还有不少，这里就不一一列举了。

从这段时间用下来的感觉来看，我以为迁移到Worktile的这个决定毋庸置疑是很是正确的：

1. 从上面不少功能来看，均可以看住SharePoint功能的升级版，好比Wiki，日历，任务列表，Web Office App等等；

2. Worktile用户体验至关不错，团队成员上手简单。并且我开始带动全部可能的人来使用。由于其用户体验的优越性，你们都并不排斥，也不会出现帐号忘了的状况（都使用的企业邮箱）。包括如今，销售和业务我都归入了使用者的范围；

3. 敏捷开发不是产品管理，固然也不是项目管理，只是项目管理的一部分，产品管理的一小部分。产品管理应该包括如下内容：产品roadmap，产品计划（包括市场计划），需求、Bug，研发，CRM等等，这是我下决定迁移的最重要的缘由。由于基于Worktile的列表和任务组合模式，我能够很灵活的管理这些。轻量灵活却不失功能，这就是我想要的；

4. 手机端的支持。我如今要求每个成员天天上班都优先打开手机端，只要状态更改了便有通知，方便及时沟通，省却了不少跑路和沟通的时间；

5. 沟通很便捷。基本上大部分功能模块均支持讨论或者评论功能；

6. 免费。创业公司能省就省；

7. 轻量灵活却不失功能，就如第3点后面所说；

8. 很便于梳理事情、任务和问题。你能够讨论，能够发布Wiki，也可使用检查项陈列，你还能用列表作个小流程，总之，你能够用不少方式来呈现和表达。

9. 一直在不断的迭代进步，并且在使用过程当中我提了不少建议与意见。

写在最后

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

最后，但愿Worktile越作越好，也但愿大家都找到本身的路，而我将继续勇往直前。