我觉得技术人员的最根本问题是，你有没有定义好自己的产出？对于管理者，这个问题则变成了，你是否意识到自己应该管理产出？现在这个时代，大多数人都依赖于自己的本能和直觉进行管理工作，而没有接受过任何基础的管理培训。并且很不幸的是，各种无用的伪管理学书籍充斥市场，伪管理学培训由根本不懂管理的 HR 部门引入公司，这让本来就糟糕的局面雪上加霜。
这个十一假期读了卡尔. 萨根的一些书，如《暗淡蓝点》和《卡尔萨根的上帝》，也看了一些相关的纪录片，比如《宇宙》和《宇宙时空之旅》。和前段时间沉浸在相对论量子物理的世界里不同，这次看的是关于经典物理学和天文学，也就是我们每个人在初高中学过的知识，比如地球不是这个宇宙的中心，地球是围绕太阳在转等等。
一个良好定义的公司，应该就像一辆运转良好的跑车，对于最高管理者，只需要掌握方向和油门，而不需要知道汽车的每一个零件如何运转。
附caoz的《再谈技术的价值》
第一要旨： 产品人员在提出功能需求时，应明确告诉开发人员，其需求的目标是什么。
很多产品人员做需求设计，给开发的时候只告诉开发你要做这个这个，那个那个，而并不具体说明为什么要做这些，也许他们认为开发不需要了解这个，也许他们认为开发应该一看就明白这是什么，但实际上，往往这里就产生理解歧义。这是很常见的问题。
此外，产品人员，特别是没有技术背景或技术背景一般的产品人员，有时候会替开发人员多想，比如会认为这样做简单而那样做复杂，但也许技术实现成本并不是他想象的那样，而对于创业公司，实现成本往往也是特别重要的需要考虑的因素，产品人员往往没有给出实现成本最低的方案，而开发人员则盲目按照定义的需求出发，有时候做出的东西从实现成本来说非常不经济，特别是时间成本，消耗非常巨大。
在符合第一要旨的前提下，开发人员应能参与需求的讨论，我知道有些大公司或者产品经理不希望这样，我定义好的需求你去实现就好了，你做研发的讨论这个干什么？ 但这样其实是有好处的。
1、研发人员的参与意识强，对产品的热爱度和积极性会提高。
2、加深对需求目标的理解，减少开发过程中因理解歧义做出无用功或不符合需求的状况。
3、有可能提供目标一致，而更低实现成本的方案。对创业公司，开发力量不够完善的场景而言，这一点也非常重要。
当然，强调一点，研发人员可以参与需求设计的讨论，但决策权仍需要明确掌握在产品经理手里，（如果研发人员确实更懂得需求定义，可以兼任产品经理。但只要你赋予了独立的产品经理角色，这个需求的决策权还是必须给予保证的。）
第二要旨：产品人员应给出所有功能需求的流程和结构图。
在给出具体功能需求设计之前，应给一个总纲，也是为了加深需求理解，形成完整的需求概念的一步重要工作。
很多时候，产品经理会觉得，我说的都那么清楚了，你怎么不明白呢？ 其实主要就是因为在这个环节上产品经理对整个项目的背景，结构，前提，目标早已有了代入感，所以觉得每个细节都理所当然是这样的，但是对研发而言，他们并没有得到完整的背景信息，对细节的理解往往就出现偏差和误判。对彼此功能点的关系，相互的联系了解的支离破碎，那么实现起来这个系统也就难免出现不尽如人意的地方。
常见的，比如，用户的某个属性，在某个功能中体现出来，而在另一个功能中被赋予或产生变化的，但是因为需求设计的时候，没有给出整体的结构和流程，只是在局部的设计中提供了不精确不严谨的描述（产品经理也许觉得描述的足够清楚了，但是缺乏必备的背景信息铺垫），那么实现的工程师，（甚至可能两个不同功能是不同工程师实现），也许会误判做成两个不同的字段，赋予不同的定义。这样这个属性的实现就彻底错了，而在上线前甚至双方都没意识到存在这样的问题。
第三要旨：具体视图设计的三要素。
不论是设计网站，还是设计app，基本都是由一个到多个交互视图组成需求设计。
产品人员在提供这样的应给与研发者如下三要素：
1、界面元素，比如哪里是文字，哪里是下拉框，哪里是按钮，这些属于界面元素，可以用草图，或word简单排版，但要明确界面上的元素是什么，如何展现。是静止？浮动？
2、数据逻辑，这一点往往也是非常多创业团队和新手产品经理容易忽视的，比如页面这里是最新新闻，那么你要说明，这个最新新闻是基于怎样的数据逻辑获取的，当然这个基本上工程师都知道，按照时间逆序就好，但是如果涉及，比如有一个区块叫做推荐游戏，那么你要告诉开发人员，这个推荐游戏是从什么地方取出来的信息，按照什么逻辑取出来的。
有的产品经理说，这不是技术活么？我怎么知道？ 哦，要是真不知道，就要跟技术人员沟通这个问题，看看你需要这个地方出现的东西体现出怎样的一种特征，然后问他应该怎么来设计，然后你也要参与思考，这个数据逻辑是否符合用户的预期，以及在运营中是否会出现一些比如说位置会固化，新数据无法体现的问题，这些都是产品经理要思考和确认的，不能说甩手给技术，当然，如果你遇到一个特别有产品经验和理念的工程师，他真能帮你都解决好，但这情况其实非常罕见。
3、操作逻辑，界面上可以进行操作的有哪些元素，哪个可以点击，可以选择，操作后出现怎样的反馈，比如显示浮层？进入新页面？或怎样怎样？ 这也是要在需求设计文档里说清楚的。
一个视图的设计，说清楚界面元素，数据逻辑，操作逻辑，开发者才能明确这个视图的开发需求。不要让开发的工程师自己去猜，去揣测，如果有些逻辑涉及算法，产品经理不清楚，也要与开发者确认他所采用的逻辑是什么，以及效果是什么，并与自己所预期的效果做比对，而不是说，这个我不清楚，让工程师决定。 操作逻辑可能会指向其他视图，这就是前面说的，结构流程图要说明的地方。
在百度这样的公司，产品经理要写繁琐冗长的MRD，（其实早期的MRD不繁琐，也不冗长，但后来对需求定义的精确性要求越来越高，内容就越来越繁冗了）。其实我不喜欢这样的风格，沟通成本太高，所以对于创业公司而言，还是尽可能简单直接有效最好。 那么我认为，要做到简单直接有效，做好如上几点，对于大部分场景来说，应该就可以满足。
重复一下，第一，要让开发工程师明确需求的目的并参与讨论。第二，要给出结构图，流程图，对需求有完整的认识。第三，针对具体的视图，提供元素，数据逻辑，操作逻辑 三要素，其实并不会很复杂，正常一个视图写一页到两页就够了。如果开发工程师配合比较默契，有较多合作基础，中间很多内容可以写个略字。但是这个结构建议还是养成习惯。
说一个执行中的要点，当产品经理给技术人员展示完文档，表达完需求后，最好的一种确认方式是让技术人员按照自己理解重述一下需求，重述的过程往往容易暴露出理解的歧义。确保你表达的与对方理解重述的一致，这样有可能减少很多后续的麻烦。
创业团队里没有牛人是痛苦的，有了牛人就一帆风顺了么？
或者，明明牛人曾经就在身边，却一不留神错过了，这种事情你意识到了么？
总有创业者会疑惑，我好不容易找了一个背景资历特牛逼的合伙人，可是共事一段发现，也没觉得水平有多高啊，和我之前招聘网站很便宜的工程师相比也不见得高明在哪里啊。别说，这事真挺常见的。
感谢互联网，技术的价值得到了极大的尊重，但是一个很悲哀的事实是，相当比例老板往往是尊重的是别人家的技术。 昨天有些意犹未尽，今天想到哪里算哪里，可能组织的内容不够有条理，大家凑活看吧。
在相当多的情况下，优秀的技术保障往往没有存在感，其价值只有出问题的时候才会被人想起来。
典型场景 1，某个公司业务一直发展的不错，某天老板查工资单，咦，这个运维总监怎么工资这么高，没见他做啥事啊，好像除了报预算要加硬件带宽就没见他给公司做过什么贡献，也不知道这钱都花哪里去了，hr 过来一下，找个借口什么价值观不符送走送走，我有个远房亲戚做过网管，管过几百台电脑呢， 俩月后，各种运营活动出来抱怨系统支持不住业务发展，漏洞迸发，公司开始请猎头到处挖资深运维负责人。
典型场景 2，某个公司同时启动项目 A 和项目 B，两个项目上线后都受到市场好评，订单不断，老板开心，但 A 项目很快开始出现大量技术问题反馈，A 项目技术经理敬业又努力，天天加班救火到处跑客户现场处理问题。B 项目技术稳定支持工作云淡风轻，技术经理天天下班回家陪老婆孩子。然后 A 项目技术团队不断扩编，B 项目技术团队不断裁撤，最后 B 项目经理被勒令调往 A 项目团队做技术支持，A 项目技术经理升任总监。
以上案例纯属假设，如有雷同纯属巧合。但你说我都是无中生有瞎编的么？
在运维，技术保障等领域，没有存在感其实是技术的最高境界，但是很遗憾，因为没有存在感，所以往往无法被升职，被提拔，被认可。往往是问题越多，救火越频繁，存在感越强，越会成为领导喜欢的人才，特别是一些大公司，这种技术价值与所谓公司价值观倒挂的现象尤其突出。
为了展示技术而创造需求，是很多技术创业者的通病。
其实这段和主题不是很符合，不过想到这里我还是想说一下。
有些技术达人创业，他们因为掌握某种技术优势，非常希望把这个优势变成商业模式，但是他们也明白要从用户需求出发，可是真明白么？很多时候，他们会基于自己的优势，“创造” 出他们认为的用户需求，然后 “完美” 的用他们的技术优势来满足。
这种把 “炫技” 当作竞争力的，好像一直以来，下场都不是特别好，技术有优势当然不是坏处，但是你必须真正理解需求，再去考虑技术优势，而不是反过来。但这个弯子很多技术大牛总转不过来。
创业公司是否明确自己的技术目标和人才匹配度，长期以来是个问题，昨天我也提到这一点，脱离业务场景谈技术架构都是耍流氓，你找一个在大公司大体系里某个领域特别资深的专家，来解决你当前小公司的实际问题，真的合适么？ 答案往往是不合适。
我以前举过这样的例子，我去架构师大会，听各位牛人分享，淘宝的技术专家，那方案杠杠的，水平超过我们不知道多少倍，我听了各种佩服，回来后，我们一样都用不上，这个，真心用不上，业务场景差距太大了，人家考虑的性能指标完爆我们两个数量级有没有。一个二线互联网公司技术负责人分享的一个技术话题和方案，技术含量肯定比不了淘宝网的，但是回来马上安排照此实施，效果立竿见影， 因为业务场景有相似处啊。
大公司的体系庞大，每个领域都需要极深的专业人士来操纵，可能光一个数据存储，就分了好几个不同的团队，有的专门做中间件和调度，有的专门做缓存，有的专门做 i/o 优化，有的专门做关系型数据库的持续性存储，可能还有的专门做备份和异地灾难恢复机制。你去请人家一个专家来了，第一，人家专长你多半压根用不到；第二，他可能还真就解决不了你的问题，虽然你的问题没人家那么复杂，但是涉及领域却远超他平时的工作范畴了。大公司要专深的人才，但小公司，特别是创业初期，最需要的是能力驳杂的全栈达人，你还会觉得大公司的人最合适么？
说一下我的一个人才观点，我觉得最适合给创业公司提供完备的技术指导的，既不是如今大公司的技术达人，也不是小公司的多面手，而是见证了一个巨头从小到大的那一小撮技术达人。也就是从 BAT 早期开始就加入并一路跟到公司超大业务规模的核心技术负责人，这样的人，既知道小公司的技术是如何起步的，如何在低成本下完成基础架构的搭建；也知道业务规模爆发后技术架构是怎样演进的，如何应对各种复杂场景中的技术挑战，但是这样的人，基本上都财务自由了有没有，岂是一般创业公司能请的起的呢？ 可是，我们反过来想，这些人当年大多也是从菜鸟工程师起步的，既然人家可以这样起来，你为什么不塑造一个环境来培养潜力股呢？
技术的价值并不是只体现在服从和完成上。似乎和 1 有矛盾，其实是两个不同的层面，保障层面和创造层面。不能因为创造层面的价值去忽视保障层面的价值。
google 倡导工程师文化，允许工程师自己去思考去设想去实现一些自己认为好玩的事情，是的，也可能是一个纯炫技的东西，但也许正好在某个业务线的发展中，这个炫技突然就变得非常有价值。
在上文里，我说以炫技为核心竞争力的往往不是正确的，但是必须指出这里存在一个空间，就是在满足用户需求的具体业务场景中，存在一些特定的技术发挥空间，而在这个领域，非技术人员往往是无法担当指导和规划能力的，但现实是，很多时候非技术人员以为自己可以担当指导和规划能力。
场景说话，一个用户平台，也许是游戏，也许是电商，随便吧，老板说，你看人家有个栏目叫 “猜你喜欢” ，挺好的，你们也搞个。 产品人员来了，说，这个吧，我们把转化率高的放这里吧，这样用户粘性强。运营人员来了，这个，当然放利润率高的了，收益至上。商务合作来了，这个，我刚签了合同，这个伙伴非常重要，老板发话了，他们的东西必须保证给量，我不管，这个位置我要了。然而，没有一个人问一句技术，你对这个位置有啥想法么？ 他们已经认定，技术你只要服从就好了，而他们的出发点都忽略了一个前提，这个位置长期来看其给平台带来的效果好坏，应该是一套机器学习算法自动调优决定的，而不是他们拍脑袋的决定的。
我在过去的发展经历里，我个人认为，最有成果的那些东西，都不是领导安排的，而是自己想做的，做的目的和初心，也不是如何的高大上，而是好奇心，好奇心是最能体现技术价值和发展技术成果的驱动力，我希望更多人能理解这一点，这也是 google 的工程师文化之所以有活力的源泉。 那么，如何让技术的好奇心和公司的业务发展路线尽可能一致呢？我的建议是，在以前的文章里提到过，尽可能让技术懂一些业务，懂一些应用场景，他们对这个了解越多，他们可能好奇心就越贴近你的业务诉求，比如说，我想知道为什么我的这个用户会流失？我想知道为什么我们产品的转化率不如对手的？当他的好奇心和你的业务方向一致时，他的所作所为的价值，很可能超出你的想象。
就好比《三体》里提到的，物理学家之所以去钻研世界的本质，并不是因为各国的政府领导人要求，也不是多么高大上的使命感，而是好奇心，好奇心推动着人类的进步。
回到昨天提到的案例，那个技术大牛说他优化的算法对转化效果的提升极为明显，然后补充了一句，之所以这个事情能很顺利的做成，是因为没有任何领导在这个领域提出任何方案和目标，他们原本只是做一些日志监测，对一些用户行为做了研究，然后基于好奇心，在毫无绩效目标压力的情况下去做了些事情，然后发现效果惊人的好。 当然，这里还有个前提，这个技术大牛在他们公司的项目决策体系里有足够的话语权，可以安排足够的测试和直接推动成果上线，但并不是每个公司都会给技术专家这样的权限。
如果，你只是把技术人员当作俯首听命的执行者，而不肯发挥他们的创造力，那么，他们的价值又如何才能体现呢？ 一个极具思维活力，极具创造才华的技术高手，和你从招聘网站找到的熟练程序员，又有什么区别呢？
文/何晓阳
来源：何晓阳读书笔记（微信号：hexiaoyang101）
创业贤内助（微信号：chuangyewife）
新媒体公司「新知百略」旗下自媒体「创业贤内助」系WeMedia自媒体联盟成员。为你做好创业的贤内助，随时分享与创业相关的新奇点子，有趣有料的案例故事，给你带来灵感、正能量，你的未来不是梦！
QQ：2850252025
微信：xiaoxintech