Misc

這不是一個技巧，也不是一個什麼特別的東西。其實就是在看一些古文的時候，發現字體缺失了。
這裏有一個字體檢測頁：http://ctext.org/font-test-page/zhs

如果你發現表格中的文字都正常顯示了，你就可以不用看本文而直接跳過了。否則，請繼續往下看：

Windows

1. 下载并存取hanazono-20110915.zip此一文档。
2. 打开hanazono-20110915.zip并把字体HanaMinA.ttf及HanaMinB.ttf存到电脑的某一个资料夹。
3. 按一下 [开始]，再按一下 [执行]。
4. 输入 %windir%\fonts，然后按一下 [确定]。
5. 按一下 [档案] 功能表上的 [安装新字型]。
6. 按两下包含字体的资料夹。
7. 选取HanaMinA 及 HanaMinB两个字体。
8. 按一下以选取 [将字型复制到字型资料夹] 核取方块。
9. 按一下 [确定]。

Mac OS X

1. 下载并存取hanazono-20110915.zip此一文档。
2. 打开hanazono-20110915.zip。
3. 按两下HanaMinA.ttf此一文档。
4. 按“安装字体”。
5. 按两下HanaMinB.ttf此一文档。
6. 按“安装字体”。

按照網站的說法，安裝完字體後，除了IE6和OPERA需要額外設置一下，其他瀏覽器都可以自動識別了。我在這裏就不復制如何設置了，因為我沒有這兩種瀏覽器。如果你有，並且在用，還是移步剛才的網站進行查看吧。

識別前：

識別後：

這個字體是在SF日本區的網站上，下載可能有點慢。等啥時候我上傳到我的博客上做一個小分流吧。

下載地址：點擊下載

請不要介意我用的是繁體字。。。

好久沒有參加過聚會了，這次架構師大會怎麼著也得參加，於是我買了門票希望能夠聽到一些不同的東西。雖然最後由於時間由於各種安排，我有一些期望的沒有聽到，但還是聽到了一些比較有興趣的東西。
一、贊助商
為什麼要提這個？畢竟現在各種社區為什麼舉辦不起來？原因有很多，其中有一部分就是因為沒有錢，你想啊，租場地要錢、租設備要錢、錄像要錢，什麼東西都是 靠錢來支撐。如果人來得少了，大家出的份子錢還不夠付付場地費啥的，這時候你也不能讓人加錢吧？如果人來得多了，原先準備的小場地可能就不夠用，或許就會 有人感到不滿意，甚至以後就可能不願來參加。
如果有錢，再加上一群有激情的人，這樣的社區就能夠延續下去，也只有這樣，社區才能延續下去。當然理想情況下，社區應該是自己能夠造血，而不是靠別人來輸血，只有自己能夠造血了，對於外在的壓力才會減輕。
所以，感謝這次的贊助商，也正因為他們，我們才有機會聽到這些知名人士或者說有才華的人給我們的技術分享

二、技術點
大概是因為thinkinlamp舉辦的緣故，所以大家基本上都是講的php相關的技術點。也正因此，更容易被大家所接受和理解。當然今天的技術點並不是 完全與PHP相關，畢竟這是架構師大會。可是誰又能真正的描述什麼是架構師呢？軟件架構師、系統架構師等都能稱為架構師，而今天的分享就幾乎都包含了這些 內容。
1、張爾寧：安居客的架構變遷。張爾寧講的幾點正好是我關注的，搜索和圖片存儲，後期又補充了一些代碼部署和數據統計、數據監控、系統監控等
搜索用的是solr，以前沒有關注過，以後會稍微看看。但圖片存儲這一塊確實是我關心的，雖然我的量肯定沒有安居客大，但我每天也會產品將近2G左右的圖片，嗯，這幾乎是指原圖。如果再算上縮略圖等，那至少也是3G左右，雖然增長幅度不高，但畢竟也在緩慢增加。100天下來，也有300G左右的數據了，雖然磁盤不值錢，但流量值錢啊。再說了就算不值錢，多少塊硬盤也經不起這樣折騰啊。於是它的圖片的存儲方式我就相對比較關注了（我這裏不介紹，事後應該有PPT，大家可以圍觀，否則我這裏就會有太多話想說了）。
然後對安居客的一些小產品和小功能有一些想法。我不知道現在有多少公司會向安居客這樣，因為使用了solr，所以又額外做了一些solr的管理程序；因為要部署代碼，甚至實現了一些簡單的github的界面；為了要管理xxxx，最後又實現了一引起xxx的管理軟件；其實我挺羨慕安居客的，至少他們的頭願意看到他們折騰也願意讓他們折騰。有一些boss就無法理解，為什麼不把本職工作做做好，做一些一個星期只能使用一兩次的WEB管理程序。這其實是很多公司的通病。不講了，再講就變成發牢騷了。不過，這些小工具的實現確實簡化了很多工作，所以我也只能是羨慕：人多啊，人多了想做什麼事情的時候都有人做。 人少的時候，事情都做不完，怎麼有空做這些東西？

2、周愛民：架构表达方法中的界面及其原则。周愛民是一個名人，我一直有訂閱他的博客，只是這兩年更新的少了。他的書除了delphi那本沒有看過外，其他的都算是看過了。今天是第一次看到真人，有點失望，長的不太象大師（開個玩笑）。不過他講的東西就是一個軟件架構師在做的事情了。怎麼樣讓架構能夠適合更多的變化。用aimingoo的話來說，架構橫切、豎切、外包圍 都是一種方法，每種方法都各有優劣，只是現在橫切用的比較多一點。（橫切：假設架構是一個正方型，橫切就橫過來一刀，一些基礎構架，一些是應用核心，希望沒有理解錯）。
周愛民還提出了一些觀點：
1.框架和库的区别：框架有明确的系统原则和模块原则
2.服务和层次化理论：服务是一种“库”、需要解除一些逻辑依赖
當然在提出這些觀點的時候，他是拿Erlang中的一些編程規範來說的，我記得最清楚的就是：盡量少用防禦性編程。
不可否認，很多時候爛代碼都是從防禦性編程裏產出的。

