Peran dan Judul Perangkat Lunak

Foto oleh Henry (CC-BY-2.0)

Saya telah melihat banyak kebingungan di industri tentang berbagai peran dan judul perangkat lunak, bahkan di antara para pendiri, manajer perekrutan, dan pembangun tim. Apa saja berbagai peran dan tanggung jawab dalam tim perangkat lunak, dan jabatan mana yang cenderung mencakup peran mana?

Sebelum saya menggali terlalu banyak hal ini, saya ingin menekankan bahwa setiap tim adalah unik, dan tanggung jawab cenderung mengambang atau dibagi di antara anggota tim yang berbeda. Siapa saja kapan saja dapat mendelegasikan tanggung jawab kepada orang lain karena berbagai alasan - banyak di antaranya valid.

Jika tim Anda tidak persis seperti yang saya jelaskan di sini, selamat datang di klub. Saya menduga sangat sedikit tim dan peran perangkat lunak tertentu akan cocok dengan apa yang akan kami eksplorasi. Ini hanya kerangka umum yang menggambarkan rata-rata lebih dari peran atau tim tertentu.

Saya akan mulai dengan jabatan manajemen dan bekerja melalui berbagai peran secara kasar oleh senioritas.

Saya juga ingin menekankan bahwa Anda tidak boleh merasa dibatasi oleh jabatan Anda. Saya suka membangun budaya rekayasa yang mendukung:

  • Keterampilan judul
  • Pengiriman terus menerus melewati tenggat waktu
  • Dukungan atas kesalahan
  • Kolaborasi atas persaingan

Saya suka menghargai inisiatif dengan tanggung jawab yang meningkat, dan jika seseorang memiliki keterampilan dan inisiatif untuk mengambil dan melampaui gelar yang mereka pekerjakan, saya lebih suka mempromosikan daripada mengambil risiko kehilangan bintang yang sedang naik daun ke perusahaan atau tim lain.

Peran Pengembangan Perangkat Lunak

  • Anggota Teknik
  • CEO
  • CTO
  • CIO / Kepala Digital Officer / Kepala Inovasi Officer
  • VP of Engineering / Direktur Teknik
  • Kepala Arsitek
  • Arsitek perangkat lunak
  • Manajer Proyek Rekayasa / Manajer Teknik
  • Pimpinan Teknis / Pimpinan Teknis / Pimpinan Tim
  • Insinyur Perangkat Lunak Utama
  • Insinyur Perangkat Lunak Senior / Pengembang Perangkat Lunak Senior
  • Insinyur Perangkat Lunak
  • Pengembang perangkat lunak
  • Pengembang Perangkat Lunak Junior
  • Pengembang Perangkat Lunak Intern

Kami juga akan berbicara sedikit tentang bagaimana peran ini terkait dengan peran lain termasuk:

  • VP Manajemen Produk / Kepala Produk
  • Manajer produk
  • VP Pemasaran
Catatan: Terkadang judul "sutradara", atau "head" menunjukkan manajer menengah antara manajer teknologi dan C-Suite. Seringkali, judul "Chief" menunjukkan judul C-suite. Karyawan C-suite biasanya melapor langsung ke CEO, dan berpotensi memiliki banyak laporan di organisasi yang dipimpinnya. Di perusahaan yang sangat besar, jabatan pengganti itu sering mengisi peran serupa dengan eksekutif C-suite, tetapi melapor kepada seseorang yang secara efektif adalah CEO dari unit bisnis yang lebih kecil di dalam organisasi yang lebih besar. Unit bisnis yang berbeda kadang-kadang beroperasi seolah-olah mereka adalah perusahaan yang terpisah, lengkap dengan akuntansi mereka sendiri yang terisolasi, pejabat keuangan, dll. Unit bisnis yang berbeda juga dapat memiliki VP, misalnya, "Wakil Presiden Teknik, Operasi Pedagang".

Anggota Teknik

Judul "sesama" adalah puncak pencapaian bagi insinyur perangkat lunak. Ini biasanya diberikan sebagai pengakuan terhadap orang-orang yang telah memberikan kontribusi luar biasa ke bidang komputasi, dan biasanya diberikan setelah seorang insinyur menulis sejumlah buku terlaris, memenangkan hadiah seperti Turing Award, Hadiah Nobel, dll. Dengan kata lain Orang-orang biasanya sudah terkenal di luar organisasi, dan perusahaan berusaha memperkuat merek mereka dengan lebih kuat mengasosiasikan diri mereka dengan orang-orang yang dikagumi dan berpengaruh.

