世纪金融网
我花了很多时间思考Brainscape的长期产品愿景。有时，我会一直睡到凌晨，可视化一些新的功能套件，这些功能套件是如此先进，以至于我们可能要花整整一年甚至两年的时间才能开发它。
我对这些愿景的热情常常如此之高，以至于我很想起草线框，在第二天早上召开设计会议，并介绍我的新模型作为我们产品架构的潜在未来。
但后来我突然振作起来。你看，你的工程团队的规模和你应该预先规划产品长期发展的细节水平之间有一个微妙的平衡。
走中间路。
如果你的计划对于你的团队规模来说太详细了，那你就是在浪费每个人的时间，因为当你真正准备好实施计划时，计划无疑会改变。如果他们不够详细，你的团队将缺乏凝聚力的愿景，作为领导者，你将显得软弱。
当你的早期团队只有一名工程师时，他或她可能不应该在一到两周后创建任何详细的低级计划，因为事情变化如此频繁。而且，应仅将较长期的任务预测到预测基本开发时间框架或潜在冲突所需的最低细节水平。
因此，一个由一个人 (或女人) 组成的开发团队应该有一个相当模糊的长期产品路线图。同时，开发人员应该专注于基于精益启动原则的最小可行产品。简而言之: 在早期阶段，你需要爱上问题，而不是解决方案。
当然，即使是最早阶段的团队canand也应该拥有比一周远得多的产品愿景! 毕竟，您正在推销一种将 “改变世界” 的产品，对吗？但是随着产品范围的延长，这些愿景应该以逐渐降低的细节水平来表达。
理想情况下，最直接的短期细节应根据数据每周冲洗一次: 顾客在说什么？在可用性测试中，您从调查对象中学到了什么？你从你的网络/移动分析中学到了什么？你从你的顾问那里得到了什么伟大的新建议？
还有什么新的工程挑战出现了，你没想到呢？所有这些事情都可以并且应该使您根据需要不断调整短期和长期计划。
以下是根据团队规模为产品路线图计划的详细程度的粗略指南。当然，真正的最佳数字可能略有不同，但你会明白:
一些快速定义可能有用:
详细任务-低级项目管理电子表格，其中概述了具体任务，并详细解释了这些任务，并分配给了团队中的工程师。理想情况下，至少每周 (或在某些情况下，每天) 都可以编写或重新访问此列表。线框/规范-这是每个即将到来的屏幕/功能的外观和工作方式的总体图片。该规范是在由领先的UX设计师领导的设计会议中理想地开发的，该设计会议具有品牌一致性的愿景，并且应包含来自关键用户和利益相关者的反馈。提前开发这些详细的线框是没有意义的，由于功能规范可能会在临时更改。Rough backlog-这是共享的愿望清单，您可以在其中记录团队成员或用户建议的每个潜在功能或计划的日志-作为每个项目的简单行项。每当有远见的产品 (理想情况下是首席执行官) 准备好决定首席用户体验设计师下一步应该设计的功能时，他或她应该检查技术背景，并根据对收入、转换或用户体验的预期影响选择优先级最高的功能。对于每月/每季度的战略性会议来说，这些决定通常是一个很好的话题。显然，每个细节级别的具体截止点取决于与您的团队和产品相关的许多因素。这些指导方针的关键在于，您的产品计划的必要级别随着团队规模和产品复杂性的增长而增长。
如果你是Facebook，微软件NASA (拥有庞大的工程团队和数十亿美元)，你提前几年就有了toplan你的下一个大型功能，而你的功能积压范围可能会达到半个世纪。
但是，如果您是车库里的两个人，则需要将详细计划限制为灵活的每周里程碑，否则其他竞争对手将更好地实施您的概念并更快地实施。
