一半技术，一半产品

不会写代码的设计师不是好产品经理！

写在前面

忙！忙！忙！基本上可以概括我这半年多的生活。年初加入目前所在的创业公司（移动医疗），作为最早加入的几个人之一，经历了一个初创公司从无到有的过程，半年的时间，仿佛过了一两年，从最初的业务讨论、产品雏形、技术选型到迭代开发、业务转型、团队扩张等等，都一幕幕亲身经历着，这种历练或许就是在大公司感受不到的。在创业公司能感受到组织的成长，能把握自己做事的节奏，带来的成就感也许正是创业公司的魅力，这也是当初我选择加入创业公司的理由。创业，是一场修行，是一段非常有意思的旅途，成长着、学习着、感悟着！

一半技术

一半技术，这是对我现阶段工作的描述。回到两个月之前，我还在每日coding，白天讨论产品，晚上直接写代码实现，那是一段煎熬并快乐的日子。一转眼，进入移动开发领域也3年多了，从最初的Android到后来的iOS，期间也是一半Android一半iOS。不能说精，至少这3年的打磨让我对这两个平台有了一个基本的认识，从2012年开始写博客，原本只是记录下自己的学习笔记，没想到无意之举竟然得到了很多朋友的关注，博客的访问量不断增多，昨天一看，CSDN的博客访问量竟然快一百万了，这是我之前绝对不曾想过的。通过写博客，提高了自己的思维表达能力和总结能力，对一些技术点的理解也越发深刻，同时，还结交了一批志同道合的朋友，这些收获是通过技术获得的。我喜欢写代码，我喜欢通过一行行的代码去创造一个产品，我喜欢研究技术点，弄懂一个问题带来的那种感觉是无与伦比的。技术的美妙就在于永远都有问题在等着你，而且那种未知性恰恰是最有意思的地方。我是那种写代码有洁癖的人，每个命名，每个换行，每个空格都很在乎，我也觉得理应如此，不说写的最好，至少让团队里其他人看起来不费劲，对自己负责，也对别人负责。

做技术的，有两种人，一种是在一个领域做深做透的人，另一种是技能全而广的人，两种选择，各有利弊，因人而异。如果让我选，我还是比较倾向于前一种（如果可以的话），因为这样能让我更专注。我也很佩服后一种人，因为他们能融会贯通。做技术的，思维一般比较严谨，或者叫工程师思维，逻辑严丝合缝，想问题总是有很多切入点，这是工程师优势。

在创业公司做技术

毕业找工作时也有几个大公司可选，但后来还是选择了创业公司。在创业公司做技术，我的感觉就是，“全靠你了”，这种感觉起初就是孤军作战，在创业公司，一个技术领域至少要有一个能hold住事的人，有问题，要解决，有难点，要攻破，要不，找谁去呢！所以，在创业公司做事，对技术的成长是一个极好的锻炼机会，因为这要求你必须不断突破自己，找方法提高自己。我们公司起初的技术团队就那么几个人，一切从零开始，不断摸索、不断调整、不断适应，这其中的坑只有自己走过才知道。团队总要扩大，我们招人有三个原则，第一，必须自身认可并感兴趣我们所做的事情，而不是单纯为了找个工作拿工资或找个地方写代码，这对创业公司尤其重要，创业公司初始阶段寻找的更多的是志同道合的合作伙伴而非员工。第二，明确知道我们目前缺乏什么样的人才，对方加入我们后是否能立马帮助到我们，这是匹配度的要求，能让加入者快速切入我们的工作，产生共鸣、产生成就感。第三，新加入的伙伴要融入我们的团队，适应我们的文化，不会对团队氛围造成影响。考虑团队的延续性，大家得是齐心的，这样才能一起打好仗、做好事、分好钱。

技术管理，是让团队能力不断提升，组织不断发展的手段。在研发流程上，我们使用的是敏捷开发，即scrum流程，我们尝试过很多方法，最终形成了一套适合我们团队自身的研发方法。和很多公司一样，我们也有自己的早会，但这个会时间一般很短，我们会要求所有人站着开会，之前我们的方法是要求每个人说明三个问题，也就是昨天完成了什么，今天计划做什么，有没有什么问题，这种方式我们持续了大概三四个月，起初人少的时候还好，基本上信息沟通都比较及时，后来人多了，这样效率就下去了，就会出现谁也没听谁说什么，造成了早会流于形式，所以，这种形式的会议要控制人数，理论上超过五个人的话这种形式的会议效率就很低了。

后来，我们人数增加到10人，早会就需要换一种方式了，我们采取的是任务需求驱动的早会，我们使用github issue来管理需求，每周一个sprint，每个sprint会把当周需要完成的任务通过issue的方式记录下来，通过label和comments来管理进度。每天早上由产品需求负责人来drive早会，从整个任务需求的角度来审视前一天的进度以及遇到的问题，大家实现信息共享后即结束会议，这个会上我们只抛出问题，并不讨论问题，所有的问题都是会后由问题相关人单独讨论，这样能比较好的保证会议效率。另外，我们在每周五下午会有个retrospect会，也就是对当前srpint的一个回顾，每个成员都说说本周的well和less well，会议driver把大家说的记录在白板上，less well需要形成AP（Action Point）并指定负责人，下一个retrospect时再反过来看看是否有改进，这个会上我们鼓励大家畅所欲言，毫无保留，这样能保证团队间能在无所顾忌的情况下指出问题并及时改进，这样，团队的整体实力是迭代提高的，这也是敏捷开发的好处。经过大半年的尝试，这种方法为我们磨合团队，提升团队作战力提供了很多有利的帮助。

