这节作者介绍了技术团队~先上图：
技术团队简图
在互联网、软件行业的项目中，需求评审通过后，技术人员开始全面介入，在各项技术设计（编码设计、数据库设计、测试设计……）完成并执行以后，再部署发布。下面谈谈各技术中的技术人员。
编码设计，有软件架构师或系统分析师，具体到编码的执行工作就是最常见的开发工程师，他们也会有分工，有人偏前台应用，有人偏底层数据库，有人专做搜索引擎，等等。此外，可能会出现专职的开发经理，配合项目经理管理整个开发过程，比如协调人员、制定开发计划等，他自己并不是项目的开发人员，可以同时担任多个项目的开发经理。
数据库设计，对于大用户量的应用特别重要，比如淘宝、支付宝这类服务的用户数实在是太多，所以相应的人员——DBA（database administrator，数据库管理员），在业界也确实是比较强的。
测试设计，相应的人员就是测试工程师，再细分一点有功能测试与性能测试等，一般来说性能测试会写一些自动执行的脚本，感觉更高科技一点。大一点的项目还会有一位测试经理，协调管理测试相关的工作。
QA是Quality Assurance，质量保证人员：我们经常把测试也叫做QA，也会误以为他们是一个概念。其实QA主要做流程管理（如需求变更流程、发布流程），文档管理（如开发规范、测试规范）等。测试和QA常常是归属于同一个部门的。在软件项目的整个过程中，需要在流程和规范上控制以防止低级失误的发生。
对于不断发布的产品、多分支同时开发的产品，软件配置管理员就显得非常重要了。有他们的控制，就不会发生“某个Bug在新代码发布之后重新出现”这样的低级失误。像简单地用SVN来管理代码、软件版本的变更、每日构建等，都是SCM（software configuration management）的职责范围。
上述各项工作完成之后，就要把各方面准备好的产出物拼在一起部署发布，就牵涉到硬件方面的管理，这就是SA，系统管理员。对于复杂的系统，可能涉及成百上千台服务器，且服务器的任务各自不同，其设计与管理的复杂度并不比软件低。
有这样两种工程师
上面提到的各种人员，都可以看作广义的工程师、技术人员，他们是很有特点的一类人，给外人的印象或许是执着、冷静、沉默、高傲……在工作中经常遇到的有两类很典型的风格。
一类是技术痴迷者，常见于工作不久的新人，或者少数工作很久且一直醉心于技术的牛人。这类人价值很大，在项目碰到技术难题的时候，往往是攻坚的主力，要把他们这些好钢用在刀刃上。但他们的优点也正是其弱点，技术痴迷者工作的目的似乎就是学习更多、更强、更新的技术，并乐于在项目中尝试“高科技”，他们追求的是解决难题的快感，而对项目本身在商业上成功与否并不关心。他们会为了技术而搞出一些用户并不需要的功能，即所谓的“镀金需求”。这就需要PD与他们充分沟通，让他们具有成本意识，不要盲目创新，这类同学都很理性，比较好交流。有极少数热衷于技术的人，缺乏必要的责任心和使命感，做项目是为了钻研新技术，钻研新技术是为了更好地跳槽，把项目的成败放到次要地位，甚至在项目的最关键时候提出辞职以此要挟老板涨工资。碰到这类人只好自认倒霉。
另一类是实用主义者，常见于工作过一段时间的老人，或者只是把技术当作工具的工程师。他们的典型特点是KPI导向，公司考核他们什么，他们就做好什么，尽量少做事，做简单的事，稳字当头。看似不思进取的态度也有其巨大价值，他们往往经验丰富，在做事之前充分考虑，让每一份付出都有超额回报。他们能在一团乱麻中找出最简单稳妥的解决方案，他们很清楚自己需要什么、公司需要什么、你需要什么，有一定的商业感觉，可算是职场中人见人爱的“老狐狸”。这种人中也有极少数让人头疼的，他们是真的不思进取，做一天和尚撞一天钟，每天只给你交一份刚好60分的作业，这就要看你的公司是否有办法把他的激情再调动起来了。
如何与工程师合作
第一，注重“流程”。一群超级理性的人很明白“没有规矩，不成方圆”的道理，他们喜欢被规则管理而不是被人管理，当事情由人来控制的时候，总给人一种不安全、不稳定的感觉，而有流程可依的时候，心里就比较踏实。具体到实施方面，需求确认的时候相关人员一定要悉数参加，以免后期才发现大家对需求理解的不一致。如时间允许，每个人都应该尽早参与到需求评审中。另外一点就是需求变更的流程。
第二大的问题就是“沟通”，这是团队合作必不可少的一个环节。站在PD的立场上，我们会把自己作为产品的中心，这个角色注定要和各种各样的人交流，客户、老板，以及开发、运营、测试、客服、合作等部门的同事。开发者们提出希望大家在交流的过程中避免情绪化。人性的弱点决定了在争论的过程中每个人都希望自己得到认同，而这点往往导致思路的变形，不再考虑产品怎么做更好，而是去想如何说服对方，并且，经常有同学会把对人的反感转移到对此人观点的反对上，这很可怕。沟通中还有一点很重要，就是每个人都要主动一点，这样才能形成互动的氛围，也可以减少信息不畅引起的问题。
第三点是PD要不断提高自我修养，技术人员希望PD给出的文档在质量上更进一步，准确、全面、简洁，即时更新、保持最新。PD有空多了解一点技术也会大大改进与工程师沟通的效果。对于有的工程师可以和他讲商业价值，而另外一些，与他讨论一些技术实现更有效，当然不是技术细节。
最后，顺便提一下与工程师差异极大的业务人员。虽然他们总是个个能说会道，但其思维的逻辑性、严密性不如工程师，可能突然因为想到某个主意就很激动，马上就想去实施，这时候需要我们来协助，把事情想周全，凡事有得必有失。
PD们在商业与技术之间，起到了平滑过渡的作用。有了我们，可以让业务人员冷静下来，让技术人员兴奋起来。这样，团队就更和谐了。
网友评论