一个互联网团队的2016总结:先做项目,再做产品,再做生意
2016年回顾
指尖到家自从我来之后，我们确定了“先能做项目，再做好产品，再做好一门生意”的思想往前走。我说，我们要招商引资，就必须先盖一栋漂亮的大楼，而不是茅草屋，而要盖大楼就必须保证我们的施工团队要有过硬的专业素养，也就是会挖地基、拌水泥砂浆、砌墙砌角、扎丝、浇梁浇柱、整平、打毛坯底、刷面墙等工序。虚拟经济跟实体经济一样是一个复杂的系统，而承载这个虚拟经济的软件系统就跟房子一样需要精心的设计和实施。团队素养的好坏，直接影响到我们的楼盖的好不好，也就影响到这门生意能不能做好。
1）先能做好项目：
交互：为了能做好项目，我们首先对交互动了刀子。我们改掉原来创维的交互，引进了新的交互模板，我们对交互有了更为严格的定义，交互包含页面名称、设计目的、页面元素、页面逻辑、页面点击；我们队交互原型图的每个字体大小、距离、版式都做了严格的规定，产品经理不再是随便一拉就了事，而是他也必须培养过硬的交互基础。如果交互做坏了，后续环节都会错掉。
设计：我们对指尖到家的整体UI也进行了调整，主题色并不是说非得是到处都是，只要不是其他颜色的恨不得都涂满它，不是的。我们还统一了设计规范，提出了设计也得懂UI实现机制，以改进切图标注，使得设计和实施不打折扣；加强了设计审查；我们在设计上借鉴了别人优秀的应用，我一再强调，抄并不可耻，抄，这么一个简单的动作背后是比那些不抄的人多出了至少三个层次的工作：1）我对比过各大竞品；2）我的价值判断刷选出最优秀的了，至少我认可了这款竞品，我的境界总算是跟竞品站到了同一个级别线上，可能水平不一定相等，但不会太大；3）我根据我的实际来进行改进，实施。所以，当有人对你的成功嗤之以鼻，说，你不就是抄的时候，心态上一定要放宽，不要跟一群连意识都还没有的人计较太多。你在这一方面不仅仅入行了而且走过了一段路，而他并没有意识，你跟他吵吵啥呢？
开发：我个人觉得对开发最大的改进是讨论。如果说交互是一个目标，那么开发就是要通过程序来实现这个目标。每一部分代码都是一个方案，我觉得是要设计的。而不是一领到需求就叭叭叭的敲键盘。那再好的设计图纸，也会成为豆腐渣工程。很多人分不清楚产品需求和实施方案指尖的边界。就是说，这个编辑地址的地方默认加载地区应该加载什么？是全局的？是已有的？还是请刷新?其实产品需求和实施方案的边界并不是那么明显，但有偏向，越是细节和逻辑性的活，应该由程序员来担任主要责任，去设计你的程序，然后和产品经理去讨论，去核实是否如此，核实是为了不偏离目标。但我们的程序员倒好，恨不得每个if else都想着别人给你设计好，你来敲就行。我在看看说，这种不叫软件工程师，不叫程序员，叫“打字员”。开发最大的改进是大家一起围在一起不断的讨论，不断的推进和细化，这是我们建立起来的最为重要的规矩，一定要坚持和传播下去；然后我们还有实现同一功能的一致性检查，两个人必须在设计上相互一致、实施方法上经常对比要保证一致、实现效果的一致，我们绝不允许出现安卓和IOS实现方法不一样的地方，除非是平台限制的迫不得已。我们还有小组负责人检查，我要追责小组负责人，能上能下，做不好你就别做，换人，所以小组负责人要培养其自己的担当来，不然我提你干嘛？我们在V3.2还建立了代码Review，小组组长审查至少两个人的，其他人审查至少一个人的，我有审查表，审查完了要写审查的功能，别人怎么实现的，逻辑评分、布局评分、代码风格评分，以及改进意见。当然，我们还有设计审查、测试等本该有的手段去保证施工质量。
质量大过天，对于开发而言。
测试：特别感谢卫萍这段时间的付出，因为测试是我唯一一个还没有介入自己的方法论的区域。一个产品的质量，从项目的角度有两个方面，一个是质量检查、一个是质量保障。质量检查是一道工序，而质量保障则是一个系统方法，更难但却是根治。所以，我来之后没有直接抓测试工作，而是更多建立起质量保障系统规则，涉及的到从产品重视交互细节、任务逻辑合理性开始，到设计重视视觉风格、搭配、系统化、标准化，到开发重视讨论、一致性检查、组长检查、代码Review、设计审查等。治病，得治根。当然，质量检查是我们出厂的最后一关，非常非常的重要，我们一定要严格的测试。只有测试盖了章，才能合格。牛逼的测试牛逼之处远超产品和开发，我为什么这么讲，因为他要理解产品的需求，然后自己去构建测试用例，其实本质上页是实现了一次代码的设计工作。更关键的是，测试就一个，他其实等于把整个软件都想过了一遍，无论是需求还是逻辑，牛不牛，你们其他人有谁达到过这个？没有。所以，测试委屈了，平时帮你们测代码，还老得罪人，领奖的时候又站后面，你只记得盖茨是程序员、扎克伯格是程序员、乔布斯、马化腾和张小龙是程序员出生的产品经理，以前大家老捧程序员，现在改捧产品经理，但你们听过捧测试的么？所以，很不公平。所以，卫萍的工作辛苦了，再接再厉，严格的抓质量。
2）做好产品
我们还是从产品的三大组成来说，商业、用户、技术。
商业：还记得我说17年挣它一个亿吧。其实很多东西有心去看，去算，都不难，我们17年的打法跟16年有差异。我们确定了业务的分类，有流量业务和现金业务，我们拟定了ToB的工作是提效降成本，ToC的工作是售前售后的一站式服务平台，进一步提升用户体验。 细节我就不多说了，我们的规划文件里面有。
用户：也就就是在体验上一定要好。所以我跟粲说，你就从交互入手学产品，上手快，效果明显；但交互仅仅是面向用户的一部分，我们还有很多内容的范围、内容的质量更为直接的接触到用户。所以我们17年的业务一定是更全面，同时重中之中是业务的关联性，我们要打通业务让用户体验的顺畅。这是17年面向用户的重点，交互这是基础。
技术：牛逼的产品经理都是程序员出身，至少你要懂软件工程，所以粲一定要补基础。从交互入手，然后切入软件工程。你不需要切计算机，但软件工程你一定要切进去。说真话，我对这几年的产品经理我基本看不上，就是因为太飘了这群人。我们要踏实的夯实基础。想想，需求是要抽象出概念的，然后梳理出人物心里画像、动作和任务逻辑安排、这些都是软件工程需求分析要做的。我在上面列的牛逼的产品经理，都是程序员出生，意在人人都可以当产品经理，但唯有真的懂了软件工程的产品经理才是一名出类拔萃的产品经理。职场，是人生的一部分，至少我自己都是当做是修炼，所以我每天都在学，系统的学，一定要系统的学习，不要信那些鬼扯的碎片学习，碎片时间可以拿来系统的学习，而不是学习碎片的知识。知识一定要体系化。其实，系统的学一门知识，不但不会限制你的思维，反倒是会激发你的思维，因为他开拓了你所了解的领域。你想想，我都不知道金融知识，我怎么会知道旁氏骗局这些背后的机制和细节、如何规避法律风险等。我只有对金融知识很了解，我才能够把金融知识跟我们互联网知识碰撞，然后组合出我们新的业务。还比如，你对图像都不了解，你怎么能够设计出用机器视觉去做医学影像的处理呢？当然胡思乱想的科幻不算，我们要的是你拿得出手的方案。 所以你的知识结构越完备，你的创造性越强。因为一个问题的问题域你了解的越宽广又越细致，你就能够快速的定位出问题的最优解在这个域的位置。问题就是像飞行的苍蝇，我们的知识网络就像蜘蛛网，能不能网住这个苍蝇，就看网放的位置对不对，以及网够不够大，够不够密、够不够牢固。记住，系统学习。
3）做好一门生意
坦白说，我们16年基本没有做生意。因为我们真正说我们要做平台，其实就是从10月份开始，前面都还是遥控。我们把到家的架子，在两个月搭建起来了。生意还没起来，我们就想办法，我们17年要做电商、要做好点子保修卡、说明书。其实有个说法就说17年企业服务将会是互联网的一个热点方向，这不就是我们规划要做的事么！可能我说我们的出路，领导们都不信，或者大领导们可能不信，但资本市场说，那就有信服力。我们没做错，方向一定是对的，我们提出的那些业务，都没有问题，过开年我们就撸起袖子开干。挣他一个亿，只要努力，我觉得我有信心。
4)专和宽如何处理？
刚入职场的新同事，总会听到，一个老人在你的左耳说，你该拓展你的领域，你不该仅仅写代码，而又会有一个老人在你的右耳说，你要把代码写好，不要这个搞搞那个搞搞，什么都没搞成，你要专注。
你说,你们他妈说的都有理，我该怎么办？
我个人觉得专和宽是一对相伴相生充满矛盾却又相互促进的关系。很抽象吧，我打个比方，我说你要写好代码，做个优秀的码农，这个是给你提“专”的需求吧，恩，我也觉得，但什么是写好代码，优秀的码农呢？你总不会觉得是懂if else while for的就是吧，你去查，哦，原来优秀的软件工程师要懂数据结构、算法、OS、网络、软件工程、需求分析等等等等，一整套的体系知识。专不？宽不？专，也够宽！！！
站在你要成为一名优秀的软件工程师的角度，上面这些知识对你而言叫做“宽”；站在你更长的人生规划的角度，你所学都是软件知识，这个层面而言，你所学则够“专”。你成为一名软件专家，是因为你在软件领域学的够宽！
所以，当你处理“专”和“宽”的关系的时候，我希望你能够像上面那样来看待专和宽。相伴相生，相互促进。但记住是相伴相生相互促进的专和宽才更有价值。你学完数据结构然后去学算法，然后去学需求分析，这是有节奏的，相伴相生，相互促进的。但你不能今天学算法，明天就去学炒菜吧，你不能今天学操作系统，明天给我去学挖掘机技术哪家强吧。所以，你不要听着我要宽就瞎几把的宽。一会东搞搞，一会西搞搞。是有相关性的拓展，一步一个脚印的拓展，一环扣一环的拓展，你程序都写不好的，你跑去大放厥词各种产品论调干什么？你可以提意见，但别瞎逼逼。学会走路再学会飞。当然，不排除你有好意见，但你个人规划自己的发力点的时候，一定要讲究个步骤，去处理专和宽的关系。你要处理不好，听不懂我上面的话，你就简单理解，先专后宽，做好本职工作，再去说其他的。
本文为头条号作者发布，不代表今日头条立场。