Penyelidikan tempat kerja terbuka

Pengenalan

GSD membimbing cara saya bekerja. Selama bertahun-tahun, saya telah menyepadukan pelbagai metodologi ke dalam tabiat kerja harian saya, termasuk gelung maklum balas kaedah ramping, dan pengoptimuman berulang pembangunan tangkas, sebagai cara untuk meningkatkan GSD. Ini bermakna saya perlu menggunakan masa saya dengan sangat cekap: senaraikan matlamat yang jelas dan diskret; Tetapi adakah kita masih boleh GSD apabila kita mendasarkannya pada keterbukaan? Atau mungkin pendekatan GSD tidak berkesan?

Bekerja dalam persekitaran terbuka dan mengikut panduan dalam Rangka Kerja Keputusan Terbuka akan menjadikan projek bermula lebih perlahan. Tetapi pada projek baru-baru ini, kami membuat keputusan yang tepat dari awal: untuk bekerja secara terbuka dan bekerjasama dengan komuniti kami.

Ini adalah keputusan terbaik yang kami boleh buat.

Mari kita lihat akibat yang tidak diingini daripada pengalaman ini dan lihat cara kita boleh menyepadukan pemikiran GSD ke dalam rangka kerja organisasi terbuka.

Membina komuniti

Pada Oktober 2014, saya mengambil alih projek baharu: Jim Whitehurst, Ketua Pegawai Eksekutif Red Hat pada masa itu, akan melancarkan buku baharu "The Open Organization". Saya mahu membina komuniti berdasarkan konsep yang dicadangkan dalam buku. "Bagus, ini kelihatan seperti satu cabaran, saya fikir!" Tetapi tidak lama kemudian sindrom penipu berlaku dan saya mula berfikir, “Apa yang kita akan lakukan untuk berjaya?”

Izinkan saya memberi anda spoiler, di penghujung buku, Jim menggalakkan pembaca melawat Opensource.com untuk meneruskan perbualan tentang keterbukaan dan pengurusan pada abad ke-21. Jadi, pada Mei 2015, pasukan kami mencipta bahagian baharu di tapak web untuk membincangkan idea ini. Kami merancang untuk menceritakan beberapa cerita, seperti yang sering kami lakukan di Opensource.com, tetapi kali ini mengenai idea dan konsep daripada buku itu. Sejak itu, kami telah menerbitkan artikel baharu setiap minggu, menganjurkan kelab buku dalam talian di Twitter, dan menjadikan Organisasi Terbuka sebagai siri buku.

Kami menulis tiga keluaran pertama siri buku secara dalaman dan mengeluarkannya setiap enam bulan. Apabila setiap isu selesai, kami mengeluarkannya kepada komuniti. Kemudian kita beralih ke isu seterusnya, dan kitaran diteruskan.

Cara kerja ini telah membolehkan kami melihat kejayaan yang hebat. Hampir 3,000 orang telah melanggan buku baharu dalam siri ini: Buku Panduan Pemimpin untuk Organisasi Terbuka. Kami mengusahakan projek itu dalam kitaran enam bulan supaya tarikh keluaran buku baharu itu ialah ulang tahun kedua buku sebelumnya.

Dalam konteks ini, cara kami menyiapkan buku ini adalah mudah dan mudah: mengenai topik kerja terbuka, kami mengumpul cerita terbaik dan menyusunnya ke dalam artikel, merekrut pengarang untuk mengisi beberapa jurang kandungan, Gunakan alatan sumber terbuka untuk melaraskan gaya fon , bekerjasama dengan pereka bentuk untuk memuktamadkan kulit muka, dan akhirnya menerbitkan buku itu. Cara kerja ini membolehkan kita bergerak ke hadapan pada kelajuan penuh mengikut garis masa (GSD) kita sendiri. Menjelang buku ketiga, aliran kerja kami kebanyakannya lengkap.