3、程輝：LAMP in Cloud --- 新浪SAE架构与设计。這個確實是我今天比較感興趣的話題之一。因為在沒有用SAE之前，自己也嘗試對PHP做過簡單的封裝，讓他僅用來跑一個小項目，而可以忽略其他的平臺因素。在今天看來，這種做法其實並不是特別可取，因為它犧牲了可擴展性。不過在5.4的時候，PHP也能夠自己就能夠實現成一個小型 Webserver，所以以前的想法又可以付諸實施了。
當然新浪SAE不可能這麼簡單，否則它今天就不可能做在這裏講解了。SAE的早期版本只是實現了一個php的runtime，只是為了這個runtime的安全，他們在上面又加上了zend sandbox和http sandbox，各種各樣的沙盒，使得runtime被攻擊的概率減少了很多。說白了，又有點象java的JVM吧，只是JVM又沒有phprumtime靈活。為了避免因為沙盒帶來的影響，sae又模擬實現了很多東西，比如curl庫（這個在早期的版本中是絕對不支持的，經歷了好多版本後才有這個支持），SAE也提供了一些基本的類庫：圖片處理、LBS、郵件發送、memcache、RDC、Counter、KVDB等等，這些小功能的實現使得用戶在遷移的時候能夠將問題最小化。
嗯，我就將yii做了一些簡單的二次開發，使得它支持SAE，我擴展的yiiforsae與另一位朋友的yii4sae不太一樣。將程序遷移到SAE平臺上最大的問題是兩個：1、上傳2、存儲3、緩存，其他的使用都差不多。因為SAE基於SVN，所以在它的項目裏就不支持通過程序生成文件，生成在項目目錄下。只能使用STorageWrapper將文件寫入到存儲中去。就這個比較繁。
SAE還對.htaccess進行了重封裝，只支持一些基礎功能，這些也足夠了。
SAE對我最大的啟發提10個版本庫。這個在SAE第一次推出的時候就有了，非常實用，因為你可以在兩個版本庫之間隨意切換，即，你在v2.xxx.com上進行開發，當測試完成後，將代碼的默認庫設置為v2即可，只要操作一下鼠標就完成了。如果發現有重大問題，繼續點一下鼠標 。一切就是這樣的簡單。
SAE宣傳的就是穩定、安全、保密。陳輝說了，如果你不放心，你可以上傳ZG處理過的代碼。

4、陈思儒 ：《AMOEBA（变形虫）的架构以及使用》。說實話這個話題我的興趣不是很大，我並非說陳恩儒的東西不好，而且這個玩意大家現在都在玩一個思想。如果真要說，那SAE的RDC已經有它的類似效果了，當然可能性能不如它。不過在目前變形蟲 還不穩定的基礎上，相信沒有多少人願意當小白鼠。
不過它的一些策略、處理流程都是可以值得借鑒的。話說，我也沒有覺得lua都很難學吧？
amoeba的一個缺點在於，因為他支持了多庫多表的即時查詢，所以，對於聚合類的函數，就無法支持了。
當然，尺有所短，寸有所長，思想是可以用來借鑒的

5、潘曉良：百姓网的“非典型”架构之路。這個分享也是我感興趣的。自從第一次知道客齊集後，後面對於它們的關注就相對比較多，只是後來突然消失了不少時間。百姓綱介紹中說他們的代碼是越來越少越來越少，現在只有7萬行不到了。而在之前的分享中張爾寧說他們的代碼有數十萬行代碼了。百姓網的代碼卻還在精簡（這不正是持續重構嗎？）潘曉良說了一點我非常受用：讓用戶盡可以快的打開網站。這點非常重要，現在很多公司為了好看，大量的CSS加上大量的圖片，使得在訪問的時候光這些圖片和CSS的加載就消耗了好多時間，他們怎麼就沒從用戶角度 想？
潘曉良介紹百姓網的架構變遷時用了四個詞做代表：遷移、減少、增加、平衡。當然前面兩個是百姓網的特殊歷史原因所造成的就不做多提了。增加，怎麼增加，對我們來說就很關鍵了，要知道程序不是說你加一臺服務器就自動將性能提升1倍了，要改很多東西。雖然潘曉良沒有提，但，因為他們從最多開始就是40臺左右的服務器，相信這些問題在初期就已經被處理或者已經遇到過了。後期這些都不是問題了。
順便說一下，百姓網才18個工程師。糾結啊，18個人做了這麼多的事情。
潘曉良還提了一下，說是百姓網並沒有用了一些多麼高深的架構，相反他們的WEB只有10臺，DB6、7臺，搜索好幾臺。並沒有多麼複雜的架構，他只是很得意說，他們的負載均衡是硬件的，用的很爽。
最後他還是總結了一下：架构是对目标的极致的最求。確實，架構不是越複雜越好，而在對極致的追求中所掌握好的平衡。

三、嘉賓致辭
幾個嘉賓的致辭也很有意思，時間都比較短，除了安居客的倪军是以講故事的方式介紹了某個架構師的成長歷程，其餘的幾位都是在介紹自己的產品。比如 海丁網、比如愛可生，嗯，我想了想，是啊，人家都贊助了，怎麼也得讓人家介紹一下自己的產品吧。再加上時間也不長，也能夠接受。我在這裏就不多談了。

四、隨想
嗯，我還是不太喜歡互動，雖然在周愛民的提問上有想過要回答那個為什麼傳入對象而不是ID，帶來的後果。其實從當時的PPT上可以很簡單的看出，那個函數大致是這樣：checkXxxxFromCompany，但結果，傳遞進去的是一個pueOrder對象。雖然在函數中是取得了這個pueOrder.getCompanyId()，但這本身就與設計不符。
不過，不喜歡互動好象是程序員的通病。很多人都不太喜歡交流，不知道自己想要說些什麼，也不知道如何將自己的想法傳達給別人，這確實是需要鍛煉的。
在結束的時候套用一句很早的臺詞：相聲（演講）是一門語言藝術。要想掌握好還是很有難度啊。

原文的內容是這樣講的：
如果你常看 HTC 发布的手机的话，不晓得你有没有发现，在 HTC 公布的手机官方图片中，时钟都是指在 10 点 8 分，是巧合吗？还是有原因？关于这个疑问，有不少人提出自己的解释，像是有可能是 HTC 发布第一款 Android 手机 G1 的日期、可能是设计者随便弄上一个时间之后再也没去改它、或者是根本没有原因等等。
-------------
OK，我想這應該算是產品設計的一種，那麼10：08究竟是什麼意思呢？
-------------
前一阵子 HTC 在官方博客里给出了答案。在 12 小时制的数字时钟里（就像下图那个时钟一样），10:08 是在合理的时间范围下，让最多液晶单位亮起来的时间，让时钟制造商可以确定时钟正确显示；大家可能会说如果要让最多的液晶亮起来的话，怎么不用 18:88 呢？因为事实上没有这样的时间。
另外，在传统指针时钟上，10:08 分时，时针与分针刚好会呈现一个 V 字形的「微笑」角度，有「胜利」的意思，这样看起来最对称，所以大家看一些手表的 DM，图片也都会刻意调到 10:08 来拍摄。总之，HTC 采用 10:08 时间的原因就是这么简单，没什么更深层的意义。

▲ 一般的指针时钟，常常会把时间调到 10:08 拍摄照片，指针看起来对称，也不会挡到品牌 logo。
原文來自：http://www.cnbeta.com/articles/191609.htm

我為什麼改用繁體字了？這不是什麼裝逼行為，而是一個無奈和尊重對方的行為。
有很多時候，我轉載了其他人的文章，但是從我的字裏行間卻看不出我在轉載，我覺得這樣不好。當然也有別人曾轉載過我的文章，嗯他們也忽略了我的信息。所以，我才決定，還是用繁體字。
如果我轉載的是簡體版的，大家就很容易看出來是我轉載的內容。黑黑。。。

下面就是我轉載的內容，一目了然吧？：6.2-6.8国外风险投资、并购、IPO清单

-------------------------
看到上面這些新聞，你可以很容易發現，最近的一些熱點，如果是你自己在做項目，你也可以盯著這些方向運作。

