首先是产品经理的职责问题。产品经理不像其他职位，比方说开发人员，测试人员那样有清晰的边界。产品经理往前一些，因为有市场部门与客户有直接接触，往往成为产品需求的入口；往后一些，产品经理与开发人员讨论需求，又容易深入到具体实现；同时，因为产品经理要对产品负责，又会承担起项目经理的角色。

Marty在书中对产品经理和围绕在其周围的几个关键角色的关系做了很仔细的分析

产品经理与相关角色的关系

• 产品管理和产品营销

小公司通常在产品管理和产品营销方面没有清晰的界限，可能一人兼任产品营销和产品经理的职位，甚至根本不设产品管理的职位，直接由营销人员收集产品需求。弊端是欠缺对产品的详细定义，这种思路指导下的产品往往只符合部分用户的需求，缺乏扩展性，难以持续发展；大公司可能会把产品营销和产品管理划分到不同的部门，但很多时候产品管理的工作仍由两个部门共同完成的，营销人员负责收集高层次需要，产品经理负责收集低层产品需求，但没有明确的产品负责人，产品经理的工作容易蜕变为制作各类文档。

“要解决问题，必须清晰界定产品经理和产品营销人员的职责。产品经理负责详细定义待开发的产品，让真实用户测试产品，产品营销人员负责向外界宣传和推广产品，为拓展市场销售渠道、组织营销活动、促进产品销售提供支持。”

处理产品营销与产品管理的关系也是在市场需求和产品定位上做平衡。产品要符合市场需要才有人买单，但一味迎合用户的短期需要，又会使产品失去方向。这是产品经理纠结所在，能解决好这个这个是产品经理的价值体现，要好好修炼。

• 产品管理和项目管理

Marty 认为项目管理与产品管理一定要分开，产品管理的职责是探索定义有价值的、可用的、可行的产品；而项目管理关注如何执行计划以按期交付产品。 产品管理和项目管理关注的重点是不一样的，产品管理定义优先级是从产品功能的角度考虑，项目管理定义优先级是从时间和资源的角度考虑。只有两者紧密结合，才能交付的有价值的产品

• 产品管理和产品设计

用户体验日益重要，而舒适的用户体验则是产品管理和用户设计共同作用的结果。产品经理应该与产品设计人员共同完成用户研究、交互设计、视觉设计、原型制作。目标是确保产品同时有可用性和价值。

• 产品管理和软件开发

在很多人眼中，产品管理和软件开发是主从关系。Marty很明确指出“产品管理和软件开发形成合作关系的关键是双方承认彼此平等－－任何一方不从属于另一方。产品经理负责定义正确的产品，开发团队负责正确地开发产品，双方相互依赖。” 在项目前期，开发人员可以通过原型设计，产品设计评估参与到产品的定义工作。在项目进行时产品经理也需要配合开发人员的工作，而不应该把需求定下来后就撒手不管。具体而言: 1)产品经理只定义满足基本要求的产品，它不是最终产品，而是满足基本要求的产品，只有这样软件开发才有足够的空间，并形成良好的互动; 2) 产品进入开发阶段，尽可能避免修改产品的需求和设计。3) 开发阶段遇到问题，比如设计阶段考虑不周，应在维持产品基本功能，避免修改的原则上拿出解决方案。

关于软件开发，Marty还提到软件架构重构问题，一个有效的方法就是为开发团队预留一定的自主时间，比如20%的时间用来重构，完善架构，提高系统性能等。

产品管理离不开以上几个关键角色。产品经理定义有价值的产品，和产品设计人员一起保证产品的可用性，和软件开发人员一起保证产品的可行性，和项目经理一起保证产品是可交付的。

产品经理的职责

• 产品经理主要职责

Marty强调产品经理的主要职责有两个 1) 评估产品机会 2) 定义要开发产品。产品机会评估是要确保产品是有价值的，而定义开发产品则包括探索产品特征和功能，用户体验等。

• 产品经理应有的特质

