当前位置:主页 > Office办公

最新发布

聊聊协同打单的一些心得体会
聊聊协同打单的一些心得体会

今天来简单聊聊软件业务中协同打单的一些心得体会。回顾总结我们这些年所做的项目型软件开发,要做这一类项目型的软件开发,首先得想方设法拿到项目。以我们公司在几个行业里多年的沉淀,要在所在行业拿到一些软件项目自然也有一些方法。这里面,解决方案销售应该算是其中最主要的方法之一,这也是软件项目打新、攻下中大型软件项目等的基本方法。要做好这件事情,其实就是要销售、售前、售后为同一目标群策群力、协同作战、持续跟踪、死磕到底。在本人过往的一些项目经历中,真正意义上的协同打单的场景仔细想来似乎屈指可数。这其中印象比较深刻的是三年前在某地市软件项目上的协同打单经历。姑且不论后面项目可持续性和规模效应问题,也姑且不论项目金额的大小,单就从项目打单的角度来看,个人认为还是可以拿出来与大家分享一下。整个项目从当年年初获知消息到当年10月底中标,前后耗时10个月之久,多达15次以上对客户单位A、B、C等的拜访与解决方案交流,基本上每一次的客户交流都做了客户拜访日志的记录和分析,至少5次的解决方案大修改,前后进行了3次大的原型开发,从最初的全静态原型到中间的嵌入真实系统的原型再到后期的逼近真实系统的原型,为投标答辩演示提交了一份相对满意的答卷,甚至于这套逼近真实系统的原型也为中标后要在一个多月内快速上线试运行目标的实现打下了良好的基础。谈到这个项目,其实中间经历了很多波折,也犯了不少错误。首要的错误就是在与客户进行第一次交流前准备不充分,对客户、竞争对手都了解甚少,同时依然按照过往的思维想问题、做方案,自我感觉良好,从而导致在当年2月份与客户第一次正式的交流时被客户批得几乎体无完肤,大败而归。经历第一次的失败之后,销售、售前及相关人员认真做了总结反思,并及时调整解决方案,并于当年3月中旬再次与客户交流,挽回了继续失败的颓势。与此同时,公司领导、销售人员、售前人员也陆续拜访客户,多措并举,协同推进。直至4月初的第一个完整原型出来及相关关键点的突破,才算基本抓住了客户方主要干系人的心,与蓄谋已久的竞争对手相比也开始逐步显现我们的解决方案销售优势。再之后自然就是解决方案的持续调整、原型的持续优化、把控住招投标等关键节点与要素,这中间自然离不开销售与售前、售后一起的密切配合。总结该项目的协同打单经历,个人主要有几点启发: (1)打项目,特别是新项目、大项目,周边豺狼一堆,竞争对手虎视眈眈,很容易处于水深火热之中,销售与售前、售后紧密配合、协同作战是出奇制胜的基本立足点。 (2)在打项目的过程中,要时刻关注客户及相关方的个人需求与项目需求。很多时候个人需求是项目需求的动机,而项目需求则是个人需求实现的体现。 (3)在关键阶段、关键环节、关键时机找到黄金人,往往能起到事半功倍的效果。 (4)认真细致地做好解决方案,同时也要认真准备售前交流,让客户信服自己的方案,在交流中把节奏往利于自己家方案和不利于竞争对手方案上引,也是需要一些技巧。 (5)既要有耐心,经得住黎明前的黑暗与寂寞,又要有恒心,持续跟踪售前过程,时刻注意变化并积极应对,一旦真正投入进去就要有不达目的誓不罢休的决心和勇气。最后,谈到售前工作,我们要清晰地认识到:售前不仅仅是售前人员的事情,也不仅仅是销售人员的事情,而是大家共同朝着一个目标前进的过程! 售前工作的三个层面包括:售前工作整体策划、售前流程和售前交流。下图是早前根据相关资料整理而成:

375 次浏览
如何在Project中处理加班工时
如何在Project中处理加班工时