Tetapi semuanya berubah apabila kami merancang untuk memulakan buku terakhir The Open Organization, yang akan memfokuskan pada persimpangan organisasi terbuka dan budaya IT. Saya mencadangkan menggunakan rangka kerja membuat keputusan terbuka untuk buku ini kerana saya ingin menunjukkan bahawa pendekatan terbuka untuk bekerja membawa kepada hasil yang lebih baik, walaupun saya tahu ia mungkin mengubah sepenuhnya cara kita bekerja. Jangka masa sangat ketat (hanya dua setengah bulan), tetapi kami memutuskan untuk mencubanya.

Gunakan rangka kerja membuat keputusan terbuka untuk melengkapkan buku

Rangka Kerja Membuat Keputusan Terbuka menggariskan 4 peringkat yang membentuk proses membuat keputusan terbuka. Begini cara kami mengharungi setiap fasa (dan cara bersikap terbuka membantu menyelesaikan tugas).

1. Konsep

Kami bermula dengan menulis draf yang menggariskan visi kami untuk projek itu. Kita perlu mengeluarkan sesuatu dan berkongsi dengan bakal "pelanggan" (dalam kes ini, pihak berkepentingan yang berpotensi dan pengarang). Kami kemudiannya mengadakan temu bual dengan pakar dalam bidang yang boleh memberi kami pendapat secara langsung dan jujur. Keghairahan yang ditunjukkan oleh pakar ini dan bimbingan yang mereka berikan mengesahkan idea kami sambil memberikan maklum balas yang memastikan kami terus bergerak ke hadapan. Jika kami tidak mendapat pengesahan ini, kami kembali kepada idea asal kami dan memutuskan tempat untuk bermula semula.

2. Perancangan dan penyelidikan

Selepas beberapa temu bual, kami bersedia untuk mengumumkan projek itu di Opensource.com. Pada masa yang sama, kami turut melancarkan projek di Github, menyediakan penerangan projek, anggaran garis masa dan menjelaskan kekangan kami. Pengumuman ini diterima dengan baik, dengan beberapa item yang hilang dari katalog yang dirancang pada asalnya telah siap dalam masa 72 jam selepas projek diumumkan. Selain itu (dan lebih penting lagi), pembaca telah mencadangkan idea untuk beberapa bab yang pada asalnya tidak dirancang, tetapi yang mereka rasa akan melengkapkan versi yang kami bayangkan pada asalnya.

Mengimbas kembali, saya merasakan bahawa dalam fasa pertama dan kedua projek, membuka projek tidak menjejaskan keupayaan kami untuk menyiapkan projek. Malah, bekerja dengan cara ini mempunyai faedah yang besar: menemui dan mengisi jurang kandungan. Kami bukan sahaja mengisi kekosongan, kami mengisinya dengan cepat dan dengan idea yang kami tidak akan pernah menganggap diri kami sendiri. Ini tidak semestinya memerlukan kita melakukan lebih banyak kerja, ia hanya mengubah cara kita bekerja. Kami menggunakan sambungan terhad kami, menjemput orang lain untuk menulis, dan kemudian menyusun kandungan yang kami terima, menetapkan konteks dan membimbing orang ke arah yang betul.

3. Reka bentuk, pembangunan dan ujian

Fasa projek ini adalah mengenai pengurusan projek, menguruskan beberapa mavericks seperti kucing, dan menangani jangkaan projek. Kami mempunyai tarikh akhir yang jelas, kami berkomunikasi lebih awal dan kami kerap berkomunikasi. Kami juga menggunakan strategi untuk membuat senarai penyumbang dan pihak berkepentingan dan memastikan mereka dimaklumkan tentang kemajuan projek sepanjang jangka hayatnya, terutamanya peristiwa penting yang kami petakan di Github.

Akhir sekali, buku kami memerlukan nama. Kami mengumpulkan banyak maklum balas tentang tajuk yang sepatutnya dan, yang lebih penting, tajuk yang tidak sepatutnya. Kami mengumpul maklum balas melalui tiket di Github dan memberitahu umum bahawa pasukan kami akan membuat keputusan muktamad. Semasa kami bersedia untuk mengumumkan gelaran terakhir, rakan sekerja saya Bryan Behrenshausen melakukan tugas yang hebat berkongsi proses yang membawa kepada keputusan kami. Orang ramai kelihatan gembira mengenainya—walaupun mereka tidak bersetuju dengan gelaran terakhir kami.

