5549555_130213499130_2_副本.jpg

如今的时代，是举剑论英雄时代，讲究快，唯快不破。这是每个互联网创业者都经常挂在嘴上的话。确实，在目前的互联网行业背景下，风口稍纵即逝，而一个app，一个网站，是你冲锋陷阵第一件需要提前完成的事。精益创业越来越深入人心，大家都推崇轻方式验证需求，快速迭代。


但是，大多数项目在启动时，产品所需的资源往往不如人意。在有限的时间、资源下，如何快速的完成从0到1（当然，这个1是项目，非整个事业部）。今天来与大家分享下我的笔记。以下scrum master与产品负责人的分工不做细分。


当项目启动之前，产品第一件大事——需求。首先，需要了解项目的用户群体，更精准地说是种子用户群体，了解项目正在解决什么问题，这个问题原先是如何解决的。（关于需求调研在这里就不一一细说了）。接下来需要先大致了解一下项目的商业画布，即，该项目的重要伙伴、关键活动、核心资源、价值主张、客户关系、渠道通道、客户细分、成本结构、收入来源等等。在对大局范围上对项目有个整体的认识，有助于我们了解整个项目的合理性，强弱点，攻防。

快速出可视化demo

核心需求确定，思维导图整理出项目的核心功能点，输出简单的可视化demo，对项目有个整体的规划。这件事为何重要，第一你可以对项目组有个整体的反馈，使其能够在较具像化地去了解项目，确定并去摸索匹配接下来的资源；第二，团队成员能够知道你这个项目的大致思考。我觉得，一个能打战的团队，每一个成员都不是简单地执行需求，而是了解并理解这个功能的意义，并一致认为这是从需求、交互、技术的角度，最好的表现方式；第三，有助于你整理出product backlog，对项目有个整体的排期。

项目Kickoff会议的很重要

确定了需求，下一步肯定是大家撩起手腕，开工了。在这之前，我觉得一个正式的项目Kickoff会议很重要。这个会议不需要很长的时间，项目的负责人需要与大家交代好项目的远景，以及Sprint 目标。这个会议不止是打鸡血，而是从这个会议中，团队成员可以知道自己做这件事的意义，解决了什么问题，已经明确了的Sprint 目标。在接下来较高强度的工作中，让大家明白价值，至关重要。


1.0版本计划再细分v1、v2、v3，需求文档分版本输出

在项目的从0到1中，有限的时间，产品与团队成员不得不面对的一件大事——需求变更。这件事似乎在所难免却极其内耗，而且极其容易造成矛盾。但是，还是可以用方式，去把这份风险降到最小。项目初始，项目的简单demo有助于你可以把版本按版本计划的规划，把需求文档细分为v1、2、3、4来做输出，这样子可以让这件事更专注，你可以把一个细分的功能点思考清楚。而团队成员在demo的整体帮助下，可以在专注于细分的版本需求，同时宏观了解项目。


避免漫长的需求评审会议，做到快速需求评审

可能初始团队原来就有个打磨时间，即配合可能不会很默契。不知大家是否有这样的场景，两个人在一起讨论个需求或设计，慢慢的3、4、5，一群人凑在一起去讨论一个细节的交互问题，并互相撕逼，拉一会议为这一需求讨论1个小时时间。当然一个优秀的团队才会去撕逼一个细节问题，是追求完美的表现。但是，再从0到1的过程中，要尽量避免这种问题。我始终坚持一个原则，一个刚需的产品，用户不会因为你的产品有交互上的瑕疵而不使用你的产品；一个产品如果价值性不高，或者瞄准的用户群体不够精准，我相信用户也不会因为你的产品有一个好的交互就去长期使用你的产品。那么，在需求会议上，一个功能最重要的是让你的团队成员，包括开发，ui，测试，了解你这个功能的意义，去解决一个什么样的问题，逻辑上是否是最优解，从而团队对功能意义优深刻的认识，并统一这种功能逻辑解决方案从技术的角度也是最优解即可。在细节的交互上，要快速做决策，快速形成文档。从能用，到好用，最后到用得爽，快速迭代。


懂得取舍，要懂的坚决地砍需求

在初始项目的开发过程中，即使前期定了比较周全的版本计划，但是还是会出现半路杀出个鲁智深的情况，比方说运营部门在资源准备中，可能杀出了个功能极其重要。然而发版时间已定，开发的资源是有限的。这时候，应该做的就是评估在初始运营过程中功能的性价比，并坚决地砍需求。当然，评估需求的重要性也不是单纯地以性价比来评估。比如说，有一两个功能实用性比较小，但是很好玩，正常来说这种功能在新项目中是优先级排低的。但是，当换一个场景，你CEO将为这个项目开发布会，那你需要设身处地为CEO着想了，想着当他上台的时候，这个功能虽然小，但是讲起来就有东西讲了，毕竟现在发布会也是个讲故事吹逼的时代了。


提高项目showcase的频率，把控好风险

在高强度的项目开发中，如何把控好团队成员的情绪是一比较大的难题。特别是在资源有限，时间短的背景下，一两个人的情绪，可能会比较大地左右项目的进展。那么，把控项目风险为比较重要的问题了。有几个小方法可以作为风控的方式吧。1、提高项目进展showcase的频率（自尊心），毕竟整个团队走在一起，好比说互相都在看着对方做的东西，会对开发的小伙伴有个无形的团队压力；2、让进展快的小伙伴做先锋车，配合尽量优先处理（好胜心），当开发团队中有一小伙伴速度快出半拍时，可能会对其他同学形成无形的映射，毕竟谁都想自己的技术很牛逼的；3、多请团队喝咖啡吧（提提神），当然，请客是相处之道，没什么特别的意思。但是，如果要请的话，就选择咖啡吧。哈~


此文从0到1指的是产品，而非项目。项目的从0到1相信还需要进过运营推广，市场验证，并迅速调整方向和角度，从而，形成自己的市场份额。简单说，带队打怪兽，产品1.0的完成好比你打造了一把武器，但是怪兽没拿下，那就没算完成。

喜欢就会放肆，爱就要克制，在产品的迭代中也是如此。但项目发布上线时，可能会有其他小伙伴怀疑产品部门，这个功能怎么没呀，这软件很不完善啊。其实产品人对功能也会有很多的想象力，巴不得马上将其全部实现。但是如果是爱，应该是对整个项目的健康发展的想象，如同一颗大树，有根，有杆，有叶，慢慢张开，而非想哪是哪。

如果有不同的想法或意见交流，欢迎关注

微信公众号：pmbelief

本文由PMCAFF产品经理社区作者 @Jason+Liao原创，未经允许，禁止转载。