产品经理应有好的个人素质和工作态度；对产品有本能的热爱；良好的洞察力和判断力，敏锐的头脑；站在用户的角度看问题，尊重目标市场；肩负产品的前途和命运，付出努力和承担义务；正直，自信，负责任；不需要实现和发明新技术，但有理解和发掘技术的潜力；优先级管理，时间管理；沟通技能，商业技能。

回想自己在前公司担任产品经理的职位几年的时间，工作的重点是为产品确定解决方案，管理产品backlog并确保产品是可行可交付得。对产品定义，价值探索确实涉足得比较少，今后或许有更多的机会实践。

• Card 是最基本的元素, 可以用它来纪录一个用户需求, 或者一个问题，又或者一个待办事项。怎么用，完全取决于你要管理的对象。

• List 是Card的容器，用于把相关的Card组织在一起。List中的Card是垂直布局的，可以根据重要程度依次摆放

• Board 可以放置各种List，而List上的Card可以在不同List之间移动。如果把List定义为不同状态Card的容器，Card在List之间的移动就会放映出状态的流转，所以Trello也被看作功能强大的看板。

Trello的特色功能:

• 功能强大的Card编辑功能。支持Markdown格式, 可以设置标签，添加附件，设置Card的封面，还可以和dropbox集成。Card的最主要用途就是用来定义任务，所以Checklist和Due date的功能也一应俱全。

• 支持多人协作。除了丰富的编辑功能，Card还可以被指派到某些用户，可以让用户投票，和订阅变化通知。用户还可以对Card发评论。除此之外还有一个Board级别的活动日志，会纪录每个用户在Board所做修改。这个功能非常好，让你看到大家的工作纪录，而不仅仅是当前的状态。这些协作功能使得Trello非常适合做远程团队协作工具

• 在Trello上你可以建很多个Board，可以将Board划分到不同的Organization，给不同的人设置权限。甚至将Board设置为公开。例如Trello的Development Board

• Trello在UI设计上很注重快速便捷，常用的功能通常可以有几种路径做到，可以选择符合自己习惯的方式。网页版还提供方便 Keyboard shortcut

• 免费，而且支持多种客户端

相关资源

• Getting started with Trello

• ifanr对Trello的介绍

如果没有任何web开发和数据库经验，就需要从头学起了。这个阶段先不急于看各种框架，扎扎实实打好基础，掌握好php语法，服务器搭建，数据库操作等基础知识。

PHP

网上各种PHP教程一大把，但质量参差，效果未必好。建议拿一本入门书看看。这类书还是很多的，之前看过一本SitePoint 出的 PHP & MySQL Novice to Ninja，浅显易懂，很适合初学者。当然这类书看看前面几个章节有个概念就可以了，重要的是动手做和学会自己翻php帮助手册。如果想对PHP内置函数有个大致了解，可以看看Adnrew Burgess的Getting Good with PHP。这个阶段需要掌握:

• 搭建服务器运行PHP服务
• 基本语法:变量，函数，表达式，控制结构
• 数组，字符串操作
• Web资源Request, Response, Session基本操作
• 数据库操作
• 函数库概览

HTML/CSS/javascript

PHP是面向web的编程，所以HTML, CSS, javascript的知识不可缺少。这类技术一般的学习方法是先了解基本概念，自己动手写写代码并且学会遇到问题查找参考手册和Cheatsheet就OK。当然如果前端是你的工作重点，这另当别论。对于javascript，了解了基本知识之后，建议直接学习使用jQuery，少走些弯路。关于Web的基本知识，推荐这个 webplatform wiki。对Web前端的基本要求是：

• HTML/CSS/javascript 基本语法
• jQuery

数据库

数据库的基础知识一定要有。使用PHP都离不开MySQL，其实PostgreSQL也不错，使用的人也越来越多。对于一般的站点，MySQL和PostgreSQL差别不大，使用MySQL的好处是资源更多一些。数据库方面需要掌握:

• 数据库的基本原理
• 表设计的原则
• SQL语法和增删改查的基本操作
• 初级的优化技巧如使用正确的类型，索引等

实践

做一个简单的带后台管理的Blog，就能把以上所学基本用上了。

