如何成为一名自截po
发布网友
共3个回答
热心网友
当一个研发或产品线团队人员数量达到几十人规模时，点对点的平面式沟通管理模式势必成为产品研发和团队发展的瓶颈，这时候就需要从人员组织架构上做出调整，即从点对点的平面式管理转换为金字塔型的梯队式管理。作为一个研发团队，技术研发主管（本文指的是带领一个小团队进行研发和管理工作，团队规模通常在3~7人之间）作为梯队式管理中的基层主管在技术人员管理以及产品开发过程把握上发挥其核心作用。本文从团队管理角度出发，从技术研发主管的定位开始展开，对如何培养和建设技术主管队伍从以下几个方面进行阐述：
1.个人
2.过程
3.工具
4.团队
我举一张龙舟图对研发主管的定位进行描述，见下图。图中除了坐在船体里划桨的队员之外，最重要的莫过于站在船头的擂鼓手和站在船尾的舵手。个人认为舵手就像团队中的产品经理为团队把握前进的方向，而擂鼓手则是我们的研发主管为技术团队加油助威、保持冲劲和斗志。
对上述定位进行细化，研发主管充当了三方面主要的角色：
1.Facilitator：作为技术团队和外部团队（如产品团队、项目团队、运营团队等）的协调人，对整个产品开发过程的统一高效起到协作和润滑作用。
2.Problem Solver：作为团队中技术方面的权威，通常需要主导解决开发过程中的疑难问题。
3.Teacher：作为管理人员，负责对新人的培训和指导，确保研发团队认知水平和工作模式达到一致。
针对以上三种角色，研发主管在研发资源的有效运用、Know-How的传承、研发流程的推动、工程师的人才培育以及技术问题的解决上将需要起到其关键作用。正如“Conway‘s Law”中所描述的那样：一个软件设计和开发的结果，很大程度上反应了团队的组织与沟通架构，而研发主管作为组织与沟通架构中的重要一环其重要性是显而易见的。
然而在肯定研发主管作用的同时，也不得不承认其面临的挑战。传统行业的主管的核心任务是整合，即要求团队成员步调一致，大家站在一起稳步朝前走；而互联网行业中的研发工程师们确有其独特的创造性，很多时候有其自身的想法和判断，这就要求研发主管既要对团队进行整合又要发挥团队成员的差异性，如同项目管理我们需要追求一种平衡一样，研发主管也面临着同样的难题。
解决上述难题的方法我认为有两个方面：一方面从组织级别需要为研发主管们提供一个Platform，包括相对完备的基础设施（如研发管理的工具、人员管理的规章制度等）、工作流程（如内部标准测试流程）等；另一方面也需要研发主管自身确立一套Mindset，包括工作的思路和方*、主观意愿等。下面我们就先从“个人”角度出发谈谈研发主管所应该具有的综合能力和面临的转变。
一. 个人
下面这张表格是普通研发工程师和研发主管之间的对比，从表格中我们不难看出研发主管需要从以往的执着、专注、本位、创意转变到全面思维、计划管理、引导培育和沟通协调，即工作的范围和内容将从“I”字形转变到“T”字形：
从价值观而言，很多来自敏捷领域的思维模式都是需要被提倡的，如沟通、简单、反馈、勇气、公开和承诺。这里不再展开，可参考XP和Scrum相关书籍。
要想成为一名成功的研发主管，国外学者梳理了“4个P”作为对其工作思想的指导，即：
1.Pencil&Paper（将过程付诸记录）
2.Plan（计划引导成功的方向）
3.Passion（热诚驱动一切）
4.Perform（个人及行动的组合）
个人觉得这个“4个P”对其他领域的管理也是通用的。研发人员从创意中不断获取技术所带来的成就感，对研发主管而言，当管理本身也变成一种创意时，所面对的可能就是一个充满战斗力和*的研发团队。
二. 过程
从类如CMMI、IPD这样的过程模型所倡导的理论思想而言，一件事情想要做成功，“如何正确的做事情”这一理念是被高度倡导的。那我们如何正确的做事情呢？这就需要进行过程管理和过程改进。狭义技术层面的过程管理可能没有像产品、项目或者组织级别所定义和关注的那么全面和重要（个人觉得多数情况下没必要和不可行，这同样也是一种平衡），但常识性的、业界普遍认为能提高产品开发和交付能力的过程实践也是研发主管做必须了解和掌握的。类似过程可能有很多，我在这里仅列举自身周围特定环境下比较有针对性的几点：
1. 版本控制
版本控制对技术人员而言不是一个新词，但在技术管理各个方面都不完善的环境下，版本控制也就需要作为一个核心过程进行统一管理和把控，我通过问答式进行简要说明。
1.版本控制的思路和目标？开发部署分离、版本可见和版本一致这三点是版本控制的基本思想，目标是在研发过程中形成一致的认识。
2.版本在哪里控制？版本控制的思想无处不在，内部测试和服务发布是其中最需要在全体成员之间形成统一规范的两个方面。内部测试中的版本控制用于与QA等部门之间的交互和协作；服务发布则作为正式的服务交付进行控制。
3.版本控制的范围？对一般系统而言，表现端、服务器端、数据库是需要明确进行版本控制的范围。尤其对数据库版本的控制是在团队协作、特别是分布式团队协作环境下的一大难点。
4.版本控制的重要性？从团队协作的角度看，合理的版本控制会促进信息透明跟踪和尽早发现问题；从服务提供者的角度看，版本控制对减小出错概率和维护成本而言也能提高用户满意度、降低实施和运营成本。
2. 配置管理
配置管理（CM）同样不是新词，在类如过程改进模型CMMI或产品研发体系IPD中都有明确的说明和指导，但对技术人员而言普遍没有形成统一的认识和实践模式。配置管理中主要包含基线（Baseline）、配置项（CI）和变更控制（Change Control）等重要概念，虽然配置管理更多应该属于是项目管理上的范畴，但在研发主管的Mindset中，如何管理系统的配置项、维护代码基线的稳定性也是日常研发管理中的一项重要任务。
3. 持续集成
持续集成是敏捷领域的一项核心实践，在《持续集成：软件质量改进和风险降低之道》这本书中，作者把持续集成抽象成如下的效果图：
从图中可以看到，完整的理想模式下的持续集成需要从代码编译、数据库集成、测试和审查以及服务部署各个方面进行集成和反馈，从而达到提升质量和降低风险的目标。实际环境下根据产品开发的场景，研发主管应对集成的程度、方式和频率进行把控，做到集成的成本和效果之间达到平衡，毕竟类似数据库集成等领域无论在理论和实践上都需要较高的要求，但持续集成的确为信息的反馈和透明提供了有效的手段和模式。
4. 过程自动化
从过程改进角度而言，过程的自动化是一个可以持续进行尝试和探讨的入手点，对提高开发效率、降低由人为因素所引起的错误起到促进作用。日常工作中，过程自动化在潜移默化中影响着研发团队内部以及跨团队协作流程，研发主管工作相关的自动化过程通常包括如下领域，我们通过Ant、Python等脚本或Jenkins等工具平台进行过程自动化建设。
1.程序开发，例如使用Ant脚本在代码编译过程中引用多方资源并形成统一服务
2.功能测试，例如使用Jenkins在构建过程中执行JUnit单元测试
3.系统部署，例如使用tomcat maven插件进行war包在tomcat容器中的自动化部署
4.服务发布，例如使用Python脚本生成面向各种Android市场的apk发布包
5. 部署流水线
代码开发和维护工作自然重要，但对研发主管而言，项目/产品的生命周期以及围绕该生命周期展开的各项流程环节更是需要花时间和精力进行设计和监控以确保整个过程的正确性。下面是一般系统开发所具有的部署流水线，该部署流水线整合了多个过程中的要素并形成了面向开发、测试和运维团队的统一工作流。
通常测试人员和运维人员技术水平相对较弱，碰到技术问题往往找研发人员进行解决，所以研发主管在部署流水线中需要起到主导作用，通过合理运行自动化工具、配置管理策略参与建立内部测试和发布流程，为外围团队（项目管理、实施运维等）提供高效易操作的技术接口，从而提高服务发布和运行的客户满意度。
三. 工具
为什么工具对于研发主管而言很重要？因为针对重复性或耗时过长的工作，我们可以利用工具来改善过程；针对自身能力或工作上存在的弱点我们也可以利用工具弥补。尤其对于研发过程而言，团队工具的使用一致性和有效性对团队工作效率有直接关系，同一个工具不同人采用不同的使用方式导致系统集成、功能测试等出现问题的现象也是屡见不鲜。研发主管作为一个Mentor，需要对整个团队的工具本身及其使用模式进行把控和协调，确保团队所有人认识一致。
关于工具有一条定律：没有最好的工具，只有最适合自己的工具；工具只有培养使用习惯后，才称之为工具。个人很喜欢，也觉得研发主管需要梳理团队中的工作流程，根据流程确定最适合自身团队的工具和使用模式。
说起工具，我们要提一个感念叫“ALM”（即Application Lifecycle Management，应用生命周期管理），后续讲的各种工具也是围绕着ALM这个主题进行展开，而不是简单的介绍某个工具而已。结合“AgileALM: Lightweight tools and Agile strategies”这本书中提到的概念，作为研发主管眼中的ALM包含的内容可能是长成这样：
上图中的各项中的制品（如代码、需求、文档、交付物等）一定程度上都需要通过工具进行有效管理和维护以确保信息的流转和跟踪，下图就是这一思路在具体工具上的一种表现形式：
对研发线而言，通过需求分析把项目/产品的范围分解成一个个带有Ticket的任务，该Ticket作为研发工作开展的基础。从上图中我们可以看到这个Ticket贯穿了整个ALM，而ALM中的每一步都有某一个工具管理着该Ticket。如：
1.Redmine：项目、研发、缺陷管理的统一平台，作为基本的Ticket系统对项目/产品范围和时间进行管理。为问题跟踪、进度控制和团队协作提供平台和视图
2.Eclipse：主流开发工具，同时又是强大的集成平台，可通过Redmine Mylyn Connector集成Redmine；通过Subclipse集成SVN；通过Jenkins Mylyn Connector集成Jenkins；也可进行Maven、Tomcat等工具的整合
3.SVN：配置管理工具，系统代码、文档和资源存档的工作平台
4.Jenkins：主流持续集成平台，自动化构建、服务发布、代码审查工具
另外作为研发主管，对团队进行知识管理和沟通管理也是日常工作中的一部分，涉及到：
1.OneNote：Office自带的知识管理平台，可建立企业内部服务完成团队内各个成员知识以及组织级别基本信息的共享
2.Email：沟通和协作的基本媒介，明确细节、追踪状态、安排事情以及进行历史记录备份
以上工具市面上类似的很多，也都大同小异，可做类比。后续会有专题对工具进行详细介绍，熟练掌握这些工具将成为研发主管手中强大的武器。
四. 团队
通常一个产品线研发团队的主要角色以及数据流如下，PO（产品经理）作为产品线的核心角色与各方都需要进行交互和协作；PM（项目经理）根据项目输入将产品线功能转化为项目范围，并对时间和成本进行监控；DEV（研发人员）负责系统设计和功能实现；而QA（质量保证人员）根据需求对DEV的制品进行验证和确认，并保证流程的正确性。
根据上图结合组织发展的需要，从团队角度出发研发主管充当三个主要接口：
1.团队外部接口：DEV主要和PO和QA之间有直接的交互和协作（与PM相对较少），这个交互和协作的接口通常就是研发主管，这是对外的接口
2.团队内部接口：研发主管作为DEV的Leader，对内部开发人员而言也有一层对内的接口
3.组织级别接口：研发主管是组织技术管理方面的中坚力量，对组织过程改进也会贡献自身的力量
团队对外接口工作一方面在于通过Ticket系统与PO在范围管理、时间管理和内部沟通模式上达成一致；另一方面与也应该通过Ticket系统与QA进行Bug管理、问题跟踪，并协助QA进行最终服务的发布。
热心网友
刚开始的时候呢PO主还比较年轻还在上大学，被学长介绍在一家小翻译社做过一段时间的外单，这段经历满满的都是眼泪啊有木有，经常发不下来工资不说，有时候连订单都没有，超低费率啊有的时候都快吃土了。销售们什么单都敢接，苦命的只是我们这些小翻译（泪奔）。后来呢PO主实在受不了了，这点收入连恋爱都谈不起呀！我有几个同学先转战了网络平台，看着他们吃香的喝辣的，PO主忍不了了！于是就转战网络平台，一直到现在都是个SOHO。我一般都是在一些比较发展成熟的翻译网站接单，比如有道人工，我译网等等。下面我就讲讲我在平台做网络翻译的经历吧，先从有道开始说吧
有道人工属于网易旗下的子业务，后台会更硬一些，当然这既是优势也是劣势，看你怎么去想。大品牌的话品牌效应会更好，对于译员来说单子也会更多一些。可是呢有道人工有一点特别的烦，就是在官网上你还不能直接注册成译员，得向HR投简历，有的时候不需要你擅长门类的翻译，人家都不理你，简直和我之前在的翻译社太像了，干预度太高。我有个朋友擅长市场领域，投出去简历大半年有活了才联系他，等的人心情爆炸。有道人工的提现周期也比较短，大概是5天吧，5天之内客户还是有可能要求修改的。我最不喜欢有道人工地方就是他们的派单模式，毫无自由可言，给你什么你就必须翻译什么，没有什么权利去选择。收入上来看其实有道的费率是不高的，坑爹的是有次我去看报价要比我收的高多了，心塞。
我最近在我译网上做自由翻译，感觉体验上要比有道人工更亲切些（不吹不黑），从费率上就更亲切了，我译网只收报价百分之八的服务费，比有道翻译良心许多，学精了的PO主这次先去看了我译网的报价，价格上也比有道低了不少（目测有道的钱去打了广告）。直接在官网上可以注册，通过审核后还可以在线选单抢单，完全就是PO主喜欢的Free style有木有，能者先行嘛。万物都有利有弊，这个平台也不例外啦，提现的周期是10天……我要还蚂蚁花呗的啊!哭死……最值得吐槽的一点就是，我译网的审核时间太！他！妈！严！了！时间还有点小长。我刚开始参加审核的时候考了三次才通过，而且审核考试每次只能参加一项，结果出来之前还不能参加其他的。那段时间简直难熬，蓝瘦香菇。
热心网友
如何成为一名字？接Paul。很容易，只要奔着自己的目标去努力。
