Vol.50 女性友谊|别躺平姐妹,10年后还得靠你!

嗑学小组

这期想和大家聊聊,女性友谊。 这个话题之前就尝试聊过一次。我们各自讲了身边的朋友故事,分享了在自己人生中比较重要的朋友类型。但是录了2个多小时之后,一直没有聊出我们想要的火花,很多话也没有说出来。关了录音,几个人又讨论了一会,中间出现了聊崩了聊哭了聊冷战了等等等等小桥段……(大宝:对不起) 想再把这个话题捡起来的时候,正好赶上了比较重要的阶段—YY马上就要出国了,从此我们的联系就要克服时差,我们的录制也要一直在线上。 那重新聊回“女性友谊”,就从我们三个自己的故事来讲起吧。 为什么会选择对方成为自己的朋友呢? 有矛盾过吗,有伤心过吗?怎么面对「隔阂」? 哪些时刻,特别感谢有对方的存在? 异地友谊该如何维护?「嗑学小组」会停更吗? 这期会伴随哭嚎会听到一些真情告白和自我剖析:我们的回顾、我们一直想说没说出口的话、我们由女性友谊所产生的思考和感动。 如今,我们是陪伴彼此日常吐槽、追剧八卦、排忧解难的情绪垃圾桶、智多星、正道的光。那未来会是什么样子的呢? 这结尾的10年之约里,希望我们的预判,都可以成真!!! 也希望评论区留下你的故事。「我的朋友会发光」请讲讲她吧! 【本期主播】 YY、Yao、王大宝 【本期可以听到】 * 05:54 我们三个人的故事:有人感伤,有人泪崩,有人偷偷看手机 * 20:32 为什么我们会成为朋友? * 32:27 误解、负面情绪、“恶意”?我们的友谊小船说翻就翻? * 37:29 一次内部冷战复盘:整理「崩溃」、直面「雷区」 * 48:01 嘿!哥们!嘿!闺蜜! * 50:30 还是我更懂你啊 * 55:56 我们的「十年之约」 【本期BGM】 * 0:02《送别》朴树 * 3:07《凤凰花开的路口》林志炫 * 19:08《you are my sunshine》Christina Perri * 41:01《南下》徐海俏 * 1:03:53《细说从头》南方二重奏 【联系我们】 即刻微博都不咋更新,求个关注求催更——@嗑学小组 拉听友群就为了能有人和我们唠没用的+v:dabaomm101 以及开始许愿,会有合作吗?

64分钟
1k+
3年前

vol.27 合理运用敏捷方法:十大秘诀(《启示录》第26章)

产品自习室

