摘要：在PMP的学习中，有一章专门是讲干系人管理的，可见干系人管理对项目管理的重要性。实际的项目管理中也确实如此。 对于不同维度的干系人需要进行不同的管理。这个的确是真理。由于我们目前的工作很多要和营销部门沟通，并且要配合营销公司的业务流程，因此必须时刻围绕营销公司的业务来运作。营销公司自然也就是我们最重要的干系人了，不仅要重点管理而且有问题要实时通报，多多沟通。接下来就是对系统关注度很高的大经销商了，需要满足这部分人的需求与愿望，当然是指合理的需求和愿望了。对于公司内部其他业务部门和其他相关的系统的人员我们则需要对系统的变化实时的告知他们，尽可能的减少我们的内部阻力，同时增强和各团队的联系，相互. 阅读全文

摘要：前几天营销部门提出了对业务进行调整的需求,由于感觉调整比较简单，所以也就没有过多的考虑，方案执行的情况。因为只是新增了几个客户类型，需要经销商将以前的2种客户类型调整为新增的4种客户类型。 然后经销商在规定的时间内调整完毕后，再将以前的那2中客户类型禁用掉即可。但是系统做了修改后，运维接到的反馈显示，经销商是对此操作很迷茫，纷纷来电或者QQ，RTX询问。一时间运维组的神经紧绷，开足了马力来应答。虽然我们也在系统中做了公告，并详细的做了说明，同时营销公司的同事也做了通知，但是效果几乎没有。因为几乎没有人看通知，也很少有人关注公告，都认为找运维支持人员最直接。 这也难怪，平时这些经销商用户就已经. 阅读全文

摘要：前段时间用户突然发现我们的系统登录慢了很多，刚开始我们也没有引起重视，因为系统登录慢可能是由于用户网络慢的原因，而且其他方面也没有什么异常的所以也就没有注意。用户反应了问题后也以为是自己的网络问题也没有再提这件事情。 在上周一次系统调查时，我们无意中将系统中的一个webservice的地址调出来，在浏览器中看了下，结果大吃一惊的是地址竟然打不开了，原因是地址被改动了，而且改动时没有通知我们，经过我们的调查确认，发现原来是网络组私下改动了地址，而且限制用域名来调用服务，必须使用内网地址。这是个要命的问题，我们的很多服务都是用域名访问的，就是为了防止由于域名映射的网络地址改变而影响到系统的服务的. 阅读全文

摘要：最近在学习PMP的课程，看到了很多关于团队建设的方案，但是感觉在国内，大多数企业这方面都做的很不好，人员流动性很大。知识和经验很难积累下来，而且由于流动性大，工作效率也大大受到影响。毕竟培养一个新人不容易，留住一个老员工也不容易，我们姑且将能呆一年的员工称为老员工吧。1年内离职的就不算了。 在最初的3个月的试用期中，新员工是不大会参与很核心的工作的，所以这3个月实际上就是熟悉公司业务及技术等的一个过程。当然这样说也不一定很准备，根据公司的业务和具体的领域来论，有的工作可能一周就上手了，有的可能半年都难以熟悉。我们平均都以3个月来计算好了。如果一个公司流动性过大，那么也就意味着不断要培养新人，不 阅读全文

摘要：由于现在项目发布比较频繁，因而经常需要改变版本，但是为了能够保有一个最新的CodeFix版本，所以我们也需要在修改主线版本的同时同步合并修改的内容到Fix版本。由于种种原因经常导致合并到CodeFix的进度被延后，因而经常导致CodeFix版本的滞后。 正常情况下这个也不会有什么很重要的问题，但是一旦出现需要紧急修复的问题或者需求要发布，这个时候Fix版本就会显示他巨大的用处了。因此在软件项目的管理中如果版本管理出现了问题，那有可能产生的影响就是灾难性的，而且将是一个不定时的灾难，你都不知道什么时候会爆发。 因此保留一个和PRD环境相同的CodeFix版本是必要的。 阅读全文