有人說：
产品经理，是个综合岗，知识当然是越全面越好。

× 你有没有对用户体验有理性的和感性的认识？
× 你有没有优化产品，提出产品改进方案的能力？
× 你能不能把握互联网的最新趋势？
× 你懂online marketing不？
× 你有技术背景不，能跟CTO顺利沟通，并且在不被其气场的打压下把他给说服不？
× 你懂市场营销不，能跟市场人员顺利沟通不？
× 流程图，ppt，这些都是必须的，你得不停演示。
× 你的外语好不好？每天早上来公司第一件事，是不是去读 techcrunch， readwriteweb，smashing magazine 这些博客？
× 你懂管理不？如果你有一只团队，能不能带领这个团队打造一个初创企业？

還有人說：
产品经理的主要工作内容

在战略层面需要考虑的内容
1.产品的定位(理解市场，细分市场，了解用户)
2.品牌的战略(经营品牌就是经营产品，品牌的价值往往反映了产品的价值)
3.产品战略规划(战略即方向，方向错误全盘皆输)
4.产品线规划和产品路标规划(后续研发项目开发的重要指导)
5.项目组合管理(产品组合分析和选择，组合决策，动态管道管理)
6.CI竞争情报和竞争战略(充分了解对手才可能打败对手)

在产品规划和执行层面
1.产品规划和技术平台规划,产品项目的版本规划。
2.管道管理和资源管理(资源需求计划，资源分配和交易，多项目间资源平衡)
3.多项目和项目群管理(产品级项目管理)
4.市场需求分析。
5.产品级风险和问题管理。
6.产品需求全生命周期管理(需求管理，需求收集，$APPEALS，需求验证和跟踪)
7.结构化产品开发方法论(并行工程，产品开发团队，决策机制)

产品开发团队管理
1.产品开发团队的组织结构和角色分工。
2.团队激励机制和绩效管理机制。
3.矩阵管理沟通汇报机制。
4.团队沟通平台建设。
5.产品层面的培训计划和资产库。

产品实施和推广
1.产品推广和实施计划，推广策略。产品营销管理。
2.产品的宣传手册。
3.定制化的产品项目建议书和产品解决方案PPT。
4.产品定价和定位策略。
产品经理的职责以及相关评价

做为一名新进产品经理，甚至一名资深PM，你可能都或多或少对这个职位产生某种迷惑。到底什么是产品经理？这个职位的主要职责是什么？在IT产业的不同领域，甚至在同一领域的不同公司，这个职位的定义似乎都有不同。

本文尝试根据自己多年的产品经理经验，给出产品经理的主要职责。 虽然在不同的公司，产品经理的角色和职责互有差异，但是有一些关键职责是任何一个产品经理都应承担的。可以将其归纳为如下六个方面：

1、市场调研

市场调研是指研究市场以了解客户需求、竞争状况及市场力量（market forces），其最终目标是发现创新或改进产品的潜在机会。

可以通过下面的方式进行市场调研：

* 与用户和潜在用户交流
* 与直接面对客户的一线同事如销售、客服、技术支持等交流
* 研究市场分析报告及文章
* 试用竞争产品
* 仔细观察用户行为等

市场调研最终会形成商业机会、产品战略或商业需求文档（BRD），详述如何利用潜在的机会。

2、产品定义及设计

a) 产品定义是指确定产品需要做哪些事情。通常采用产品需求文档（PRD）来进行描述，PRD可能包含如下信息：

* 产品的愿景
* 目标市场
* 竞争分析
* 产品功能的详细描述
* 产品功能的优先级
* 产品用例（UseCase）
* 系统需求
* 性能需求
* 销售及支持需求等

b) 产品设计是指确定产品的外观，包括用户界面设计（UI，User Interface）和用户交互设计（User Interaction），包含所有的用户体验部分。在大型公司里，PM通常和UI设计师或互动设计师一起完成产品设计，不过在小公司或者创业公司里，产 品经理也许需要全包这些工作。

这是产品经理工作中最有价值的部分， 如果产品经理工作中不包含这部分内容，那几乎可以肯定滴说，那不是产品经理的工作。

3、项目管理

项目管理是指带领来自不同团队的人员（包括工程师、QA、UI设计师、市场、销售、客服等），在预算内按时开发并发布产品。其中可能包括如下工作内容：

* 确保资源投入
* 制定项目计划
* 根据计划跟踪项目进展
* 辨别关键路径
* 必要时争取追加投入
* 向主管领导报告项目进展状况等

在大型公司里，通常会有项目经理来处理大部分项目管理工作，产品经理只需提供支持。不过在创业公司里，产品经理通常需要自己进行项目管理。在有些公司，技术负责人也可能做为项目经理，处理大部分项目管理事宜。

4、产品宣介

主要包括和内部同事如老板、销售、市场、客服等沟通产品的优点、功能和目标市场，也可能包括向外界如媒体、行业分析师及用户宣介产品。

大公司的产品经理通常都有产品市场、市场推广和媒体关系（PR）团队帮忙进行对外的产品宣介。

这是除了产品定义和设计之外，对产品经理而言价值第二高的工作，尤其是在向老板、市场同事宣介产品并让他们感到兴奋的时候。

5、产品市场

主要是对外的信息传播——告诉外界有关产品的信息。通常包括制作产品数据表、手册、网站、Flash演示、媒体专题以及展会演示等。

在大型公司，产品市场工作通常不会由PM来负责，这些公司会有专门的产品市场经理来打理此项工作。当然，这种分工最大的缺点就是导致沟通效率较低，并会削弱对外传播。

在某些公司，“产品管理”和“产品市场”被认为是同义词，会由一个人担当两者的职责。而在那些将产品管理团队和产品市场团队分开的公司，后者会打理本节所提及的工作职责，同时他们也可能会承担“市场调研”、“产品宣介”和“产品生命周期”管理的部分工作。

6、产品生命周期管理

指那些随着产品经历概念化->发布->成熟->退出市场整个生命周期中的产品管理活动。

主要包括的工作有：

* 产品定位
* 产品定价及促销
* 产品线管理
* 竞争策略
* 建立或收购合作伙伴
* 识别并建立合作关系等

产品经理和产品市场、BD及市场沟通同事一起完成这些工作。

希望这篇文章有助于你了解产品经理（包括产品市场经理），以及他们在公司中密切合作的部门，并祝你成长为一名优秀的产品经理。




互联网产品经理是一个累活；不知道很多人觉得互联网产品经理是一个美差的缘由何在。从竞争对手分析、市场调研报告、需求分析这些大方面到一个页面 核心元素的位置、核心元素的状态（变化）等无一不包括其中。互联网是一个特殊的行业，信息极其发达而且有人免费的做语言之间的转运工具，在大洋彼岸的一篇 文章凌晨刚过就被翻译成了我们的语言，无论好坏，基本意思通顺了。于是，很多思想就被引入了。在嘈杂的声音背后是各种各样的观点；不过在某些论坛上看到了 某些帖子时从能发现这是人么的感叹。
所以，互联网产品经理是一个累活。

