Memisahkan masa antara usaha produk dan kejuruteraan

Di setiap syarikat yang saya telah bekerja, kami telah berpecah antara masa yang dihabiskan untuk inisiatif produk dan kerja kejuruteraan. Peratusan selalu berubah, kadang -kadang produk 70%, kejuruteraan 30%, kadang -kadang sebanyak 50/50 perpecahan. Dorongan adalah untuk memastikan bahawa kejuruteraan membelanjakan sebahagian masa mereka membina ciri -ciri baru, tetapi juga memastikan kita dapat melakukan kerja "kita sendiri" seperti alamat hutang teknikal, sistem peningkatan, dan dokumen kod kami.

Masalahnya ialah, satu perkara untuk mengatakan ini pada awal, dan satu lagi untuk menjadikannya realiti. Terdapat beberapa sebab yang saya lihat model ini gagal, bukan kerana orang tidak faham secara teori bahawa ia adalah berharga, tetapi kerana dalam praktiknya, terdapat beberapa perangkap biasa yang perlu anda fikirkan. Kami akan merangkumi beberapa senario ini dari perspektif pemimpin kejuruteraan supaya kami dapat menangani jalan yang baik ke hadapan.

Isu -isu

Beberapa petunjuk di bawah adalah reaksi dan perancangan berdasarkan apa yang boleh salah, jadi mari kita bercakap terlebih dahulu tentang cabaran yang boleh anda hadapi jika ini tidak ditetapkan dengan betul.

• Produk mungkin mempunyai konflik, sama ada dengan kerja itu sendiri atau masa yang terlibat. Ini boleh menimbulkan hubungan antara produk dan kejuruteraan. Sekiranya mereka terkejut, anda berpotensi mencari sempadan kerja anda semakin ketat.
• Jurutera anda mungkin tidak memahami apa yang diharapkan daripada mereka . Parallelization usaha boleh menjadi sukar untuk dilakukan, jadi membina proses yang baik dapat memberikan kejelasan.
• Laluan penyelenggaraan harus jelas : Adakah anda merancang untuk membuat peningkatan sistem gergasi? Ini boleh menjejaskan pasukan lain dari masa ke masa dan jika anda tidak jelas tentang pemilikan akhirnya, ia boleh kembali menghantui anda. ?

Sebaiknya mempunyai kebebasan dalam masa kejuruteraan, komunikasi, perancangan, dan jangkaan yang jelas dapat membantu memastikan anda mengelakkan sebarang isu yang digariskan di atas.

Komunikasi

Sebaik sahaja anda mengetahui masalah yang anda ingin menangani, penting untuk menulis satu-satunya yang boleh anda kongsi dengan pihak berkepentingan mengenai sifat kerja, jumlah masa yang akan diambil, dan mengapa ia penting.

Sekiranya ia merupakan projek yang besar, anda juga boleh skop kepingan tersebut ke dalam isu GitHub/Gitlab/Jira, dan menambah label untuk jenis kerja yang ada. Ini hebat kerana anda boleh menggunakan sistem pengurusan projek yang sudah anda gunakan untuk meningkatkan jumlah kerja dan jangkaan setiap minggu. Adalah baik untuk memastikan dialog terbuka dengan rakan kongsi produk anda pada skop dan sifat kerja supaya mereka tidak terkejut dengan kerja lain yang dilakukan. Ini sebahagian besarnya akan berbeza -beza oleh budaya pasukan dan organisasi.

Ini dapat membantu memberikan kejelasan kepada jurutera anda juga. Jika mereka memahami sifat kerja dan apa yang diharapkan daripada mereka, lebih mudah bagi mereka untuk menangani isu -isu kecil yang membentuk keseluruhannya.

Anda mungkin mendapati bahawa ia kurang masuk akal dari perspektif fokus untuk mempunyai setiap masa berpecah jurutera di seluruh projek produk dan kejuruteraan. Mereka mungkin lebih suka memecah kerja di antara mereka: tiga orang dalam kerja produk selama beberapa minggu, satu orang dalam kerja kejuruteraan. Terdapat juga masa di mana semua orang perlu terlibat supaya mereka mempunyai pengetahuan institusi yang sama (migrasi boleh seperti ini, bergantung kepada apa itu). Perbatuan anda mungkin berbeza -beza berdasarkan saiz pasukan, jumlah kerja produk, dan jenis projek.