在微软Project软件中有处理加班工时的功能,但是我在系统课程中没有讲,为什么呢?就像Project软件中的【进度线】功能,这个功能还不够完善,所以暂时不建议大家使用。加班工时这个问题也是如此,总体上说,Project软件设计了加班工时这个功能,但是目前还不够完美,今天就给大家系统地讲一下它应该怎么用,还存在哪些问题。首先,我澄清一个概念,Project软件中讲的“加班工时”指的是日历中工作时间内的加班工时,比如你用的是“标准”日历,星期一到星期五上班,星期六星期日是不上班的。软件中的加班工时指的是星期一到星期五的“加班”,而不是周六周日的加班。周六周日的所谓“加班”应该通过项目日历或者任务日历来体现。我希望大家在阅读后面的内容前,先理清这个概念。我们创建一个简单的项目举个例子,采用“标准”日历,只创建一个任务A,工期为10天,如图1所示。图1所谓加班工时,既然是“工时”,肯定是和资源有关的,接下来我们在【资源工作表】视图中创建一个工时类资源,比如叫做“项目经理”,标准费率假如是100元,加班费率假如是150元,如图2所示。(如果没有加过班,可能你是一个假的项目经理~~~加班还想要加班费?说明你是一个有想法的项目经理~~~)图2然后我们将“项目经理”这个资源分配给任务A,我们可以在【任务分配状况】视图中操作,尽管分配资源在很多视图都可以操作,但是接下来的很多操作都需要在【任务分配状况】视图中进行了 。在分配资源之前,需要提醒大家,如果我们需要用到工时的话,先把任务类型改成固定工期。如果用默认的固定单位,那么你一旦调整工时数量,工期就随之变化,整个计划就全乱了。使用固定工期的好处是,调整工时数量后,工期的变化可以由我们自己来把握和手动调整。如图3所示,默认任务每天使用8个小时的项目经理,工期为10天,总工时为80小时,总成本为8000元。

1337 次浏览
Project2007下载地址_安装流程_产品密钥
Project2007下载地址_安装流程_产品密钥

Project2007是一款非常专业的office办公软件必备组件,其为用户供了一些优质目管理工具,让用户可以高效地管理office报表项目,提高用户工作效率。小编将网络收集的Project2007下载+安装流程+产品密钥汇总分享,需要的赶紧阅读吧。Project2007下载地址由于Project2007有单独的安装包,并没有像Word2007一样是默认集成在office2007安装包中,所以单独下载Project2007安装包然后安装即可(启动迅雷,然后复制下述ed2k地址)。ed2k://|file|cn_office_project_professional_2007_cd_X12-18938.iso|392437760|48C3FCBE802FDA5C8326C5A26F2A95FD|/Project2007安装流程第一步:解压下载的压缩包后,点击『setup.exe』开始安装,然后在安装界面中输入Project2007产品密钥『W2JJW-4KYDP-2YMKW-FX36H-QYVD8』,再点击右下角的『继续』;第二步:在『阅读Microsoft软件许可证条款』界面中勾选『我接受此协议的条款(A)』后,点击右下角的『继续』;第三步:进入Project2007『安装进度』界面,耐心等待几分钟;

从零开始学Project
从零开始学Project

MS Project是一个门槛极低的应用软件。只要你懂什么是横道图(甘特图),基本上就会用它。觉得太简单了?你知道怎样建WBS吗?怎样分配资源?怎样优化进度?那么,你知道什么是项目分解?什么是资源规划?什么是关键路径么?MS project 功能简介1.项目进度计划制定活动定义(范围说明WBS&活动清单)/ WBS示例 /▲仅为示例,并不代表任何具体项目的全部项目范围/ 活动排序 /

450 次浏览
如何从 Project 看项目管理核心思想
如何从 Project 看项目管理核心思想

本文将从 Project 软件的独特视角,强调产品经理需要的项目管理相关思想及其关联知识。在网上流传着这样一份腾讯产品经理能力模型,暂且不论其真假,但不难发现做一名合格的产品经理需要非常综合的各项专业能力。而在能力模型中有一项很重要的能力就是项目管理能力,它能在产品的整个生命周期中,帮助 PMer 进行产品迭代的规划、各类资源的整合以及生产进度的把控。在日常工作中,大部分企业或团队都会选择一些协同软件来进行产品/项目的管理。但在更专业的项目管理领域,项目经理们普遍采用 Microsoft 出品的 Project 软件来进行这项工作。本文将从 Project 软件设计的独特视角,强调产品经理需要的项目管理相关思想及其关联知识。至于 Project 的强大功能及其使用方式,不在本文的讨论范畴中。在 Project 中,每一个项目的开始都需要建立项目信息,主要填写的是项目开始日期以及日程排定方式。其中日程排定方式提供两个选项:以项目开始日期或以项目完成日期。