在现实工作中，互联网产品经理的角色也是不尽相同，从制作线框图到业务策划业务分析均被称为产品经理。
同时，在互联网产品经理中间把一本书《产品经理手册》奉若产品经理的必修课，这件事是不错的；不过那本书从其本身的角度来看并不适合互联网行业的产品经理。
在传统行业，产品经理原于矩阵式管理，我曾经在大型项目类软件公司接受过丰富的项目经理培训（主要是HP模式的培训），培训的核心是跨部门领导 （协作：cooperation）和无冕之王（群众领袖的意思）。一般意义上的项目经理就是一个做文档和备案的记录员；但是，对于一个项目而言真正的产品 经理是这个项目的CEO，能够把握和掌控整个项目人员调度、工程进度、风险和资金等。在互联网行业，其矩阵式管理和协调的能力受到了极大的制约，主要的协 调对象成了技术部门而不是市场部门，这是很有意思的现象。这当然也有其行业特殊性。（不排除互联网企业的产品经理具有良好的市场协调能力；我仅针对某个意 义上的普遍提一点看法。在很多企业的流程中是销售和市场直接和运营衔接，产品经理的沟通是在新产品讨论会或者产品改版中遇到大量的信息反馈；平时的信息反 馈是看到的网站数据而非精良的客户数据）
在书的开头提到了一句很重要的话：要做一个有天分的产品经理，其关键是必须要以市场为导向。
目前，在互联网行业某条产品线的产品负责人基本能够达到书中所提到的产品经理的素质和工作内容。

不过，互联网行业的产品经理有其多样性，在技术性研发公司可能算法和技术主导的人员被称为产品经理，在以市场运作和内容运作为主导的方向上具有策划性质的运营或者编辑人员被称为产品经理。这导致了互联网产品经理的服务内容多样性、交付物的多样性和手段方法的多样性。
很难用某一个统一的标准和手段来概括互联网产品经理的特征和工作内涵。
大体而言，通常意义上的产品经理工作内容和职责还是有较为明确的界定的。并且，对产品经理而言其人格魅力也是不可或取得一部分。

互联网产品经理的交付物一般有：（所有的，并非每一个产品经理都需要做这些）
MRD——市场需求文档
PRD——产品需求文档
Wireframes——线框图
Blueprints——设计蓝图
Metadata schema

Navigation Systems——（配合交互设计一起完成）

PPD——和设计、前台工程师一起完成


互联网产品经理经过各类讨论总体上讲要看几本书：
《Information Architecture》
《The Product manager’s Handbook》
《Human-Computer Interaction》
《Introduction to Algorithms》
《Requirements Analysis Form Business Views to Architecture》
《Mining the WEB : Transforming Customer Data into Customer value》
《Influence science and Practice》
《The Practice of Management》
《Emotional Design: why we love(or hate) Everyday Things》
《Cognitive Psychology》
《Lateral thinking》
当然还有很多书是需要阅读的。

互联网产品经理的常用工具：
Office系列——word execl powerpoint Publish
思维脑图
MAC下的原型工具：OmniGraffle
等很多软件。

不过这这些书籍的背后，产品经理需要的一项基本功就是人格魅力；没有人格魅力的产品经理很难形成意见领袖。
自身修炼是必不可少的。


就产品经理的职责看，第一是负责策划与产品有关的活动，如分析市场（消费者、竞争者和外部环境），并利用这些信息指定产品的营销目标和策略。第二 是与企业中的其他部门合作，如产品研究与开发、生产、销售以及财务部门，通过内部游说获得其他经理人员的协助与支持。因此，他的工作贯穿整个价值链的始 终。

产品经理为他们负责的产品指定营销目标和战略，他们所做的关键决策是战术性的，围绕着营销组合进行：该花多少钱去做广告？怎样应付竞争者的折价促 销活动？什么样的分销渠道才合适……总之，产品经理因产品在市场的一举成功而成为企业的功臣，也可能因为一时的疏忽成为众人痛打的“落水狗”。

至于产品经理负责的地域大小对职责影响不大，只是地域越大，越需要有全局的眼光和观念，要负更大的责任，当然，会得到更高的报酬。


产品管理的职位体系

产品专员（产品经理助理）——产品高级专员——产品经理——高级产品经理/产品线经理/产品组合经理——产品总监——产品副总裁，产品管理的职位体系是如何？

要弄清楚这个问题，比较全面而且典型的方法应该是对一些多品牌、多产品线的公司的产品管理体系进行研究，包括对产品管理人员、一般管理岗位甚至高阶主管进行一些书面访谈，并进行不同公司之间的对比研究。

通常而言，在外国公司的例子更加具有价值，因为国内公司的产品管理经验更多的是学习和借鉴这些公司的经验。国内公司单纯依赖自己培养的管理人员是 不可想象的，因此中高层的产品管理人员必须接受过正规的产品管理培训并且具有产品管理经验才可以胜任。国内著名公司的产品管理的成功更多的来自于对这些科 学的管理体系的借鉴，并将它们应用到营销实践中去，结合对中国市场的了解，加之对市场的直觉等因素，从而达成产品管理目标。

1.产品专员（产品经理助理）

我们可以看一看国外公司招聘产品管理体系最基层的产品专员（产品经理助理）的资格要求：具有商学院的专业学历，一般要求具有MBA学位；不需要过 多的指导就能够知道工作的重要和优先次序，并具有独立完成这些工作的能力；有领导素质并且能够指导他人完成工作；对市场有直觉的判断能力；能够逻辑清晰地 分析问题；有良好的管理技能；具有可以培养成为全面产品管理人员的潜力和资质。

产品专员（产品经理助理）是保证公司产品管理体系能够有效运行的基础环节，因此非常重要。他们一般都是在工作过程中进行不断地培训和积累经验，不 仅对销售要有基础的了解，而且要了解市场是如何被有效管理、公司的业绩如何被有效达成、产品管理是怎样渗透到公司管理的每一个环节、消费者/零售商/经销 商是怎样思考的，等等。在产品专员（产品经理助理）的岗位上面，当他们能够担负起销售规划工作、进行简单的财务预算控制、产品计划协调、管理促销以及学会 了与公司各个部门打交道，而且懂得在这个过程中不断地通过协调沟通使自己的工作得到各种资源的支持的时候，升职为产品高级专员的时候就该到了。按照一般的 情况进行统计，产品专员（产品经理助理）跨越这个过程通常需要20个月左右的时间。

在我所接触的产品专员（产品经理助理）人员中，曾经有少数人，看起来对数字非常敏感，并且具有清晰地分析数字的能力，似乎是十分科学严谨的思考和 管理者。其实不然。产品管理人员不能够只懂得数字，更重要的是通过这些数字发展成为策略，并且几乎在所有的时候都能够迅速地发现关键问题所在，不是在次要 的问题上纠缠不休。

2.产品高级专员（副产品经理）

