열린 직장 연구

소개	GSD는 내가 일하는 방식을 안내합니다. 수년에 걸쳐 저는 더 나은 GSD를 위한 방법으로 린 방식의 피드백 루프, 애자일 개발의 반복적 최적화 등 다양한 방법론을 일상 업무 습관에 통합했습니다. 이는 내 시간을 매우 효율적으로 사용해야 함을 의미합니다. 명확하고 개별적인 목표를 나열하고 완료된 프로젝트를 표시하고 반복적인 방식으로 프로젝트 진행을 계속 진행해야 합니다. 하지만 개방성에 기반을 두고도 여전히 GSD를 할 수 있을까요? 아니면 GSD의 접근 방식이 단순히 작동하지 않는 걸까요?

개방형 환경에서 작업하고 개방형 의사결정 프레임워크의 지침을 따르면 프로젝트 시작 속도가 느려집니다. 그러나 최근 프로젝트에서 우리는 처음부터 올바른 결정을 내렸습니다. 즉, 개방적인 방식으로 커뮤니티와 협력하여 작업하기로 했습니다.

이것은 우리가 내릴 수 있는 최선의 결정입니다.

이 경험의 의도하지 않은 결과를 살펴보고 GSD 사고를 개방형 조직 프레임워크에 통합할 수 있는 방법을 살펴보겠습니다.

커뮤니티 구축

2014년 10월, 저는 새로운 프로젝트를 맡았습니다. 당시 Red Hat의 CEO였던 Jim Whitehurst는 새로운 책 "The Open Organization"을 출간할 예정이었습니다. 저는 Red Hat에서 제안한 개념을 기반으로 커뮤니티를 구축하고 싶었습니다. 책. "좋아요, 도전처럼 들리네요. 저도 참여하겠습니다!" 하지만 곧 가면 증후군이 시작되었고 저는 "도대체 우리가 성공하려면 무엇이 필요한가?"라고 생각하기 시작했습니다.

스포일러를 하나 말씀드리자면 책 끝부분에서 Jim은 독자들에게 Opensource.com을 방문하여 21세기의 개방성과 관리에 대한 대화를 계속할 것을 권장합니다. 그래서 2015년 5월에 우리 팀은 이러한 아이디어를 논의하기 위해 웹사이트에 새로운 섹션을 만들었습니다. 우리는 Opensource.com에서 자주 하는 것처럼 몇 가지 이야기를 들려줄 계획이지만 이번에는 책에 나온 아이디어와 개념을 중심으로 이야기를 나누고자 합니다. 그 이후로 우리는 매주 새로운 기사를 게재하고, 트위터에서 온라인 북클럽을 개최하고, Open Organization을 책 시리즈로 전환했습니다.

우리는 책 시리즈의 첫 3호를 자체 집필하여 6개월마다 출판했습니다. 각 이슈가 완료되면 이를 커뮤니티에 공개합니다. 그런 다음 다음 호로 넘어가고 순환이 계속됩니다.

이러한 작업 방식을 통해 우리는 큰 성공을 거둘 수 있었습니다. 거의 3,000명에 달하는 사람들이 시리즈의 새로운 책인 개방형 조직을 위한 리더 핸드북을 구독했습니다. 신간 출간일이 전작의 2주년이 되도록 6개월 주기로 프로젝트를 진행했습니다.

이러한 맥락에서 우리가 이 책을 완성한 방법은 간단하고 간단했습니다. 오픈 작업 주제에 관해 최고의 이야기를 모아 기사로 정리하고, 콘텐츠 공백을 메우기 위해 작가를 모집하고, 오픈 소스 도구를 사용하여 글꼴 스타일을 조정했습니다. , 디자이너와 협력하여 표지를 마무리하고 최종적으로 책을 출판합니다. 이러한 작업 방식을 통해 우리는 자체 일정(GSD)에 따라 최고 속도로 전진할 수 있습니다. 세 번째 책에서는 작업 흐름이 대부분 완료되었습니다.