437 次浏览
项目管理工具之 Project 使用技巧
项目管理工具之 Project 使用技巧

在实际工作过程中,项目经理怎么样能够快速的做出一个清晰且有效的项目计划呢?今天给大家分享微软体系的项目管理工具 Project 的使用,本文以Project 2016为例,结合Excel+实际项目为例进行讲解。安装Project 2016如有需要安装包的同学请直接点击用Excel收集任务清单及时间估算产品在出PRD文档时,通常会包含功能清单,研发相关人员根据功能清单拆分为可执行的任务清单,并评估出相应的工作量。项目计划有效的基础是合理的拆分任务,任务的拆分要遵循“自上而下,完全穷尽” 原则,具体实现方案荔枝哥会在项目管理篇提到(可利用工具Xmind)以服务端任务为例:

606 次浏览
Project Professional自动模式工作日工时问题
Project Professional自动模式工作日工时问题

个人觉得Project这个软件最重要的就是项目工时的理解。先简单假设: 一个工作日默认6个工时,每个工时是每个人的工时;或者说是每个任务的工时,超过了就是加班。但是——这个软件会自动占用到到下一个工作日。更改项目的默认选项,记住这里是6个工时: 常见问题1,前置任务没有用: 原因是日历默认工作时间是8~17:00 我们更改了项目的工作时间,日历没有自动更改——那就要手动了 举例更改工作时间 如果只更改当天工作时间,会出错所以两个都要改 可能引发问题2: 工作日计算异常 因为工时是6小时,所以一个工作日的工作时间必须6小时 所以设置每天的默认工时也要恰好是6小时 如果默认的设置好了,对于指定日期可以选默认,也可以自己指定(优先使用) 总的来说: 工作日计算出了问题,就是每天的工作时间和工时不一致。

840 次浏览
project 敏捷转型行动笔记:价值流分析
project 敏捷转型行动笔记:价值流分析

价值流分析是敏捷转型前期非常重要的一环,也是最基础的一项必做工作。 关于价值流,百度百科中这样定义:价值流是指从原材料转变为成品、并给它赋予价值的全部活动,包括从供应商处购买的原材料到达企业,企业对其进行加工后转变为成品再交付客户的全过程,企业内以及企业与供应商、客户之间的信息沟通形成的信息流也是价值流的一部分。一个完整的价值流包括增值和非增值活动,如供应链成员间的沟通,物料的运输,生产计划的制定和安排以及从原材料到产品的物质转换过程等。在软件开发领域,价值流主要是指从需求获取开始一直到产品成功上线发布的活动。在精益产品开发中,价值流是价值项从左至右的流动过程,是信息的产出过程,也是价值增加的过程。 而价值流分析则是针对从左到右的端到端的过程进行各个环节的分析,从而找出浪费、发现瓶颈,并进行持续改善。那么,在敏捷转型的过程中,对于价值流分析我们应该如何做呢? 首先,建议采用看板方法,将软件开发过程中的各工作项等全部可视化出来。这里面可以借鉴《看板方法》、《看板实战》、《精益产品开发》等书中提到的有关可视化价值流动的相关方法。这个环节会用到看板搭建的一些方法,每一个团队可以结合实际开发流程,先绘制出最简单易懂的看板辅助开展价值流分析。 其次,要结合产品或项目目标、用户需求、交付要求等对各工作项进行价值分析。这里面要回归到用户需求/用户故事交付的本质上来,在需求、设计、开发、测试等环节也许会有很多的细分的工作任务,要理清楚这些任务的映射关系、依赖关系等等,同时标注每一个工作项的前置条件、优先级、拥有者、开始时间及预计完成时间等等。这个环节是价值流分析的核心环节,是后续能否真正发现问题及瓶颈并作出持续改进的先决条件,因此必须要让团队的全体成员参与,而且要将当前每个人手上的全部工作项都要可视化出来。在表现形式上,通常采用便利贴(预先定义好格式要求)等易于操作的方式罗列出来。 再次,要从价值流分析中找出问题和瓶颈。这里面要从价值交付的角度出发,从整体和局部等多角度审视各工作项的流动情况。从整体来看,主要关注需求、设计、开发、测试、发布等各个环节的工作项分布情况,是否会存在大面积阻塞的问题,或者虽然有很多工作项同时在进行,但在待发布或发布的需求很少,即在制品很多的情形,等等。之后是要标识阻塞的工作项,并分析为什么会阻塞,比如是否工作分配不合理,或者是需求拆解不合理,或者是任务要求不清晰,或者是团队技能跟不上,或者是团队工作不紧凑等等。并记录下这些问题可能存在的原因,深入分析,识别出主要问题和相应的瓶颈。 最后,要明确团队改进的方向。做价值流分析的最终目的是为了促进团队的持续改进并持续高质量地交付价值,这既是敏捷转型的重要基础,也是贯彻DevOps里面有关三步工作法中提到的有关持续学习与实验的思想。只有定下改进方向并确实行动起来,才能开启敏捷转型的大门。在我曾参与敏捷转型的一个团队中,也是充分使用了看板方法来进行价值流的分析。在当时,整个团队常常接收到客户投诉,问题处理缓慢,需求交付周期长。为了实施敏捷转型,在初期充分了解团队现状之后,组织团队进行了价值流分析,将各项需求、开发任务、问题处理、测试任务等等全部按照约定的规则通过看板进行可视化,之后分析出存在的瓶颈,比如由于系统为多年前老旧的单体架构很多问题改动起来非常困难,比如由于业务非常复杂每个人都只能掌握其中一部分,比如由于人员流动频繁团队中有不少新人,比如需求过于庞大导致开发工作量很大,比如只能依靠单纯的手工测试而无法推行自动化测试,比如必须要等所有需求都完成才发布导致发布周期很长,诸如此类的问题等等。在明确了这些瓶颈后,项目团队对各类问题及瓶颈进行了分门别类,并制定了改进计划。 通过价值流分析,可能让团队很好地认清现实、看清团队自身,从而更有利于做出改变。诚然,每一个团队的价值流分析模式可能不尽相同,但最终的目标都是一致的,那就是对软件开发的整个价值流进行统一管理,发现浪费,降低或去除没有价值的工作,减少不必要的活动,从而做到持续高质量地交付价值,提高竞争力。