产品高级专员其实是一个非常有意思的岗位。它介于产品经理和产品专员（产品经理助理）之间。我的经验告诉我，一个只会按照程序工作而没有思路、没 有策略发展能力，不懂得利用组织的空隙发展和争取有助于自己工作完成的产品专员（产品经理助理）永远不应该被升职为产品高级专员。因此，产品高级专员通常 是从那些表现优秀，能够在产品管理过程中迅速的使产品管理的绩效得到提升，使产品线得到延伸，使产品的生命周期延长并且帮助使自己管理的品牌变成有长期价 值的品牌趋势的产品专员（产品经理助理）中发展而来。不同能力和资质的产品专员（产品经理助理），有经验的产品高级专员很容易就可以通过工作表现分辨出 来。

在很多时候，产品高级专员要管理一个产品的一些比较重要的工作，或者全面管理一个小的品牌也是有可能的。优秀的产品高级专员在向产品经理报告的时 候，从来不会把没有解决方案的问题汇报给他的上司，并且他必须能够有效且独立地与生产、研发、技术、市场研究、广告等部门沟通解决相当一部分问题。

3.产品经理

产品经理是产品管理体系中的核心岗位，被授权负责对产品进行全面地管理，包括年度计划制定，战略和战术计划的制定，同时保证能够被得到实施。在被 赋予全面管理产品的时候，产品经理必须具有全面的能力，这个时候，仅仅具有产品广告和促销能力的时候就注定不可能高质量地完成产品管理的职责。产品经理必 须能够推动所负责的产品项目的发展和推进，并使得它一步一步靠近公司的目标，成为决策和执行的关键角色。

我先后曾经负责或者协助负责过多个产品的管理。在这些产品中，不同的产品处于不同的产品周期阶段，选用的分销渠道、采取的营销和传播策略也各不相 同。在这些过程中，你可以接触到不同职能部门的专业管理人员，了解他们是如何站在自己专业的角度考虑问题，仅仅从产品管理人员自身的角度来考虑问题不是有 效的方法，它只能使工作完成速度被延缓。

通常，在一个多品牌管理的公司，产品经理大约有10％左右的时间与自己的上级在沟通，20％左右的时间是培训自己的产品管理小组的成员（如产品专 员、产品高级专员）并指导他们完成工作，大约30%的时间是与广告代理商和职能部门沟通，10％左右的时间解决一些程序性的工作，其余的时间则被用来思考 产品线的发展策略并制定商业计划。什么样的产品经理是好的产品经理呢？经验和研究告诉我，那些不仅能够拿出三年左右的商业计划，而且能够清晰地表达出在这 个计划中的不同阶段应该从事哪些工作，怎样和配置多少资源，怎样使资金投入的财务风险达到最小的产品经理，是最好的产品经理，他们具有进一步晋升为更高阶 主管的能力和潜力。

4.高级产品经理、产品线经理和产品组合经理

高级产品经理，产品线经理（Product Line Manager）和产品组合经理（Product Portfolio Manager）一定是由那些曾经在产品经理岗位上有优秀表现的人员来担任。他们不再只是管理一个产品，而是管理多个产品。通常一位产品线经理或者产品组 合经理下面会有2个或者以上的产品经理为他工作。

因此，他们的工作决不是是一些细致具体的产品管理工作，他们必须平衡不同产品的预算，使得资源得到有效合理的配置，保证产品线（Product Line）、产品组合(Product Portfolio)的发展目标，并且根据实际情况对资源的调配进行调整，使新发现的生意增长机会得到实现。

5.产品总监、产品副总裁VP

产品总监、产品高级总监、产品副总裁VP是产品管理体系的顶端职位，属于高管层的人员。他的核心工作是规划企业产品策略，制定业务单元的发展计划，并对日常性的营销管理工作承担最终责任。

产品管理体系正是通过以上的不同岗位完成自己的职能。一个产品管理体系不一定要具有以上所有的岗位，但是必须完成以上体系不同岗位应该完成的工作，缺少其中的任何一环，产品管理的表现就会受到影响，从而直接影响公司的成长。


很多人对“产品经理”的三点误解

1、 产品经理是团队管理者

很多人误认为产品经理就是团队的管理者，就是传统意义上的manager。

其实不然，“产品经理”负责产品的管理和经营，“经理”负责某个组织或团队的管理和经营，这一词的差别对于用人单位来说也许无关紧要，明确工作职责就行，但是作为应聘者往往因为这个闹出笑话，甚至影响了工作和职场生涯。

我有个同学，之前一直存在这个误解，到某公司应聘产品经理，商谈之后很快入职，上班第一天，他惊讶的发现该公司作业都是跨部门式的，没有专属自己的团队，他所在的是产品管理中心，每个人都是产品经理。这让他工作和心态上都适应不了，感觉自己被骗，没几天就离职了。

其实对于部门完善、分工明确的公司来说，这种跨部门式的工作方式是很正常的，而且似乎这就是一种标准，他们招的是产品管理人员，而非团队管理人员。

那么产品管理和团队管理有哪些区别呢？

产品管理（产品经理）：对所担当的产品或者产品线整个生命周期负责。这个周期包括产品策划、需求/功能、产品Demo、产品前端呈现、可用性、产 品测试、产品包装、产品上线、产品经营/整合、产品跟踪/诊断、产品优化、新的需求和功能、新的Demo···这样一直迭代下去，直到你的产品退出市场为 止。这个周期中的环节很多，不要被吓着，上面提到的那些部门完善、分工明确的公司，每个环节都会有专门的部门来协助完成，而产品经理更多的是沟通、协调、 挖掘、时间节点、策划让所负责的产品或者产品线良性的、有计划的发展下去。作为产品经理，虽然针对产品本身有很大的权利，可以对产品生命周期中的各阶段工 作进行干预，但从行政上讲，并不像一般的经理那样有自己的下属，但他又要运用很多资源来做事，因此如何做好这个角色是需要相当技巧的。

团队管理（manager）：对自己所主管的部门进行有效规划，制定相应的战略目标和发展规划，与自己的部属一起，通过切实有效的办法，使之逐一落到实处，逐步实现。这个我就不多说，大家都清楚！

不要因为产品经理在公司里没有中高层这样的头衔而懊恼，一个成功的产品经理绝对具备将军的风范和能力！试想，在管理产品的过程中你能协调好那么多 的部门和人，而且这些人的绩效或者经济利益和你还没有直接的关系。那么转型去做团队管理，去做中高层，团队的绩效和经济利益都在你控制中，你还有什么好担 心的呢？

记得业内有句话：一个成功的产品经理不但能引导产品的发展，而且能引导公司的发展。

2、 产品经理只要负责产品上线

这不仅仅是个误解的问题，牵扯到产品经理职业发展的两个方向。

有一种产品经理往往是一个产品上线之后就不管了，开始着手另一个产品，我称之为代孕型；另一种是负责整个产品的生命周期，直至产品退出市场，我称之为母亲型。

为什么说会是两种发展方向呢？我们就从生孩子说起。

现在社会上有个职业叫“代孕”，让我想起另一个职业“ji女”。我的联想并不是觉得代孕这个职业的轻浮，而是因为这两个职业的相近，前者是出卖子宫，后者是出卖阴道。换句话说，代孕这个职业只要30岁以下有子宫的女性都可以胜任。