相关资源

• 好用的jQuery cheatsheet
• 前端开发wiki webplatform
• cheatsheet 大集合 overapi

自定义less

以下是Bootstrap的less文件引用关系

• bootstrap.less (编译后生成bootstrap.css)
  • variables.less
  • mixins.less
  • buttons.less
  • … (widgets)
• responsive.less (编译后生成bootsrap-responsive.css)
  • variables.less
  • mixins.less

bootstrap.less 是主文件，定义需要引用的文件。variables.less和mixins.less定义各种变量和函数。而Widget(如button, navbar)的具体样式则由对应的文件分别定义。修改这两个文件基本上可以满足大部分自定义的需求。responsive.less定义的是响应式布局相关的样式，一般不需要改动。

具体步骤

1) 以bootstrap.less为蓝本定义项目的less文件style.less。import 的路径作相应修改

2) variable的改动较多，所以单独定义style_variables.less文件用于覆盖默认变量定义。如果必要，其他less文件也可以作类似处理

3) 编译style.less文件，生成style.css。html中的引用由bootstrap.css改为style.css。

4) 如果以后需要升级bootstrap，检查一下新的bootstrap.css和variables.css有没有变化，一般直接替换bootstrap下的less文件就可以了。

文件示例

目录结构

1
2
3
4
5
6
7
8
9
10
11

/Web_dir
     /bootstrap
          /less
          /js
     /css
          style.css
     /less
          style.less
          variables_override.less
          buttons_override.less
          my_component.less

style.less

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

/*!
 * style.css based on bootstrap.less (v2.0.2)
 */

// CSS Reset
@import "../bootstrap/less/reset.less";

// Core variables and mixins
@import "../bootstrap/less/variables.less"; // Modify this for custom colors, font-sizes, etc
@import "variables_override.less"//project overriding variables
@import "../bootstrap/less/mixins.less";

// Grid system and page structure
@import "../bootstrap/less/scaffolding.less";
@import "../bootstrap/less/grid.less";
@import "../bootstrap/less/layouts.less";

variables_override.less

1
2
3
4
5

//override the bootstrap/less/variabiles

@linkColor:             #f89632; //Green #7CA60A  //Orange #f89632

@bodyBackground:        #f7f7f7;

编译less文件

编译less文件可以使用client-side或server-side方式，client-side由浏览器完成less文件的编译，一般在开发阶段使用；而production一般使用server-side方式，事先编译好css文件。现在有很多编译工具可以监测文件变化，瞬间完成编译，所以即使在开发阶段也可以使用server-side方式。

想找less编译工具可以到这里 看看，Mac，Windows和Linux上的都有。如果你在用Sublime Text2， 使用插件会更方便些。我用的是less2css，在package control直接安装。使用前需要简单配置一下。建议在项目级别配置，具体可以点击Project->Edit project菜单项修改配置，在setttings项中增加less2css节点就可以自动编译了。

1
2
3
4
5
6
7
8
9
10
11
12

"settings":
{
  ...

  "less2css":
      {
          "autoCompile": true,
          "main_file": "style.less",
          "minify": true,
          "outputDir": "./css"
      }
}

什么是看板

看板最早起源于丰田，是其推动精益和持续改善的有效工具。

一般而言，想提高做事效率，最有效的方式是让工作的各个环节流动平滑起来，消除瓶颈和减少等待时间。基于这个出发点，看板只规定两件事：1) 工作流必须可见，2) 控制”在制品”(Work In Progress) 上限，并在此基础上 3) 优化流程，缩短生产周期并使其可预测。以上三点是看板的精髓。

1)工作流可见

任务拆分：将项目拆分成一系列小而具体的可交付的任务。

标识工作流程：在白板（看板图）上画出任务从开始到完成需要经历的阶段。

用卡片表示任务：随着工作的开展，卡片会从左至右流动，直至完成。

看板图直观地反映了工作的进度。当进度出现问题的时候，很容易暴露出来。

2） 控制”在制品”