Menurut pendapat saya, organisasi tidak boleh mencoba mempekerjakan untuk peran "sesama". Alih-alih, cari yang terbaik dan paling cerdas, pekerjakan mereka, dan kemudian berikan gelar (dan manfaat) jika insinyur itu layak mendapatkannya.

Seorang rekan biasanya juga memegang gelar lain di perusahaan. Seringkali CTO, Arsitek, Wakil Presiden bidang Teknik, atau peran utama, di mana mereka berada dalam posisi untuk memimpin, membimbing, atau melayani sebagai contoh dan inspirasi bagi anggota organisasi lainnya.

CEO

CEO adalah posisi otoritas yang paling dalam suatu organisasi. Biasanya, mereka menetapkan visi dan bintang utara untuk perusahaan. Mereka mengumpulkan semua orang di sekitar pemahaman umum tentang mengapa perusahaan ada, apa misinya, dan apa nilai-nilai perusahaan itu. Seringkali, CEO juga merupakan wajah publik perusahaan, dan dalam beberapa kasus, menjadi identik dengan merek (mis., Steve Jobs dengan Apple, Elon Musk dengan Tesla / SpaceX, dll.)

Dalam beberapa kasus, CEO juga merupakan pendiri teknis organisasi perangkat lunak, dalam hal ini, mereka juga sering mengisi peran CTO, dan mungkin memiliki Wakil Direktur Operasi, Penjualan, Strategi, dan Pemasaran membantu dengan beberapa tanggung jawab CEO umum lainnya. .

CEO sebuah perusahaan kecil sering memakai banyak topi, karena Anda mungkin telah mengambil dari semua peran lain yang jatuh dari jabatan CEO ketika saya menyebutkan bahwa beberapa CEO memimpin tim teknologi.

Bagaimanapun, jika ada keputusan organisasi penting yang harus dibuat, Anda tidak dapat menjalankannya dengan rantai tanggung jawab yang lebih tinggi daripada CEO.

Jika Anda seorang CEO, ingatlah bahwa Anda pada akhirnya bertanggung jawab, dan Anda harus memercayai naluri Anda, tetapi jangan lupa bahwa bahkan sebagian besar CEO terkenal memiliki mentor dan penasihat yang mereka ajak berkonsultasi secara teratur. Percayalah pada naluri Anda, tetapi carilah orang yang cerdas dan berwawasan luas untuk menantang Anda untuk meningkat juga.

CTO

Seperti peran CEO, peran CTO berubah bentuk seiring waktu. Di startup muda, CTO sering merupakan salah satu pendiri teknis untuk CEO visioner atau yang digerakkan oleh domain. Seringkali mereka tidak memenuhi syarat untuk mengambil gelar di perusahaan yang lebih besar, dan mudah-mudahan tumbuh menjadi perusahaan tersebut seiring dengan pertumbuhan perusahaan. Seringkali, CTO startup menemukan bahwa mereka lebih suka peran teknis yang lebih teknis, dan menetap kembali ke peran lain, seperti Principal Engineer, VP of Engineering, atau Chief Architect.

Di banyak organisasi, peran CTO dewasa menghadap ke luar. Mereka berpartisipasi dalam pertemuan pengembangan bisnis, sering membantu mendapatkan kemitraan atau penjualan yang besar. Banyak dari mereka memasuki sirkuit konferensi dan menghabiskan banyak waktu untuk menginjili kegiatan pengembangan organisasi ke dunia yang lebih luas: berbagi inovasi perusahaan dan menemukan peluang di pasar yang cocok dengan kompetensi inti perusahaan. CTOs sering bekerja erat dengan tim produk pada strategi produk, dan sering memiliki mitra yang menghadapi internal dalam rekayasa, seperti VP of Engineering.

CTOs juga sering menetapkan visi dan bintang utara dari tim teknik. Sasaran bagi tim untuk bekerja.

CIO / Kepala Digital Officer / Kepala Inovasi Officer