好！大家已经明白我要表达的意思了。只要是有一点互联网从业经验的人都很容易转型到代孕型产品经理。这样的产品经理时刻都充满着危机感，一成不变 的工作一方面让他们感到生活的空虚和迷茫，一方面却又自我感觉很NB，抱怨着工作枯燥的同时频繁的跳槽。对蕴育中的产品筹划着天花乱坠的未来，最后出来的 要么是畸形、要么丢给别人养、要么半路夭折。想学习ji女一样吃青春饭赚个几年就从良回家嫁人养老，可是偏偏一个月的薪水还不如ji女一天的收入。

也许我说得偏激了一点，但是此类的产品经理占到了60％，也许还要多。这便是产品经理这个大家庭中一类分支的生存现状。

而作为另一个分支像母亲扶养孩子长大一样，经营产品的这类产品经理却是将这一职位能力真正体现的群体。女性的伟大不在于繁衍后代，真正伟大的女性 是母亲，她们辛勤的养育着自己的孩子，教她们说话、走路，教育孩子做人、在激烈的社会中生存。这种类型的产品经理通过长期的积累和丰富的业务经验，对市场 具有敏锐的嗅觉，对产品的发展具有很强的把控能力，像铁轨一样风吹日晒的工作着，保证火车朝终点有序的运行。虽然很辛苦、肩负着巨大的压力、产品策略随时 都可能需要调整，或者迎合公司的战略将产品做出牺牲，但是他们感到幸福和快乐。从职场上来说，这类产品经理炙手可热，因为他们往往可以创造价值，甚至为公 司带来新的生机。

要改变代孕型的职业现状：

A、从现在开始就主动的考虑产品上线之后的经营，不要惧怕困难，不要高估自己的身份，你甚至要做好亲自接触客户卖你产品的准备。

B、即使你的产品交接给其他人负责，也应该不遗余力、毫无保留的帮助接管的人，不要吝啬或者心理不平衡，既然是公司的决定，哪怕是你离职了，生个孩子是多不容易的事情！

C、产品发展遇到困难，不要轻易的抛弃它，既然当初做这个产品，就应该给自己多一点信心。

D、不要放过任何一个宣传你产品的机会

E、多关注市场上类似的产品，学习他们是怎么做的，模仿可以让你快速的上路，一旦你熟悉了路子会有很多新的创意出来。

3、 产品经理是无冕之王

这绝对是一个冠冕堂皇的说辞。 “无冕之王”已经让很多同仁对产品经理这一职位充满了幻想，似乎从事这个职位就可以呼风唤雨、指点江山了。就像我小时候幻想着成为一家之主，到时候可以想 买啥就买啥，想吃啥就吃啥。可是当我真的成家之后，发现其实“一家之主”更多的是一种责任。

所以，“无冕之王”这个词只是看上去很美。一个真正能做到无冕之王的产品经理，需要具备很多条件，例如丰富的行业经验，大佬级的人物了，大家都对他景仰；在公司与各部门长时间的磨合你的能力和你的人品被大家认可；你通过努力争取到了高层对你负责产品的支持等等。

在管理一个产品的过程中，90％的工作需要产品经理自己去协调，公司不会动不动就召集大家或者发个授权通知。你所要面对的是其他部门也有时间排 期，不是你说要做就能给你做，这考验你的计划能力，能不能把一个月甚至一个季度之后的事情现在就来计划，进入其他部门的排期。有时候即使进排期了，也不能 坐着等，还得跟进，人不是机器，每个人都有自己的主观意愿，让对方做个页面，效果也许会天地之差，或者你的需求说要做个电视机，结果会出来微波炉。

前几天公司内部培训，让几位产品经理说说这个职位最重要的能力是什么，有答沟通能力，有说时间管理能力、运营能力等等。最后投影仪放出两个大字“主动”

是啊！主动才是无冕之王的精髓所在！
-------------部分內容來自：http://kaidi0314.iteye.com/blog/1393492
因為最近正在謀求轉型，所以自然對這些內容就關注的比較多一點。

本文来自infoQ，关注它的原因是因为又拍网这种图片超多而且文件较小的架构，我在不久的将来可能会遇到这个问题。所以先了解一下。

原文地址是：http://www.infoq.com/cn/articles/yupoo-partition-database
我这里只做摘要，如果要看，还是直接看原文吧：

分库设计

和很多使用MySQL的2.0站点一样，又拍网的MySQL集群经历了从最初的一个主库一个从库、到一个主库多个从库、 然后到多个主库多个从库的一个发展过程。

最初是由一台主库和一台从库组成，当时从库只用作备份和容灾，当主库出现故障时，从库就手动变成主库，一般情况下，从库不作读写操作（同步除外）。随着压力的增加，我们加上了memcached，当时只用其缓存单行数据。 但是，单行数据的缓存并不能很好地解决压力问题，因为单行数据的查询通常很快。所以我们把一些实时性要求不高的Query放到从库去执行。后面又通过添加多个从库来分流查询压力，不过随着数据量的增加，主库的写压力也越来越大。

在参考了一些相关产品和其它网站的做法后，我们决定进行数据库拆分。也就是将数据存放到不同的数据库服务器中，一般可以按两个纬度来拆分数据:

垂直拆分：是指按功能模块拆分，比如可以将群组相关表和照片相关表存放在不同的数据库中，这种方式多个数据库之间的表结构不同。

水平拆分：而水平拆分是将同一个表的数据进行分块保存到不同的数据库中，这些数据库中的表结构完全相同。

拆分方式

一般都会先进行垂直拆分，因为这种方式拆分方式实现起来比较简单，根据表名访问不同的数据库就可以了。但是垂直拆分方式并不能彻底解决所有压力问题，另外，也要看应用类型是否合适这种拆分方式。如果合适的话，也能很好的起到分散数据库压力的作用。比如对于豆瓣我觉得比较适合采用垂直拆分， 因为豆瓣的 各核心业务/模块（书籍、电影、音乐）相对独立，数据的增加速度也比较平稳。不同的是，又拍网的核心业务对象是用户上传的照片，而照片数据的增加速度随着 用户量的增加越来越快。压力基本上都在照片表上，显然垂直拆分并不能从根本上解决我们的问题，所以，我们采用水平拆分的方式。

拆分规则

水平拆分实现起来相对复杂，我们要先确定一个拆分规则，也就是按什么条件将数据进行切分。 一般2.0网站都以用户为中心，数据基本都跟随用户，比如用户的照片、朋友和评论等等。因此一个比较自然的选择是根据用户来切分。每个用户都对应一个数据 库，访问某个用户的数据时， 我们要先确定他/她所对应的数据库，然后连接到该数据库进行实际的数据读写。

那么，怎么样对应用户和数据库呢？我们有这些选择：

按算法对应

最简单的算法是按用户ID的奇偶性来对应，将奇数ID的用户对应到数据库A，而偶数ID的用户则对应到数据库B。这个方法的最大问题是，只能分成两 个库。另一个算法是按用户ID所在区间对应，比如ID在0-10000之间的用户对应到数据库A， ID在10000-20000这个范围的对应到数据库B，以此类推。按算法分实现起来比较方便，也比较高效，但是不能满足后续的伸缩性要求，如果需要增加 数据库节点，必需调整算法或移动很大的数据集， 比较难做到在不停止服务的前提下进行扩充数据库节点。