Fasa "beta" buku memerlukan banyak pembacaan pruf. Ahli komuniti benar-benar terlibat dalam menjawab siaran "minta bantuan" ini. Kami menerima kira-kira 80 ulasan pada tiket GitHub yang melaporkan kemajuan kerja penyemakan pruf (belum lagi banyak maklum balas tambahan yang diterima melalui e-mel dan saluran maklum balas lain).

Mengenai menyelesaikan tugas: Pada peringkat ini, kami secara peribadi telah mengalami undang-undang Linus: "Dengan lebih banyak mata, semua kesilapan menaip adalah cetek jika kami menyelesaikannya secara bebas seperti tiga buku pertama, Maka seluruh beban membaca pruf jatuh ke bahu kami (). seperti yang berlaku untuk buku-buku ini)! Sebaliknya, ahli komuniti dengan bermurah hati memikul beban membaca pruf untuk kami, dan tugas kami beralih daripada menyemak pruf sendiri (walaupun kami masih melakukan banyak perkara) kepada mengurus semua permintaan perubahan. Ini adalah perubahan yang dialu-alukan untuk pasukan kami dan peluang untuk komuniti terlibat. Kami pasti boleh menyelesaikan membaca pruf dengan lebih cepat jika kami melakukannya sendiri, tetapi dengan keterbukaan kami mendapati lebih banyak ralat sebelum tarikh akhir, itu sudah pasti.

4. Terbitkan

Nah, kami kini mengeluarkan versi akhir buku ini. (Atau hanya edisi pertama?)

Kami membahagikan pelepasan kepada dua peringkat. Pertama, mengikut garis masa projek awam kami, kami melancarkan buku itu secara senyap-senyap beberapa hari sebelum tarikh akhir untuk membolehkan penyumbang komuniti kami membantu kami menguji borang muat turun. Peringkat kedua kini, pengumuman rasmi versi umum buku ini. Sudah tentu, kami masih menerima maklum balas selepas keluaran, seperti pendekatan sumber terbuka.

Kandungan

Pencapaian Dibuka
Mengikuti rangka kerja membuat keputusan terbuka adalah kunci kepada kejayaan Panduan Perubahan Budaya IT. Dengan bekerjasama dengan pelanggan dan pihak berkepentingan, berkongsi kekangan kami, dan bersikap telus tentang kerja kami, kami melebihi jangkaan kami sendiri untuk projek buku.

Saya sangat gembira dengan kerjasama, maklum balas dan aktiviti sepanjang projek. Walaupun terdapat tempoh kebimbangan tentang tidak menyelesaikan sesuatu secepat yang saya mahu, saya dengan cepat menyedari bahawa membuka proses itu sebenarnya membolehkan kami melakukan lebih banyak perkara. Ini jelas berdasarkan gambaran keseluruhan saya di atas.

Jadi mungkin saya perlu memikirkan semula mentaliti GSD saya dan memanjangkannya kepada GMD: Dapatkan Lebih Banyak Selesai, lakukan lebih banyak perkara dan dalam kes ini, dapatkan hasil yang lebih baik.

(gambar tajuk: opensource.com)

Mengenai pengarang:

Jason Hibbets - Jason Hibbets ialah Penginjil Komuniti Kanan dalam Pemasaran Perusahaan Red Hat dan Pengurus Komuniti di Opensource.com. Beliau telah bersama Red Hat sejak 2003 dan merupakan pengasas Yayasan Bandar Sumber Terbuka. Jawatan sebelumnya termasuk Pakar Pemasaran Kanan, Pengurus Projek, Penyelenggara Pangkalan Pengetahuan Red Hat, dan Jurutera Sokongan.

Atas ialah kandungan terperinci Penyelidikan tempat kerja terbuka. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!