Komunikasi membantu di sini juga - jika anda tidak pasti apa jalan yang betul, ia dapat membantu untuk memiliki brainstorm kecil sebagai satu kumpulan tentang bagaimana anda ingin menyelesaikannya. Pastikan anda juga menyelaraskan semua orang dengan mengapa projek itu penting seperti yang anda lakukan.

Jenis projek

Terdapat banyak jenis projek yang boleh anda buat dalam masa pasukan kejuruteraan anda, dan masing -masing mempunyai pendekatan yang sedikit berbeza dari apa yang saya lihat, jadi mari kita pergi ke setiap satu daripada mereka.

Hutang teknologi

Mari kita atasi hutang teknikal terlebih dahulu kerana itu adalah salah satu kerja yang paling biasa yang boleh membuka kunci pasukan anda. Untuk setiap ciri yang anda tulis, jika usaha kejuruteraan diperlahankan, anda bukan sahaja kehilangan masa dari segi pembangunan produk, anda juga kehilangan wang dari segi masa kejuruteraan.

Sedikit hutang teknikal adalah semulajadi, terutamanya di syarikat -syarikat yang lebih kecil di mana ia membuat lebih banyak fiskal untuk bergerak dengan cepat, tetapi terdapat beberapa titik di mana hutang teknologi menjadi lumpuh untuk pembangunan dan siaran, dan membuat codebase tidak stabil. Kadang -kadang perlu dilakukan dengan segera untuk memastikan semua jurutera anda dapat berfungsi dengan cekap, dan kadang -kadang ia beransur -ansur.

Dalam banyak kes, kepingan hutang teknikal adalah perkara yang anda pelajari dengan pendekatan bawah: Devs yang paling dekat dengan bekerja dengan sistem akan mengetahui yang terbaik apa hutang teknikal sehari-hari daripada pengurus kejuruteraan (EMS) biasanya. Cabaran sebagai EM adalah untuk melihat corak yang lebih besar, seperti ketika ramai orang mengadu perkara yang sama, bukannya satu dev yang mungkin mempunyai pendapat yang kuat. Meminta sekitar sebelum anda memulakan jenis projek ini boleh membantu - mengundi orang tentang berapa banyak masa yang mereka fikir mereka sedang membuang -buang dalam satu minggu yang diberikan berbanding prospek alternatif.

Kadang -kadang hutang teknikal adalah masalah sejumlah besar refactor. Saya telah melihat ini menjadi yang terbaik apabila orang berada di hadapan apa jenis permintaan tarik (PR) diperlukan. Adakah anda perlu mengemas kini CSS di satu juta tempat? Atau menukar komponen kelas lama ke cangkuk? Anda mungkin tidak mahu satu PR besar untuk semua itu, tetapi tidak masuk akal untuk memecahkan kerja ini setiap komponen. Bekerja bersama sebagai satu pasukan mengenai berapa banyak PR akan dipegang dan apa yang diharapkan dari semakan supaya anda tidak membuat "lubang semakan" semasa kerja sedang dilakukan.

Projek inovatif

Banyak syarikat akan melakukan projek Hack Week/Inovasi Minggu di mana Devs boleh bekerja pada beberapa ciri yang berkaitan dengan produk syarikat yang tidak disengajakan. Ia adalah masa yang tepat untuk penjelajahan, dan saya telah melihat beberapa ciri yang kuat ditambah kepada aplikasi terkenal dengan cara ini. Ia juga sangat bertenaga untuk pasukan melihat idea mereka sendiri datang untuk membuahkan hasil.

Masalah dengan melakukan jenis projek -projek ini dalam masa kejuruteraan yang berpecah adalah bahawa anda boleh, kadang -kadang, membuat pasukan produk merasa sedikit sedikit. Kenapa? Nah, fikirkan perkara dari perspektif mereka. Tugas mereka adalah untuk mengemukakan ciri -ciri ini, merancang dengan teliti dengan pihak berkepentingan, mengumpulkan roadmaps (sering berdasarkan metrik dan penyelidikan syarikat), dan mendapatkan jadual kejuruteraan, biasanya bekerja dengan pengurus projek. Sekiranya anda menghabiskan separuh masa anda bekerja pada ciri-ciri yang tidak dirancang, anda boleh berpotensi untuk membuat rancangan yang sedia ada untuk projek, menentang beberapa penyelidikan yang diketahui, atau hanya melambatkan proses untuk mendapatkan ciri-ciri yang mereka perlukan.

