创业公司压缩流程成本的一些项目经验_话题_圈子与群组

项目管理者联盟 | 中国工程管理网 | 中国研发管理网

会员中心

资料库

适合敏捷开发项目
敏捷项目管理最佳实践

重视项目商业分析
商业价值与需求分析能力

产品管理国际认证
全球产品管理最佳实践

单项目管理经典指南
年轻项目经理首选

北京 | 直播 | 录播

大型复杂项目全球标准
定位高级项目管理层

链接战略与项目
实现组织资源投资回报

信息系统项目管理师
系统集成项目管理工程师

计划 | 报名 | 经验

圈子
	志同道合，朋友再聚首

会员· 圈友

圈子信息

圈名：国内项目管理探索
加入方式： 允许任何人加入

国内项目管理探索本圈子是方便大家就国内的项目管理自主之路的探索，建立一套我们的标准。

圈主：onroading 管理员：暂无管理员
成员数：30	主题数：1701	排名：8

	通讯录
	圈友列表
	加入本圈
	管理本圈

发表话题 | 发起投票 | 上传资料

话题区

投票区

资料区

精华区

标题：创业公司压缩流程成本的一些项目经验楼主
铁托 PMB：19794 省份：安徽省行业：综合应用注册：2006/4/30	我曾提到蝉小队在压缩流程成本上，还是比较有成效的。这部分可以讲一讲，或许对别人有点帮助。　　关于立项　　到目前为止，虽然我们只做了一个蝉游记，其实还做了另外四款App的设计，只是没时间研发，先搁着。　　立项的过程是这样的，通常由我先提一个想法，跟大家聊聊;如果没遇到强烈反对，再跟几个亲朋好友聊聊。我心里有点底的时候，一边看同类产品一边出Axure原型——这很快，不会超过两天。但也有可能在过程中发现想法不靠谱，便放弃了。　　低保真原型画出来之后，蝉小队会挤成一坨，听我讲解，提提意见。如果没遇到强烈反对，就请UI设计师抽空出PSD，通常只出主页面，次要的小页面都不用管。　　然后我把视觉稿拷到手机里，遇到熟人就掏出来给他看看，听听外人怎么评价。　　对于新项目，我会倾向于设计好了之后“放一段时间”，而不是立刻上马。当然，也是我们没时间立刻投入研发。放一放会让想法渐渐成熟，也从外人那里得到更多反馈来改进设计。一款App在开始编码之前，可能已经大改过几次原型，修正了不少细节。　　蝉游记采用同样的处理方式，经常把排期在半年后的模块先设计出来，放半年，反复改。这样可以抵消一部分快速设计带来的冒失。对着一套成型的东西，才会有更细致的思考。想法需要快速转化成有说服力的原型，否则单凭拍脑袋拍出来的点子，没资格讨论做不做，上不上。　　关于一个完整的版本流程　　蝉游记的一个正常App版本迭代，通常用3-5周的时间。　　版本计划里的小功能点由我直接定，大功能点要提前征询工程师的意见，走一遍原型评审。说是评审，其实是大家挤成一坨，听我讲解原型。讲完了没人反对，我便在 Tower上把视觉任务排好日程，跟UI设计师确认好时间，设计师按着白纸黑字的排期出PSD(Tower真协作神器也)。　　在新版本研发开动之前，我会准备好全部的PSD，版本计划在Tower上用蓝色标签标识出来。事先跟工程师约定好大概用几周时间，每研发完一个功能点，就在Tower勾掉，每天看Tower知进度，晨会都不用开。　　如果按4周的版本迭代来计算，最初2周我在作下一个版本准备，从第3周开始，我介入测试，对着Tower上勾掉的蓝色标签一条条测，再把调试需求用红色标签记录下来。第3周会完成功能研发，预留1周半时间调试。新版本需求全部搞掂后，我用一整天的时间全面回归测试一轮，蝉小队接着全员测试一轮，通过之后提交。提交之后工程师到我旁边来，这时蓝色标签已经整理好了，对着Tower听我讲下一个版本计划。　　善用tower.im，可以让项目有条不紊，清晰透明地推进。　　关于文档　　我有个观点，大公司里完备的产品文档其实没几个人看，主要是用于扯皮。“我在文档里写得很清楚，是你没有实现!”“你的需求和文档不一致，工期必须延后!” 　　蝉小队组建初期，还用DOC来记录需求，后来熟了，默契了，就大力简化流程。UI设计师对着低保真Axure原型出PSD，工程师则对着PSD编码。交互效果主要靠口头交流，简单的功能算法也口头交流，复杂的就作为一则功能点，在Tower上单列出来详细备注。　　当然，这是特别默契的做法。　　还在磨合期的时候，我会出一份更完整的草图原型，把交互效果，功能算法，设计思路都标注在上面，方便工程师建立对产品的整体印象。但我是懒得做原型动态效果的，标注全用文字，像黄色便签纸一样贴在草图旁边，佐以口头讲解。再后来，工程师对产品设计滚瓜烂熟了，就甩开原型直接看更直观的PSD，对应Tower 上的功能点，一看就明白。　　这样做的坏处是，缺乏完整的产品记录，一旦忘了什么立马傻眼。且慢……我还有一份特别详细的测试用例，单单App就列举了接近500个细碎的测试点。虽然它是用mindmanager写的，可读性特别差，绝逼只有我自己能看懂，但涵盖了绝大部分的功能点。当产品进入稳定期，正规期之后，对照着测试用例，很容易能整理出规范的产品文档来。在那之前，由于需求多变，在测试用例上直接修订会便捷得多。　　关于tower.im 　　写到后面，我发现这篇文章基本上变成Tower的广告贴了。没错，我就是Tower的脑残粉。有人说它复制了那谁谁，然后我就得忍受极慢速度与英文界面去使用原版，以彰显我的道德优越感?别扯了。　　用Tower有这么几个好处。第一是条理性特别强，任务被一条条分解出来，对应人头，对应日期，十分的清晰。　　第二是弹性特别好，配合分项目、分组与标签，可以记录版本需求、调试意见、疑难问题、视觉排期、运营计划，不论啥玩意儿都可以装进去。　　第三是进展特别透明，谁分配了多少任务，完成度如何，所有人都看得到。　　适应Tower一段时间之后，每个人每天shua一下Tower，既知道自己做什么，也知道别人做什么。既能接受我安排的任务，也可以自己给自己下任务。因为所有的工作安排都平铺在上面，都有着明确的截止时间，很容易制定出合理的时间计划来。　　但适应Tower有一个前提，你本身就得是一个很有条理性的人。Tower并不会改变你的工作方式，而是让你原有的工作条理变得更清晰，更透明，更有效率。如果你很少1、2、3地给自己下任务，给别人下任务，很少将任务分解成细颗粒度，也很少进行严格的时间规划，那是玩不转Tower的。而且我也不认为那样的人有提升效率的意愿和能力。　　最后，请彩程设计的老沈将5毛钱汇入我的支fu宝账户。
	回复 \| 引用发表时间：2014/11/22 15:46:29