개방형 조직과 IT 문화의 교차점에 초점을 맞춘 The Open Organization의 마지막 책을 시작할 계획을 세웠을 때 모든 것이 바뀌었습니다. 나는 이 책에서 개방형 의사결정 프레임워크를 사용할 것을 제안했습니다. 왜냐하면 개방적인 접근 방식이 우리가 일하는 방식을 완전히 바꿀 수 있다는 것을 알면서도 업무에 대한 개방적인 접근 방식이 더 나은 결과를 가져온다는 것을 보여주고 싶었기 때문입니다. 일정이 매우 빡빡했지만(단 2개월 반), 우리는 한번 시도해 보기로 결정했습니다.

책 완성을 위해 개방형 의사결정 프레임워크를 사용하세요 공개 의사 결정 프레임워크는 공개 의사 결정 프로세스를 구성하는 4단계를 간략하게 설명합니다. 각 단계를 진행하는 방법은 다음과 같습니다(그리고 개방성이 작업을 완료하는 데 어떻게 도움이 되는지).

1. 컨셉 우리는 프로젝트 비전을 설명하는 초안을 작성하는 것부터 시작했습니다. 우리는 무언가를 꺼내서 잠재적인 "고객"(이 경우 잠재적인 이해관계자 및 작성자)과 공유해야 합니다. 그런 다음 직접적이고 솔직한 의견을 줄 수 있는 해당 분야 전문가와의 인터뷰를 준비했습니다. 이러한 전문가들이 보여준 열정과 그들이 제공한 지침은 우리의 아이디어를 검증하는 동시에 우리가 앞으로 나아갈 수 있도록 피드백을 제공했습니다. 이러한 검증을 받지 못하면 원래 아이디어로 돌아가 어디서 다시 시작할지 결정합니다.

2. 기획 및 연구 몇 차례의 인터뷰를 거쳐 Opensource.com에 프로젝트를 발표할 준비가 되었습니다. 동시에 우리는 Github에서 프로젝트를 시작하여 프로젝트 설명, 예상 일정을 제공하고 제약 조건을 명확히 했습니다. 발표는 호평을 받았으며 원래 계획된 카탈로그에서 누락된 일부 항목은 프로젝트 발표 후 72시간 이내에 완료되었습니다. 추가적으로(더 중요한 것은) 독자들이 우리 계획의 일부는 아니었지만 우리가 원래 구상했던 버전을 보완할 것이라고 생각하는 일부 장에 대한 아이디어를 제안했습니다.

돌아보면 프로젝트의 첫 번째와 두 번째 단계에서 프로젝트를 공개하는 것이 프로젝트를 완료하는 능력에 영향을 미치지 않았다고 생각합니다. 실제로 이러한 방식으로 작업하면 콘텐츠 격차를 발견하고 메우는 큰 이점이 있습니다. 우리는 단지 공백을 메운 것이 아니라, 우리 스스로는 결코 고려하지 않았을 아이디어로 신속하게 채웠습니다. 이로 인해 반드시 더 많은 작업을 수행해야 하는 것은 아니며 작업 방식이 바뀔 뿐입니다. 우리는 제한된 연결을 활용하고 다른 사람들에게 글을 쓰도록 초대한 다음 우리가 받는 콘텐츠를 정리하여 상황을 설정하고 사람들을 올바른 방향으로 안내합니다.

3. 디자인, 개발 및 테스트

프로젝트의 이 단계는 프로젝트 관리, 고양이 같은 독재자 관리 및 프로젝트에 대한 기대 사항 처리에 관한 것입니다. 우리는 명확한 기한을 갖고 있으며, 사전에 소통하고 자주 소통합니다. 또한 기여자와 이해관계자 목록을 작성하고 프로젝트 수명 전반에 걸쳐 프로젝트 진행 상황, 특히 Github에서 계획한 이정표에 대한 정보를 제공하는 전략을 사용했습니다.