一半产品

一半产品，这也是对我现阶段工作的描述，或者说是主要描述。很早之前就对产品工作非常感兴趣，期间也一直关注移动互联网领域的产品变迁，从2011年开始接触移动互联网，从那时比较火的签到应用和各种LBS社交应用，到现在遍地开花的O2O应用产品，移动产品也在一步步演进着。在公司写了大半年代码后，由于没有找到合适的产品经理，加上开发和需求间的间隙，产品的工作需要立马开始，所以，我被委任担任产品一职，说是说做产品，其实做的更多的是PE（Product Execution）的工作，和公司业务团队另一个同事配合组成PE Group，正式开始了我们公司的产品工作。初入产品圈，没有经验，没有积累，一切从头开始，其中辛酸历程，听我慢慢道来。

在创业公司做产品

由于我们公司的产品工作是从头开始，所以一切靠自己，还是那句话“全靠你了！”。Ok，没有经验那就从头开始积累经验，没有方法，那就从头开始摸索方法，于是我们PE便开始了在产品路上的披荆斩棘。

做产品，对需求的理解和整理肯定是第一要做的，由于我们做的是新业务，没有可参考或模仿的对象，所以需求的来源更多的来自前期的假设，说白了就是YY，我们会把可能的需求点全部列出来，然后根据业务主干原则，把其中影响业务的关键节点选出来，从很长的需求列表中挑选出必须完成的需求，把需求沉淀成功能，这个过程就叫做最小化原型产品MVP，通过完成MVP，我们可以快速将假设的产品投入实际验证，根据验证反馈的结果再来对产品进行迭代和改进，因为前期的需求选择和功能设计都是按照最小化原则展开的，所以根据验证结果去修改或推翻之前的假设所造成的影响或损失就非常小。经过不断的迭代，原本基于假设的产品可以逐渐演化成经过证实的验证，得出的产品基本是用户或市场真实的反馈。这个过程在《精益创业》一书里面说的比较详细，推荐大家阅读。

通过开发最小化原型产品，我们可以快速验证假设，经过几轮的迭代下来，原本的需求可能会发生天翻地覆的变化甚至是被砍掉，因为我们以为我们自己了解用户、了解市场，其实我们只是基于自己的认识或先验的结论在做一件使我们越来越自信的事情。然而，在创业公司成长的过程中，最怕的应该也就是这个不断自信的过程。这里说的自信，是只对自己假设的业务或产品盲目崇拜，没有经过验证的业务或产品，都是YY，都是对公司资源的浪费。所以，我们做产品就基于这么一个原则，若是得到没有经过验证需求或产品功能设计，我们一定要以最小的代价去实现，把今后修改或推翻的成本降到最低，哪怕它是多么的丑陋或无法使用。因为一个功能对用户如果真的有价值，用户会帮助我们慢慢去完善它，如果我们把一个无用的产品功能做的绚丽无比，那这只是在浪费用户和浪费我们自己。另外，对用户体验和视觉的设计也是如此，设计我们也采用最小化设计原则，通过简单的交互，直观的视觉体验，尽可能简单的把我们想传达信息呈现给用户，其他的全部砍掉。因为很多时候，我们自high出来的产品往往不是用户和市场真正想要的，所以，要尽量避免团队陷入这种“自信”的误区。

我们做产品没有大公司的流程和各种文档，我们通过github的issue来管理需求，给每个需求在issue中编上号并归入不同的milestone，通过label去管理每个需求的状态，在每个sprint期完成对下个sprint中产品功能的线框图设计和高保真设计，当下个sprint来临时直接基于上一个sprint的产品产出进行开发。当然，还是那个千年不变的问题，没有不变的需求，所以，我们制定了应对需求变更的SOP，通过衡量每个需求的优先级来排定开发计划，我们设定了三个优先级，分别是P0、P1和P2，P代表priority，P0是优先级最高的程度，代表需要立马解决的，P0级别情况一般是比较少出现的，大部分情况下，我们的需求级别定义在P1和P2，在完成P1级别的功能后再处理P2的任务。

沟通，是做产品最重要的工作之一，理解老板的意图，翻译成产品语言，通过设计传达给开发团队，其中任何一个环节的理解和执行不到位都会导致信息丢失或失效。所以，产品经理往往也是一个公司的中枢，起到承上启下的作用。与老板沟通要用宏观语言，站在战略角度，与设计沟通需要用设计体验语言，站在用户体验的角度，与开发团队沟通要用技术语言，站在工程实现的角度。产品经理不易，且行且珍惜。业界产品经理们自嘲自己为产品狗，可见我们的无赖与委屈，但那又怎样，看到用户使用我们的产品流露出的满意感，看到公司业务随着产品的完善而不断增长，看到团队因为产品的完善而充满成就感，那么，我们也值了。

写在最后

一半产品，一半技术！我因技术而入行，因产品而成长！我不会放弃技术，但我会重新学习产品。今天说了很多这半年多的一些感受，有的是总结，有的是分享，不一定正确，但都是我真真实实经历着的，希望这段旅程上能收获更多的知识，得到更大的提高和成长，不管是在技术路上还是产品路上，希望能得到大家的帮助。