2019-12-18印象最深：把自己的全部精力和热情投入到一件事情上的时候，结果通常不会太坏。
觉得石老师做的比较好的：产品需求、技术风险、开发流程、开发工具、团队建设。
产品需求：一开始有个初步的需求，不断迭代、清晰。
技术风险：能在项目早期消除该项目用到所有技术的技术风险
开发流程：敏捷软件开发，精益看板，明确分支策略、异地团队简间的沟通、合作机制（一周一次会议）
开发工具：jira docker Python Django Vue 其他工具未知。。。
团队建设：沟通、信任、放权、模棱两可的时候拍板
以上是我的理解😊。
感谢石老师毫无保留地倾囊相授。展开作者回复: 感谢你毫无保留的总结😄 非常清晰，为你点赞哈，作为一个有心人，祝你新的一年里面事业有成，突飞猛进哈！
2
2019-12-18“事实证明，但凡能打硬仗的同事，在后来都是非常靠谱且独当一面的，这与年龄无关，哪怕是应届生，也同样如此。” 活的久了越来越发现，成长和年龄其实没有必然的联系。有些人虽然很年轻，但是有自己的思考框架和处事原则，积极主动愿意承担责任，事后会复盘，持续在迭代，这时候时间就是Ta的朋友；而有些人行事随性，做事挑肥拣瘦，逃避责任，得过且过，永远也不去反思，吃一堑，只长肉不涨智，这时候时间就是Ta的敌人。作者回复: 有一个特别经典的问题，你如何判断现在工作是否给你提供了足够的挑战和空间，答案就是看你现在的生活是否足够安逸，有挑战的工作是不会让你安逸下来的，要经常提醒自己这一点哈，当然啦，劳逸结合也是必要的，提前祝你新年快乐哈！
1- 2019-12-18老师这篇文章真是看的让人热血沸腾！
作者回复: 每个人都值得拥有一次急行军呀，IT人员的热情就在于全情投入，不是吗😝
1 
2019-12-17内容很精辟：老师如果长期夹在产品与研发、销售与研发、研发与运维之中，整个的过程会更加的顺利的。电商的数年一直处于此种角色，由于工作中的随和且都做任何事情都绕不开需要数据部门做支持，导致长期在几方之间协调，不知不觉锻炼出了整体的格局观和效率沟通能力。
最近学习产品和项目管理课程时：自己就明显感受到这点。虽然之前没有专门的去学产品、运营，可是之前一直处于他们和研发部门的沟通协调中，让我觉得不少知识都不陌生只是不知道相关理论而已。
谢谢老师今天的分享：期待后续课程的学习。 1
2020-01-19这篇对于产品运营策略感受最深，以前做过2个内部使用的系统，满怀信心的上线却无人问津，想找人吐吐槽都没有。那个时候很简单的就认为产品经理只要负责产品优秀，推广运营的事情都是市场部门的活。现实打了个很响的巴掌，嘲笑当时的天真，现在努力不断了解如何给自己的产品做运营，找天使用户，找渠道，找合作者～作者回复: 没错，以后不会做运营的产品经理都不是合格的产品经理，因为很多时候产品功能都需要搭配运营功能，比如：关键数据的埋点等等。如果一开始就没有考虑这个因素，那么产品迭代越来越快，你很难知道究竟哪些功能是有价值的，哪些是拍脑袋拍出来的。再加上A/B测试，原型验证和数据分析，线上监控的手段越来越丰富，提供给产品的选项也越来越多。要相信，做得好，也要说得好，这一点在任何地方都是很重要的。
2019-12-19老师。关于文中提到的三分支策略，我有两个问题，期待老师的回答。
1.出现bug，是不是新增加一个bugfix的特性分支进行修复，修复完后把代码合并到dev分支？
2.在dev分支AutoMerge到master分支（或者master分支AutoMerge到release分支）时，是将分支的代码全部合并过去，还是挑选一部分特性的代码合并过去，如果是挑选一部分代码，怎么挑选？
比如：我只想从dev分支中挑选一部分特性合并到master分支；或者只从master分支中挑选一部分特性合并到release分支，该如何挑选出这些特性代码？展开作者回复: 你好，回答你的问题如下：
1. 出现Bug，要看Bug的严重程度，如果一般的问题，那么跟正常开发需求一样，从dev，到master再到release就可以了，但如果非常紧急的Bug，那就反过来，在Release上拉出hotfix分支，然后上线后再反向合并回master，dev
2. AutoMerge是全量的合并，而并非挑选部分特性哈，如果想实现基于特性的AutoMerge，这对特性的管理要求很高。具体你可以这样实现，首先每个特性的开发都在特性分支上完成，然后特性的交付是以特性分支向主干合并为标志的，那么如果你希望挑选几个特性，那么就合并提交特性分支即可。但这可没这么简单，首先特性的依赖要处理好，其次，特性的颗粒度要足够小，发布频率足够快，第三，避免有些特性长期不合并导致的多分支差异变大的情况。- 2019-12-18“关于产品运营策略，‘酒香不怕巷子深’的理念已经有些过时了。想要一个产品获得成功，团队不仅要做得好，还要善于运营和宣传，而这又是技术团队的一大软肋。” 很赞成。对这个观点最有感触的时候是在我学习Linux的时候发现居然有这么那么有用的功能居然没人知道！
作者回复: 这就好比人人都在用苹果电脑，但没几个人是真正会用的一样，但这恰恰是一个好产品应该具备的特征，易于上手，难于精通，空间足够。
- 2019-12-18“研发环境容器化”这真是一个很好的思路。真像老师所说的，在做环境部署的时候，文档再怎么详尽，都会被一两个不起眼的小坑绊倒，而且可能要很久才能再爬起来。现在想想敏捷宣言里面提到的“working software over comprehensive documentation”，放在运维文档也是一样，繁琐不变的文档永远都赶不上瞬息万变的环境…
作者回复: 文档即过时，这话一点不假。。。正因为这样，才出现了自动化文档生成的技术，比如类似swagger这类工具，都是为了保证代码和文档的实时同步的，我认为这也是未来的一个比较好的方向哈。
2019-12-18不仅仅是学习devops的知识，更是一种思路和解决问题的方式方法作者回复: 说的没错，一个人的价值不就是他能解决的问题的价值吗😝
2019-12-17很喜欢这种从无到有做一个产品的感觉，没有什么历史束缚，可以自由发挥自己的思想和主动性。
2019-12-17看完这一篇，更加期待老师的实战篇！- 2019-12-17👍，期待下一讲石老师的实战历程