Chief Innovation Officer (CIO) seperti CTO, tetapi biasanya dipekerjakan oleh perusahaan yang biasanya tidak dianggap sebagai "perusahaan teknologi". Tujuan dari CIO adalah untuk membentuk kembali perusahaan menjadi sesuatu yang konsumen anggap cerdas dan inovatif: Untuk menunjukkan kepada dunia seperti apa masa depan industri itu, tidak peduli apa pun industri itu. Misalnya, rantai superstore renovasi rumah mungkin memiliki CIO yang bertanggung jawab untuk bermitra dengan perusahaan teknologi untuk membangun aplikasi realitas campuran untuk menunjukkan kepada pembeli seperti apa warna sofa atau warna dinding di ruang tamu mereka, atau menggunakan blockchains dan cryptocurrency untuk meningkatkan kualitas. keamanan dan efisiensi logistik rantai pasokan.

Jangan bingung dengan Chief Information Officer (CIO), sebuah judul yang biasanya digunakan di perusahaan-perusahaan yang bahkan lebih jauh dari teknologi, tertarik sejauh ini membantu operasi inti mereka. Tidak seperti Chief Innovation Officer, Chief Information Officer lebih cenderung memimpin integrasi teknologi dan proyek migrasi data daripada membangun aplikasi baru dan mencoba mencari cara bagaimana perusahaan dapat mengganggu dirinya sendiri dari dalam. Ada Chief Information Officer yang bertindak lebih seperti Chief Innovation Officers, tetapi menurut saya, mereka harus menggunakan judul yang sesuai.

Sebagian besar perusahaan teknologi-asli (pengembang aplikasi, dll) tidak memiliki CIO. Sebaliknya, tanggung jawab tersebut jatuh ke CTO dan VP Teknik.

VP of Engineering / Direktur Teknik

Sementara CTOs sering menghadap ke luar, VP of Engineering sering menghadap ke dalam. VP of Engineering sering bertanggung jawab untuk membangun tim teknik dan membangun budaya dan operasi rekayasa. CTO mungkin memberi tahu tim teknik apa yang perlu dilakukan pada skala besar, misalnya, "menjadi inovator terkemuka dalam interaksi manusia / komputer". VP of Engineering membantu menumbuhkan budaya yang mengelola "bagaimana". VP Teknik terbaik pada awalnya tampil sebagai seseorang yang ada di sana untuk membantu tim bekerja secara efisien, dan kemudian mereka hampir menghilang. Pengembang di tim berkolaborasi dengan baik, saling membimbing, berkomunikasi secara efektif, dan mereka berpikir, "Hei, kami tim yang hebat. Kami bekerja sama dengan sangat baik! "Dan mungkin mereka berpikir itu semua kebetulan beruntung.

Yang benar adalah bahwa hampir tidak pernah terjadi secara kebetulan. Itu terjadi karena ada seorang VP Teknik yang terus-menerus memantau kemajuan tim, proses, budaya, dan nada komunikasi. Mereka mendorong pengembang untuk menggunakan alat tertentu, mengadakan pertemuan jenis tertentu pada waktu tertentu untuk mendorong kolaborasi yang lebih baik dengan lebih sedikit gangguan. Wakil Presiden Teknik terbaik adalah insinyur, baik di tim disfungsional, dan di tim yang sangat fungsional. Mereka tahu pola dan anti-pola untuk alur kerja pengembangan perangkat lunak yang efektif.

Mereka bekerja dengan kepala manajer produk dan produk untuk memastikan bahwa ada proses penemuan produk yang baik (mereka tidak memimpin atau mengambil alih, hanya memastikan bahwa ada seseorang yang melakukannya dan melakukannya dengan baik), dan produk itu serta hasil desain secara memadai ditinjau oleh para insinyur sebelum pelaksanaan hand-off. Saya akan berhenti di sana sebelum saya menulis buku tentang semua pekerjaan yang mengarah ke operasi pengembangan yang efektif. Untuk lebih banyak pemikiran saya tentang topik ini, lihat Cara Membangun Tim Pengembangan Berkecepatan Tinggi.

Banyak startup yang terlalu kecil untuk menyewa VP Teknik penuh waktu, tetapi masih sangat penting untuk mendapatkan budaya rekayasa sedini mungkin. Jika Anda butuh bantuan untuk hal ini, hubungi.

Kepala Arsitek