Cara saya melihat permainan ini dengan baik adalah apabila EM berkomunikasi di depan dengan produk. Pertimbangkan ini perkongsian: jika produk mengatakan bahawa ciri tertentu tidak masuk akal, mereka mungkin mempunyai alasan yang baik untuk berfikir demikian. Sekiranya anda boleh mendengar satu sama lain, terdapat kemungkinan jalan ke hadapan di mana anda berdua bersetuju.

Adalah baik untuk menangani ketakutan mereka juga. Adakah mereka bimbang bahawa tidak akan ada masa yang cukup untuk kerja produk? Tanya pasukan anda secara langsung berapa minggu pada separuh masa mereka fikir ia mungkin mengambil (dengan jangkaan bahawa perkara mungkin beralih apabila mereka menggali). Jadikannya jelas kepada semua orang bahawa anda tidak mengharapkan ia dilakukan dengan pantas.

Akhirnya, komunikasi adalah kunci. Idealnya, ini adalah projek kecil yang tidak akan menjejaskan apa -apa yang boleh dilakukan selari dengan kerja biasa. Cadangan saya adalah untuk mencubanya dengan sesuatu yang sangat kecil terlebih dahulu untuk melihat apa yang terdapat di jalan raya, dan juga membina kepercayaan dengan produk yang anda masih akan menyelesaikan kerja anda dan bukan "pergi penyangak."

Sekeping akhir ini adalah untuk mengetahui siapa yang bertanggungjawab untuk metrik, hasil, dan apabila keadaan tidak berjalan lancar. Sebahagian daripada sebab produk dapat memutuskan arah adalah kerana mereka berada di cangkuk apabila ia gagal. Pastikan anda jelas bahawa sebagai pemimpin kejuruteraan, anda bertanggungjawab untuk hasil, baik dan baik yang buruk untuk mengekalkan hubungan yang baik.

Kerja perlahan, berterusan

Ini mungkin yang paling jelas mengenai mana-mana jenis projek dan kemungkinan akan mendapat sedikit sebanyak menolak dari sesiapa sahaja. Contoh -contoh jenis kerja ini adalah dokumentasi dalaman, perkakas (jika anda tidak mempunyai pasukan alat khusus), atau penyelenggaraan kecil.

Komunikasi yang diperlukan di sini sedikit berbeza dari projek lain, kerana ia tidak semestinya menjadi satu projek yang dikekang yang anda hantar, melainkan proses berulang. Ambil dokumentasi sebagai contoh: Saya akan mencadangkan masa bangunan untuk dokumentasi dalaman ke dalam proses ciri.

Sebagai contoh, katakan anda mencipta ciri baru yang membolehkan pasukan berkolaborasi. Tidak semua orang di seluruh syarikat mungkin tahu bahawa anda mencipta microservice untuk ciri ini yang boleh digunakan oleh mana -mana pasukan, dan parameter yang diharapkan, atau bagaimana untuk menambah fungsi di jalan. Dokumen dalaman boleh menjadi perbezaan antara perkhidmatan yang digunakan, serta pasukan anda diminta untuk berpasangan dengan seseorang setiap kali seseorang perlu menggunakannya. Atau lebih teruk: mereka cuba menggodam dan memikirkannya sendiri, mewujudkan kekacauan sesuatu yang boleh dilakukan dengan lebih cepat dan lebih cekap.

Tidak seperti projek inovasi, kerja yang perlahan dan berterusan biasanya bukan sesuatu yang benar -benar mengidam, jadi menetapkan proses dan jangkaan sehingga lurus berfungsi dengan baik. Dokumentasi dalaman adalah bahagian yang kadang-kadang tersembunyi tetapi sangat penting dalam pasukan yang berfungsi dengan baik. Ia membantu dengan onboarding, mendapatkan semua orang di halaman yang sama tentang seni bina sistem, dan bahkan dapat membantu Devs benar -benar menguatkan apa yang mereka bina dan berfikir bagaimana mereka menyelesaikannya.

Migrasi

Migrasi dikendalikan sedikit berbeza daripada beberapa jenis projek lain kerana ia mungkin memberi kesan kepada semua orang. Tidak ada cara yang betul untuk melakukan ini, dan juga bergantung pada jenis penghijrahan yang ada - kerangka kerangka, memecahkan monolit, dan berhijrah ke proses binaan atau pelayan yang berbeza mungkin mempunyai pendekatan yang berbeza. Oleh kerana setiap satu daripada ini mungkin merupakan artikel sendiri, mari kita melalui beberapa pilihan peringkat tinggi yang digunakan untuk organisasi mereka.