442 次浏览
Project 任务名称自动缩进与取消缩进实现技巧
Project 任务名称自动缩进与取消缩进实现技巧

用Project软件排定计划时,通过对任务降级或者升级设置了任务的层级关系后,在【甘特图】视图的【名称】(就是任务名称)列中会看到名称会根据大纲级别自动缩进,如下图所示,这样的话任务的层级关系一目了然。也可以在【格式】菜单下勾选最右侧的【大纲数字】,让任务名称前自动显示大纲数字。 图1而有个别同学却发现,他的Project计划中虽然也设置了任务的层级关系,但是任务名称却没有自动缩进,而是统一靠左对齐的,如下图(图2)所示。 图2这是什么原因造成的,又该如何让任务名称按照大纲级别自动缩进呢?在Project 2010及之后的版本中,操作菜单及按钮中没有“名称缩进”这个选项,所以大家如果已经习惯了Project 2010 / 2013 / 2016以后,可能甚至不明白为什么会出现像图2的情况。在2010之前的版本中虽然也是默认名称自动缩进,但至少还能在软件的操作菜单及按钮中找到。所以,假如某位同学用Project 2007做了计划,又把【名称缩进】的默认勾选给去掉了,就会出现图2 的情形。假如你用Project 2010、2013、2016打开了这个计划,就会发现,可能任务名称就都是靠左对齐的,却又找不到设置自动缩进的按钮。怎么办呢?第1步:首先要打开Project选项的【快速访问工具栏】窗口。既可以点击【文件】-【选项】-【快速访问工具栏】,也可以在任何一个菜单比如【任务】或【资源】菜单下鼠标右键选择【自动以快速访问工具栏】。 

1084 次浏览
打开Project文件显示空白怎么办?
打开Project文件显示空白怎么办?

话说有一天,我打开一个Project文件,意外的是,文件打开以后居然是这样的... 图1这是什么情况?难道是文件损坏了?其实不一定。在【视图】菜单下最右侧,点击【全部重排】按钮,如下图所示。 图2这时候,计划就正常显示出来了,如下图所示。 

1635 次浏览
共计75934条记录 上一页 1.. 6631 6632 6633 6634 6635 6636 6637 ..7594 下一页