项目管理：从会议参与者变成会议组织者（需要与老板同事们约时间）－以始为终，不忘小结，拥抱变化，一步一个脚印。
文档，流程，敏捷都只是手段，都是为项目、产品、团队服务的：立项、需求、开发、测试、发布。
项目只进行一次，包含多项互相关联的任务，并且绩效、时间、成本和范围限制的一项工作，是一个过程，而产品是解决某个问题的东西。做产品和做项目是分不开的，做产品的过程正是通过做一个个项目实现的，但并不是项目的简单累加－版本、模块、增值服务。
产品经理－靠想（判断力和创造力），做正确的事，其所领导的产品是否符合市场的需求，是否给公司带来利润。关注整个产品周期，关注产品能否賺钱，能否持续賺钱－能够规划整个产品的架构和发展路线，能够确定产品定位和受众，能够预计产品真正的价值和效益。
项目经理－靠做（执行力和控制力）－怎么做/谁来做/何时做，把事情做正确，做完美，在时间、成本和资源约束条件下完成目标。
一个事物有它的两面性，一个产品经理可能想要增加非常多的功能和特征以满足用户需求，项目经理却想控制范围，以保证项目在规定时间与预算内完成－好的产品经理和项目经理需要在冲突中找到平衡。
一切从kickoff开始：项目启动大会，立项就是启动大会及其准备工作（团队组建和各种计划的制定）－每次项目都要去跟不同团队主管、经理要人（邮件主题明确，优先级），混到脸熟后做产品比较顺畅些－项目督导委员会（权力大责任大：背黑锅和买单，项目成本时间需求变更时提出申请审批－资源最好有富于，尽量省着用，随时通知信息），一开始不可能全部到位，关键几个人项目经理，PD，开发经理一起参加即可。
项目计划，评估工作量推出工期，高手调入关键路径，开发任务分配给合适的人，三点估算法，考虑任务间依赖关系，会议，每天工作5-6个小时，项目计划，里程碑－最初的约定，不一定加大资源投入就能节省项目时间。
项目沟通：周期（日/周为单位，取决于项目时间的长短和变化频率）、渠道（会议、邮件等，成本和效益平衡）、发起者（项目经理、开发经理和测试经理主导相应的沟通）、参与者（不要遗漏边缘的同事）－包括项目晨会（开发到发布）、项目日报、评审会（需求/开发设计评审/功能评审/测试评审）、项目变更申请、发布预告及公告（发布前两工作日预告，发布后发）。
不可或缺的誓师大会：KO，15分钟左右的时间，项目背景－为什么（我们在哪里）；项目意义、目的和目标，我们去哪里，解决问题；需求、功能点描述（我们怎样去，什么方法实现转变）、项目组织架构（互相认识，关键人物到场，早期让老板们多多参与，反复确认正确的方向，也不要遗漏工作不多的项目成员，服务配合部门等，介绍成员可示意）、项目计划（时间点和里程碑，各个时段需要的资源）、沟通计划。凡是会议总会有人缺席，把会议记录发给所有人。
了解项目背景、目的、目标的前提下，明确任务后，首先分解WBS，滴水不漏。产品级项目模板：项目准备、过程管理（立项、时间计划、项目wiki维护、沟通计划、项目总结－心得体会、资源预估Review）、需求、实施、测试、部署、服务、上线配合－边计划、边行动、边修改。
需求开发（写文档－熟悉产品、团队，团队做事方法、常用工具），产品从抽象到具体过程主要产出文档：
BRD（商业需求文档）－产品生命周期最早文档，其内容设计市场分析，销售策略，盈利预测等－给大老板演示的PPT，短小精炼没有细节，获得认可争取资源；
MRD（市场需求文档）－获得老板支持后的实施阶段，细致市场和竞争对手分析，包括可通过哪些功能实现商业目的，功能非功能模块分类与功能优先级－Feature List、业务逻辑图（从商业目标到技术实现）－偏商业；
PRD（产品需求文档）－对产品功能的细化，包含整体说明、用例文档、产品Demo等，总体说明（修订历史/项目概述－kick off内容/功能范围/用户范围/词汇表/非功能需求/其它说明）+ UC部分（整体说明－可视化：类图、用例图、状态图/UC/对单个UC的说明……视觉层面通常由Demo表达，界面细节，交互细节，文案细节）
FSD（功能详细说明）－产品界面、业务逻辑细节等，用例文档等都可以。
人治（领导人的魅力，小公司）－法治（靠法律+伦理+执行者自身作者）－德治（由内而外，企业文化，大公司）：字不如表，表不如图。
UC概述：用例唯一标识、用例名称（粒度自己把握－新功能可以详细些）、业务描述（商业目标和用户目的等）、需求描述（产品需求实现哪些功能点）、行为者、前置条件、后置条件、其他说明。
UC主体：界面描述（截图，demo）、业务规则、流程主干（分主干、分支和异常）－尽量用时序图、活动图及其它－包括流程1（主流程：流程名称，触发事件，时序图or活动图）。
UC一般只用来描述功能的需求，不便于描述诸如产品扩展性、系统容量、人员培训等非功能需求，对语言的要求是：无歧义、完整、一致、可测试等。不管是visio，工具是为人服务的，最重要的是：把要做的事情跟受众说清楚！
产品Demo（原型，演示版，Mockup），线框图/纸面demo/PS/Dreamweaver等工具－专业的人做专业的事情。
不以写的东西是需求还是设计区分，而是按照业务和技术区分；细枝末节单独讨论后形成产品规范。
写作－评审－修改－评审（项目中的相关几个小团队坐在一起，一方讲，另外几方听并确认，统一认识，消除误解，及时发现偏差，防止问题随时间放大）
需求评审：PRD评审、UC评审、Demo评审，做出比较大力度的PRD后马上安排一次评审，半成品评审，偏商业叫上老板；Demo评审外观，建议干系人参加，UC偏技术；商业团队可选择参加。
设计评审：概要设计和详细设计后。
测试评审：用例评审，可能多轮，小问题当场确认，改动多再次评审，异议不大可以通过。
可能漏掉参与者：各种评审会上能做决定的人－有人拍板+相关产品接口人，识别干系人。
日常需求发布流程：需求采集、分析、筛选等前期过程（决定做不做，做多少）－确定需求负责人，需求状态变成“需求中”－项目kickoff－需求评审（决定怎么做）+ 确定开发计划（确定何时做，谁做－确定开发负责人）－需求确认，需求状态变开发中－设计，设计评审－编码－功能评审+TC编写，TC评审，测试－发布确认（需求状态变成“已发布”），产品项目PD是产品不断改进的源动力。
1. 项目开始之前。在产品团队内部分析需求价值的需求讨论会、多个产品间的产品会议，PD带着自己的需求参与讨论，为仅有的开发和测试资源PK－人性的本能都是每个人极力维护自己的需求并设法反驳别人－出发点都是为了用户－活下来的需求确定需求负责人，状态变为“需求中”。
2. 项目中需求阶段，PD完成需求开发，不时召集需求评审会，大家一起讨论问题，反复修改直到最后评审通过，需求确认后状态变为“开发中”－需求冻结里程碑要求我们在这里不要轻易改动了。
3. 项目中的需求阶段之后。开发后不断和开发测试确认各种细节。PD需要在测试环境代表产品用户进行验收测试，确认产品与自己设计相符，顺便发现一些可用性问题。（用户验收更好）组织一次功能评审会，让干系人确认这些功能是不是大家想要的，有问题可以补救－最后上线改成“已发布”。
需求评审作为项目的重要里程碑，需求确认和冻结－开发阶段修改要慎重，甚至强制走一些需求变更流程－更好地控制风险。
开发阶段：设计－设计评审－编码－单元测试，审核工程师对需求的理解度；代码评审，单元测试发现问题早成本越低－自测完成－开发完成。
测试阶段：TC编写－TC评审－冒烟测试－功能评审－测试（测试任务描述－体现测试方案、方法、技术和策略），内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本、模拟器等形成文档。（产品演示会）多轮测试回归，PD准备功能、卖点介绍，产品更新公告；培训服务人员和销售人员；运营人员策划推广方案；销售人员更新说辞；服务任务根据测试环境制作帮助手册。
缺陷级别定义：功能缺陷（Urgent：数据丢失，死机致命错误，性能与需求不一致，系统资源/配置引发性能问题，安全性问题，频繁崩溃；Very High：功能与需求不一致，需求未实现，功能有错误影响使用，数据传输有错误，安装卸载错误；High：功能有误但不影响使用，界面错误，边界条件出错－能用；Medium：界面设计不规范，消息、提示不准确、交互不友好－好用）+需求缺陷（low：软件设计有问题、文档不完整或不准确、需求冻结后，描述不清楚的地方－有用）。
有争议的时候面对面交流－所有TR的总结状态必须是close/defererred。
Open-Updated（本地修复）－Fixed（更新到测试环境）－Reopen（验证不过）－Reject（否认缺陷）－Deferred（推迟）－Close（关闭缺陷）。
发布：发布评审（运维人员确认）－预发布（尽量模拟真实状态）－发布－线上验证，灰度发布让一部分人先用，收集反馈再决定大面积发布时机（回滚方案），一些手续－发布申请单，立项申请表等签字画押。
发布标准：SQL无异议、全部缺陷关闭、因技术或时间原因无法修改的缺陷－开发测试需求一起看是否可接受，有争议上报上级主管、测试过程中，因技术无法实现的需求改动，PD第一时间通知全组，并修改UC。加班的时候别忘了给大家买夜宵！
以始为终，项目小结（赶紧发项目公告！）－比较形式化，而意义重大的项目写得很煽情：比如项目中的种种艰辛、对每个参与者的感谢、发布后的内心感言、产品对公司和用户的革命意义，贴几张最新图片，诗兴大发，设计海报－邮箱+贴出来《内部宣传，全公司》－项目经理应该时刻为团队成员争取各种精神物质的奖励，邮件、海报和大老板的回信等－有经费可以组织一次聚餐，以后大家开心合作。
项目小结，几周两三个月项目比较适合在发布后半个月完成。心得体会（碰到哪些问题，原因是什么，怎么解决的，如何避免再犯；项目资源评估是否合理，收获了哪些经验，如何提高准确度；根据数据监控的反馈，分析出了什么结果，项目的商业目标是否达到等）－问题+解决方案，可以用表格代替文字，完成期限－通过项目日报和周报随时记录每天情况，总结的时候水到渠成－对项目成员的保护。
项目名称、总体情况、本周要闻、下周看点、当前问题与解决方案（问题，描述，紧急度，解决期限，解决方案，备注）、项目进度（任务、描述、完成率、计划完成、实际完成、备注－原材料积累）、里程碑（名称、描述、完成率、计划完成、实际完成、备注）。
拥抱变化：
1. 变更事件（需求变化，尤其是需求冻结后的变化）－做流程控制让每次变更都经过深思熟虑（最怕需求方举棋不定，来回反复）：流程要求提出变更的人先和相关方确认，获得一致认可后，在修改文档、邮件说明、即时通信群里吼一声……过大过晚的变化有权拒绝或者让更大老板定夺。
2. 搭车事件，项目范围的扩展，5个工作日以下零散小需求不参与产品会议讨论－尽量搭顺风车，找内容相关的项目；尽量早搭车，在需求冻结后一般不要再提；作为项目经理尽量把关，不能随意让别人搭车导致团队长期高负荷加班。
3. 紧急事件，高层确认后自上而下的推动，优先处理－紧急生产环境故障，需要站出来紧急应付。
4. 资源不足，快车让慢车－早期评估不足而吃紧，不要太过分－即使开快车，想想自己也有开慢车的情况。
5. 人力资源半途加入的其他部门配合人员，容易消极怠工，沟通本事，讲kickoff的PPT？转换心态做自己的事？聊人生谈理想－如果对方确实没时间，经验是统一战线。向他老板表明问题，帮助他减轻压力，千万不能有低级的－“你不帮我做事，我向你老板告状”。
山寨级项目管理：计划与控制－目标是把产品做好，没有考虑采购、成本预算的事情，文档、流程、敏捷都是手段。
文档只是手段－模板、规范、操作步骤，PRD模板、项目流程等。作者做的－建立自己的文档规范，每隔几个月整理一次，给产品团队发布一个文档包。
PD常用文档模板（商业需求文档+产品需求文档+需求规范类+需求管理类+流程管理类+项目管理类+日常工作类）－为公司为团队为产品做，也是为自己做。
需求规范类：
PD做什么：工作内容总结和新人快速入门。
用户体验规范（负责UE的同事编写）：交互规范（默认排序、翻页样式、判断规则－字段检验，出错信息反馈等）、视觉规范（页面大小、字体字号、颜色编码等）、文案规范（语言风格、语法模板）。
通用原则：待补充，不断优化。
需求规范类：
用户调研：模板说明典型用户调研前中后都要做什么，用户访谈提纲怎么设计，有哪里块内容。
产品需求列表（含需求管理流程）：产品需求模板，需求管理文档模板，需求状态变化流程图。
产品信息架构：产品页面或功能间关系。
流程管理类（只列出小团队常用的）
日常发布流程、变更事件流程（紧急发布流程、需求变更流程、需求搭车流程）等
项目管理类
项目管理制度：选择性的东西，产品会议制度，项目经理、开发经理、测试经理的权责利
项目任务书：网上模板，BRD
Kick Off PPT：
项目组织结构：模板
项目WBS（可生成进度）：WBS Chart Pro生成project文件
项目日报周报：主要有今日/本周要闻，明日/下周看点、当前问题、所需支持、项目进展等几项－以始为终。
项目发布预告与公告：大量重复内容模版化，为了省时间而已。
日常工作类：
会议记录：会议决议、遗留问题与行动方案－我们急需靠谱的会议
个人日报周报：用于团队分享每个人工作情况。
其它编码规范、开发工作不在PD范围内。
模板作用（规范、流程）：让经常看同类文档的人提高效率、让新写文档的人尽快上手、让写作者不会考虑漏掉某些内容－相对成熟的团队和产品，项目开始前必须约定好各种模板、规范和流程－统一，逐步完善，简单到全面，不断迭代优化－总结产品团队得失，精华糟粕，传递优良传统－一次性文档不用做成模板（奥卡姆剃刀原理），经常做的事情才有必要形成模板或规范。
产品文档管理的本质是需求多人合作，协同办公，Wiki比较好（每个人负责一部分，随时保持更新，直接wiki写需求随时更新，版本号文档管理－大讨论改动，小讨论改动，发布改动）
Office：
Word一开始设置页面，格式，样式；
Excel－条件筛选、单元格锁定、隐藏、基本函数、单元格有效性
PPT－思路更重要，减少文字，图片和大数字，想说的东西加入备注，演讲者模式（让每张PPT上想说的观点一条一条出现，突出当前讲的一条，让观众注意力聚焦）
字、表、图－思维导图整理思路，其它工具如Visio、Outlook－创建文件夹结构+邮件规则+邮件标记+会议邀请等功能、Project－复杂项目超多任务多种资源即可。
流程也是手段（长视者把目的当手段，短视者把手段当目的）：产品－公司商业目标－公司使命和愿景。
产品流程：概念DCP－立项DCP－开发－验证DCP－发布－生命周期维护DCP（前两个阶段需要高手做，新人新人做老产品不挑活，老产品不容易出事；老人做新产品，有变化才有激情）。
快－稳：设计流程的目标，就是无论谁做这个，都能到80分－流程的好处是人走了，事还能做－路况（软硬件环境）与开车水平（即个人能力）要求成反比，流程目的是改善路况－当年的英雄把自己的个人经验转变成显性知识表达出来，而对于经常做的事情，用流程固化传承，后人不会太无助，团队竞争力－个人竞争力显性知识转化为影性知识的能力+团队核心竞争力把隐形知识转化为显性知识的能力。
评审可省？从立项之前的产品会议，到Kickoff会议，需求评审（PRD评审、UC评审、Demo评审），设计评审，代码评审，TC评审，功能评审以及发布评审（评审会议本身不产生价值，应尽量简化：重要的评审不能省，最好单独评审，参与者取决于评审内容偏商业还是偏技术），商业评审决定做不做，比如产品会议与功能评审；技术评审决定“怎么做”，是需求、设计、TC、发布评审－最好分开进行，不同时讨论商业和技术问题－没关系的人不要来参加－参加评审的人要承担相应的责任。
商业评审的三个决定：项目继续、重新定向、项目终止，最重要的目的就是砍项目。分阶段分发资源，通过评审的项目发放资源。
技术评审的三个决定：项目继续、有风险地继续、必须解决某些问题后再继续，需要避免的技术评审三部曲：抓壮丁－随便找有空的人参加；科普会－来的人根本不了解情况；批斗会－没完没了的争论。
产品会议：必须有，决定做不做，做多少－方向太重要了，产品间同一产品不同需求争夺资源，可以把确定需求商业价值的需求讨论会、初评工作量等工作等一起放在产品会议－参与者最少是产品团队、开发、测试、服务等各个部门的头，或者有话语权的接口人。
Kickoff会议：最好开一下，鼓舞士气，可以考虑与需求评审合并为一次会议，安排最开始15分钟，项目干系人都应该参加，有的人结束后可以不参与需求评审。
需求评审：具体三个评审怎样做取决于实际情况。
设计评审：开发弱，新人多，业务不熟的情况下必须进行设计评审－否则后面出问题很麻烦，也可以跟需求评审其中一个合并，开发人员很强的情况下可忽略－开发讲需求，PD提问，让开发认真看需求，降低不做设计评审的风险。
TC评审：仅次于需求评审，纯技术，商业团队一般不参加。
功能评审：必须的，需要项目干系人都参与，可以线下评审，重要的项目开一个产品演示会。
发布评审：开发经理决定是否需要。
敏捷更是手段：一周发布两次？一两周发布频率－有计划更要拥抱变化，迭代期内尽量不加任务（当前迭代不变，下次迭代待定），集中工作小步快跑（站会第三个问题－碰到什么问题，打算如何解决，需要什么帮助），持续细化需求强调测试（很强很严谨的测试－测试驱动+更早测试+重度测试），不断发布尽早交付（冒烟测试，每日构建－分而治之，先解决核心风险最大的部分－两天周二周四发布，一次周三）。
敏捷沟通
“无论最终发现了什么，我们必须理解并完全相信：每个人在其所处的情况下，在其能力范围内，做了最大的努力”－让人温暖
临时邮件列表（所有人的邮件和电话号码）；即时通信群（重要邮件，重要文档更新，测试环境正在构建无法访问等）+群公告（文档，wiki，测试环境等）－0%,30%,50%,100%等，不同颜色，其它信息。保质不保量－敏捷方法。任何情况下，我们都要做好手头上的事情，确保“就算这事儿对公司又黄了，我也要通过做事所有收获”。
特色项目：
老板项目－在保证质量情况下，在时间、成本和范围内平衡（给自己留缓冲，帮老板建议优先级和资源，资源是丰富的）
秘密行动，封闭开发－临时团队，上限两三个月
开发外包，项目外包－项目一开始要明确合作模式，划分责权利，责权利对等，承担风险和好处损失（权责明确）
三边六拍：边计划、边行动、边修改－关键的方向目标一开始清晰，一些原则、约定不能总是变；拍脑门、拍肩膀、拍胸脯、拍桌子、拍屁股、拍大腿，拍完了不吸取教训才可怕。
作者经历的几个项目：测试阶段过不了压力测试、需求阶段停了－没有高层支持的项目完全是白搭、市场调研觉得不值得做下去、项目上线后客服技术支持财务和部门间协调也很多事情、和其他公司公司合作。
七天项目模板：晚上晚点走、周末尽量不加班，倒计时天数（第一天主题明了：今日完成－Kickoff完成、项目范围与方案、需求写作、团队建设、知会干系人+明日重点预告－需求评审、进入设计和开发；第二天：上午需求评审&确认完毕、下午进入开发阶段、测试人员确定、相关事宜跟进）－一起战斗的感觉真好。