オープンな職場調査-Linux-php.cn

＃＃＃導入＃＃＃ GSD は私の仕事のやり方を導いてくれます。長年にわたり、私は GSD を改善する方法として、リーン手法のフィードバックループやアジャイル開発の反復最適化など、さまざまな手法を日々の仕事習慣に統合してきました。これは、時間を非常に効率的に使用する必要があることを意味します。明確で個別の目標をリストし、完了したプロジェクトにマークを付け、反復的にプロジェクトの進捗を進め続ける必要があります。しかし、オープン性をベースにした場合でも GSD は可能でしょうか?それとも、GSD のアプローチは単に機能しないのでしょうか?

オープンな環境で作業し、オープンな意思決定フレームワークのガイダンスに従うと、プロジェクトの開始が遅くなります。しかし、最近のプロジェクトでは、オープンな方法でコミュニティと協力して取り組むという、最初から正しい決断を下しました。

これが私たちが下せる最善の決定です。

この経験がもたらす予期せぬ結果を見て、GSD のアイデアをオープンな組織フレームワークにどのように組み込むことができるかを見てみましょう。

コミュニティを構築する

2014 年 10 月、私は新しいプロジェクトを引き継ぎました。当時、Red Hat の CEO だったジムホワイトハーストは、新しい本「The Open Organization」を出版しようとしていたので、その概念に基づいたコミュニティを構築したいと考えました。本の中で提案されています。「素晴らしい、これは挑戦のようだ、私も参加する！」と私は思いました。しかしすぐに詐欺師症候群が始まり、「いったい何をするつもりなのか? 成功するには何が必要なのか?」と考え始めました。

ネタバレをさせていただきますが、本の最後でジムは読者に Opensource.com にアクセスして 21 世紀のオープン性と管理についての会話を続けるよう勧めています。そこで、2015 年 5 月に、私たちのチームはこれらのアイデアについて議論するための新しいセクションを Web サイトに作成しました。 Opensource.com でよく行うように、いくつかのストーリーを語る予定ですが、今回は本のアイデアやコンセプトを中心にお話します。それ以来、私たちは毎週新しい記事を公開し、Twitter でオンライン読書クラブを主催し、『Open Organization』を書籍シリーズ化してきました。

私たちはこの書籍シリーズの最初の 3 号を社内で執筆し、6 か月ごとに 1 号を発行しました。各問題が完了したら、コミュニティにリリースします。それから次の問題に進むというサイクルが続きます。

この働き方により、私たちは大きな成功を収めることができました。シリーズの新しい本『オープンな組織のためのリーダーズハンドブック』は、3,000 人近くが購読しています。新刊の発売日が前作の2周年となるよう、半年サイクルでプロジェクトを進めました。

このような背景に対して、私たちがこの本を完成させた方法はシンプルかつ単純明快でした。オープン作品というテーマで、最高のストーリーを集めて記事にまとめ、一部のコンテンツを埋める著者を募集しました。空白、オープンを使用してフォントスタイルを調整しました。ソースツールを使用し、デザイナーと協力して表紙を完成させ、最終的に本を出版します。この働き方により、私たちは自分自身のタイムライン（GSD）に従って全速力で前進することができます。 3 冊目の本までに、ワークフローはほぼ完成しました。

しかし、オープンな組織と IT 文化の交差点に焦点を当てた『The Open Organization』の最終書籍の執筆を計画したとき、状況はすべて変わりました。私がこの本でオープンな意思決定フレームワークの使用を提案したのは、仕事へのオープンなアプローチが、私たちの働き方を完全に変える可能性があることはわかっていても、より良い結果につながることを実証したかったからです。期間は非常にタイトでした（わずか 2 か月半）が、試してみることにしました。

オープンな意思決定フレームワークを使用して本を完成させるオープンな意思決定フレームワークは、オープンな意思決定プロセスを構成する 4 つの段階の概要を示しています。ここでは、各フェーズで私たちがどのように仕事をするか（そして、オープンであることが仕事の遂行にどのように役立つか）を説明します。

1.コンセプト私たちは、プロジェクトのビジョンを概説する草案を書くことから始めました。私たちは何かを取り出して、潜在的な「顧客」（この場合は潜在的な利害関係者と著者）と共有する必要があります。次に、直接的で率直な意見をいただける分野の専門家とのインタビューを設定しました。これらの専門家が示した熱意と彼らが提供した指導は、私たちのアイデアを検証すると同時に、私たちを前進させるフィードバックを提供してくれました。これらの検証が得られない場合は、元のアイデアに立ち戻り、どこからやり直すかを決定します。

2. 計画と調査数回のインタビューを経て、Opensource.com でプロジェクトを発表する準備が整いました。同時に、Github 上でプロジェクトを開始し、プロジェクトの説明、推定スケジュールを提供し、制約を明確にしました。この発表は好評を博し、当初予定していたカタログに欠落していたアイテムもプロジェクト発表から 72 時間以内に完成しました。さらに (そしてさらに重要なことに) 読者の皆様から、私たちの計画には含まれていなかったが、私たちが当初想定していたバージョンを補完するものであると感じたいくつかの章についてのアイデアが提案されました。