在看板列中设置卡片数量上限（上图红色数字），当卡片数达到了列设置上限就不能再为该列添加新的卡片。如果这时有人手头上没有任务，他/她可以

• 领取下游没有到达上限的列的任务。例如上图的Dev列的限制是3，而这时只有两个任务正处开发状态，可以领取Todo列的任务进行开发
• 帮助其他人解决问题。例如Test列已达到上限，如果不尽快完成Test任务，会导致Dev任务排队等待测试，造成瓶颈，阻塞整体进度。 列中设置的上限就是限制“在制品”，由于引入了这个限制，迫使大家优先解决阻塞和瓶颈问题，减少等待的时间。

3) 优化流程和缩短生产周期

看板每列（最后一列除外）都可以设置上限。“上限该设多少”在一开始并不重要，随着团队的运作，可以根据实际的运作情况进行调整优化。 通过一些指标（如生产周期，不同工作类型的生产率等）和图可以发现瓶颈，分析不均衡生产，超负荷问题。

看板与Scrum的比较

书中对看板与Scrum做了非常详细的对比

• 看板没有规定任何角色；而Scrum规定了三种角色（Product owner，Scrum master，team）
• 看板没有固定迭代周期，生产周期是事后度量出来的；Scrum有固定迭代周期，而且迭代内有非常明确的节奏：计划，过程，发布。
• 看板通过流程状态来限制在制品；Scrum通过固定时长（Timebox）来限制在制品，即一个迭代内能做多少是有限制的。
• 看板图对应的是流程，不一定对应一个团队；Scrum则只属于某个团队（当然其他人也可见）。
• 看板对工作估算没有明确规定；Scrum规定了任务估算和生产率（Velocity)。
• 看板没有要求图表（但也可以使用，如累积流图）；Scrum会使用燃尽图跟踪迭代进度。

另外Scrum中要求的计划会议，站立会议，回顾会议，在看板中都没有定义。总体来看，看板相比Scrum，约束更小。

总结

就开发而言，看板适合于周期不确定，或者同时管理周期不一致的任务，例如Bug fixing，Customer support，Operation support 等等；而Scrum更适合于有固定周期的工作，例如产品开发 看板非常灵活，在不同的应用场景下可以有不同的配置，实践中可以参考10 kanban boards and their context

另外，也可以考虑在Scrum中加入看板元素，最直接的就是为状态列设置上限。例如，迭代初期团队往往只关注开发，到后期可能由于环境和人手的问题无法顺利进行测试，所有功能都在等待排队测试。这时候如果在测试列和Checkout列设置上限，问题就会很容易被发现，团队也会自发地优先解决阻塞问题。

除了用在团队开发，也有研究将它应用在个人任务管理，如Personal Kaban。我们可以试试给自己个人“在制品”也设置一个上限。

如果对看板感兴趣，可以试试这两个工具：

• KanbanFlow：简单易用，我之前简单介绍过，目前只有web版
• Trello： @LeoLiang_艳阳天 推荐，Fog Creek出品，功能强大，定制灵活。有Web版和iOS客户端

参考链接

• 电子书下载 中文版 英文版
• Crisp (一间看板咨询公司)
• 10 kanban boards and their context
• Personal Kaban

什么是Kanban? Kanban 也称作看板，源自丰田汽车生产的精益管理。除了工业生产外，现在被广泛用于软件开发管理中，也有人将其用于个人任务管理，例如 Personal Kanban。

KanbanFlow 类似Scrum whiteboard, 按任务状态设定不同列，任务从左至右流动直至完成。Kanban的核心思想之一是限制在制品(WIP), KanbanFlow也可以设定没列任务的上限。

KanbanFlow可以用作项目管理，也可以个人任务管理。其特色在于：

• 灵活定制，还可以随意增加列及看板
• 不同类别可以用不同看板管理，例如可以分为 Work, Life, Personal development
• 任务可以再细分任务，可记录估算时间和实际使用时间
• 集成了番茄时间(Pomodoro Technique)，并可以查看统计数据，这点最赞
• 支持团队协作，如任务分配

这一两周暂时搁置Calinbox, 先试试KanbanFlow