|
1.1 项目故事项目管理者联盟
就在昨天，经历了一次典型的技术和业务沟通故事，这是一个金融支付项目，技术团队是界面设计团队，负责前端展现界面的设计，业务团队来自银行内部一线业务人员(柜员)，而我是一个列席者。过程中发现一个非常熟悉的不能再熟悉现象(交代一个前提，界面一共有两百多个)，界面设计人员一面逐个界面打开每一个交易界面，业务人员则不断的提出自己的想法和发现的问题，然后继续进行下一个界面的讨论。这个场景是否你也感到很熟悉呢?一个人在讲，一个人在听;然后一个人在讲，一个人在听。也许你要说整个过程很好啊，没问题啊。讲的能讲明白，听的也能听清楚。事实真的如此吗?想一想你所经历的项目沟通故事，再次沟通的时候，到底有多少问题得到落实呢?又有多少问题反反复复的来回折腾呢?答案应该就在你心中。项目管理者联盟
1.2 实践是检验真理的唯一标准项目管理者联盟
沟通的主题是信息，因此沟通只是手段，不是目的。沟通过后，又有多少问题得到最终的解决?因此落实才是检验沟通的标准。借用我们伟大领袖林彪爷爷的话来说：“一切凭数据说话，开会不落实=0，落实不检查=0，检查没效果=0”。套用到项目沟通过程中来讲就是：“一切凭数据说话，沟通不落实=0，落实不检查=0，检查没效果=0”。blog.mypm.net
1.3 何时开始沟通项目管理者联盟
以界面设计的项目为例来讲，你认为何时开始沟通比较合适呢?这个项目中我听到了两种不同的声音，这也是典型的两种观点，当然观点不止这两种，谨以此两种作为实例来进行说明。观点一、完成所有界面设计和业务逻辑后，集中进行沟通。观点二、完成模块级界面设计后即进行与业务人员的沟通。持有观点一的人，认为只有完成业务逻辑的设计后，才是一个整体，才能够向业务人员演示整个过程。持有观点二的人认为，界面设计与业务逻辑分离，让业务人员今早参与进来，可以有效降低，后期变更的成本。那么你持有何种观点呢。做一个选择题吧?项目管理者联盟
1.4 如何进行沟通项目管理者联盟
沟通是一个信息传递的过程，只要不是太业余的选手，把问题表达清楚这个方面，一般都不会形成问题。真正形成问题的是能否把沟通的结果落实到纸面上，是的，纸面上。记得有句经典的话，可以借用一下：宁愿相信世上有鬼，也不要相信男人那张破嘴。语句本身有攻击男性的意思，但是隐藏在这背后的寓意则是：空口无凭，不认账的男人和不认账的程序员或者业务人员，本质上没有什么不同。回到我之前提到项目沟通故事，过程中我发现业务人员提出问题集中在几个方面：项目管理培训
(1) 界面元素有些不应该存在。项目管理者联盟
(2) 界面元素可选值有些不应该出现。项目管理者联盟
(3) 界面业务逻辑部分交易有争议。项目管理者联盟
(4) 菜单结构和顺序不合理。项目管理者联盟
看看这几个争议点，你发现问题没有。如果只是业务人员这样用嘴说一次项目管理者联盟
你能记住多少?到底哪些界面元素不合适?哪些界面元素可选项需要调整呢?作为技术人员的你能说的清楚吗?所以正确的做法是什么呢?pmp.mypm.net
1.5 沟通成果如何检查项目管理者联盟
如果按照这个情况进行下去，下一次沟通的时候，技术人员能拿一个什么样的界面给业务人员进行展示呢?如果你想象不到，只能证明你需要好好锻炼一下想象力了。再次沟通的时候，作为技术人员的你，怎么证明你已经把上一次发现的问题已经更新过了呢?点点斗斗吗，这样做是否有说服力呢?而作为业务人员的你，又怎么来验证之前已经发现的问题已经得到及时的相应和处理了呢?再一次过逐个界面检查一遍吗?项目管理者联盟
1.6 我的建议talent.mypm.net
关于何时开始沟通的选择，不做说教，看个结论吧，采用第一种方式的界面设计团队已经被淘汰掉了。关于沟通的方式，说一个下我个人给这两个团队的建议吧，我是没有胆量静待下一次的沟通会议让他们自己去反思了。一、针对业务团队，把每一个认为有问题的地方，通过截图加圈注的方式提出，尤其是涉及界面元素的细节的问题。二、针对技术团队，把业务人员提出的每一个问题，采用Excel表的方式，进行记录，再次沟通时进行逐项检查。三、关于业务规则有争议的地方，暂时搁置，则期邀请相关人员再议。项目管理者联盟
作者：张子良，版权归作者所有，转载请注明出处：http://www.cnblogs.com/hadoopdev项目管理者联盟
项目管理者联盟
bbs.mypm.net项目管理者联盟
|
