和CIO问答软件项目实施管理

一、问：首先，一个项目的起源，应该是起源于项目申请书吧。你在做项目时，是基于什么样的需求提出了这个项目需求书。以及你是怎么去做的这份项目需求书？并让你的这个项目为老总所认可，在后期给你大力的支持。恩。我的第一个问题就是，在项目的最前期，你的项目申请书（递交给公司管理层的）里包含了那么内容。使得这个项目计划让老板所认可，并在后期给你大力的支持？

答：

我建议这样来，先解决你最困扰的问题，这样就有成效，否则很容易僵化。因为现实中很少能按照正规流程来的。我们把正规流程讨论好，不管是甲方还是乙方一般都难以保证按正规流程互相配合。所以只能把流程中的各个环节拆开，个个击破，以后就可以见招拆招了。

OK。

1这个项目要解决哪个业务部门的什么问题？列出1、2、3、4。如果一个项目要解决多个业务部门的多个问题，按部门来分，再按问题1、2、3、4列举

2需要业务部门改变什么职责、流程、考核方法，或者业务处理方法。

3需要什么样的IT软硬件产品保证？

4市面上的这些可选择的IT软硬件是哪些？分别优劣性和价格高低如何？

5上线阶段步骤如何？每一个步骤持续的时间多长？每个步骤需要什么业务部门什么职责的人配合？总的时间长度如何？

二、问：当项目一但确认下来，组建项目小组时，你是怎么考虑项目小组的成员以及具体分工的？这个项目小组日常的工作是如果开展汇报的？

答：

1项目小组需要我方IT科室参与、所要解决业务问题的业务部门参与、IT公司参与。所以需要以下的人知晓这个项目的进展和异常和变化。

A我方老板

B各个业务部门的部门经理

C主要参与该项目日常需求讨论、上线使用的主力业务部门人员

DIT方老板

EIT方项目经理

F我方这个IT项目的IT科室的负责项目经理，如果要同时上线多个子系统，需要成立多个项目经理。但是每个子系统算一个子项目，互相之间不开大会，除非几个系统之间需要业务连接问题，然后开相关人员的会议。不要让一个项目经理负责多个模块的上线。如果IT科室没有那么多人，建议按现在的人手数量来上线子系统，千万不要人少还要顶着上，会忙的手忙脚乱，事情也没做好

2、这些人都应该进入项目组，然后各个项目组内联系人的邮件、手机、座机，首先把通讯录建立起来，然后通过邮件发给大家。，如果以后项目组在项目过程中有人员增减变动，应该及时更新这张通讯录，并且仍然通过邮件发给大家。每个子系统的项目组，都单独成立项目组，都有各自的通讯录。也为这个项目，列出专门的文件夹和邮件子目录，这样一个项目过程的所有文件和变更都能很快整理出来。

3、IT科室的该项目的IT项目经理按照刚才回答的第一个问题中提到的项目阶段步骤来做事。列出本月该做的工作列表，并且有落实人。这个落实人是项目通讯录中的一员。

4然后召集本月任务中涉及到的人通知开会，开会地点、时间、开会内容与确定结果。因为每个人可能都有一堆事，所以在这个开会通知邮件中要让每个人都有阅读回执

5真正开会，把真正的事情落实下去，到人，还有每个落实人的计划提交报告时间。有人记录会议纪要，并且会后给项目组全体人群发。并且把需要每个事情的每个落实人，在会议纪要中用红颜色背景专门标出来。对遗留未决问题要列出1、2、3、4。并且把这1、2、3、4增加进本月任务列表中，然后继续往返循环，一条条的解决任务。

三、问：你会把一个项目分几个阶段，每个阶段你认为都需要提交那些必须的成果以及文档？作为IT部负责人，你是如何把控整个项目的总进度并修订计划进度的？

答：

1记住，一个项目是一个子系统的上线。多个子系统要多个项目。整体是一个大项目，那是宏观的，不好落实和执行的。所以强烈要求分解，不能混为一谈。虽然各个子系统之间肯定关联紧密，而且很有可能是一个IT供应商，而且IT供应商也可能只会派1个项目经理来总揽（为了省成本，其实上线效果很差，一个项目的双方项目经理的工作非常多），但也不要混在一个大项目里，否则很难有这么强大的管理协调分配监督检查的能力。

2每个项目的阶段，就按实施来说，有项目需求调研环节。这里又分为流程梳理、需求收集、需求需要材料收集、需求讨论、需求确定。

需求调研环节完了，需要需求答复，该修改呢，还是不满足呢，还是绕弯解决呢，还是下一阶段满足呢，给出每个需求的详细答复。

把需求答复环节解决了。需要IT公司修改的。把修改列表让他们做好，他们的计划时间让他们确定好，然后这些文档都要群发给你所负责的项目组成员。让所有人都知晓，而不是关注。他们不看是他们自己的事 。每个阶段环节中，需要主力参与的人都不同。光一个需求调研环节，就需要牵扯IT项目经理、业务部门经理、业务部门骨干。

