用户名*
邮箱*
密码*
确认密码*
验证码* 点击图片更换验证码
找回密码
忘记密码了？输入你的注册邮箱，并点击重置，稍后，你将会收到一封密码重置邮件。
来自leader的声音最好统一
1.前面两位的答案是错的。恰恰是流程不明确的公司，才会需要浪费时间开会找背锅人。
2.流程是死的，人是活的这句话也是错的。流程是由人执行的，只要人是活的，流程也必然是活的。这句话的本意是给不愿意遵守流程而又无法恰当的说明理由时用的借口。
3.你的流程图问题不大， 但是这假定于每一步的工作都是能完成的，不过有总比没有好。
4.流程的本意是：清晰的表明如何产生需求，如何完成需求到产品的转换，如何进行控制。
5.流程设计的理论是：从实际已经成功的工作中提炼流程，这就是经验的传承。再根据有用添加，有错就改的原则完善流程。
很简单，小公司玩不起流程
直接拉主要人员，设计程序等直接开会，简单粗暴，CEO表让他参加。你只主持，别发表观点，因为专业肯定没他们懂，主要负责听记录就OK。最后全体决定是否有必要通过CEO审批
还有，要勇于去扛锅
问题的关键在于高效，所以我推荐提问者可以关注一下【敏捷交付】或者【精益开发】。这里是两套理论，但都有助于高效开发。
在我的理解里，敏捷交付的精髓是保持沟通，从产品立项的目标到每日15分钟例会到每次迭代的总结，产品经理和设计师和开发人员和利益相关者之间都要有充分沟通，保证目标行动一致，才能保证开发按照计划进行，按时交货。
而精益开发的精髓则在于，小步快跑。不要等所有功能都开发出来了再投入市场试探，拆分成合理的小版本，快速接触市场和用户声音，减少不必要的时间和成本浪费。这也是高效的一种体现，但它偏向于产品设计的思想，所以在产品开发流程这个问题上我不多赘述。
———————————————————正文分割线———————————————————
下面结合【敏捷交付】来详细说一说我曾经呆过的创业团队中是怎么管理产品开发的。
现在很多大大小小的公司都开始使用敏捷开发这一套理论，有的公司严格执行，有的公司只抽取部分的规则来遵守。不能说那个更好那个不好，因为一切都以自身适合才是最重要的。敏捷交付的最灵魂思想就是“敏捷”二字，也即【灵活】。
能当面交流的就不要发邮件，能当天交代的就不要等下周一。一句话能说明的就不要死板地套用说明文档的模板，一张图能表达的逻辑也不要用一堆文字去表述。整个开发管理的过程相对灵活，不需要死板地按部就班，是高效的关键。很多时候，人为了高效而创造流水线和流水线中的规定，但长久以后，我们反而会被这种固话的东西拖慢进度。
敏捷交付的四个中心原则都是围绕“灵活”两个字，读者可以细细体会。
另外想补充的一点就是，保证所有人都理解、所有人都目标一致是沟通中的关键所在。就好像大家明明都在谈节约成本，一个人在讨论时间成本，一个人在说资金成本，他们永远都无法达成共识的。其实，他们要谈的不是节约某个成本，而是找到一个解决方法可以令这两个成本之和最小。所以，首先要先确定维度相同，然后再确定目标相同，才能共同讨论，得出一个大家都认同的解决方案。这样的沟通才是高效的，而且保证所有人都理解正确，执行时才不会有偏差。
————————————————————总结————————————————————
我在最开始的那个创业团队中，大家使用的是非常落后的瀑布式产品开发管理模式，一切都必须按步骤完成才能进入下一个环节。于是效率非常之慢，甚至，我们实施了996的工作制，看上去好像更卖力了，结果反而是产品没有按时上线，还出现重大失误。
后来，我们引进了敏捷交付的一套方法和思想，我们在需求过程中就确定好所有功能点的开发优先级；在产品未完成UI设计的时候，技术人员可以先开始做基础的技术开发工作；在一个功能完成进行测试的时候，技术团队先进入下一个功能的集中开发。我们把原来996的节奏，成功变回了965，变成一个不用加班还准时上线的团队。当时大家都好喜欢这样的工作状态，积极性也更高。
现在讲最球里最先进的敏捷交付的方法论有一本392页的书，叫《规范敏捷交付》，有中文版的。我个人啃了一半多，还没啃完。但其实我想说的是，它里面的具体方法论都不是最重要的。一个灵魂思想和四个中心原则能够领会透彻，一切都会不一样。
所以，我没有把我们当时整理出来的那套属于我们团队的开发流程图放上来。因为每个团队每个公司的情况都不一样，我觉得好的流程别人不一定适用。如果提问者真的想要提高自己产品的开发流程效率，我觉得不妨重新回顾你们已有的开发流程，把每一个小步骤都仔细想一遍，它是否可以有被删除或被简化的可能性。
我觉得小公司和大公司的区别里，就有流程的区别吧，这个也是小公司能活下去的动力，说白了，没流程，流程小而短暂，好调头，大公司，船大舵大，能开稳都很不容易了。
还有，你这样设计，是基于什么去设计的？？你要明白的是，你设计的这个要适用于整个公司的所有部门（如果是一整套产品的流程）因为，感觉你这个设计，只是满足了产品组的需求，程序组，UI组，测试组，运营组的需求喃？你要考虑全。
小公司最有效率的方法，就是没流程
给开发团队找个有经验的Leader，此Leader自己管开发+管项目，boss输出deadline
用结果考核团队。最多增加一个助理，负责整理资料
流程是大公司玩的东西，是为了分摊责任，出了问题好找背锅人
昵称*
E-Mail*
回复内容*
回复 ( 6 )
来自leader的声音最好统一
1.前面两位的答案是错的。恰恰是流程不明确的公司，才会需要浪费时间开会找背锅人。
2.流程是死的，人是活的这句话也是错的。流程是由人执行的，只要人是活的，流程也必然是活的。这句话的本意是给不愿意遵守流程而又无法恰当的说明理由时用的借口。
3.你的流程图问题不大， 但是这假定于每一步的工作都是能完成的，不过有总比没有好。
4.流程的本意是：清晰的表明如何产生需求，如何完成需求到产品的转换，如何进行控制。
5.流程设计的理论是：从实际已经成功的工作中提炼流程，这就是经验的传承。再根据有用添加，有错就改的原则完善流程。
很简单，小公司玩不起流程
直接拉主要人员，设计程序等直接开会，简单粗暴，CEO表让他参加。你只主持，别发表观点，因为专业肯定没他们懂，主要负责听记录就OK。最后全体决定是否有必要通过CEO审批
还有，要勇于去扛锅
问题的关键在于高效，所以我推荐提问者可以关注一下【敏捷交付】或者【精益开发】。这里是两套理论，但都有助于高效开发。
在我的理解里，敏捷交付的精髓是保持沟通，从产品立项的目标到每日15分钟例会到每次迭代的总结，产品经理和设计师和开发人员和利益相关者之间都要有充分沟通，保证目标行动一致，才能保证开发按照计划进行，按时交货。
而精益开发的精髓则在于，小步快跑。不要等所有功能都开发出来了再投入市场试探，拆分成合理的小版本，快速接触市场和用户声音，减少不必要的时间和成本浪费。这也是高效的一种体现，但它偏向于产品设计的思想，所以在产品开发流程这个问题上我不多赘述。
———————————————————正文分割线———————————————————
下面结合【敏捷交付】来详细说一说我曾经呆过的创业团队中是怎么管理产品开发的。
现在很多大大小小的公司都开始使用敏捷开发这一套理论，有的公司严格执行，有的公司只抽取部分的规则来遵守。不能说那个更好那个不好，因为一切都以自身适合才是最重要的。敏捷交付的最灵魂思想就是“敏捷”二字，也即【灵活】。
能当面交流的就不要发邮件，能当天交代的就不要等下周一。一句话能说明的就不要死板地套用说明文档的模板，一张图能表达的逻辑也不要用一堆文字去表述。整个开发管理的过程相对灵活，不需要死板地按部就班，是高效的关键。很多时候，人为了高效而创造流水线和流水线中的规定，但长久以后，我们反而会被这种固话的东西拖慢进度。
敏捷交付的四个中心原则都是围绕“灵活”两个字，读者可以细细体会。
另外想补充的一点就是，保证所有人都理解、所有人都目标一致是沟通中的关键所在。就好像大家明明都在谈节约成本，一个人在讨论时间成本，一个人在说资金成本，他们永远都无法达成共识的。其实，他们要谈的不是节约某个成本，而是找到一个解决方法可以令这两个成本之和最小。所以，首先要先确定维度相同，然后再确定目标相同，才能共同讨论，得出一个大家都认同的解决方案。这样的沟通才是高效的，而且保证所有人都理解正确，执行时才不会有偏差。
————————————————————总结————————————————————
我在最开始的那个创业团队中，大家使用的是非常落后的瀑布式产品开发管理模式，一切都必须按步骤完成才能进入下一个环节。于是效率非常之慢，甚至，我们实施了996的工作制，看上去好像更卖力了，结果反而是产品没有按时上线，还出现重大失误。
后来，我们引进了敏捷交付的一套方法和思想，我们在需求过程中就确定好所有功能点的开发优先级；在产品未完成UI设计的时候，技术人员可以先开始做基础的技术开发工作；在一个功能完成进行测试的时候，技术团队先进入下一个功能的集中开发。我们把原来996的节奏，成功变回了965，变成一个不用加班还准时上线的团队。当时大家都好喜欢这样的工作状态，积极性也更高。
现在讲最球里最先进的敏捷交付的方法论有一本392页的书，叫《规范敏捷交付》，有中文版的。我个人啃了一半多，还没啃完。但其实我想说的是，它里面的具体方法论都不是最重要的。一个灵魂思想和四个中心原则能够领会透彻，一切都会不一样。
所以，我没有把我们当时整理出来的那套属于我们团队的开发流程图放上来。因为每个团队每个公司的情况都不一样，我觉得好的流程别人不一定适用。如果提问者真的想要提高自己产品的开发流程效率，我觉得不妨重新回顾你们已有的开发流程，把每一个小步骤都仔细想一遍，它是否可以有被删除或被简化的可能性。
我觉得小公司和大公司的区别里，就有流程的区别吧，这个也是小公司能活下去的动力，说白了，没流程，流程小而短暂，好调头，大公司，船大舵大，能开稳都很不容易了。
还有，你这样设计，是基于什么去设计的？？你要明白的是，你设计的这个要适用于整个公司的所有部门（如果是一整套产品的流程）因为，感觉你这个设计，只是满足了产品组的需求，程序组，UI组，测试组，运营组的需求喃？你要考虑全。
小公司最有效率的方法，就是没流程
给开发团队找个有经验的Leader，此Leader自己管开发+管项目，boss输出deadline
用结果考核团队。最多增加一个助理，负责整理资料
流程是大公司玩的东西，是为了分摊责任，出了问题好找背锅人