마지막으로 우리 책에는 이름이 필요합니다. 우리는 제목이 어떠해야 하는지, 더 중요하게는 제목이 어떠면 안 되는지에 대해 많은 피드백을 수집했습니다. 우리는 Github의 티켓을 통해 피드백을 수집하고 우리 팀이 최종 결정을 내릴 것임을 공개합니다. 최종 타이틀 발표를 준비하는 동안 제 동료인 Bryan Behrenshausen은 우리가 결정하게 된 과정을 훌륭하게 공유했습니다. 사람들은 우리의 최종 제목에 동의하지 않더라도 그것에 대해 기뻐하는 것 같았습니다.

책의 '베타' 단계에는 많은 교정이 필요합니다. 커뮤니티 회원들은 이 "도움 요청" 게시물에 답변하는 데 실제로 참여했습니다. 교정 작업의 진행 상황을 보고하는 GitHub 티켓에 대해 약 80개의 댓글을 받았습니다(이메일 및 기타 피드백 채널을 통해 받은 많은 추가 피드백은 말할 것도 없습니다).

작업 완료에 대해: 이 단계에서 우리는 "눈이 많을수록 모든 오타가 얕아진다"는 리누스의 법칙을 직접 경험했습니다. 처음 세 권의 책처럼 독립적으로 완료하면 교정의 모든 부담이 우리 어깨에 지게 됩니다( 이 책들과 마찬가지로)! 대신, 커뮤니티 구성원들이 우리를 위해 교정 부담을 관대하게 떠맡았고, 우리의 임무는 스스로 교정하는 것(비록 여전히 많은 일을 했지만)에서 모든 변경 요청을 관리하는 것으로 바뀌었습니다. 이는 우리 팀에게 환영할 만한 변화이며 커뮤니티가 참여할 수 있는 기회입니다. 우리가 직접 교정을 했다면 확실히 더 빨리 교정을 끝낼 수 있었겠지만 공개적으로 마감일 이전에 더 많은 오류를 발견한 것은 확실합니다.

4. 게시

자, 이제 책의 최종 버전이 나왔습니다. (아니면 초판만?)

출시를 두 단계로 나눕니다. 첫째, 공개 프로젝트 일정에 따라 우리는 커뮤니티 기여자들이 다운로드 양식을 테스트하는 데 도움을 줄 수 있도록 최종 날짜 며칠 전에 조용히 책을 출시했습니다. 두 번째 단계는 이제 이 책의 일반판이 공식적으로 발표되는 단계입니다. 물론 오픈 소스 접근 방식과 마찬가지로 출시 후에도 피드백을 계속 받습니다.

콘텐츠

업적 잠금 해제
개방형 의사결정 프레임워크를 따르는 것이 IT 문화 변화 가이드의 성공에 핵심입니다. 고객 및 이해관계자와 협력하고, 제약 사항을 공유하고, 작업에 대해 투명하게 공개함으로써 우리는 도서 프로젝트에 대한 우리 자신의 기대치를 뛰어 넘었습니다.

프로젝트 전반에 걸친 협업, 피드백 및 활동에 매우 만족합니다. 내가 원하는 만큼 일을 빨리 끝내지 못하는 것에 대한 불안감이 있었지만, 프로세스를 공개하면 실제로 더 많은 일을 할 수 있다는 것을 금방 깨달았습니다. 이는 위의 개요에 따르면 분명합니다.

그러므로 내 GSD 사고방식을 다시 생각하고 이를 GMD로 확장해야 할 것 같습니다. 더 많은 일을 하고, 더 많은 일을 하고, 이 경우에는 더 나은 결과를 얻으십시오.

(제목 사진: opensource.com)

작가 소개:

Jason Hibbets - Jason Hibbets는 Red Hat Enterprise Marketing의 수석 커뮤니티 전도사이자 Opensource.com의 커뮤니티 관리자입니다. 그는 2003년부터 Red Hat에 근무했으며 Open Source Cities Foundation의 창립자입니다. 이전 직위로는 수석 마케팅 전문가, 프로젝트 관리자, Red Hat 지식 기반 유지관리자, 지원 엔지니어 등이 있습니다.

위 내용은 열린 직장 연구의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!