我们在实施过往经历中会遇到一个事情，经常系统还没使用，就提了一大堆需求，从很细的到很不着边际的臆想的需求都有，很多在以后实际使用过程中用到，白开发白开会白较真了。所以，需求，一定要围绕项目立项时，每个业务部门的列出来的那几个问题。如果和那几个问题无关，千万不要加入到此项目中。很多人以为反正这个小需求好实现，加入吧。最后发现，项目很累人，项目过程遥遥无期。因为就是很多小事占用了一片片的时间，最后时间没有了。

想想吧，开一个会，一上午过去了。写个计划，写个会议纪要，通知个人，确认一下，一下午过去了。一个月，其实只有22天工作日，还得防着国家公休日，其实一个月也有20天工作日，因为国家的节日很多，平均下来，一年，每个月也只是工作20天。做计划，一定要按20-22天做，而不能认为是30或31天。不能这样做计划。

一个项目最怕就是没有项目目标，或者项目目标不明确，或者项目想干的事太多。 我经常会听到一个项目目标：让我们的管理上一个台阶，让我们的工作效率更高。让我们知道每个人都在干什么。这是最扯淡的项目目标，根本没法分解可执行计划 。

所以，项目目标，一定是解决哪个部门的哪几个问题。要落实到部门落实到问题。有限的人，有限的钱，有限的时间，必须只能做有限的事情。

四、问：需求的调研是项目的一个进度，在这个进度中你认为甲乙双方都需要整理或者确定哪些有关键性的文档？

答：

需求调研，这是一个阶段。我把这个阶段刚才分解了更小的多个环节：流程梳理、需求收集、需求需要材料收集、需求讨论、需求确定。每个小环节完毕，都有文档要留下。

对于流程梳理。为什么要做这一步呢？因为IT公司对行业可能了解，甚至可能都不了解。但是对我方的业务流程肯定不了解。所以需要先整盘了解一下。比如，要解决哪个业务部门的问题，首先要把这个业务部门的每个人的日常业务，一天初、一天末的特殊业务处理，一周初、一周末的特殊业务处理，一月初、一月末的特殊业务处理，一季初、一季末的特殊业务处理，一年初、一年末的特殊业务处理，都先画了大致流程。并且把每个人每个业务过程中处理的单据、表格、报表都要收集上来。不管是纸质的、电子EXCEL的、其他现有软件系统里的，都要收集出来

一个项目实施的成败就在于：

1项目目标要解决的问题

2项目过程中的需求

3项目计划

4项目计划实际执行确认、检查、报告

5双方项目经理跟各方的协调

问：你会将模拟运行分几个阶段？每个阶段都模拟那些业务行为？你如何更进单据的流程？打印的格式？外在数据的体现？和内部财务资金帐的表述？功能表与功能表之间的相互关联你怎么测试？报表与功能表之间的关联逻辑你是如何去理清测试的？

答：你的问题，其实如果没有流程梳理环节，你目前这个问题是无法做到的。因为你全靠自己感知感觉想着模拟录入和验证 。所以，你做完流程梳理后，业务部门的每个人要做什么业务，要录入什么，要得到什么样子的报表，都在流程梳理完成后得到了 。你就按照这个流程和录入和输出来验证即可。流程梳理是将你现有的业务流程都拍个照片，就是梳理现状 。流程梳理完毕后，才是需求调研真正环节。那时候会提出新需求。并且这些新需求都要围绕项目立项的目标来说，不符合目标不能提，提了也不答应做和整改。需求调研结束后，按照新需求来调整这个过去拍好的现有业务流程照片。

需求一定要确认。因为大家一起开会，都是会上现拍脑门想的一些思路，真正你在第二天或一个星期后再问他，他又变了思路了，所以必须需求确认。确认这些修改这样做后确实可以解决问题，并且操作性和现在一样复杂或者更简单，或者更复杂。让业务部门那个提出该问题的人来确认。如果他不敢确认，那么还得开会，找他的部门领导和他一起开会确认。如果开会也确认不下来，那么提出下次确认时间。如果下次确认时间到来还无法确认，就放弃不做。而且下次确认时间就限定5天内。千万不要超过5天工作日，否则一个月才20天工作日，几下就把一个月折腾光了

业务部门他们自己、IT方、我方，这么多人智慧讨论都无法确定怎么解决问题，而且一周后还是想不清楚该怎么办，那说明这个问题本身就不太可能解决。企业有许多问题，不是每个问题都有答案的。或许问题本身就出在最大的老板身上

所以，紧紧抓住项目目标，紧紧围绕目标中的问题展开需求满足 。我们经常走的太快，而忘了思考自己为什么要这样走？过多的时候我们总是跟着感觉在走，而忽略了 为什么走？能不能换个路走？这样走能给企业带来什么样的效益？为什么不那样走？能不能不走？

