26 | 平台产品研发：三个月完成千人规模的产品要怎么做？
该思维导图由 AI 生成，仅供参考
项目启动
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文分享了一个非专业的DevOps产品经理如何应对挑战，从项目启动阶段开始介绍了团队构成、项目构思、Kickoff会议的准备工作和重要性，以及团队达成的关键结论：系统方案选型和建立协作机制。在技术框架方面，选择了Python+Django+VUE的方式来进行开发，并建立了固定的沟通机制。此外，强调了识别项目的技术风险，并提前开启专项预研的重要性。文章还介绍了开发策略和开发协作流程，包括研发环境容器化、选择分支策略、使用Jira进行研发协作规范等。总的来说，文章强调了在项目启动阶段要重点关注的几件事情：明确项目目标，沟通开发模式和技术架构选型，建立沟通渠道，识别项目的技术风险，提前开启专项预研。这些经验可以帮助读者快速了解如何在短时间内完成大规模产品的开发，体现了文章的技术特点。文章还分享了产品运营策略和团队文化建设的观点，强调了产品运营的重要性以及团队文化建设中专业人员的重要性和抓大放小的原则。整体而言，本文内容丰富，涵盖了项目启动、技术选型、开发策略、产品运营和团队文化建设等方面，对于非专业产品经理和技术团队具有一定的借鉴意义。
《DevOps 实战笔记》，新⼈⾸单¥59
全部留言(17)
- 最新
- 精选
心在飞印象最深：把自己的全部精力和热情投入到一件事情上的时候，结果通常不会太坏。 觉得石老师做的比较好的：产品需求、技术风险、开发流程、开发工具、团队建设。 产品需求：一开始有个初步的需求，不断迭代、清晰。 技术风险：能在项目早期消除该项目用到所有技术的技术风险 开发流程：敏捷软件开发，精益看板，明确分支策略、异地团队简间的沟通、合作机制（一周一次会议） 开发工具：jira docker Python Django Vue 其他工具未知。。。 团队建设：沟通、信任、放权、模棱两可的时候拍板 以上是我的理解😊。 感谢石老师毫无保留地倾囊相授。作者回复: 感谢你毫无保留的总结😄 非常清晰，为你点赞哈，作为一个有心人，祝你新的一年里面事业有成，突飞猛进哈！
2019-12-189
陈斯佳“事实证明，但凡能打硬仗的同事，在后来都是非常靠谱且独当一面的，这与年龄无关，哪怕是应届生，也同样如此。” 活的久了越来越发现，成长和年龄其实没有必然的联系。有些人虽然很年轻，但是有自己的思考框架和处事原则，积极主动愿意承担责任，事后会复盘，持续在迭代，这时候时间就是Ta的朋友；而有些人行事随性，做事挑肥拣瘦，逃避责任，得过且过，永远也不去反思，吃一堑，只长肉不涨智，这时候时间就是Ta的敌人。作者回复: 有一个特别经典的问题，你如何判断现在工作是否给你提供了足够的挑战和空间，答案就是看你现在的生活是否足够安逸，有挑战的工作是不会让你安逸下来的，要经常提醒自己这一点哈，当然啦，劳逸结合也是必要的，提前祝你新年快乐哈！
2019-12-187- 陈斯佳“研发环境容器化”这真是一个很好的思路。真像老师所说的，在做环境部署的时候，文档再怎么详尽，都会被一两个不起眼的小坑绊倒，而且可能要很久才能再爬起来。现在想想敏捷宣言里面提到的“working software over comprehensive documentation”，放在运维文档也是一样，繁琐不变的文档永远都赶不上瞬息万变的环境…
作者回复: 文档即过时，这话一点不假。。。正因为这样，才出现了自动化文档生成的技术，比如类似swagger这类工具，都是为了保证代码和文档的实时同步的，我认为这也是未来的一个比较好的方向哈。
2019-12-184 
johnny老师。关于文中提到的三分支策略，我有两个问题，期待老师的回答。 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-193- 陈斯佳老师这篇文章真是看的让人热血沸腾！
作者回复: 每个人都值得拥有一次急行军呀，IT人员的热情就在于全情投入，不是吗😝
2019-12-183 - 陈斯佳“关于产品运营策略，‘酒香不怕巷子深’的理念已经有些过时了。想要一个产品获得成功，团队不仅要做得好，还要善于运营和宣传，而这又是技术团队的一大软肋。” 很赞成。对这个观点最有感触的时候是在我学习Linux的时候发现居然有这么那么有用的功能居然没人知道！
作者回复: 这就好比人人都在用苹果电脑，但没几个人是真正会用的一样，但这恰恰是一个好产品应该具备的特征，易于上手，难于精通，空间足够。
2019-12-181 - sugar不仅仅是学习devops的知识，更是一种思路和解决问题的方式方法
作者回复: 说的没错，一个人的价值不就是他能解决的问题的价值吗😝
2019-12-181 
linda.zx这篇对于产品运营策略感受最深，以前做过2个内部使用的系统，满怀信心的上线却无人问津，想找人吐吐槽都没有。那个时候很简单的就认为产品经理只要负责产品优秀，推广运营的事情都是市场部门的活。现实打了个很响的巴掌，嘲笑当时的天真，现在努力不断了解如何给自己的产品做运营，找天使用户，找渠道，找合作者～作者回复: 没错，以后不会做运营的产品经理都不是合格的产品经理，因为很多时候产品功能都需要搭配运营功能，比如：关键数据的埋点等等。如果一开始就没有考虑这个因素，那么产品迭代越来越快，你很难知道究竟哪些功能是有价值的，哪些是拍脑袋拍出来的。再加上A/B测试，原型验证和数据分析，线上监控的手段越来越丰富，提供给产品的选项也越来越多。要相信，做得好，也要说得好，这一点在任何地方都是很重要的。
2020-01-19
leslie内容很精辟：老师如果长期夹在产品与研发、销售与研发、研发与运维之中，整个的过程会更加的顺利的。电商的数年一直处于此种角色，由于工作中的随和且都做任何事情都绕不开需要数据部门做支持，导致长期在几方之间协调，不知不觉锻炼出了整体的格局观和效率沟通能力。 最近学习产品和项目管理课程时：自己就明显感受到这点。虽然之前没有专门的去学产品、运营，可是之前一直处于他们和研发部门的沟通协调中，让我觉得不少知识都不陌生只是不知道相关理论而已。 谢谢老师今天的分享：期待后续课程的学习。2019-12-173
桃子-夏勇杰其实最感兴趣的是老师没有讲出来的部分，这个平台最初的MVP是什么样子的，解决了用户什么样的核心诉求，后续开发又开发了一些什么功能，都解决了一些什么问题。2020-06-011