Di organisasi kecil, kepala arsitek bisa menjadi co-founder teknis dengan kesadaran diri untuk menyadari bahwa mereka tidak menginginkan tanggung jawab CTO ketika perusahaan tumbuh. Mungkin mereka tidak suka bepergian, atau hanya lebih tertarik pada desain perangkat lunak daripada pembicaraan konferensi, pengembangan bisnis, dan panggilan penjualan yang menyusup ke kehidupan banyak CTO. Arsitek kepala mungkin bertanggung jawab untuk memilih tumpukan teknologi, merancang kolaborasi dan antarmuka antara sistem komputasi, menilai penawaran layanan komputasi (AWS, Azure, ZEIT Now, dll.), Dan sebagainya. Seorang arsitek kepala dapat mengevaluasi berbagai penawaran industri dan membuat rekomendasi yang disetujui atau disukai untuk bekerja dengan vendor tertentu.

Saat perusahaan matang, kepala arsitek mungkin juga perlu bekerja sama dengan CTO, dan terkadang organisasi mitra untuk mengembangkan integrasi antar layanan. Di banyak perusahaan, CTO juga berfungsi sebagai kepala arsitek.

Arsitek perangkat lunak

Arsitek perangkat lunak melayani banyak tujuan arsitek kepala, tetapi umumnya bertanggung jawab atas fungsionalitas lintas-bagian yang lebih kecil. Arsitek akan sering bekerja dengan kepala arsitek untuk mengimplementasikan potongan mereka dari visi arsitektur yang lebih besar. Arsitek perangkat lunak sering membuat pilihan tumpukan teknologi untuk aplikasi atau fitur tertentu, alih-alih keputusan di seluruh perusahaan.

Manajer Proyek Rekayasa / Manajer Teknik / Manajer Proyek

Seorang Manajer Proyek Rekayasa (juga disebut "Manajer Teknik" atau hanya "Manajer Proyek") bertugas mengelola alur kerja tim teknik. Beberapa perusahaan besar memiliki Manajer Teknik dan Manajer Proyek. Dalam hal itu, Manajer Teknik biasanya bertindak seperti VP Teknik pada lingkup tim lokal, sedangkan Manajer Proyek mengambil tanggung jawab yang dijelaskan di sini.

Manajer Proyek biasanya berinteraksi dengan para pemimpin produk dan pemimpin teknik seperti VP of Engineering, CTO, atau manajer menengah untuk mengolah dan memangkas tumpukan pekerjaan, melacak kemajuan tiket kerja, laporan kemajuan yang terperinci (tonggak grafik terbakar, selesai vs tiket terbuka, laporan kemajuan bulan / bulan, dll.) Anda dapat menganggapnya sebagai analog dari manajer toko untuk jalur perakitan manufaktur. Mereka mengawasi lantai kerja dan memastikan bahwa jalur perakitan berjalan dengan lancar, dan produk kerja tidak menumpuk di lantai di depan kemacetan.

Manajer Proyek terbaik juga menghabiskan banyak waktu untuk mengklasifikasikan masalah dan bug untuk menganalisis metrik seperti kepadatan bug per titik fitur, apa yang paling banyak menyebabkan bug (kesalahan desain, kesalahan spesifikasi, kesalahan logika, kesalahan sintaksis, kesalahan ketik, dll.) dan seterusnya. Metrik semacam itu dapat digunakan untuk mengukur efektivitas berbagai inisiatif, dan menunjukkan di mana perbaikan dapat dilakukan untuk proses rekayasa.

Manajer Teknik cenderung mengembangkan pemahaman yang baik tentang kekuatan berbagai anggota tim, dan pandai menugaskan tiket kerja kepada pihak yang bertanggung jawab yang tepat, meskipun, ini harus merupakan upaya kolaborasi, mencari umpan balik dari pengembang individu tentang apa tujuan karir mereka dan apa yang ingin mereka fokuskan, dalam batas-batas ruang lingkup proyek yang tersedia.

Jika ada tekanan waktu atau tumpukan pekerjaan yang menumpuk, Manajer Proyek harus berkolaborasi dengan para pemimpin teknik dan produk untuk mencari tahu akar penyebabnya dan memperbaiki disfungsi sesegera mungkin.

