Open ydj9931 opened 4 months ago
ydj9931
commented
3 months ago 运营人员发展之困
谁是开源运营成功榜样？
专业开发者生态运营的可复制进阶之路在哪里？
生态运营是简单、繁杂工作还是复杂创新工作？
生态运营缺乏提供源源不断顶层思维的上游共同体
编程的上游是 工程、数学、网络科学等
当前生态运营方法论还处于经验层的粗浅总结
市场营销、项目管理、计算机科学、产业生态学、网络科学、数据统计
内容运营、活动运营、用户/专家运营、产品运营
更别说，企业的财报中极少有开发者生态，也罕见生态负责人做企业顶级的领导人。
ydj9931
commented
3 months ago show me the code
价值周期、覆盖规模、复杂性、创新性
作品：
ydj9931
commented
3 months ago 最入门的作品就是文档（公开文档或手册，不是工作文件）：以Gitlab HandBookFirst为例
When asked during an INSEAD case study interview (shown above) about challenges related to being all-remote, GitLab co-founder and CEO Sid Sijbrandij provided the following reply. 在欧洲工商管理学院（INSEAD）的案例研究访谈中（如上图所示）中被问及与全远程相关的挑战时，GitLab联合创始人兼首席执行官Sid Sijbrandij提供了以下回答。
The biggest problem is GitLab not working handbook first. We have an amazing handbook that allows us to collaborate, onboard new people, and think collectively. 最大的问题是 GitLab 没有先工作手册。我们有一本了不起的手册，使我们能够协作、招募新朋友并进行集体思考。
However, it is counterintuitive to communicate changes to the handbook. The default of people, when they wish to communicate a change, is to send a Slack message, send an email, give a presentation, or tell people in a meeting — anything but make a change in the handbook. 但是，将更改传达给手册是违反直觉的。当人们希望传达更改时，他们的默认设置是发送 Slack 消息、发送电子邮件、进行演示或在会议上告诉人们——除了在手册中做出更改之外，别无他法。
It’s slower for them. It’s quicker to use any other form. If they make a change in the handbook, they first have to find the relevant part of the handbook, they sometimes have to adjust the handbook to make sure their change will fit in, they have to go through a technical process and a review or two, and they have to wait a bit before it’s deployed. 对他们来说速度更慢。使用任何其他形式都更快。如果他们对手册进行了更改，他们首先必须找到手册的相关部分，有时他们必须调整手册以确保他们的更改适合，他们必须经过一个技术过程和一两次审查，他们必须等待一段时间才能部署。
It’s slower than any other option. However, it allows people that commit a change after that to build upon a change. When they take that extra time, it’s building a foundation for the next thing. 它比任何其他选项都慢。但是，它允许在此之后提交更改的人在更改的基础上进行构建。当他们花费额外的时间时，就是在为下一件事奠定基础。
I think of it as brick laying. Every piece of information is a brick. At GitLab, there is a well-structured house, and everyone adds to that one house. Because we’re pretty particular on how we build it, it has a strong foundation and we can build it very high. 我认为这是砌砖。每一条信息都是一块砖头。在GitLab，有一个结构良好的房子，每个人都在那个房子里增加。因为我们对如何构建它非常讲究，所以它有一个坚实的基础，我们可以把它建得非常高。
In every other company, they send the brick into the hands of people. Everyone is receiving bricks daily that they have to add to the house they’re building internally. They forget things and things are unclear. A lot of context has to be created because there is no context around where to place the bricks. 在所有其他公司中，他们都把砖头送到人们的手中。每个人每天都会收到砖块，他们必须将这些砖块添加到他们内部建造的房屋中。他们忘记了事情，事情不清楚。必须创建很多上下文，因为没有关于在哪里放置砖块的上下文。
So, you can end up with a thousand houses that look quite different, that are all hanging a bit, and each time you add a brick to the top one pops out at the bottom. — GitLab co-founder and CEO Sid Sijbrandij 所以，你最终可能会得到一千栋看起来完全不同的房子，它们都挂着一点，每次你在顶部添加一块砖头时，底部就会弹出一块砖头。— GitLab 联合创始人兼首席执行官 Sid Sijbrandij
远程工作很容易。挑战在于异步工作。组织必须创建一个系统，在这个系统中，每个人都可以使用信息并做出贡献，无论他们的级别、职能或位置如何。我们投资于支持异步通信的工作实践，并致力于教育和支持其他公司完成从 COVID-19 期间开始并一直持续到今天的全球向远程工作的过渡。
Within GitLab, our handbook, which is more than 2,700 web pages and available to the public, is a big part of what enables us to work asynchronously.1 When an employee has a question, they can almost always find the answer documented in our handbook, without having to tap someone on the shoulder. 在 GitLab 中，我们的手册包含 2,700 多个网页，可供公众使用，是使我们能够异步工作的重要组成部分。1当员工有问题时，他们几乎总能找到我们手册中记录的答案，而不必轻拍别人的肩膀。
The “handbook first” system is embedded in the way we work. Every change must first be documented in the handbook, and all communications about the change include a link back to the handbook. We work together to make sure it is always up to date. For example, our CMSO [chief marketing and strategy officer] is responsible for maintaining the marketing section, though anyone can propose edits as needed. “手册优先”的制度已经融入我们的工作方式。每项更改都必须首先记录在手册中，并且所有有关更改的通信都包含指向手册的链接。我们共同努力，确保它始终是最新的。例如，我们的 CMSO [首席营销和战略官] 负责维护营销部分，但任何人都可以根据需要提出编辑建议。
面向运营人员的开源协作入门
每个人应该都成为文档工程师