- 博客(93)
- 问答 (1)
- 收藏
- 关注
RSS订阅
原创 6.1 对偶表示（PRML读书笔记）
本节小结 许多回归的线性模型和分类的线性模型的公式都可以使⽤对偶表⽰，从而引出了核函数。本小节将正则化的平方误差函数（公式6.2）转换成对偶表示（公式6.9）。其中， k(x)T=(k(x1,x),...,k(xN,x))\textbf{k}(\textbf{x})^T=(k(\textbf{x}_1, \textbf{x}),...,k(\textbf{x}_N,\textbf{x...
2019-04-11 09:15:32
970
1
原创 第4章 分类的线性模型（PRML读书笔记）
本章小结 本章讨论分类问题。分类的⽬标是将输⼊变量x分到K个离散的类别CkC_kCk中的某⼀类。最常见的情况是，类别互相不想交，因此每个输⼊被分到唯⼀的⼀个类别中。因此输⼊空间被划分为不同的决策区域，它的边界被称为决策边界或者决策⾯。在本章中，考虑分类的线性模型的，即决策面是输⼊向量x的线性函数，因此被定义为D维输⼊空间中的(D − 1)维超平⾯。如果数据集可以被线性决策⾯精确地分类，那么这...
2019-04-08 19:38:25
333
原创 4.2 概率生成式模型（PRML读书笔记）
本节小结本小节介绍了通过生成式方式求解类的后验概率的方法。我们通过对类先验概率p(Ck)p(C_k)p(Ck)和类条件概率p(x∣Ck)p(\textbf{x}|C_k)p(x∣Ck)分别建模，再根据贝叶斯定理p(Ck∣x)=p(x∣Ck)p(Ck)∑jp(x∣Cj)p(Cj)p(C_k|\textbf{x})=\frac{p(\textbf{x}|C_k)p(C_k)}{\sum_{j}p...
2019-04-06 10:21:27
504
原创 项目管理者必须清楚产品的点点滴滴，可以做随机查看、甚至补位
项目管理者必须清楚产品的点点滴滴：产品当前状态、有没有风险点、bug数量及分布必须使用产品并对产品足够熟悉对产品的各方面至少要随机查看，比如需求描述、交互设计、测试情况，如果有相关背景甚至对后端设计也做相应查看。必要时甚至要补位，比如如果产品需求描述经常不全面...
2019-05-11 18:18:41
246
原创 项目管理：角色必须齐全
不能因为觉得某个产品简单而忽略测试。进一步总结，整个项目过程中，每个角色必须齐全，每个角色要做哪些事情由每个角色提出、项目管理者确认。...
2019-05-11 18:11:52
1006
原创 文档写得好得人升职快
今天在跟一同事讨论文档时，另一同事脱口而出：文档写得好得人升职快。这句话看似笑谈，实则是很有其合理性的。文档要写得好，则必然思路很有条理。而一个人思路有条理，则往往做事有条理，自然容易把自己的事情安排得井井有条；如果是一个团队管理者，那么更容易把团队的事情管理得井井有条。可不就说明了“文档写得好的人往往升职快”。...
2019-05-09 15:27:33
286
原创 产品设计：先有概念，后有界面
好的产品应当是“先有概念，后有界面”。所谓”先有概念“，是指先确定产品中涉及的概念，随后理清概念之间的逻辑关系，概念及概念之间的关系这里我们称之为草图。”后有界面“是指在”概念及其关系“理清楚的前提下，再去做具体的原型。 与面向对象软件设计做下类比，概念类似软件设计里的一个个接口，草图则代表软件设计里的抽象的业务逻辑（接口之间的关联与交互），界面则是把每个接口替换成具体实现类。草图必须是...
2019-05-08 16:27:33
330
原创 研发管理：不能由开发来决定功能点需不需要做测试
公司里出现了几次这样的现象：开发觉得这个地方不需要测，但是测了一下就出问题，更糟糕的情况是最终没测，到生产环境出了问题。 总体说来，很多开发是偏乐观的，没有太多的风险意识。所以不能由开发来决定功能点需不需要做测试，哪些地方需要测试，更多的要由测试或这项目管理者来决定的。当然，项目管理者必须要有风险意识。...
2019-05-08 15:08:26
189
原创 项目管理：不仅要管理项目成员，还要管理所有依赖方
由于产品资源紧张，所以将一块功能交给了外援去做，公司的A员工与外援对接，项目又是与B对接，辗转了好几层。B员工也给出了具体完成的时间点、状态。但是最后发现根本没有达到想要的。这里边的教训是：看似双方达成一致，实则未必，所以对于目标，一定要双方确认。这个很重要，哪怕是啰嗦了一点。对于依赖方，也要跟踪管理。有时甚至要跟踪最终的依赖方 总结起来，就是对依赖方（甚至最终依赖方）也要以项目管...
2019-05-08 11:39:24
315
原创 韬光养晦，上善若水
道德经第八章：水善利万物而不争，处众人之所恶，故几于道。 居，善地；心，善渊；与，善仁；言，善信；正，善治；事，善能； 动，善时。 夫唯不争，故无尤。 人无常在，心无常宽，上善若水，在乎人道之心境，即，心如止水。 水善利万物而不争，不去做过多的争抢，把心思放在做事上，收获往往更大。群众的眼睛是雪亮的，是金子总会发光。就事论事可以，要立足于解决问题，千万不要有不良动机。...
2019-05-06 16:09:28
355
原创 发现组织的问题，解决它，这就是亮点
多去发现组织内的问题，进行调查分析，去解决它，这就是你的工作亮点。职责范围内的，责无旁贷，是首要解决的。职责之外的，也可以无边界去推动或解决...
2019-04-30 15:33:32
173
原创 学会换位思考
每件事情如果只是从自己的角度去考虑问题，很容易陷入误区，最终导致永远无法达成共识。如果换位思考一下，对对方也会有更多的理解，也就更容易达成双赢。...
2019-04-30 12:37:33
230
原创 要有大局观
管理这要有大局观，我觉得有几层意思：不要过于在意个人得失，多从组织得失角度考虑问题。看事情要具有全局视野，抓住主要矛盾。考虑问题要长远，提前布局。...
2019-04-30 12:35:10
369
原创 沟通：多技能、学习能力、泛化能力的重要性
如果经常与不同角色的人沟通，那么有以下特点最好：多技能或者知识面广。这样很容易与对方聊起来。学习能力强。能快速学习需要跟对方沟通的内容。泛化能力，基于自己的知识进行泛化，能与不同背景、技能的人聊在一起。这是最高境界，这样才能够一通百通。...
2019-04-29 17:39:49
737
原创 沟通：不同的人采用不同的沟通方式
跟技术人沟通，可以讲些技术细节；如果跟非技术人沟通，切忌去讲技术细节，否则会听的人家一头雾水。跟高层沟通，多讲宏观，少讲细节。
2019-04-29 17:34:11
2688
原创 重视用户的反馈，及时作出回应
工作中一定要有用户思维，重视用户的反馈，并及时作出回应。用户的反馈是你提高的正向反馈。用户未必是真实用户，也许是你工作的下游，他们对你有依赖。...
2019-04-29 17:28:13
1052
原创 沟通：要有用户思维
沟通时切忌与对方不在一个频道上。所以谈话时，不妨将对方看作你的用户，多去想下对方需要从与你的沟通当中获取什么，这样沟通才够高效。
2019-04-29 17:24:55
159
原创 质量管理体系之验收质量
测试完成之后还要做几轮验收，再加一层保证。验收会更多的以用户视角。第一轮：产品经理的验收。第二轮：售前人员的验收。产品经理参与了从产品设计开始的整个过程，所以对新版本的功能已经很熟悉，容易陷入思维定势。而售前人员对产品新功能并不熟悉，可以提出一些不一样的视角。...
2019-04-29 17:20:29
252
原创 质量管理体系之测试质量
测试人员按照下面几点执行即可：参考需求描述文档和设计文档，设计全面的测试用例破坏性测试对测试之后的bug进行总结，不断循环
2019-04-29 17:14:06
1893
原创 质量管理体系之编码质量
清晰的需求描述文档和详细的设计文档是好的编码质量的基础。所以编码人员需要确保对需求文档和设计文档的理解。在此基础上，编码人员按照设计文档编码。有些编码人员提到不知道如何提高自测覆盖率，其实这跟编码一样，只要按照设计文档进行各种case的自测就能保证足够高的自测覆盖率了。...
2019-04-29 17:10:42
643
原创 质量管理体系之设计评审
设计评审分两块：后端设计评审和前端交互评审。后端设计评审。把后端组长带起来，确保其设计文档质量；然后后端设计文档一律由组长带动进行内部评审，过关之后再组织外部评审；外部评审的参与对象包括架构师、测试人员。前端交互评审。前端交互评审采用轻量化的方式。由前端组长带动大家（主要是产品、测试人员）一起逐步形成完善的交互规范。凡是交互规范里提到的，一律遵循；其余个性化的写在交互设计文档里。 ...
2019-04-29 17:04:21
740
原创 质量管理体系之需求评审
首先，需求评审的主要靠产品。但是，仅靠产品是不够的，还需要后续的架构、设计、测试人员进行补充完善。技术类的产品更是如此。所以，在很多公司，最终如果发现需求评审有问题，从责任的角度：产品一定主责架构/设计/测试人员次之。当然这个是有条件的，条件是“功能点存在，但是不够完备”。如果是一个独立的功能点在需求描述中缺失，那么架构/设计/测试人员是免责的。...
2019-04-29 11:22:48
362
原创 未必要分绝对的对错，双方达成一致才是双赢
技术人往往较真，凡事老是想分出对错。销售却是很务实，与客户成交才是目的，所以他们很会变通。该变通时还是得变通，非要分出对错可能永远没法达成一致，造成的是双输。变通一下达到双赢才更有利于双方。...
2019-04-29 07:57:08
300
原创 把别人的成功或失败也吸收过来作为我们成长的养分
要想成长，不仅要靠自己的经历，也一定多去观察他人的经历，从他人的成功中学习经验，从他人的失败中总结教训。这样的成长将是指数级的。
2019-04-28 22:54:48
199
原创 管理者务必言而有信，切忌轻诺寡信
管理者辐射的是整个团队，是大家的主心骨，必须具有公信力。如果要让大家信服，必须言而有信，切忌为了短期目标而轻诺寡信。一旦失去了团队的信任，做起事来势必大受影响。...
2019-04-28 22:52:03
217
原创 管理者务必一碗水端
《孙子兵法·始计篇》说到“主孰有道？将孰有能？天地孰得？法令孰行？兵众孰强？士卒孰练？赏罚孰明？吾以此知胜负矣。” 法令孰行，讲得是法治的重要性，赏罚孰明，讲得是一碗水端平的重要行。对于任何一个管理者而言，该法治的地方务必法治，该一碗水端平的务必端平，否则必定引起团队成员的不服与猜疑。...
2019-04-28 22:47:01
133
原创 要具有做全、做深、做细的能力
项目在推严格的质量管理体系，对需求说明书、设计文档、编码质量、测试质量，都提出了严格的要求。这时候，每个环节的责任人，必须具备把相应事情做全、做深、做细的能力。其实这个能力是专业人士应该具备的，而且一旦具备了这个能力，也应该是可以泛化到其他事情上的。所以，“做全、做深、做细的能力”应该成为人的基本素质。...
2019-04-28 22:39:27
269
原创 要给下属试错的机会，但是也一定要失败的案例促使其成长
首先，我们要给下属试错的机会。因为他们自己从错误中的成长才更扎实。但是，却不能一味的试错，务必及时的抓住其失败的案例，与其一起总结，促其成长。...
2019-04-28 22:34:45
700
原创 在做深自己领域的同时，也要抓住拓展自己广度的机会
对于想以后从事管理岗位的人来说，做深自己的专业领域固然重要，但是也一定记住抓住拓展自己广度的机会。因为对于管理岗来说，知识的广度会使得管理者更容易与人沟通。所以，抓住拓展自己广度的机会，相当于为未来的管理工作提前做了储备。...
2019-04-28 22:30:33
231
原创 明知不可也要为
“明知不可也要为”，乍一听很怪。试想，如果一个难题摆在我们面前，绕又绕不过去。怎么办？首先，打退堂鼓显然不是好办法，所以只能迎难而上。其次，尽管很难，但是尽力去做了，胜负也未可知。再者，即便败了，那么成也辉煌，败也辉煌。而且这次努力的经历，必然也会成为一笔宝贵的财富。...
2019-04-28 22:25:05
102
空空如也
为什么hadoop比strom的吞吐量高
2015-05-15
TA创建的收藏夹 TA关注的收藏夹
TA关注的人