按索引/映射表对应

这种方法是指建立一个索引表，保存每个用户的ID和数据库ID的对应关系，每次读写用户数据时先从这个表获取对应数据库。新用户注册后，在所有可用 的数据库中随机挑选一个为其建立索引。这种方法比较灵活，有很好的伸缩性。一个缺点是增加了一次数据库访问，所以性能上没有按算法对应好。

比较之后，我们采用的是索引表的方式，我们愿意为其灵活性损失一些性能，更何况我们还有memcached， 因为索引数据基本不会改变的缘故，缓存命中率非常高。所以能很大程度上减少了性能损失。

索引表的方式能够比较方便地添加数据库节点，在增加节点时，只要将其添加到可用数据库列表里即可。 当然如果需要平衡各个节点的压力的话，还是需要进行数据的迁移，但是这个时候的迁移是少量的，可以逐步进行。要迁移用户A的数据，首先要将其状态置为迁移数据中，这个状态的用户不能进行写操作，并在页面上进行提示。 然后将用户A的数据全部复制到新增加的节点上后，更新映射表，然后将用户A的状态置为正常，最后将原来对应的数据库上的数据删除。这个过程通常会在临晨进行，所以，所以很少会有用户碰到迁移数据中的情况。

当然，有些数据是不属于某个用户的，比如系统消息、配置等等，我们把这些数据保存在一个全局库中。

--------

问题我就不列了，其实各种问题都会遇到的....

//...................这是缓存的问题，我也准备这么处理

revision信息也是存放在缓存里的，Key为Photos-revision。这样做看起来不错，但是好像列表缓存的利用率不会太高。因为我 们是以整个数据类型的revision为缓存Key的后缀，显然这个revision更新的非常频繁，任何一个用户修改或上传了照片都会导致它的更新，哪 怕那个用户根本不在我们要查询的Shard里。要隔离用户的动作对其他用户的影响，我们可以通过缩小revision的作用范围来达到这个目的。 所以revision的缓存Key变成Photos-{shard_key}-revision，这样的话当ID为1的用户修改了他的照片信息时， 只会更新Photos-1-revision这个Key所对应的revision。

因为全局库没有shard_key，所以修改了全局库中的表的一行数据，还是会导致整个表的缓存失效。 但是大部分情况下，数据都是有区域范围的，比如我们的帮助论坛的主题帖子， 帖子属于主题。修改了其中一个主题的一个帖子，没必要使所有主题的帖子缓存都失效。 所以我们在DBTable上增加了一个叫isolate_key的属性。

这是一篇2年前的文章，之所以会再拿出来说，主要还是因为其中的一些话仍然在打动我。虽然时隔两年，但这些内容并没有过期。
原文在：Flipboard：iPad 上的革命性社交新闻应用初探
部分摘要：

1. 什么是 Flipboard？它做了一件非常简单的事情：把你的 Twitter 和 Facebook 变成了一本杂志。你还可以建立一个自定义的杂志，要么选用 Flipboard 内建的版面，要么直接导入Twitter 的列表。这是一个非常强大而且使用感受十分美妙的 Twitter 阅读方式。同样的，你也可以把个人 Twitter 帐号、或者某个品牌的 Twitter 帐号转换成 Flipboard。你可以在 Twitter上 跟随 Techcrunch，然后使用这个应用把 Techcrunch 转换为漂亮的像杂志一样的界面，这样的界面比任何其他阅读器都要容易阅读。
2. 对于视觉的研究证明，如果一个页面有一行大标题，是其它标题的两倍，这个页面更可能被人们所阅读。图片也同样，如果你在一个页面上放的图片是同样尺寸，另 一个页面上放的图片中有一个图片比其它图片大两倍，人们会更加注意有大尺寸图片的那个页面。我们的大脑就是这样工作的，一个大的标题和图片在我们观看页面 的时候提供了一个进入点。
3. Flipboard 是怎样做到这一切的？毕竟，我的账户在 Facebook 上有 1800 个好友，而在 Twitter 上，我跟随了 19,000 人，但 Flipboard 仍然成功过滤了绝大多数的“杂讯”(其他客户端没有这个功能)。事实上，它有自己的一套逻辑来选择关联性最大的内容。比如说：有大量评论的，很多人喜欢 的，很多人 retweet 的。它还会根据状态信息的内容来过滤相关的图片并把它们显示出来。（膘叔：不要相信这些话，如果这是真的，那人人都能做了。）
4. 站在内容创造者的立场，我很担心这会将过多品牌效应和广告利益从他们身边抽离。比如，我分享 Techcrunch 的文章的话，得到的好处还要多于在他们的内容被分享到 Flipboard 中得到的。这 可不好。而且内容创造者也需要一个更好的方式来告知 Flipboard 他们在用的正文篇幅。现在 Flipboard 只是通过内容创造者的 RSS 种子来分析他们的同步规则，究竟是全文输出、部分输出还是仅输出标题，但是 Flipboard 需要和内容方就其自身意愿进行沟通，因为我相信很多内容创造方不会乐于见到目前他们在 Flipboard 中所呈现的内容。站在用户的角度，我发现这种阅读体验很棒，所以媒体还是应该和 Flipboard 多沟通、合作，而不是如默多克（Rupert Murdoch ）一样激动失控。

5. 位于加利佛尼亚 Palo Alto 的 Flipboard 公司创始人是 Mike McCue，Tellme 和 Evan Doll 的前 CEO，曾在苹果公司做过iPhone 高级工程师。

   Flipboard 刚收购了 Ellerdale，这个公司开发了一组基于 Twitter 的实时搜索工具。Ellerdale 的联合创始人 和 CTO Arthur van Hoff 做为 CTO 加入了 Flipboard 公司。

   van Hoff 说有两年历史的 Ellerdale 一开始的目的是开发一个个性化的网络产品，但是投资者认为风险大，所以它先开发了技术，然后找到了用武之地。只有到了现在，那个最初的主意才有了价值。 “我们一直在开发一个伟大的分析引擎，但我们没有找到将内容分类导出的传导机制，我们的站点只是一个演示，不是一个产品，现在加入 Flipboard 之后，我们有了一个伟大的产品“。

   McCue 说 Flipboard 一开始会是一个免费应用，在未来，公司会探索广告，订阅模式，以及和出版商分享收入。公司也计划尽快加入其它的内容渠道，比如 Tumblr, LinkedIn 和 Yelp。

   Flipboard 现在有 1050 万（10.5 million dollars）的投资，来自 Kleiner Perkins 和 Index Ventures。其它投资的风投包括 Twitter 的创始人 Jack Dorsey，Google 投资人 Ron Conway，Facebook 联合创始人 Dustin Moskovitz，Peter Chernin创立的 Chernin Group， Alfred Lin, Peter Currie, Quincy Smith, actor/entrepreneur Ashton Kutcher, 主流投资商 Kleiner Perkins Caufield & Byers, and Index Ventures。
   --------以上这段是来自2010年的文章，其实也说明了几件事：

   • flipboard 不是一个晚上造出来的，他基于了Ellerdale和Readability，这两家公司在事先都存活了多年，摸索了多年
   • flipboard也是摸着石头过河，10年的时候，他们最多只有9个格子。而如今是2页的九宫格+列表
   • 商店的变迁也是颇为巨大，从聚合到分散再到聚合。这其中经历了多少。。。

