Banyak yang harus berurusan dengan situasi di mana manajer membutuhkan tim unicorn dengan kulit pelangi, dan batas waktu kemarin. Dalam tim seperti itu, pekerjaan dapat berubah menjadi konflik abadi, semua orang berusaha melindungi kepentingan mereka dan semua orang benar-benar lupa bahwa mereka awalnya bersatu untuk membuat produk yang berkualitas dan mengkomunikasikan manfaat. Tim seperti itu sulit disebut efektif.
Tentang apa tim produk yang efektif, bagaimana membangunnya dan apa yang perlu dilakukan agar semua anggota tim terlibat secara maksimal dalam proses tersebut, kami berbicara dengan para ahli dalam diskusi panel yang berlangsung di kantor kami. Bersama kami, jawaban atas pertanyaan diajukan oleh Roman Abramov (direktur produk CarPrice dan pendiri ProductStar), Mikhail Alexandrovsky (Pendiri Dostavista), Anna Boyarkina (Kepala Miro Produk), Ilya Krasinsky (CEO Rick.ai), Michael Yan (CEO ManyChat) . Detail di bawah potongan.
Pada 8 Agustus, sebuah diskusi panel berlangsung di kantor ManyChat, di mana mereka membahas topik membangun tim produk yang efektif yang relevan bagi banyak perusahaan. Para pakar yang diundang adalah
- Roman Abramov, Direktur Produk CarPrice dan Pendiri ProductStar
- Mikhail Alexandrovsky, Pendiri Dostavista
- Anna Boyarkina, Kepala Produk Miro
- Ilya Krasinsky, CEO Rick.ai
- Michael Yan, CEO ManyChat.
Pertemuan tersebut dimoderatori oleh Kira Matveeva, direktur produk di Lamoda Group. Selama diskusi, kami membahas alat dan proses apa yang ada, bagaimana menyatukan dan mengarahkan tim, membantu karyawan tumbuh dan berkembang, mempertahankan motivasi, memompa keterampilan, dan juga menjawab pertanyaan dari audiens.
Bagi mereka yang terutama menghargai efek kehadiran pribadi, kami
sarankan menonton rekaman siaran . Untuk semua orang - transkrip diskusi yang terperinci. Selamat membaca!
Apa itu tim produk, apa bedanya dengan tim non-produk?
Roma:
Tim produk adalah tim yang melihat produk, kemungkinan besar online. Dalam pemahaman saya, ini mungkin termasuk pengembang, penguji, pemasar, desainer (terutama). Ini bukan hanya produk. Tugas produk adalah untuk memimpin dan mengatur tim ini. Sehingga mereka merasa senang bersama, dan semua ini membuahkan hasil.
Ilya:
Mari kita tambahkan holivar segera sehingga tidak membosankan: ketika semua orang setuju dengan semua orang. Saya selalu dibom ketika tim produk "melihat produk." Omong-omong, tim berbeda dari karyawan dalam hal anggota tim disatukan oleh satu tujuan. Saya suka tim yang bertanggung jawab atas uang, dan ternyata 60% dari waktu Anda tidak perlu memotong produk. Sebaliknya, perlu untuk membuang yang tidak perlu darinya.
Michael:
Mari kita lanjutkan ke holivarit. Saya tidak setuju bahwa timnya adalah tentang uang. Ini tentang beberapa metrik produk. Tim produk dan non-produk berbeda karena tim non-produk memiliki sasaran dalam metrik non-produk. Tidak lebih.
Michael:
Mari kita tambahkan sesuatu yang lain untuk ini. Biasanya semua orang setuju dengan segalanya, tetapi di sini mereka mulai dengan perselisihan. Kami punya pertanyaan besar - apakah produk bertanggung jawab atas uang atau metrik lainnya. Saya baru-baru membaca hal yang baik di
Product Star : "Tujuan dari manajer produk adalah untuk meningkatkan pendapatan perusahaan." Tampak bagi saya bahwa ini menggabungkan sudut pandang yang berbeda, karena perusahaan yang berbeda pada tahap yang berbeda dapat memiliki tujuan yang sama sekali berbeda. Dan tim produk pergi ke misi perusahaan melalui tugas dan tujuan yang kini dihadapi perusahaan ini. Pada awalnya, Anda mungkin memiliki tugas untuk mencapai profitabilitas. Kemudian, ketika Anda sampai pada profitabilitas, Anda terus tumbuh, maka Anda dapat memikirkan banyak hal lainnya.
Anya:
Ini adalah pertanyaan yang sangat kompleks, kontroversial dan aneh. Masing-masing dari kita menambahkan makna kita sendiri. Jika Anda memikirkannya, manajer produk dan tim produk adalah tim yang memiliki produk yang dapat digunakan, dan melalui itu tim memengaruhi metrik, bisnis perusahaan, dan pencapaian tujuan. Saya setuju, mereka bisa berbeda. Ini bisa berupa kapitalisasi, bisa berupa uang, bisa juga beberapa indikator lain. Dalam kasus umum, ini bukan hanya cerita tentang tim yang menggergaji beberapa fitur (meskipun ini keren dan menarik), tetapi tentang bagaimana tim memecahkan masalah dalam mencapai tujuan perusahaan.
Struktur tim, peran dan jenis organisasi. Siapa yang bisa berada di tim, dan apa bidang tanggung jawabnya?
Anya:
Saya pikir itu menarik untuk diceritakan ... Pada suatu waktu, kami memutuskan untuk membagi tim menjadi tim produk (inti) dasar dan tim pertumbuhan. Di suatu tempat 3-4 tahun yang lalu, ketika kami memprioritaskan tugas, selalu ada konflik kepentingan: apa yang kami investasikan - dalam pengembangan fungsionalitas produk atau dalam eksperimen. Membuat nilai atau mencoba skala itu? Salah satu solusi keren yang bekerja pada tahap ini (saya tidak mengatakan bahwa itu akan selalu seperti itu): tim terpisah dialokasikan untuk pertumbuhan. Anda perlu memahami bahwa kami memiliki seluruh bisnis dibagi menjadi dua bagian bersyarat: bagian dari keuntungan dihasilkan dari swalayan, ketika beberapa orang datang dan membeli produk, dan ada juga bisnis yang menyentuh manusia dengan departemen penjualan. Dalam layanan mandiri, tim pertumbuhan bekerja dan menyediakan GoToMarket
(sekitar GoToMarket - entri ke pasar) untuk produk baru. Tim ini mempekerjakan 20-22 orang: manajer produk, desainer, pengembang. Ada 4 manajer produk.
Ilya:
Artinya, ini adalah, sebenarnya, 4 tim yang memiliki metrik tertentu, mereka dapat mencari tahu lebih cepat, dan sebagainya. Dan tim infrastruktur yang mengendalikan mereka sehingga mereka tidak menyembuhkan apa pun.
Anya:
Apa arti tim infrastruktur?
Ilya:
Saya suka skema ini: Anda perlu melakukan eksperimen cepat. Ini adalah tipe tim yang sangat berbeda, pengembang menerima aturan permainan bahwa “kami tidak melakukannya sekarang, benar, dengan pola desain, basis data, dan ORM. Kami membuat rintisan; mereka telah melempar bagian depan, meluncurkannya sesegera mungkin, dan seterusnya. ”
Dalam kasus ini, muncul masalah bahwa banyak tim mulai membuat banyak kode sampah, kualitasnya menurun, sehingga mereka diperkuat oleh tim infrastruktur yang melakukan tinjauan kode, memastikan kualitas kode, dan sebagainya. Fitur difokuskan pada metrik produk dan eksperimen cepat, tim infrastruktur - pada kualitas kode, komponen yang rumit dan panjang, engine, refactoring, dll.
Anya:
Ya, secara umum. Harus selalu ada semacam fondasi yang memungkinkan Anda melakukan eksperimen cepat.
Michael:
Kami juga memiliki sesuatu yang serupa. Beberapa waktu lalu, kami membagi pengembangan produk ke dalam Core dan tim pertumbuhan. Setiap tim memiliki regu
(kira-kira Skuad - perintah) yang menangani sesuatu yang terpisah. Seperti banyak perusahaan, kami mulai berbagi pengembangan dan produk. Tetapi ketika pertumbuhan dimulai, kami mulai membuat kotak di mana ada pengembang, produk, analis, dan orang lain, jika perlu, misalnya, DevOps. Awalnya, para pengembang mematuhi stasiun layanan dan tidak lebih. Sekarang mereka juga menurutinya, dia menolak mereka, mengangkat mereka, dan itu saja. Tetapi pada saat yang sama, para pengembang juga anggota regu. Ini berfungsi dengan baik, kode ini dipertahankan dalam kondisi baik. Awalnya, kami memiliki semua pengembang Signora. Ini juga buruk ketika tidak ada gerakan, ketika seseorang mengajar, membesarkan seseorang.
Ilya:
Tetapi apakah Anda memiliki beberapa jenis asimetri, beberapa tim fokus pada eksperimen cepat, yang lain pada pemeriksaan kode dan refactoring: penagihan, misalnya, adalah topik menyakitkan yang abadi yang digergaji dan di refactored untuk waktu yang lama?
Michael:
Ada tim infrastruktur yang tidak ada dalam tim pertumbuhan, ini berkaitan dengan "bagian kode yang intim".
Anya:
Kami juga punya satu!
Ilya:
Saya akan menambahkan. Ada satu hal yang tidak begitu sering saya lihat. Apa itu fungsionalitas silang? Ketika kami tidak lari ke departemen lain, karena kami memiliki desainer dan pengembang di tim yang sama. Dan saya sangat suka menambahkan manajer penjualan ke tim produk sehingga mereka tetap berada di sana sepanjang waktu. Ada pelanggan, dan manajer penjualan berkomunikasi dengan pelanggan, memahami apa yang mereka butuhkan. Dan ada tim produk yang terlibat dalam pengembangan produk. Saya suka menjembatani kesenjangan antara manajer penjualan dan tim produk. Saya ingin penjualan menjadi dukungan dan pengembangan dan berbicara tentang apa yang terjadi, entah bagaimana dipengaruhi.
Michael:
Kami memiliki poin yang menarik. Awalnya kami adalah tim jarak jauh dan mencoba untuk mendapatkan pertumbuhan sesedikit mungkin. Ketika kami menjadi lebih dari 20 orang, kami berkumpul di kantor Moskow pertama. Lalu kami punya kantor di San Francisco, kami menyewa pria keren lokal dari Atlassian yang membangun cerita besar. Dia juga mulai mempekerjakan orang lokal. Dan kami memiliki masalah bahwa pemasaran mulai terpisah dari tim produk.
Sekarang kami mulai membangun tim baru. Kami mulai mengirim pengembang ke kantor San Francisco. Mereka membantu pemasar dengan pengetahuan dan keterampilan mereka.
Dan sekarang kami membentuk dua tim pertumbuhan yang akan bersatu dalam satu era
(sekitar Area Produk, lini produk yang menggabungkan beberapa tim produk) dan akan bekerja sama dengan pemasaran. Mereka akan memiliki metrik dan tugas mereka sendiri. Satu tim akan berada di San Francisco, yang lain di Moskow. Dan untuk mencapai tujuan mereka dan bergerak maju, mereka harus terus melakukan sinkronisasi. Saya tidak bisa mengatakan bahwa itu sudah berfungsi, tetapi menurut saya itu akan keren.
Roma:
Dari yang menarik, saya bisa mengatakan tiga hal. Pertama, tren kami adalah "lebih sedikit, tetapi lebih baik." Ada 100 dari 600 orang di TI, sekarang ada kurang dari 50 orang, tetapi mereka melakukan lebih baik dan lebih banyak. Tiga pengembang kuat, bahkan tanpa produk, akan melakukan lebih dari 10 yang buruk dengan suatu produk. Sebagai bengkel personel, kami memiliki cabang Kirov.
Tren dan kenyataan kedua adalah bahwa kita memiliki banyak offline. Bisnis tidak hanya penjualan, tetapi juga ritel besar, waralaba di seluruh negeri, gudang raksasa, ribuan mobil yang benar-benar membalikkan seluruh negeri dalam tiga hari. Untuk semua ini, kami melakukan CRM, semua ikatan yang orang butuhkan. Ini sering diabaikan oleh orang-orang dengan latar belakang online, tetapi ini penting, dan ini adalah kisah yang hebat.
Tren ketiga - kami mentransfer semua IT ke pekerjaan jarak jauh. Hasilnya dua kali lipat, omsetnya nol. Sebelumnya, seorang junior datang, kami melatihnya, ia menguasainya, dan segera setelah ia mengangkat tangannya, ia tersapu - di Avito, Siprus. Sekarang semua orang senang, mereka bekerja di rumah, istrinya ada di dekat, produktivitasnya luar biasa, motivator yang baik untuk pengembang, semua orang baik.
Kami beralih secara bertahap sebagai tes A / B. Kami memiliki sistem bisnis OKR, kami telah menggunakannya selama dua tahun, sangat membantu untuk menyinkronkan dengan bisnis. Awalnya ada satu hari dari rumah. Lalu ada dua hari dari rumah, lalu tiga. Kuartal ini masuk sepanjang minggu dari rumah. Sementara semuanya bekerja dengan baik, orang-orang senang, ada hasilnya. Saya percaya bahwa ini adalah masa depan - mengapa duduk di kantor yang pengap, membayar sewa.
Hanya ada satu colokan - ini adalah proses. Masalah utama adalah diskriminasi terhadap karyawan jarak jauh. “Kenapa kita akan menghubungkan beberapa pria yang sedang duduk di luar rumah. Biarkan dia duduk di sana. " Tetapi ketika semua orang mengerti bahwa besok dan saya akan duduk dari rumah, semua orang menghubungkan semua orang. Saya juga bekerja dari jarak jauh.
Bagaimana cara memastikan bahwa semua karyawan jarak jauh terlibat sebanyak mungkin?
Roma:
Semuanya diputuskan dengan latihan. Jika Anda menulis kepada karyawan, tetapi dia tidak online, jika Slack tidak memiliki status "pergi makan siang", maka minggu depan dia duduk di kantor. Seseorang harus bertanggung jawab, jika dia bekerja dari jarak jauh, dia harus selalu tersedia.
SkyEng banyak berbicara tentang latihan mereka di bidang ini. Salah satu penyedia utama mengatakan bahwa Anda dapat bekerja sambil berdiri, dan menggunakan papan setrika sebagai dudukan. Saya membeli kursi yang nyaman, saya duduk di meja dapur, berbicara di Skype, semuanya baik-baik saja.
Ilya:
Kantor harus ada di sana sehingga Anda dapat berkumpul dan mendiskusikan ide-ide. Tetapi hal keren tentang hal yang jauh adalah bahwa orang-orang duduk dan melakukan hal mereka sendiri, tidak ada yang mengganggu mereka sekali lagi. Keren ketika jumlah pertemuan minimal. Hal yang paling penting, menurut pendapat saya, dan apa yang kami ajarkan sebagai satu tim:
- Bagaimana tugas yang diajukan. Ini adalah masalah abadi. Kami menggunakan kerangka kerja solusi masalah-situasi (lihat 2 bab pertama dari buku piramida Minto) dan mengatur tugas dari hasilnya, yaitu menjawab pertanyaan tentang apa yang harus dilakukan dan apa hasilnya seharusnya.
- Budaya ranjau: pertama, anggota tim menulis teks, lalu menelepon dan membahas penghalang dan pertanyaan singkat atau merencanakan tindakan mendalam.
- Budaya pengiriman hasil, termasuk perantara.
Secara umum, tim yang didistribusikan adalah tentang orang dewasa yang tahu cara mengatur waktu mereka dan membantu mereka melakukannya secara efektif.
Apakah produk dan proyek satu orang?
Anya:
Produk harus memutuskan apakah mereka memerlukan proyek atau tidak. Jika Anda perlu memajukan segala sesuatunya, lalu siapa yang peduli?
Michael:
Kami memiliki kelulusan produk di mana kami melihat pertumbuhan bertahap. Ngomong-ngomong,
Roma membicarakan hal ini
sebelum diskusi panel . Bagi kami, produk tingkat pertama adalah ketika Anda dapat mengambil masalah dari jaminan simpanan dan menyelesaikannya. Ketika ada spesifikasi dan deskripsi, Anda hanya perlu melengkapinya. Level kedua adalah menemukan solusi ketika "rasa sakit" pengguna diketahui. Setiap orang dari level 2 harus mampu dan level 1. Tingkat ketiga, ketika ada metrik khusus pada input yang perlu Anda pengaruhi, dan sudah ada masalah dan peluang untuk itu. Tingkat keempat bekerja dengan strategi. Dalam komponen saat ini, produk, yang terletak di dalam tim lintas-fungsional, melakukan fungsi manajer proyek itu sendiri, atau (lebih baik) tim itu sendiri memiliki fungsi terdistribusi dari manajer proyek. Ketika sebuah tim kecil (misalnya, 6 orang) dan bekerja bersama, dan lari cepat, manajer proyek tidak diperlukan. Untuk unit yang lebih besar - eria, yang terdiri dari beberapa tim, ada pemilik produk yang juga dapat bekerja secara langsung dengan manajer produk dalam tim. Jadi sekarang kami tidak memiliki manajer proyek di ManyChat.
Anya:
Seringkali dalam wawancara yang berbeda mereka bertanya kepada saya: "Apakah Anda memiliki produk yang terlibat dalam manajemen proyek"? Sangat bagus ketika ada tim yang bergerak sendiri. Tapi tetap saja, ini adalah keterampilan yang penting, dan Anda harus mengerti bagaimana melakukannya. Jika Anda harus mencapai hasil, Anda harus dapat menyelesaikan masalah. Karena itu, saya percaya keterampilan itu harus ada, karena tanpanya sangat sulit untuk memajukan segala sesuatu, terutama dalam situasi dengan tingkat ketidakpastian yang tinggi. Dimungkinkan untuk menumbuhkan tim yang akan melakukan semuanya sendiri, tetapi Anda harus bisa melakukan ini.
Michael:
Produk harus bertanggung jawab untuk memastikan bahwa hasilnya tercapai. Tetapi bagaimana ini dilakukan tidak penting. Jika ada kompetensi dalam tim - ini keren. Jika tidak, perlu diisi ulang.
Michael:
Kami secara historis memiliki proyek dan produk yang berbeda, kemudian jumlah tim meningkat, dan kami menyadari bahwa kami tidak memerlukan manajer proyek yang terpisah. Ketika semuanya lebih atau kurang disesuaikan dalam tim, itu tidak diperlukan. Sebuah proyek diperlukan ketika tim baru dibentuk, perlu dibangun, proses harus disesuaikan. Kami membutuhkan orang yang tahu bagaimana melakukan ini. Tetapi jika dia terus dibutuhkan, maka ada sesuatu yang salah pada tim. Setiap tim memutuskan cara kerjanya. Awalnya, proyek berpartisipasi dalam semua ini. Seiring waktu, beberapa proyek tetap, mereka tidak ditugaskan ke tim tertentu dan melakukan hal-hal lain.
Ilya:
Sangat dekat dengan pola yang "kami anut." Berkat Maxim Dorofeev, frasa seperti "seorang pria dengan tangan keledai" muncul di industri. Orang ini sangat mudah diidentifikasi, ia sering bekerja pada akhir pekan, dan jika ia pergi berlibur, maka semuanya berantakan dalam tim. Dia ping sepanjang waktu sehingga mereka datang ke pertemuan harian. Ada kelas pria yang mengunci semuanya pada diri mereka sendiri, dan masalah muncul. Ternyata "pass manajer" yang terus-menerus mentransfer tugas antara orang-orang dengan kehilangan makna di sepanjang jalan.
Produk kami dapat bertindak sebagai proyek dalam tim, mereka dapat mempromosikan tiket dalam sistem. Tapi kami sangat menyukainya ketika pengembang menulis tiket sendiri. Proyek kami mempertimbangkan metrik, memvisualisasikan masalah dalam tim, memantau berapa banyak tugas yang sedang berlangsung, melihat kecepatan kemajuan, memperkirakan di mana tugas digantung - apakah itu review kode atau tidak. Ini membantu untuk membuat diagnosa. Proyek ini berada di luar tim, dalam arti tidak menutup proses itu sendiri, tetapi membantu, memfasilitasi, dan mereka berada pada tahap peluncuran bersama tim.
Manajer proyek adalah "kata penutup" di mana Anda dapat memasukkan apa saja. Secara umum, jika seorang karyawan menginginkan, saya dapat memberinya posisi Ratu Victoria. Siapa yang peduli apa namanya? Seseorang menyukai istilah "Scrum-master", seseorang lebih menyukai "fasilitator proses".
Michael:
Pelatih yang gesit ...
Ilya:
Aku mencintai mereka dari kejauhan ... Aku sangat mencintai mereka, tetapi dari kejauhan.
Novel:
Banyak orang datang ke kursus kami yang bekerja dalam peran proyek. , , , , , , .
, , , , , , « ». , , . .
?
:
, , . :
: ? ?
: , ?
: , -?
, – . , . , , . , , . , , .
? . , . B2B B2, . , , B2B 80% . , .
— , , . , , , , . — , . , , . , , , .
. , — , . : - , . , . , , — .
, . , , , , , , , -, . . , , , .
:
. , , . — . , , .
, , ( , ), , , -. , . , , . , , . : ( ), , , , , . - , - . , . , — , . — 90% .
— . , , . MVP, . «» ? custdev, . , , . — . , .
— 10 . , 30% . , . , , , . , , , . , .
, , 2 CEO, , , . , 0 1, , . .
, $15 000. - , 20-30 , , 50-60. « ». , 0 1 — . . , , .
:
, - -. Google: « 20% , ». , . « » , , .
, . , , , , — , «», . , , .
, , . , , . , : , . , . . , , — 10 , . , , . , . , , (: ). , , . , , — - , . , , « ». , , .
, . , OKRs. , , . , , , , . , - , .
:
— , , . , . -, - , . - , -… . . , . , , , . , . , . . . , . , — . -, . , , , .
:
, , . , - , . , .
. . , . , ( ).
:
: . — -. , . - , . - . , . , -, , . . -, , : « … … ». , . .
Tentu saja, ketika Anda dihadapkan dengan tugas praktis, Anda akan memilih konferensi yang tepat dan buku yang tepat. Lebih baik ketika kebutuhan untuk pertumbuhan berasal dari tugas tertentu.Dan sebagai kesimpulan
Kami meminta para ahli untuk membagikan tautan yang bermanfaat dan menempatkannya di satu tempat. Semua informasi dapat diperoleh dari bot kami di Facebook atau di saluran Telegram .