编辑导语：随着人生经历的丰富、身处环境的变化，我们总会时不时生出一些关于生活、工作等方面的感悟。本篇文章里，作者便对自己的十年产品工作进行了总结，并阐发了自己对产品工作的一些认知，一起来看一下。
一、关于我是谁
最近一年来我一直被工作瓶颈和35岁焦虑所深深困扰，脑子里不断在回放这些年的工作经历，总想写点什么。今天是我的生日，此时夜深人静，在GZ的一个酒店里，我敲下了这篇文章纪念并复盘这10年多的产品经历，希望一切过往皆为序章，人生才刚刚起航。
我2010年毕业于美丽自由的樱花大学，虽说我学的是软件工程专业，但是因为种种原因在学校时我竟没有写过一段完整的代码。幸运的是，靠着临时抱佛脚我在大三时拿到了一家不大不小的软件公司的软件开发岗offer，一个月工资4300元，工资不高不低，刚刚够养活自己。
我深知自己不会写代码，离开发岗差距很大，所以我拿到offer后立马向公司申请了实习。2009年11月10日我来到了HZ，开始了我的职业生涯。
二、我曾经是一个程序员
1. 通过大半年的实习我学会了写代码
入职后我的导师给了我三本书、一份文档、一个任务，这就是我实习生涯的开始。这三本书和一份文档及一个任务构建了我最初工作知识结构，现在回想起来这对我的职业影响很大。
- 一本书是古老的Delphi6开发指南，主要是介绍如何编写前端代码、制作程序界面。Delphi开发工具自带界面设计器，界面设计器和Axure非常相似。这让我对交互设计与用户体验有了初步了解。
- 一本书是pro*c开发指南，主要是介绍如何编写后端代码的，包含了如何编码c语言以及如何访问数据库。
- 一本书是oracle开发指南，主要是介绍如何编写数据库sql语言、如何进行数据库设计。这让我理解了什么是数据，数据是如何记录的。
- 一份文档是我们部门所负责的产品的业务文档，包含了各种业务介绍、功能需求。
- 一个任务就是根据这些资料完成一个简易版本的能运行的程序系统。这个也是我的毕业设计作品。
这个简易版本麻雀虽小五脏俱全，它包含了从业务→需求→设计→开发→测试→部署发布的完整IT研发流程，包含了各个岗位的工作内容，这让我对研发流程和工作分工有了一定的理解。
虽然鸭梨山大，但是我没有办法，我只能硬着头皮一页一页地去看书、一行一行地去写代码、一个一个地去debug，我一边自学一边百度一边请教同事。过了几个月后团队又加入了6个实习生共同完成这个任务，经过了大半年的努力，我们终于让程序运行起来了，我们也都完成了毕业设计作品。实习期和试用期结束后，我在事业部几十号新人里面考核前三拿了A。
感谢这些同事与领导，感谢这段实习经历，这比我大学四年学习的程序实操知识都要多。这段经历让我明白并且相信不懂的东西可以通过学习获得，学习也成了我长期的习惯与能力，让我不惧怕各种新领域新知识的挑战。
2. 我的两年程序员经历
这是一段踏踏实实干活，打基础的经历。
我的主要工作是按照领导分配的需求任务，进行概要设计、详细设计、编码、单元测试等等。最初是做一些简单的前端操作页面、查询等任务，试用期过了后开始做一些前后端一体的业务逻辑处理。这个阶段的工作相对来说是最简单的，日常主要碰到这些问题
1）对某些业务知识不熟悉
对于一个处理金融业务的行业级B端核心业务系统，业务知识十分复杂，对安全性与业务逻辑正确性要求极高，容不得半点差错，短期内很难快速掌握。
由于B端业务知识的特殊性，很难在百度等外部工具上找到资料。解决这个问题最有效的办法是自己先学习内部的相关需求文档，然后再去向领导同事请教，直接问到关键点，切忌自己什么都不了解就直接去问，毕竟大家都很忙都有很多工作要去处理。
2）对某些系统实现逻辑不清楚
一个行业级B端核心系统往往都经过了很多年的迭代，系统错综复杂，修改一个功能往往牵涉到很多其他功能点，对一个新手来说常常无处下手。
在每次修改之前我需要确保自己已经熟悉了需要修改的程序原有逻辑、可能的影响点，我的方法就是一遍一遍去看现有程序代码，先做好设计再编码，编码完成后不要急着调试而是先自己代码走查看看逻辑是否正确，最后再做好单元自测。我认为大部分时间应该放在熟悉需求、熟悉现状、做好设计上面，想清楚再去做。
3）对某些技术知识点不掌握
对开发人员来讲技术问题反而是容易解决的，我们工作中使用的都是成熟的技术，百度等工具上都有大量的资料，这个只要我们花时间去找资料总是能解决的，当然做了充分准备后向同事请教依然是高效的办法。
4）复杂bug修复难
debug就是开发人员的日常，熟悉业务然后耐心仔细覆盖好每个分支逻辑基本就能解决了，有些神仙问题大多跟环境等有关系。
5）代码重构影响面大
不做重构的程序员不是一个好程序员。程序维护的人多了，时间久了必然会出现各种问题。
编码规范这类问题都是管理的问题，坚决落实就好。对于一些其他代码坏味道就需要主动承担重构的职责了，不要形成破窗效应。当然重构之前务必要清楚原有逻辑、可能的影响点，与直接主管、测试团队做好沟通，毕竟软件研发是一个工程性的工作。
6）害怕与领导同事沟通
刚毕业的时候容易把领导同事，特别是领导当着单纯的管理者监督者，害怕沟通。
其实大家是一个团队，为了共同的目标在工作，只是分工不同而已。领导是一个管理者监督者没错，同时也是我们工作的协助者，在我们能力和权责范围之外的事情我们可以跟领导沟通商量寻求帮助支持，日常的一些重要工作也需要寻求与领导、重要同事达成一致。只要出发点是正确的，再搭配合适的沟通方式，就不用担心害怕。
从各个角度看这两年的工作是相对单纯的，没有什么高深复杂的技术甚至很落伍的，大多数时间也只用跟电脑打交道，可以安安静静地干自己的活，唯一有难度的是复杂的业务逻辑。
当我开始熟练掌握这个工作后，这份工作开始没有了挑战。我开始焦虑，焦虑目前这种落伍的技术以后要怎么找的到工作；我开始浮躁与失落，看着大学同事都去了互联网大厂，看着身边绩效没我好的同事跳槽到金融机构工资翻倍翻几倍，再看看自己每个月所剩无几的工资和高昂的房价，我很迷茫很浮躁……
我发现我的内心其实不喜欢做开发工作，长期安静地与电脑打交道也不是我的长处。
当然这2年的工作我也收获了很多：
- 我养成了比较好的工作习惯与方法，特别是持续学习、多思考、有计划等，这在上文已经介绍就不赘述了；
- 我对技术工作有了真真切切的理解，前后端如何配合实现业务、数据如何存储、技术各岗位分工协作等；
- 我掌握了一定的业务知识，我熟悉了我们系统所服务的业务以及我们系统是如何实现这些业务处理的，这个阶段虽然没有形成自己的认知逻辑，这是我对TOB产品的最初认知；
- 我在同事间形成了良好的口碑，我的学习能力、沟通能力获得了大家普遍认可，工作中获得了很多表彰奖励，我受到了事业部领导、HR部门、甚至是公司领导的关注，成为了事业部新人中的重点培养对象。
三、我开始成为一名产品经理
得益于部门业务的快速发展与领导对我沟通等能力的认可，2012年我开始承担了行业所有客户的需求沟通与分析工作，我负责的是一个维护迭代周期的成熟期产品，客户数大概60多家，每年产品营收大概1000~2000万左右，这是我做产品经理的起点。与此同时我还承担着系统概要设计、任务分配、编码等工作。主要工作包含：
1. 客户需求分析与沟通
客户的需求通过各种渠道统一汇总到我们的需求管理系统，我每天的工作就是打开需求管理系统去处理这些需求，这部分工作大概占了我30%的工作时间，一般步骤如下：
第一步：在与客户沟通之前仔细阅读客户的原始需求材料。
第二步：判断该需求是否属于我们的产品业务范围，如果不属于则需要分析清楚哪个产品承接更合适，将需求移交给对应团队承接。
第三步：对于我们产品业务范围内的需求，需要分析是个性化需求还是通用需求、是付费需求还是免费需求。对于个性化极强的需求一般的处理方式是拟拒绝，对于重要客户、强势客户，为了维护良好的客户关系则会让客户额外付费实现。对于需要付费的需求一般会在与客户沟通后启动商务评估与对接流程。
第四步：制定初步的处理方案、评估大概的工作量、初步的版本计划与交付周期、需要沟通确认的需求点等。对于一些复杂的、重要的、工作量大的需求一般会在团队内部先沟通达成一致。
第五步：与客户进行电话沟通，对需求疑问点进行确认，就处理方案寻求达成一致，大多数情况下大多数客户都是相对容易达成一致的。对于无法达成一致的则需要多轮沟通、上升层级沟通、大多是我们做出一定层度的让步。
第六步：将需求沟通结果更新到系统中。在领导审核后系统会自动将处理结果信息邮件同步到相关人员，包括同步到客户。这一步既是对信息的同步，也是对处理结果的确认留痕。
（在处理需求过程中会有很多成熟的方法论，选择合适的方法就好，这部分后续有机会再成文探讨。）
2. 产品方案设计
在与客户沟通清楚需求后接下来就是具体的产品方案设计。在方案设计过程中主要考虑这些方面：
1）产品化
我们是在持续维护迭代一个产品，服务于行业60多家客户。软件的利润应该来自于复制，我们在做方案设计的时候需要尽可能做到功能点的模块化、通用性、可配置性。
模块化是产品化的基础，合理的颗粒度才有更好的复用性；通用性是为了兼容并服务于更多客户；可配置性是为了减少对不同客户的影响能够按需使用。
2）功能性
TOB产品主要用于处理企业内部各种业务流程，实现对各种业务流程的处理支持是最根本性的要求。在产品定位和职责范围内，能够支持的业务流程越多、场景越多则产品性功能越强大。
当然更强大的功能意味着更多的研发投入，我们一般的实现方式是在服务客户过程中不断积累产品功能。
3）稳定性
这也是一个根本性要求。我们的产品是处理金融业务的上游系统，下游系统依赖我们产品的数据进行后续业务处理，这就对我们产品的业务处理的时效性，准确性提出了极高的要求，少出错少宕机。我们在设计过程中要考虑如何尽量降低系统处理和用户处理的复杂度与出错的可能性，出错后如何快速且正确地恢复。
4）易用性
虽然易用性要求没有TOC产品高，但是在设计过程中也需要考虑客户使用习惯、操作效率等。
5）扩展性
金融机构的核心业务系统一般使用周期都会在5~10年，需要持续维护。我们在方案设计过程中需要为未来的业务发展适度预留可能性（这对业务的理解要求比较高），比如对需求多变的场景进行参数化设计。
6）性能
这个很好理解，就是在相同的数据量的情况下更快速地得到处理结果。设计方案对性能影响也很大，对于大数据量的业务和操作特别要注意，多跟架构师沟通。
3. 开发编码
编码工作就不再赘述。不过有一点需要特别说出来的的是，在处理过大量需求后，我开始能感受到每一行代码的温度和情感，因为每一行代码都在服务客户服务客户的用户，都是有生命的。
这个工作持续了将近两年时间，我想成为专职产品经理的想法越来越强烈。2013年左右的时候正是C端产品经理开始炙手可热的时候，我也投过互联网大厂的产品经理岗，不过都是石沉大海，毕竟我没有任何C端经验，那个时候也没有B端产品经理的概念。
虽然我没有成为专职产品经理，但是我也学到了很多东西，有了很多认知：
- 技术只是手段，是为业务服务的：这段工作会让我去思考如何用技术去服务业务，所有的技术工作最终都是为了更好地服务于业务开展，能产生业务价值的技术工作才更有价值。
- 如何做好产品：TOB产品的成功需要靠产品综合竞争力，包含了产品质量（功能性、稳定性、易用性、性能等）、产品服务（售前服务、售后服务等）、产品价格、客户关系等等，这些最终都会反应在客户满意度上反应在客户购买和续购上。
- 业务思维与敏感度：处理了数千条需求后，面对需求时我第一反应是考虑业务场景、业务流程，再是产品方案。
- 与客户沟通的能力：最初与客户沟通时我会比较紧张，使用的多是技术语言，但是客户方人员很多是非技术背景的，通过一段时间的调整我能熟练地在业务语言和技术语言之间切换，与客户沟通顺畅多了。
- 全面思考问题：一个需求的实现涉及到公司内外，团队上下游很多环节，要关注到每一个环节，对重点环节需要重点关注。
- 计划性条理性：每天都在多种工作中切换，工作时间开始碎片化，这就需要对工作按重要性紧急性进行组合排序做好时间和精力分配。
- 小团队管理能力：2013年我开始负责管理一个5人左右的小团队，这让我有了最初的团队管理认知，不过这种认知还是相对浅薄的。
四、我做过半年项目经理
随着业务的发展，2014年我们部门所负责的业务线出现了一个新的机会，领导从长远发展的角度让我去负责这个项目。这个项目是为某部级监管部门研发一款行业级监管系统，项目周期大半年，我主要的工作是：
1）需求沟通
由于这是一个新的业务领域，我们对业务的理解不够没有行业高度，监管部门安排4家行业头部金融机构IT负责人来牵头梳理需求制定标准。我主要是参与记录需求，提供参考意见，然后整理出需求文档，最终由会议领导确定需求。这个过程中最困难的是对业务知识的不了解，这个只能通过认真听取需求讨论会议与自学解决。
2）团队管理
带着10人左右的团队，负责团队的任务分工和人员管理。最主要的是合适的人干合适的事情，提高团队效率。
3）项目管理
我们做的其实很粗放，只是做了初步的需求范围控制然后通过大量加班来赶项目进度。
这个工作也是有一定的收获的，对项目研发形式有了一定的认知，明白了产品研发与项目研发的差异。项目研发关注的是使用预定成本在预定周期内完成约定范围内的需求，它的核心其实是成本控制，最终要通过毛利率来衡量；产品研发则更看重在实现客户需求过程中迭代产品，与此同时也会按照产品规划路线图沿进，产品研发最终要通过客户数和财务指标来衡量。
我的职业生涯过程中大概每两年就会出现一次发展瓶颈，随之而来的就是焦虑、浮躁、迷茫。机缘巧合，后来我参与了一家创业公司的筹建，我开始进入互联网行业……
这个成长记我分成三部分来写，后续根据阅读情况再更二三。