--------

准备转行做产品了。所以开始对一些内容进行慢慢研究。

不是说真的没用。但是真有可能，以前我的显示器就是22寸的，那时候外面都还是19寸，我用的很爽。屏幕大，用的爽。。。

当然我现在也希望有大屏幕的，但好象不太现实了。我当然希望有一台iMAC，一台17的mbp，两台一起用。但好象有点不太现实。光这两样东西，就要将近4W了。但真正算起来，这些其实也并没有多少钱。相对于一名开发人员的薪水来说。无非就是挤挤乳沟就有了。但为什么很多公司就是不愿意投入这些呢？不明白。真的不明白，好象越是把硬件搞的越便宜就越开心。

----以下是内容，来自：http://news.cnblogs.com/n/144016/
英文原文：Why Quit? Because They Have Bigger Monitors

　　好的技术人员向往具有很强的企业技术文化氛围的工作场所。但如何你能从外部看清一个企业的技术文化状态？这里要讲的是我使用的两个简单而好用的参考指标。

　　首先我要讲讲“企业技术文化”这个词指的是什么。它是指技术人员在一个企业内受重视的程度和重要性。它能从一些事情上体现出来：

• 公司里的决策是如何制定出来的？在一个具有很好的技术文化的公司里，技术人员参与要做什么、何时做、由谁来做等决策制定。并不是说有最终拍板权，而是有真正的发言权。
• 对开发软件这个工种是否尊重？开发软件是一种创造性的工作，这种工作需要有合适的时间和合适的地点。有些项目很难预测出究竟要多久才能开发出来，而公司能认可这种情况。
• 基础设施。当需要把精力放到非软件特征功能方面的事情上时，明白事理的人(技术人员，经理)需要花多少的口舌才能让老板知道这些工作的重要性？这通常是指一些运行时系统里的工作(比如扩充消息队列容量)或后勤服务工作(例如编译系统或版本控制工作)。

　　不幸的是，想通过一次交谈咨询就把这种底细都摸清是不现实的，除非你在这个公司内部有受信任、知道内情的线人。

　　他们的显示器有多大？

　　发生在我的前一个公司里的故事。我当时是技术经理，试图想挽留一个人才。团队里有个程序员辞职要去一个很小的但很新潮的公司。下面是我跟他离职前的谈话：

我: 为什么要走？

他: 因为他们的显示器很大。

我: (怀疑) 开什么玩笑？我们也可以给你配个大显示器。

他: 并不只是我——每个人都需要大显示器。

我: 这有那么重要吗？

他: 这反映了公司如何看待我的时间的价值。公司需要决定的是，多花一些钱买个大显示器让更多的像素映入我的视网膜是否值得。

　　现在我明白了，他说的一点没错。重视员工的公司会认为设备上的额外开销相比起提高员工的工作效率(和提升他们的幸福感)来说，后者更重要。让最好的程序员使用最好的开发工具来工作。大个儿的显示器是一个非常醒目的判断指标。

　　员工是否可以选择他们自己的邮件地址？

　　非技术人员很多时候并不认为邮件地址有多么的重要。可它是你网上的身份证。严格的邮件地址命名规范(姓的全拼加名的缩写，或更糟糕的名的缩写加 姓的全拼)反映出公司重视所谓一致性超过对员工的心情的关心。更糟糕的是，这种规定非常直白的让员工们感觉到自己被当成了“齿轮”或“人力资源”，而不是 一个了不起的个人。

　　(旁白: 让我们远离“人力资源”这个词儿。太难听了。)

　　这一点对我个人而言格外重要，因为我有一个很独特的名。如果你不允许我的邮件地址为sef@company.com ，那你在我的印象里会大打折扣。不仅如此，冗长的邮件地址名让人产生错觉，就好象是个邮件列表地址，但里面只有一个成员，可以忽略不计。它很重要，它是你 shell 环境的提示符；它很重要，它是whoami命令的返回值。

　　最后一句话：我并不是在谴责你们这些不辞辛劳的搞 IT 的男孩和女孩们。你们让很重要的东西保持正常运转，但还不得不被迫遵守这些强加的规则。相反，我针对的是这些糟糕的制度(通常是根植于糟糕的企业文化 中)，是它们使你们处于糟糕的境地。如果你身处这样的一个公司里，那跪下来吧，祈求阳光的降临。

今天又遇到了这个问题，以前其实是知道的。IE下的cookie长度和firefox下不一样。GET的长度也不样。
但我在记忆中一直是当成4096来处理的。看来我脑子里想的更多的都是firefox或者chrome，今天遇到某些信息不能显示的时候，又想起这个问题。才发现：
原文：http://blog.csdn.net/tuwen/article/details/5257154

看见很多朋友讨论浏览器最大URL长度限制的问题。其实实际中URL长度限制是由2方面决定的。1 客户浏览器 2 接受服务请求的服务器端的设置。对于大多数用户来说，他们使用的浏览器是IE浏览器，IE的最大URL长度限制是2083字节，而实际可以使用的最大长度 为2048字节。

--------------------
关于cookie，可以看一下：
Cookie常识
“同名Cookie”的分析
cookie，又见cookie

又到了一周回顾的时候了。本周确实没有做过多的事情。自己给自己加加压了
1、看了一下postgreSQL。准备用作mysql的补充。其实也考虑过用其它数据库做补充，比如mangoDB之类的。由于目前已经采用了redis。所以对于mongoDB的需求就不是那么明显了。
不过redis和mongoDB还是有区别的。但只有一台机器的话。redis分配了不少内存的情况下，再用mongo，内存就吃紧了

2、本周针对系统中原来的缓存功能做了清理，发现了一系列的问题，调整了一下。这确实是由于以前的功能单一而造成的原因

3、对于数据抓取，先作分词再做匹配。当匹配次数小于总次数的1/4时，认为原文是不匹配的。这个功能对于采用readability功能的抓取还是相对有点效果的

4、对于宽度固定的图片，原来在做PHP缩图的时候，保持宽高比的情况，现在做了调整，基于宽度进行调整（当然，这仅能用在宽度是指定的情况下。不是适合所有情况。当然对于图片过小的情况，也先作了放大处理。避免出现小图片）

5、nginx的php-fpm超时时间过短，导致上传大文件就会有问题，比如视频这一块的上传，就好纠结啊。尝试用cgi的方式上传，还没有折腾。

6、下周准备对于现有系统的API进行调整，业务增长的同事，原有架构需求也发生变化了。毕竟在最初写程序的时候不可能会考虑到所有会发生的情况，但事实上，这些业务正在逐步变化，没辙的情况下，只能做调整。否则，以后会更痛苦