Abstract:基础篇，关于PM怎样愉快地跟程序员沟通。哪些话会惹恼程序员？提需求的正确姿势是什么？
沟通
- 产品本质是获取信息（程序猿角度），信息-数据；前端：展示数据，后台：管理数据（守着服务器鼓捣数据）；
- 不要重复造轮子：别人写过的代码不要重复写，可以直接搬运；
- 全栈：前端后台样样精通；
后台
- 分布式：为了让各个服务器并行工作，故研究分布式算法，把大任务拆成小任务，分布给哥哥服务器单独运算；
- 非关系型数据库NoSQL：提高数据库的存取速度；
- 缓存技术：解决硬盘速度远远跟不上内存速度的问题，即数据从硬盘取出来就不放回去了；
哪些话会惹恼程序员？
- 先做出来看看：随时可能被删除的需求，删代码等于割肉；（好的pm把需求的关键路径在脑海里演练上百次）
- 我就要这种效果，怎么实现是你的问题：有的创意功能实在不好实现／根本无法实现／不合适实现；（功能设计时要考虑：用户需求／商业模式／设计和开发实现的可能性）
- 不要教育程序员怎么写代码；
- 你就说能不能做吧：不要粗暴直接问程序员做决定；pm大可不必跟开发探讨技术细节，就讲道理／讲数据／大局观，迂回取胜。
- 我有一个绝妙的 idea，什么都准备好了，就差一个写代码的了：idea谁都能想，不要在言语里露出对程序员的轻视；
- 这个需求老大已经同意了，你照着做就是了：不要拿上级压人，易遭致反感；最好以理服人，充分pk／摩擦产生高效输出；
提需求的正确姿势是什么
- 往往一些看似很简单的需求，实际上会遇到很多坑：比如一个很简单的按钮的实现可能需要千行代码；（好的pm需要从用户角度想清楚一个功能的前后逻辑）
举例：实现「视频播放的时候，用户可以设置屏幕亮度」的功能
问题：调用系统提供的「设置屏幕亮度」的程序接口
存在问题：
1.如果用户在我的APP里提高了屏幕亮度，退出之后要不要给人家还原呢？如果用户只是暂时离开了我的APP，退出又回来，我是不是要给人恢复成原来设置的亮度呢？
2.「设置屏幕亮度」的接口是一个很耗时的接口，可能会造成整个APP的卡顿，这时候你就得考虑用多线程来解决。引入多线程之后，线程之间的资源共享问题如何解决，谁先谁后的问题如何解决，等等…
- 程序员写代码：完成功能，代码规范，扩展性，后期的完全负责；
- 知道有哪些轮子：
开源社区：平时多看一些别人整理的技术博客，你可能并不需要知道里面技术上是如何实现的，你只需要记下，这个功能是有轮子可以用的，就够了。
自己的项目：想知道自己项目积累了哪些轮子，去问你们的开发吧，找他们抽支烟、吃个饭，很容易就套出来了。
系统平台：买一本介绍你们产品平台的技术书，比如《疯狂Android讲义》、《iOS Programming》，大体翻一下就行了，主要是了解一下这个平台到底可以做哪些事情。
- 提需求要跟着项目的版本周期走：每个版本会经过功能开发（有提必应）、单元测试（一个功能模块的需求做完后给测试找bug的时段，大多数有提必应）、集成测试、beta验证（提需求拉仇恨，需要评估需求的实现难度）、上线五个阶段
程序员需要什么样的PRD？
- 程序员不需要文字式的需求文档，只要清晰的流程图和原型即可。
以程序猿的逻辑去沟通产品逻辑：状态机（万字不如一图）
- 状态机：描述事物不同状态切换的逻辑方式；
- 要素：现态（描述事物当前的状态）+ 次态（现态在一定条件下出发相应动作后能达到的状态）+ 条件（执行动作的前提）+ 动作（条件满足时触发状态机状态改变）
- 核心：各个可相互切换的状态+出入动作
tip：
要为状态定义入口动作/出口动作
要详细设计每一个状态，列出层次化状态结构
针对具体问题，严格限制状态跳转的请求
同一层次的状态数量不宜超过5个
记录每一次的跳转历史，方便调试
可能的话，最好使用编辑器来编辑状态机
- 1.有限状态机FSM：只有一个层级的状态切换
- 2.无限（层次）状态机HFSM：存在多个层级的状态切换（状态嵌套）
状态内的状态是不需要关心外部状态的跳转的，这样也做到了无关状态间的隔离；
为什么项目会延期？
- 关于需求：pm在初期需明确每个需求的关键路径和效果预期；存在风险的需求需提前预估风险；复杂需求需与开发评估实现成本；大需求最好化成小需求，方便进度跟进和风险响应；
- 排期与风险控制：排期取决于交付周期+需求量+所需人力；大项目前期可采取周会+后期或短周期项目可采取晨会；延期风险：敢于做减法，分清主次需求；加班；
- 沟通沟通！