摘要：在一个阳光明媚的周一上午，当我们正准备开始一周工作的时候，运维组的突然跑过来告诉我，十万火急的问题出现了，销售，采购，库存这几个核心模块都无法使用了，早上9点前还好好的，现在运维组的电话都已经爆线了，所有人都手忙脚乱的向用户道歉。 我马上找组里的开发和配置人员进行确认，有没有人动过数据库脚本并让配置人员进行了发布，因为公司现在有权限的直接操作PRD数据库和PRD环境的人比较有限，一般都需要通过配置人员来完成操作，其他人是不会有权限直接执行的。 配置组的同事告诉我，刚才的确是执行了一个脚本，但是这个脚本是在QAS环境执行通过了的而且只花费了几秒钟时间，刚才他在PRD环境执行时，却执行很慢，而且. 阅读全文

摘要：前几天有幸参加了公司的一次会议，上面提到了公司当前的业务状况及未来的发展方向，感觉对公司的业务从宏观上有了进一步的了解，思绪豁然开朗了。以前在刚入职的时候公司也进行过培训，但是那时候由于对公司了解非常有限，所以也没有很深的理解。作为一家专业性的软件公司，平时很少有这样的会议。会议大多和工作相关的各种技术和业务需求讨论会议，以及项目管理和汇报的会议。但是我们一天到晚忙忙碌碌，却很少明白这样做的真正意义，可能我们只是很简单的了解到，这个项目我们可以赚多少钱而已，其他的就很少去想了。估计这也是大多数软件公司的标准做法，而且开发人员也很少主动去关心，感觉事不关己，就难得咸吃萝卜淡操心了。 但是我自己. 阅读全文

摘要：在项目开发的过程中，经常会遇到和其他系统的接口交互的需求，面对这种跨项目团队，跨产品组的接口问题，我们应该如何处理呢？是等到项目需求明朗后，再找相关的系统开发人员来进行洽谈，然后合作开发测试呢？还是在立项后就开始着手准备呢？ 从项目风险的角度来看，如果到了需求明朗后才开始找相关人员来进行分析确认，然后开发，测试，恐怕会是一种很理想的状态。因为其他项目团队的资源是否能够恰好在你需要的时候能够协助你呢？如果你没有进行预约，那么很显然你是没有获得邀请卡的机会的，那么你的项目进度恐怕就不是那么容易把握了。 因此在项目立项的时候如果涉及到和其他系统的接口，那么要注意了，一定要和相关的第3方人员进行预约， 阅读全文

摘要：最近系统发布比较频繁，因此每次发布我们都要有个发布说明，以前没有注意这个发布说明的统一性，只是根据每次的实际情况不一样做了下说明，但是还是感觉有必要做一个发布说明的文档出来比较好些。这样每次就可以按照一个规范来执行。 我大致列了如下几条：一、正式版的服务端和客户端dll发布每次发布正式版的服务端和客户端时，从要发布的测试版的服务端拷贝日期最新的dll到正式版服务器的FTP后，再从FTP拷贝到服务端文件夹中进行替换即可，注意在进行正式版的发布前一定要做好备份。同样客户端要发布的dll也要拷贝到正式版服务器的FTP后，在覆盖到正式版客户端所在的文件夹。二、正式版的客户端和服务端的配置文件的修改如. 阅读全文

摘要：最近进行了系统的一次大的升级，由于要进行升级执行的数据库的脚本很多，所以发布时一不小心执行了一个不该执行的脚本。事后虽然我们及时的进行了补救，但是仍然让系统的业务停滞了近2个小时。 因而有必要对数据库脚本的登记和管理及数据库脚本的发布流程进行下梳理。 首先就体现在数据库的脚本登记上： 1.脚本登记一定要按照项目登记在统一的文件夹，文件夹的名称要按照统一的规范来命名，让发布人员一眼就能根据文件夹的名称来区分。 因为我们目前一般都会有多个项目并行，虽然都是围绕一个产品在进行开发，但是项目的启动和终结是有先后顺序的，所以一般一个项目 的脚本都应该在一个文件夹下，同时由于项目是在迭代进行的，不是一次. 阅读全文

摘要：大约3周前去客户那边出差实施并部署新版本的系统，由于此次为客户追加了很多定制化的功能，所以需要做的准备和确认工作很多，在和客户对所有的功能模块和业务进行确认时，突然发现了一个我们以前忽略掉的业务，而且考虑到我们现在的系统已经在全国都展开使用几年了，这个被我们忽略的业务还不能加到我们系统中来，只能做一个类似插件的小系统帮助用户来实现功能。而且这个小系统的很多基础数据来源于我们系统，但是它的数据存储就不能放在我们的系统中了，必须单独来存储。 在了解业务时，我们发现用户所需的这个功能其实不算很复杂，于是决定在我们给用户做培训和实施的时候将其开发完成了，由于现场只有我一个开发人员，这个任务当然就只有由 阅读全文