【本期介绍】 继续分享 Marty Cagan 的《启示录》里面的知识。 今天的主题是「合理运用敏捷方法:十大秘诀」,主要内容见时间轴~ 【时间轴】 00:50 一、概述 1. 认识敏捷方法 (1)起源与注意 (2)官网:https://agilemanifesto.org/ 02:03(3)敏捷软件开发宣言 我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观: * 个体和互动 高于 流程和工具 * 工作的软件 高于 详尽的文档 * 客户合作 高于 合同谈判 * 响应变化 高于 遵循计划 也就是说,尽管右项有其价值,我们更重视左项的价值。 03:01(4)敏捷软件的十二条原则 * ① 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。 * ② 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。 * ③ 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。 * ④ 业务人员和开发人员必须相互合作,项目中的每一天都不例外。 * ⑤ 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。 * ⑥ 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。 * ⑦ 可工作的软件是进度的首要度量标准。 * ⑧ 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。 * ⑨ 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。 * ⑩ 以简洁为本,它是极力减少不必要工作量的艺术。 * ⑪ 最好的架构、需求和设计出自自组织团队。 * ⑫ 团队定期地反思如何能提高成效,并依此调整自身的举止表现。 05:40 2. 本章注意 * 这些诀窍只适用于产品软件团队,不适用于定制软件团队 -------------------------------------------- 05:51 二、十条原则 1. 产品经理即是产品负责人 * 代表客户的需求 * 敏捷方法不能让工作变轻松 (部分观点参考:vol.03《启示录》产品管理与产品营销:两者不是一回事) 2. 使用敏捷方法绝不等于省略产品规划 * 仍然要做的事 * 敏捷环境里的特殊处理 (部分观点参考:vol.12《启示录》评估产品机会:确定待解决的问题) 3. 产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期 * 让交互设计师和视觉设计师提前设计 * 让开发人员参与评估产品设计和产品原型 (部分观点参考:vol.20《启示录》 用户体验设计与实现:先定义用户体验再动手开发) 4. 把产品设计工作拆分成独立的部分,分而治之,但也不能拆得太细 * 解释 * 敏捷环境下的注意事项 (部分观点参考:vol.21《启示录》 基本产品:消减功能还是延长工期?) 5. 产品经理的主要任务是定义有价值、可用的产品原型和用户故事,作为开发的基础 * 替代文档的三个优势 * 具体做法 6. 让开发人员自主划分迭代周期 * 不同产品的迭代周期不同 * 开发团队的考虑 7. 产品经理和交互设计师必须出席每天的晨会 晨会是一天沟通的开始,而不是结束 * 设计师的沟通 * 开发人员的沟通 * 测试人员和开发人员的沟通 8. 除非达到了产品经理的要求,否则不要轻易发布新版本 (部分观点参考:vol.25《启示录》平滑部署:避免更新产品导致用户反感) 9. 在每次迭代完成后,产品经理应该向团队展示产品现状,以及下次迭代的产品原型 * 这样做的意义 10. 在团队内展开敏捷培训 * 聘请敏捷顾问 * 让每位成员都理解敏捷方法 -------------------------------------------- 04:01 三、问答 14:37 1. 迭代初期开发的产品能做原型吗? (1)这种做法对产品软件是行不通的 (2)原因如下 * 两种效率的比较 * 应该减少占用开发团队的精力 * 开发团队的成本和难度问题 16:52 2. 敏捷方法可以用来开发产品软件吗? (1)很多人持怀疑态度 * 原因 (2)敏捷方法的起源 * 起源于定制软件领域 (3)关于定制软件 * 长久以来,开发定制软件困难重重 * 定制软件领域长期很难招聘/留住顶级程序员 * 定制软件的客户 * 定制软件的另一特点:项目规模较小 * 定制软件领域的瀑布式开发方法 (4)敏捷方法对于定制软件的作用 提高了开发定制软件的效率: * 增进客户和开发的交流 * 降低风险 * 引进现代软件测试的理念 * 省去撰写连篇累赘的产品说明文档的麻烦 (5)敏捷方法与产品软件 * 同样适用,但需要调整 * 敏捷方法唯一不适合产品软件的地方:架构设计方面 * 产品团队使用敏捷方法时遇到问题的原因 * 转型成为敏捷开发团队的关键 【关于主播】 感谢大家收听「产品自习室」,做这个播客的目的,主要是想记录自己的产品经理的学习过程,希望通过声音输出提高自己的学习吸收率,通过做轻文案播客锻炼口才。 欢迎添加我的微信交流!pmnino9 公众号:PM尼诺

27分钟
82
3年前

vol.26 快速响应阶段:产品出炉后切忌虎头蛇尾(《启示录》第25章)

产品自习室

【本期介绍】 继续分享 Marty Cagan 的《启示录》里面的知识。 今天的主题是「快速响应阶段:产品出炉后切忌虎头蛇尾」,主要内容见时间轴~ 【时间轴】 00:58 一、产品发布后的“误操作” 1. 迅速撤走资源,急于投入下一个项目 2. 此时正式收集反馈信息、改进产品的最佳时机 3. 为什么说是最佳时机? * 只要稍微延长项目周期,观察用户对产品的反应,效果会有天壤之别 -------------------------------------------- 01:58 二、作者的主张 1. 留出时间作为快速响应阶段 2. 这个阶段的主要工作 3. 快速响应阶段的发展 -------------------------------------------- 02:56 三、关于快速响应 1. 为什么要快速响应? * 应对发布后的意外情况 2. 快速响应的关键 * 不在于是否会出现问题,而在于能多快解决问题 3. 评估产品表现 * 使用明确的、可量化的指标 * 具体使用哪些指标? * 给指标分出轻重缓急,并保持关注 * 对结果导致成功或失败,心中有数 4. 针对不同产品的特殊说明 * 针对大众的网络服务 * 企业级软件 5. 其它说明 * 其他工具或方式推荐 * 客户服务人员、销售人员和合作伙伴的意见也不容忽视 【关于主播】 感谢大家收听「产品自习室」,做这个播客的目的,主要是想记录自己的产品经理的学习过程,希望通过声音输出提高自己的学习吸收率,通过做轻文案播客锻炼口才。 欢迎添加我的微信交流!pmnino9 公众号:PM尼诺

8分钟
12
3年前
EarsOnMe

加入我们的 Discord

与播客爱好者一起交流

立即加入

扫描微信二维码

添加微信好友,获取更多播客资讯

微信二维码

播放列表

自动播放下一个

播放列表还是空的

去找些喜欢的节目添加进来吧