实施过程好文记录

计划性

　　　　我们在发开软件的时候有这样一个功能，做生产排产计划，做过相关工作的人应该都知道：工厂在加工某个产品的时候，会先做一个排产计划，比如这周要排产什么产品，排产数量是多少，所需要领料是多少，产品的先后顺序是什么。 做排产计划的目的是为了让工作更加有序的进行，在规定的期限达到相应的目的，软件开发这个功能方面我们都非常擅长。但是你真的会做计划吗？

　　　　任何事情都要有计划，这样才能保证自己的事情按照既定的目标和轨迹推进，虽然不能完全一致，但是至少让你有一个目标感！在开发和项目实施的过程中，我们往往缺少这样的计划任务，事情想到哪里做到哪里，导致所做的的事情毫无章法头绪。先做这个发现问题做不下去然后又走另外一个，最终一个都没有做成。个人做计划应该达到如下几个要求:

　　　　(1) 针对目的： 做这个计划是针对什么，也就是我们的目标，我们要达到什么目标

　　　　(2) 明确任务: 这个计划是要做具体什么事情，甚至包括具体的实施推进步骤

　　　　(3) 时间限制： 做计划一定要有时间限制，这个计划实施要在什么时间范围内完成

关系型

销售和客户：销售首先和客户接洽，销售会和客户说我们公司会做什么，我们的产品有什么优势，我们能够给你们解决什么问题，我们能够提供什么样的服务(我们公司主要提供仓库，生产等条码解决方案)。客户对此非常感兴趣，决定要上什么项目，于是销售和客户一拍即合。在这个过程中销售因为不懂技术，有时候会过度承诺给客户一些需求，往往这个时候过度的要求在于其他公司看来也是一个难点，客户也许正为这个为难，所以问题的症结点扣准，那么你就能够拿下客户。销售给客户说我们能够解决这个问题，客户一定对此非常感兴趣，但是这个时候往往会给技术留下一个坑，可能解决这个问题所花费的人力时间都超出想象。但是要说明的是，有时候会为了一种商业目的，往往会有这样的一种销售手段来提高销售的成功率，这个也是无可厚非的，技术问题一般都是可以解决的，只是难易程度问题。

　　　　销售的过渡承诺往往在项目还是没有开始的时候就决定了后面的开发以及实施的难度，然后销售人员为了签单也不可避免的做一些承诺。我这里不是贬低或者抵制销售的过渡承诺，相反还比较支持销售有时候的适当承诺，从公司的整个的整体出发点来说这样是没有错的，只不过需要承担更多的风险和压力，而这些压力会实际体现在开发和实施人员的身上。为了让项目良好的推进，在项目前期在适当的时间可以让有资质和经验的技术人员和销售一起去了解项目的内容，而不是等到最后签单之后才决定让技术人员介入此事,这是保证项目推进的一个比较不错的方式！

　　　　(1) 销售人员在前期明确自己公司的整体实力，整体实力是:能够做什么，做到什么程度有难度，完全不能完成

　　　　(2) 了解客户的真实需求和目的,不是细节需求而且想解决一个什么问题。比如我要解决排产人工计划的问题，要能够使用软件编辑计划和调整计划

　　　　(3) 销售可以和技术在适当的时间同时去拜访了解客户问题，并且多做沟通

实施和客户: 实施是在项目推进过程中直接和客户接触的，他能够在项目推进的过程中及时的发现问题。但是项目实施有时候又是项目开发经理来担任的，这是一个非常重要的过程，在很多时候我们一直在强调如何使用文档管理项目的需求等等，客户说话要算数，让客户明确自己的需求等等，无论我们使用何种方式来管理这个需求和确认需求，在开发的过程中总是新需求不断的出现和需求的变更。往往项目延期我们都会认为项目是因为不断的有新需求和需求变更导致项目无法把控，当然我承认事实是如此，难道我们就无法减少这种不可控的因素么？

　　　　项目实施的过程中就要不断的和客户去沟通，我们知道有些事情无法避免，那么当问题出现的时候我们应该努力去找客户商量解决办法，而不是等问题完全暴露无遗的时候再去努力抱怨。可以加强和客户的沟通，你可以现场操作，你可以去问实际的操作人员，甚至在某段时间你可以帮助他们去做某项工作，只有这样你才能理解他们是怎么做的，你才能发觉项目的需求。客户领导可能会抱怨你的实施进度很慢，但是实施人员一定要努力去面对这些问题，而不是去逃避客户的问题。

　　　　(1) 实施人员可以现场操作，实际跟踪，甚至某段时间协助他们完成相应的工作

　　　　(2) 向实际操作的人员了解具体如何使用的，他们的工作难点在哪里，不同的工种操作你都要去了解，最好是实际操作

　　　　(3) 跟客户领导反馈你发现的真实问题，有时候客户领导和公司领导一样根本不可能知道实际的问题，而只是表面的知道问题，并且让客户确认。

　　　　(4) 放下自己的身段，就作为一个普通的操作工。我觉得这点很重要，很多做这种相对高级点的工作，在实际的项目实施过程中都怕去做这种流水线的工作，就和技术人员很多不敢给客户打电话一样的。

实施和技术：在项目过程中，技术和实施及时亲兄弟，用一句话来形容就是"唇亡齿寒"，所以这两个一般情况下关系是相当不错的，但是有时候也会有冲突的。实施人员在实施的过程中软件出现问题，那么最直接的问题就是技术人员没有做好，而这个关键的时候如果客户知道了，倒霉的肯定是实施人员。实施人员受罪了技术人员还会好过么。因为实施人员直接接触客户所以能够知道客户具体需要什么东西，这个决定了技术人员的开发方向，这个过程也会影响项目的推进。

　　　　(1) 实施人员要能够把握住客户的确实要求，了解他们的问题之后要能够总结归类然后反馈。我在实施过程中会先将客户的问题给记录下来并且分析难以程度以及紧急程度再反馈给技术开发人员。

　　　　(2) 过滤伪需求排除不再范围内的需求，有些客户提出的要求并不是一个可行性的需求，也有一些不是在我们范围内的需求。我们这个需要明确把握，在项目实施的过程中我有几次充当烂好人，结果也没有得到什么好处，反而适得其反。先做好本职工作再在有能力的情况下去帮助客户解决问题。

　　　　(3) 技术人员要能虚心的接受实施反馈的问题，在某种情况下技术人员认为不太可能的事情但是对于客户来说是非常重要的。比如在一个表格中第一列和队列显示的内容问题，你认为第一列和第二列位置无所谓，但是对于客户来说却是非常重要，为什么这样你体会不出来，或许是习惯问题！所以技术人员要能够接受莫名的问题。

博主原路径：https://www.cnblogs.com/qingyuan/p/3751052.html（仅作为好文记录）