Jika memungkinkan, Manajer Proyek harus menjadi satu-satunya yang secara langsung mendelegasikan tugas kepada masing-masing insinyur untuk menghindari masalah banyak bos. Insinyur harus memiliki gagasan yang jelas tentang siapa mereka melapor langsung, dan siapa yang bertanggung jawab mendelegasikan kepada mereka. Jika Anda seorang pemimpin teknik yang berbeda, dan Anda bersalah mendelegasikan langsung ke insinyur, mungkin merupakan ide yang baik untuk berkoordinasi dengan Manajer Teknik yang bertanggung jawab atas laporan yang Anda delegasikan dan didelegasikan melalui mereka sehingga pekerjaan menerima prioritas yang benar dan terkoordinasi, dan Manajer Teknik mengetahui apa yang sedang dilakukan setiap insinyur secara aktif pada saat tertentu.

Pada organisasi yang sangat kecil, Manajer Teknik sering juga merupakan CTO dan Wakil Presiden Rekayasa (dengan atau tanpa gelar yang sesuai). Jika itu Anda, jangan khawatir tentang paragraf sebelumnya.

Disfungsi yang umum adalah Manajer Teknik dapat mulai berpikir bahwa karena produk lepas tangan dari pekerjaan untuk diimplementasikan oleh para insinyur, dan Manajer Teknik bekerja erat dengan tim produk, maka Manajer Teknik melapor kepada Manajer Produk. Dalam setiap kasus saya telah melihat itu terjadi, itu adalah kesalahan. Lihat “Menghindari Gangguan fungsi…” di bawah.

Pimpinan Teknologi / Pimpinan Tim

Pimpinan Tek atau Pimpinan Tim biasanya adalah pemimpin dari sejumlah kecil pengembang. Mereka biasanya adalah insinyur senior yang bertindak seperti mentor, contoh, dan panduan untuk anggota tim lainnya. Biasanya, para insinyur melapor kepada manajer proyek atau manajer teknik, tetapi seorang pemimpin teknologi mungkin bertanggung jawab atas ukuran kualitas kode tim, seperti memastikan bahwa tinjauan kode yang memadai sedang dilakukan, dan bahwa standar teknis tim (seperti TDD) sedang dilaksanakan. ditegakkan.

Kemajuan Karir Insinyur

Secara umum, insinyur dapat mengambil salah satu dari dua jalur karier: beralih ke manajemen, atau terus mengkode. Posisi manajemen tidak untuk semua orang. Banyak insinyur lebih memilih untuk tetap berada di jalur teknis. Kemajuan itu dapat mengambil banyak arah, belokan, dan belokan, tetapi bisa terlihat seperti ini:

Intern -> Pengembang Perangkat Lunak Junior -> Pengembang / Insinyur Perangkat Lunak -> Insinyur Perangkat Lunak Senior -> Insinyur Perangkat Lunak Utama -> Arsitek Perangkat Lunak -> Arsitek Perangkat Lunak Senior -> Arsitek Utama -> CTO -> Rekan Teknik

Atau, bagi para insinyur yang tertarik pada peran kepemimpinan orang, suatu perkembangan mungkin terlihat seperti ini:

Magang -> Pengembang Perangkat Lunak Junior -> Pengembang / Insinyur Perangkat Lunak -> Ketua Tim / Pimpinan Teknis -> Manajer Teknik / Manajer Proyek -> Manajer Teknik Senior -> Direktur Teknik -> VP Teknik

Menghindari Gangguan Fungsi dalam Kepemimpinan Teknik

IMO, VP Teknik, CTO, VP Produk, dan VP Pemasaran semua harus melaporkan langsung ke CEO. Masing-masing dari mereka harus bertanggung jawab atas proses mereka sendiri. CTO menghadapi eksternal tidak boleh memiliki laporan langsung (jika mereka melakukannya, itu biasanya berarti mereka mengisi CTO dan VP Peran Teknik). Sebaliknya, para pemimpin Teknik melapor kepada Wakil Presiden Rekayasa. Ini untuk menghindari disfungsi dua bos, tetapi juga karena peran-peran ini secara fundamental berbeda: yang satu berfokus pada pelanggan dan bagaimana organisasi itu cocok dengan dunia yang lebih luas, dan yang lain berfokus pada operasi internal, sehari-hari. Mereka adalah dua rangkaian keterampilan yang sangat berbeda, dengan prioritas yang terkadang bersaing.