摘要：昨天开始到宁波出差，开始了前不久完成的一个项目的实施工作，以前总是认为项目实施是件非常容易和轻松的事情，但是通过昨天和今天这2天的全程了解，明白了原来实施工作也不是想象中的那么轻松的事情。特别是要对系统的业务非常的了解，对应客户提出的问题，能够给出一个让客户满意的解决方案，是相当的不容易。这2天里，首先进行了项目的启动会议，和各业务部门的进行了沟通，让用户对我们的新系统有了初步的印象，同时针对客户的疑问做出了解答，后面还要对用户进行培训，调整系统上线时的期初数据等等。和客户探讨一些业务问题，有些现有系统的业务解决不了的问题，还需要和公司的开发人员进行沟通，协商处理或者针对客户提出的需求进行进. 阅读全文

摘要：前段时间开始带领一个小团队进行一个项目的开发。经历了从需求分析，设计，评审，开发，到目前进入测试阶段的一系列过程。项目的各个阶段中遇到了各种不可控的因素，如核心骨干离职，同事突然生病，项目中间被其他优先级更高的任务打断，中断了一段时间后才又重新开始等等。。。，因此感慨颇多。先说下需求阶段，在对客户需求进行分析时，经过和客户的多次确认和引导，终于完成了需求的分析和设计，可是再将需求再次发给客户进行需求最后确认时，客户又将需求进行了部分变更，还好不是全部的变更。总算完成了需求评审，准备进入开发阶段了，可是忽然接到公司安排，要求将项目先暂停，进行一个优先级更高的项目，于是只是让所有人员将项目先停下， 阅读全文

摘要：今天下午同事在PRD数据库服务器上更新了一个脚本，没有想到的是，本来很平常的一个操作，却导致了灾难性的后果，由于我们系统前不久改变了同SAP交互的方式，以前通过另外的中间接口访问SAP，最近进行了迁移，换了个接口程序。可是我同事的脚本更新后不久，用户就发现订单中有些产品被莫名的更改了，订单上开始选择的是芝麻油500箱，结果后来生成订单后发现变成了橄榄油500箱，虽然后来我们发现后马上进行了进一步的验证，而且没有发现大量的错误数据，只有一家用户，下了一个订单出现了问题。风险范围比较小，大家总算松了口气，马上进行了修复，并进一步进行了再三的Check，但是也暴露出了一个问题。事关这种全局性的修改， 阅读全文

摘要：在项目的新版本发布过程中，暴露出了一些数据库权限管理的问题和数据库升级流程规范的问题。在这次发布完真实版后，居然发现有些脚本没有被执行，导致用户升级完就出现了些Bug，产生了很不好的影响。为此项目组专门开会讨论这个问题，具体原因分析如下：1.开发人员现在都有测试数据库的写入权限，导致人人都可以在测试数据库中进行执行脚本，这样就有开发人员在测试环境直接执行了脚本，但是却没有进行登记，结果在测试时没有发现问题，但是发布真实环境时却漏掉了一些脚本的发布。2.一些数据库的存储过程没有按照规定直接更新到VSTS中指定的目录下，而是直接在开发版本的数据库中执行了，或者在测试数据库中执行了，这样在发布时没有 阅读全文

摘要：目前在公司参与开发的一个项目是一个非常成熟稳定的项目，项目已经在全国的经销商推广使用了几年了，因此对于新版本的每次升级首要考虑的不影响用户的使用的情况下发布新功能和修复bug。对于开发人员而言，每次的新版本发布将会面临着很大的压力。因为即使我们再三小心，也难免在发布新版本时，不对用户产生丝毫的影响。有时候甚至会产生些比较严重和紧急的Bug。经历过几次新版本的发布后，我对此进行了些思考，总结以下几点：1.每次发布新版本的间隔时间不宜过长，新版本中包括的需求和Bug不宜过多，应该根据需求和Bug的紧急和重要程度来排序，然后选择一定数量的新需求和Bug来发布。（比如每月发布一次新版本，每次累计需求. 阅读全文