！您尚未登录，不能回复主题。现在登录注册

建设运营：共创时网络

标题：创业公司压缩流程成本的一些项目经验楼主
铁托 PMB：19794 省份：安徽省行业：综合应用注册：2006/4/30	我曾提到蝉小队在压缩流程成本上，还是比较有成效的。这部分可以讲一讲，或许对别人有点帮助。　　关于立项　　到目前为止，虽然我们只做了一个蝉游记，其实还做了另外四款App的设计，只是没时间研发，先搁着。　　立项的过程是这样的，通常由我先提一个想法，跟大家聊聊;如果没遇到强烈反对，再跟几个亲朋好友聊聊。我心里有点底的时候，一边看同类产品一边出Axure原型——这很快，不会超过两天。但也有可能在过程中发现想法不靠谱，便放弃了。　　低保真原型画出来之后，蝉小队会挤成一坨，听我讲解，提提意见。如果没遇到强烈反对，就请UI设计师抽空出PSD，通常只出主页面，次要的小页面都不用管。　　然后我把视觉稿拷到手机里，遇到熟人就掏出来给他看看，听听外人怎么评价。　　对于新项目，我会倾向于设计好了之后“放一段时间”，而不是立刻上马。当然，也是我们没时间立刻投入研发。放一放会让想法渐渐成熟，也从外人那里得到更多反馈来改进设计。一款App在开始编码之前，可能已经大改过几次原型，修正了不少细节。　　蝉游记采用同样的处理方式，经常把排期在半年后的模块先设计出来，放半年，反复改。这样可以抵消一部分快速设计带来的冒失。对着一套成型的东西，才会有更细致的思考。想法需要快速转化成有说服力的原型，否则单凭拍脑袋拍出来的点子，没资格讨论做不做，上不上。　　关于一个完整的版本流程　　蝉游记的一个正常App版本迭代，通常用3-5周的时间。　　版本计划里的小功能点由我直接定，大功能点要提前征询工程师的意见，走一遍原型评审。说是评审，其实是大家挤成一坨，听我讲解原型。讲完了没人反对，我便在 Tower上把视觉任务排好日程，跟UI设计师确认好时间，设计师按着白纸黑字的排期出PSD(Tower真协作神器也)。　　在新版本研发开动之前，我会准备好全部的PSD，版本计划在Tower上用蓝色标签标识出来。事先跟工程师约定好大概用几周时间，每研发完一个功能点，就在Tower勾掉，每天看Tower知进度，晨会都不用开。　　如果按4周的版本迭代来计算，最初2周我在作下一个版本准备，从第3周开始，我介入测试，对着Tower上勾掉的蓝色标签一条条测，再把调试需求用红色标签记录下来。第3周会完成功能研发，预留1周半时间调试。新版本需求全部搞掂后，我用一整天的时间全面回归测试一轮，蝉小队接着全员测试一轮，通过之后提交。提交之后工程师到我旁边来，这时蓝色标签已经整理好了，对着Tower听我讲下一个版本计划。　　善用tower.im，可以让项目有条不紊，清晰透明地推进。　　关于文档　　我有个观点，大公司里完备的产品文档其实没几个人看，主要是用于扯皮。“我在文档里写得很清楚，是你没有实现!”“你的需求和文档不一致，工期必须延后!” 　　蝉小队组建初期，还用DOC来记录需求，后来熟了，默契了，就大力简化流程。UI设计师对着低保真Axure原型出PSD，工程师则对着PSD编码。交互效果主要靠口头交流，简单的功能算法也口头交流，复杂的就作为一则功能点，在Tower上单列出来详细备注。　　当然，这是特别默契的做法。　　还在磨合期的时候，我会出一份更完整的草图原型，把交互效果，功能算法，设计思路都标注在上面，方便工程师建立对产品的整体印象。但我是懒得做原型动态效果的，标注全用文字，像黄色便签纸一样贴在草图旁边，佐以口头讲解。再后来，工程师对产品设计滚瓜烂熟了，就甩开原型直接看更直观的PSD，对应Tower 上的功能点，一看就明白。　　这样做的坏处是，缺乏完整的产品记录，一旦忘了什么立马傻眼。且慢……我还有一份特别详细的测试用例，单单App就列举了接近500个细碎的测试点。虽然它是用mindmanager写的，可读性特别差，绝逼只有我自己能看懂，但涵盖了绝大部分的功能点。当产品进入稳定期，正规期之后，对照着测试用例，很容易能整理出规范的产品文档来。在那之前，由于需求多变，在测试用例上直接修订会便捷得多。　　关于tower.im 　　写到后面，我发现这篇文章基本上变成Tower的广告贴了。没错，我就是Tower的脑残粉。有人说它复制了那谁谁，然后我就得忍受极慢速度与英文界面去使用原版，以彰显我的道德优越感?别扯了。　　用Tower有这么几个好处。第一是条理性特别强，任务被一条条分解出来，对应人头，对应日期，十分的清晰。　　第二是弹性特别好，配合分项目、分组与标签，可以记录版本需求、调试意见、疑难问题、视觉排期、运营计划，不论啥玩意儿都可以装进去。　　第三是进展特别透明，谁分配了多少任务，完成度如何，所有人都看得到。　　适应Tower一段时间之后，每个人每天shua一下Tower，既知道自己做什么，也知道别人做什么。既能接受我安排的任务，也可以自己给自己下任务。因为所有的工作安排都平铺在上面，都有着明确的截止时间，很容易制定出合理的时间计划来。　　但适应Tower有一个前提，你本身就得是一个很有条理性的人。Tower并不会改变你的工作方式，而是让你原有的工作条理变得更清晰，更透明，更有效率。如果你很少1、2、3地给自己下任务，给别人下任务，很少将任务分解成细颗粒度，也很少进行严格的时间规划，那是玩不转Tower的。而且我也不认为那样的人有提升效率的意愿和能力。　　最后，请彩程设计的老沈将5毛钱汇入我的支fu宝账户。
	回复 \| 引用发表时间：2014/11/22 15:46:29