如果这个单据类型或者这个报表是原有系统没有的呢？那就用手工算。确实，在原有EXCEL表格、纸张报表、原有系统中没有这个报表。但任何事物都不是孤立突然存在的。所以总是和过去数据有关联的，只是从不同角度或层次统计数据而已 。手工算，别怕麻烦。其实也没有那么麻烦，只不过是自己觉得麻烦，连头都没有开，尝试执行都没有做，就说麻烦做不了。很多事情，就连IT科室人员都是一样的，太麻烦了， 交给IT公司去做吧 。于是，一层推一层，IT公司当然不想算了，随便报一个马虎过去就行了。最后运行中出了问题了，我方都后悔当初懒了。

关键就是项目明确要解决的问题1234、项目计划、计划任务落实责任人、项目进度每周检查、流程梳理、与项目目标密切相关的需求讨论与确认、培训管理。

五、问：培训怎么管理？

答：

1培训管理，要有针对业务部门操作人员的、业务部门操作人员管理字典的、业务部门经理的、IT部门系统管理员的，这是主要培训对象。

2培训的课程、课本、教案在哪里？

3培训用模拟数据库在哪里？

4培训用的环境在哪里？服务器？打印机？扫描器？模拟练习的PC机？

5培训了几次，谁培训的？培训什么内容？什么时候培训的？谁参加了，谁没有参加？

6培训后考试，每个业务操作人员的考试成绩如何？考试问卷在哪里？

这样来管理培训，才能决定业务部门有没有能力使用起新的IT系统来做他们的日常业务 。

项目立项、现有流程梳理、需求确认、系统整改、系统培训、模拟运行、系统切换，在每个环节中我们都可以看做是一个项目。要管理好整个项目，我们就要管理这些环节项目。

管理好每个环节，整个子系统的上线就成功了。每个子系统上线成功了，整个大项目才上线成功了。我最怕有企业说，让我们现在开始实施ERP吧。如果这个ERP有20个子系统，核心系统有10个，难道就要同时上线？难道就要每个功能都要使起来？我们到底要解决哪个业务部门的哪些尖锐问题？有些问题解决了也没有多大作用。有些问题很尖锐但是连人都解决不了，所以，要找急需解决的还是能解决的，而且还是IT擅长解决的。有不少问题，IT软件并不擅长解决，非要IT来解决，肯定没效果或者效果更差

六、问：在切换上线这个重要环节中，你是如何去让数据完整有效的进行切换的？在这个工作中，你认为作为IT负责人必须去关注那些点？以及多长的切换周期是最有利于系统的切换的？

答：

1我不赞成导入老数据到新系统中，数据格式和数据校验不匹配，倒进去，更扰乱了从新系统中录入的数据。我干过这事，最后干了一个月，最终还是废弃了

2我不赞成12月份和1月份上线。因为这时候都很忙，忙着结账、报账、调帐、应收应付回收、年底述职汇报，大家还想着过春节准备东西。

3我不赞成月中上线，否则下月初打印报表，两个系统中找数。我建议在每月3号以后开始切换。这样，两天的数据，可以及时再补录进去。而1号、2号事情忙，业务部门都不想着上线。

4星期五、六、日不上线切换。因为看着没事，星期一本来事多，一运行，全是问题，事更乱。建议在星期三上线。这样星期一的事差不多忙完了，如果有问题，也只是挨1-2天，又星期六日了，又机会修复了。

按理说：1 字典准备好，验证好了。2 现有业务流程验证好了。3 培训做好了。系统切换，新系统使用，是相对比较风险小了 。

还有几点告诫：

1千万不要让IT方实施人员从流程梳理到项目上线，都一直待在我方。即使我方承诺提供食宿也不要这么干。一个环节一个环节干，干完一个环节就回去，让他们在自己公司或住所做。否则人容易疲惫，最后莫名发火，怠工，很多事情本来容易也不想做了，本来没啥冲突最后莫名吵架或怄气了，事情就不好继续了。

2一个任务计划或需求的讨论，你和关键主力对口人或责任落实人之间还没有互相了解和达成一致，千万别召集相关人开会。否则，本来问题就不清还没想明白，最后大家你说一嘴我说一嘴就更容易理不清问题。而且如果会上临时拍脑门决定下来该怎么做的是一个领导，那么就更不好办了。做还是不做，明知领导说的有问题，还不能不做。所以你和关键主力对口人或责任落实人之间还没有互相了解和达成一致的时候，千万别召集相关人开会 。

这是豆瓣评论

http://www.douban.com/subject/3319935/

《走出软件作坊》网上订购：

互动网：http://www.china-pub.com/508874

卓越网：http://www.amazon.cn/mn/detailApp?prodid=bkbk812538&ref=GS_TS&uid=168-8093432-0389064

当当网：http://product.dangdang.com/product.aspx?product_id=20435119