振り返ってみると、プロジェクトの第 1 フェーズと第 2 フェーズでは、プロジェクトをオープンにすることはプロジェクトを完了する能力に影響を与えなかったと感じます。実際、この方法で作業すると、コンテンツのギャップを発見して埋めるという大きな利点があります。私たちは単にギャップを埋めるだけではなく、自分たちでは思いつかなかったアイデアで、すぐにギャップを埋めました。これは必ずしも私たちがより多くの仕事をする必要があるわけではなく、私たちの働き方が変わるだけです。私たちは限られたつながりを利用し、他の人に執筆を依頼し、受け取ったコンテンツを整理してコンテキストを設定し、人々を正しい方向に導きます。

3. 設計、開発、テスト

プロジェクトのこのフェーズでは、プロジェクト管理、猫のような異端者を管理し、プロジェクトの期待に対処することがすべてです。私たちは明確な期限を設けており、事前に連絡し、頻繁に連絡を取ります。また、貢献者と関係者のリストを作成し、プロジェクトの全期間を通じてプロジェクトの進捗状況、特に Github 上で計画したマイルストーンを常に知らせるという戦略も採用しました。

最後に、この本には名前が必要です。タイトルがどうあるべきか、そしてさらに重要なことに、タイトルがどうあるべきではないかについて、多くのフィードバックを集めました。私たちは Github 上のチケットを通じてフィードバックを収集し、私たちのチームが最終決定を下すことを公表します。最終的なタイトルを発表する準備をしていたとき、私の同僚のブライアン・ベーレンスハウゼンは、私たちの決定に至ったプロセスを共有する素晴らしい仕事をしてくれました。たとえ最終的なタイトルに同意できなかったとしても、人々はそれに満足しているようでした。

書籍の「ベータ」段階では多くの校正が必要です。コミュニティのメンバーは、この「助けを求める」投稿への回答に積極的に参加してくれました。校正作業の進捗状況を報告する GitHub チケットに約 80 件のコメントを受け取りました (電子メールやその他のフィードバックチャネルを通じて受け取った多くの追加フィードバックは言うまでもありません)。

タスクの完了について: この段階で、私たちはライナスの法則を個人的に経験しました: 「目が多ければ、すべてのタイプミスは浅い。」最初の 3 冊の本のように独立している場合、完了すると、校正の負担全体がかかってきます。私たちの肩は（これらの本と同じように）！代わりに、コミュニティのメンバーが私たちに代わって校正の負担を惜しみなく引き受けてくれて、私たちの仕事は自分たちで校正することから (それでも多くのことは行っていましたが)、すべての変更リクエストを管理することに変わりました。これは私たちのチームにとって歓迎すべき変更であり、コミュニティが参加する機会でもあります。自分たちで校正していれば間違いなくもっと早く校正を終えることができましたが、オープンにしたことで締め切り前にさらに多くの間違いが見つかったのは確かです。

4. リリース

さて、この本の最終版が出版されました。 (それとも初版だけ?)

リリースは 2 段階に分けて行われます。まず、公開プロジェクトのスケジュールに従って、コミュニティの貢献者がダウンロードフォームのテストに協力できるように、最終日の数日前に静かに書籍を公開しました。第 2 段階は、本書の一般版の正式発表です。もちろん、オープンソースのアプローチと同様に、リリース後もフィードバックを受け付けます。

＃＃＃コンテンツ＃＃＃ 実績のロックが解除されました オープンな意思決定フレームワークに従うことが、「IT 文化変革ガイド」の成功の鍵となります。クライアントや関係者と協力し、制約を共有し、仕事について透明性を保つことで、私たちはこの本のプロジェクトに対する私たち自身の期待をも超えることができました。

プロジェクト全体にわたるコラボレーション、フィードバック、活動に非常に満足しています。思ったほど早く物事が終わらないのではないかと不安になった時期もありましたが、プロセスをオープンにすることで実際にはより多くのことを成し遂げることができることにすぐに気づきました。これは、上記の概要に基づいて明らかです。

だから、自分の GSD の考え方を再考して、それを GMD にも拡張する必要があるかもしれません。「Get More Done、より多くのことをやり遂げ、この場合はより良い結果を得る」ということです。

(タイトル画像: opensource.com)

＃＃＃著者について：＃＃＃

Jason Hibbets - Jason Hibbets は、Red Hat Enterprise Marketing のシニアコミュニティエバンジェリストであり、Opensource.com のコミュニティマネージャーです。彼は 2003 年から Red Hat に勤務しており、Open Source Cities Foundation の創設者です。これまでの役職には、シニアマーケティングスペシャリスト、プロジェクトマネージャー、Red Hat Knowledge Base Maintainer、サポートエンジニアなどがあります。

以上がオープンな職場調査の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。