• Cadangan pertama saya adalah untuk melakukan penyelidikan sebanyak mungkin di hadapan pada jenis penghijrahan yang anda lakukan. Tidak ada cara untuk mengetahui segala-galanya, tetapi anda tidak mahu mendapatkan sebahagian daripada proses untuk mengetahui sesuatu yang kritikal. Ini juga merupakan maklumat yang berguna untuk dikongsi dengan pihak berkepentingan.
• Adakah terdapat perdebatan dalaman mengenai arah mana syarikat anda harus pergi? Timebox satu unit masa untuk bekerja melalui masalah dan pastikan anda mempunyai pembuat keputusan yang jelas pada akhirnya . Banyak masalah teknologi tidak mempunyai satu penyelesaian "benar", jadi mempunyai seorang pemilik membuat keputusan dan semua orang tidak setuju dan komit dapat membantu. Tetapi anda juga ingin memberi sedikit masa untuk orang -orang untuk mendengar suara mereka tentang apa yang memberi mereka jeda, walaupun mereka tidak setuju - mereka mungkin memikirkan sesuatu yang anda tidak.
• Dokumen pelan penghijrahan, baik di peringkat tinggi dan kemudian bekerja melalui kesan pada setiap pasukan. Ini juga merupakan masa yang tepat untuk menjelaskan kepada produk mengapa kerja ini penting: adakah asas anda menjadi tua dan tidak lagi dapat bermain dengan baik dengan perpustakaan dan alat lain? Adakah proses binaan baru keluar yang dapat menjimatkan masa jurutera anda dalam proses pelepasan? Bantu mereka memahami mengapa kerja itu kritikal.
• Jelas tentang penyelenggaraan dan pemilikan. Jika satu pasukan memindahkan proses membina yang kemudian menyebabkan isu -isu yang lain, siapa yang membetulkan perkara untuk menyahsekat pasukan itu? Anda harus memutuskan ini sebelum ia berlaku.
• Sesetengah laluan penghijrahan membolehkan anda melakukan perkara perlahan -lahan dari masa ke masa, atau pasukan oleh pasukan, atau melakukan banyak kerja di depan. Walau bagaimanapun, biasanya ada masa apabila ia akan menjadi kritikal dan semua tangan di dek diperlukan. Tidak seperti beberapa kerja lain yang boleh dipasangkan, anda mungkin perlu melakukan sesuatu dengan produk di mana semua kerja ciri lain terhenti untuk sedikit semasa anda mendapatkan sistem baru di tempatnya. Sekiranya anda bekerja rapat dengan mereka, anda mungkin mendapati bahawa ada masa di musim di mana anda secara semulajadi mempunyai lebih banyak pelanggan, dan ia dapat memberi anda ruang pernafasan yang anda perlukan untuk menyelesaikannya. Saya akan mencadangkan bahawa jika mereka sanggup membiarkan anda mengambil masa kejuruteraan hingga 100% untuk seketika, anda kembali memihak; Dan apabila platform stabil, dedikasikan 100% masa pasukan untuk kerja produk.

Raikan!

Langkah terakhir ini mungkin kelihatan pilihan, tetapi ia adalah masalah besar pada pendapat saya. Pasukan anda hanya menarik sesuatu yang luar biasa: mereka usaha yang selaras, mereka adalah rakan kongsi yang baik untuk produk, mereka mendapat sesuatu yang dilakukan untuk org kejuruteraan pada umumnya. Adalah penting untuk meraikan kerja seperti anda akan dilancarkan.

Pasukan perlu tahu anda menghargai kerja ini kerana ia sering tidak bersyukur, tetapi sangat berkesan . Ia juga boleh membina kepercayaan untuk mengetahui bahawa jika sesuatu yang berbulu muncul pada masa akan datang, ia sebenarnya membantu jalan kerjaya mereka juga. Meraikan dengan pasukan anda apa yang anda lakukan sangat sedikit, dan mempunyai kesan budaya yang hebat.

Beli buku

Ini hanyalah contoh jenis kandungan dari buku terbaru saya yang dikeluarkan tidak lama lagi ...

Sertai senarai!

Atas ialah kandungan terperinci Memisahkan masa antara usaha produk dan kejuruteraan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!