Saya telah melihat banyak disfungsi dalam kepemimpinan enjiniring karena kebingungan tentang pemimpin enjiniring mana yang bertanggung jawab untuk apa, dan itu cenderung menjadi resep untuk bencana. Apa pun yang tepat untuk organisasi Anda, pastikan bahwa tanggung jawab dan rantai otoritas jelas, untuk menghindari insinyur merasa terpecah antara dua atau tiga "bos" yang berbeda.

Demikian juga, dalam suatu organisasi dengan ukuran yang memadai, produk dan teknik perlu menjadi dua tim yang dipimpin secara terpisah. Yang saya maksudkan adalah bahwa manajer produk harus memiliki roadmap produk. Mereka harus menjadi penginjil bagi para pengguna, dan mereka harus benar-benar terhubung dengan para pengguna, sering kali terlibat dengan mereka 1: 1 dan belajar tentang alur kerja dan poin rasa sakit mereka secara mendalam. Mereka harus menjadi ahli tentang apa yang dibutuhkan pasar, dan mereka harus sangat akrab dengan kekuatan dan kemampuan perusahaan untuk memenuhi kebutuhan itu.

Yang mengatakan, Wakil Presiden Rekayasa (atau siapa pun yang mengisi peran itu) harus bertanggung jawab atas pengiriman, dan kecepatan produksi. Sementara manajer produk harus memiliki roadmap, manajer engineering perlu bertanggung jawab untuk mengambil prioritas roadmap tersebut, mencocokkannya dengan kapasitas engineering, dan melaporkan waktunya. Tim produk dan pemasaran akan memiliki pendapat yang kuat tentang kapan sesuatu harus dikirimkan, tetapi hanya manajemen teknik yang dapat menentukan apakah jadwal pengiriman tersebut dimungkinkan atau tidak mengingat persyaratan peta jalan. Tim teknik memerlukan otoritas tidak hanya untuk mendorong pengaturan waktu, tetapi dalam banyak kasus, untuk sepenuhnya mengatur waktu, bekerja dengan CEO, produk, dan tim pemasaran untuk menentukan prioritas, memahami kebutuhan strategis perusahaan, dan kemudian membantu membentuk irama pengembangan yang dapat memenuhi kebutuhan-kebutuhan itu tanpa memaksakan tenggat waktu mati yang pada akhirnya merusak kemampuan perusahaan untuk memberikan produk-produk berkualitas dengan kecepatan yang andal.

Tim berkinerja terbaik yang pernah saya terlibat dengan berlangganan pendekatan tanpa batas waktu. Kami membangun produk hebat tanpa mengumumkannya terlebih dahulu, dan kemudian membiarkan tim pemasaran mempromosikan pekerjaan yang sudah dilakukan. Atau, saat Anda bekerja di tampilan publik, transparansi adalah solusi yang bagus. Alih-alih menjejalkan untuk memenuhi tenggat waktu yang sewenang-wenang, secara aktif bagikan kemajuan Anda, dengan bagan burn-down tiket, pandangan yang jelas tentang pekerjaan yang tersisa, kemajuan, kecepatan, dan ruang lingkup yang tersisa, dan perubahan dari waktu ke waktu yang dapat menunjukkan creep lingkup. Saat Anda berbagi informasi terperinci tentang kemajuan yang dibuat, dan membagikan filosofi bahwa kami tidak dapat menjanjikan tanggal pengiriman, tetapi kami dapat membagikan semua yang kami ketahui tentang kemajuan kami kepada Anda, orang-orang dapat melihat sendiri pekerjaan dan langkahnya.

Karena tujuan yang berbeda, seringkali saling bersaing, produk, pemasaran, dan teknik perlu terpisah perannya, melapor langsung kepada CEO di mana tidak satu pun dari mereka dapat saling mendikte. Jika tim Anda merasakan tekanan waktu untuk bekerja lembur, atau berderak untuk mendapatkan beberapa pengiriman kunci sebelum batas waktu yang ditentukan, itu menunjuk ke disfungsi di sini. Entah manajer teknik melaporkan kepada orang yang salah, atau tim tidak memiliki pemimpin teknik yang kuat yang memahami kesia-siaan perkiraan perangkat lunak dan kebutuhan untuk saling memberi dan menerima secara kolaboratif antara teknik dan produk untuk memastikan fleksibilitas pengiriman yang ditingkatkan -mundur MVP untuk mencapai target pengiriman.

Produk harus memiliki proses penemuan berkelanjutan. Rekayasa harus memiliki proses pengiriman berkelanjutan. Pemasaran harus bekerja bahu-membahu dengan tim produk untuk memastikan bahwa pengiriman produk ke dunia yang lebih luas tepat sasaran. Seluruhnya harus cocok bersama seperti pipa, menciptakan siklus umpan balik positif yang mengalir lancar. Seperti jalur perakitan, hambatan paling lambat dalam proses harus menetapkan kecepatan untuk sisa proses, jika tidak, itu akan mengarah pada tumpukan yang terus tumbuh yang menumpuk sedemikian rupa sehingga item tumpukan menjadi usang, dan manajemen tumpukan menjadi penuh pekerjaan -waktu.

Tim produk yang merasa teknik tidak mengikuti kecepatan harus fokus pertama pada kualitas hasil serah terima teknis. Sudahkah kita melakukan tinjauan desain yang memadai? Pernahkah seorang insinyur berkesempatan memberikan umpan balik yang konstruktif sebelum handoff? 80% bug perangkat lunak disebabkan oleh spesifikasi atau kesalahan desain UX, dan banyak di antaranya dapat ditangkap sebelum pekerjaan diserahkan ke tim teknik. Setelah proses itu selesai, tanyakan pada diri Anda apakah Anda benar-benar menjelajahi ruang desain produk dengan cukup teliti. Apakah Anda membuat satu UX dan menyebutnya selesai, atau apakah Anda mencoba beberapa variasi? Membangun dan menguji variasi pada alur kerja pengguna adalah salah satu kontribusi paling berharga yang dapat dibuat oleh tim produk. Apakah Anda memiliki sekelompok pengguna tepercaya atau pelanggan yang dapat Anda jalankan pengujian prototipe A / B?

Salah satu disfungsi terbesar dari tim perangkat lunak adalah bahwa tim produk memproduksi hasil kerja sub-par (kadang-kadang sedikit lebih dari beberapa, buggy mock-up), dan gagal menjalankannya oleh pelanggan atau insinyur sebelum menyerahkannya. . Disfungsi itu menyebabkan tumpukan re-work dan backlog engineering yang sering disalahkan pada tim engineering.

Pastikan bahwa pelimpahan tanggung jawab masuk akal, bahwa Anda tidak memberikan tekanan waktu yang tidak semestinya pada teknik, dan bahwa Anda memiliki tim produk hebat yang terlibat dalam proses penemuan produk kolaboratif, bekerja dengan pengguna nyata untuk membangun produk terbaik.

Manajer teknik, saya tidak akan membiarkan Anda lolos. Jika disfungsi ini ada di tim Anda, Anda bertanggung jawab untuk mengatasinya dengan produk, pemasaran, dan kepemimpinan bisnis, dan persyaratan ujung tombak untuk penyerahan teknik. Ini juga merupakan tanggung jawab Anda untuk melindungi kecepatan produktif tim Anda, mencari sumber daya tambahan jika tim Anda ditekan untuk menghasilkan lebih dari kemampuan Anda saat ini, untuk melaporkan dengan jelas tentang mondar-mandir pekerjaan dan simpanan, dan untuk demo pekerjaan yang selesai dan memastikan bahwa tim Anda mendapatkan kredit jatuh tempo untuk pekerjaan baik yang sedang dilakukan.

Jangan menyalahkan, tetapi tunjukkan bahwa tim Anda melakukan pekerjaan terbaik mereka.

Eric Elliott adalah pakar sistem terdistribusi dan penulis buku-buku itu, "Menulis Perangkat Lunak" dan "Memprogram Aplikasi JavaScript". Sebagai salah satu pendiri DevAnywhere.io, ia mengajarkan para pengembang keterampilan yang mereka butuhkan untuk bekerja dari jarak jauh dan merangkul keseimbangan kerja / kehidupan. Dia membangun dan memberi nasihat kepada tim pengembangan untuk proyek kripto, dan telah berkontribusi pada pengalaman perangkat lunak untuk Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, dan artis rekaman top termasuk Usher, Frank Ocean, Metallica, dan banyak lagi.

Dia menikmati gaya hidup terpencil dengan wanita paling cantik di dunia.