Timlid di startup - sekaligus, dan Elon Musk, dan Frankenstein. Di pagi hari dia membangun pesawat ruang angkasa, dan di malam hari dia memanggil ke proyek tangisan: "Hidup! Anda tidak harus mati! " - Dan tertawa tidak sehat. Dan semua ini ditemani oleh tiga junior.
Alexander Polomodov memimpin pengembangan manajemen atraksi di Tinkoff.ru; Dia sebelumnya adalah CTO / Manajer Pengembangan untuk perusahaan kecil. Kami meminta Alexander untuk mengingat masa lalu dan memberi tahu jebakan apa yang bisa diharapkan dari seorang pemimpin tim yang datang ke startup.
Di bawah potongan - jawaban untuk pertanyaan penting:
- bagaimana bertahan dalam kondisi ketika proses interaksi tidak terjadi (atau tidak ada sama sekali);
- bagaimana menyusun tim yang keren ketika penggajian terbatas;
- bagaimana memahami bahwa Anda harus melarikan diri dari proyek.
1. Penuh ide, tidak ada yang bisa dilakukan
Anda datang bersama tim di startup. Harapan: segera mulai bekerja pada fitur-fitur baru. Realita: Berburu pengembang, karena tim yang kuat diperlukan kemarin, dan tidak ada yang peduli untuk merakitnya.
Dua opsi dimungkinkan di sini - lebih berat dan lebih ringan. Pilihan yang menyakitkan: ada sedikit uang di PHOT. Salah satu keputusan terbaik dalam situasi ini adalah untuk membawa pekerja magang dengan kepala yang bersih dan cerdas, dan memasukkan semua pengetahuan dan keterampilan yang diperlukan ke dalam kepala ini: gambarkan masing-masing individu dengan rencana pengembangan individu, langkah demi langkah gambarkan pengetahuan apa yang perlu ia peroleh, keterampilan apa yang harus dikembangkan. Ini cara yang hebat, tetapi, sayangnya, itu bukan milik Anda: ini adalah permainan yang panjang, dan startup yang perlu dengan cepat menunjukkan hasil hampir tidak pernah melakukan ini.
Ungkapan khas: “Kami membutuhkan spesialis top di Angular. Kami membayar di bawah pasar. "
Opsi yang lebih mudah: ada uang, dan Anda siap menawarkan kondisi pasar yang baik.
Kasus khas. Praktik umum di perusahaan IT dalam hal ini adalah mengekspos persyaratan dasar bagi seorang kandidat untuk mengetahui tumpukan teknologi tertentu. Beberapa tahun yang lalu, dalam deskripsi pekerjaan, "kami mencari seorang ninja jQuery" terus muncul. Masalahnya adalah bahwa banyak ninja ini tampaknya telah meninggalkan ranjang Procrustean - mereka hanya dapat menulis di jQuery (bukankah itu ada di proyek baru? Yah, maafkan aku). Dan jika seseorang tidak hanya mengetahui tumpukan spesifik dengan sempurna, tetapi juga memiliki basis yang baik, maka kemungkinan besar beberapa perusahaan akan membunuh penawaran gaji Anda.
Solusi Ketika ada uang untuk gaji yang memadai, Anda perlu mencari orang, fokus pada keberadaan pengetahuan mendasar dan keterampilan yang diperoleh dengan susah payah seperti pemikiran sistemik. Bahkan jika seseorang tidak terbiasa dengan bahasa tertentu atau tumpukan teknologi, dia akan menguasai semua hal utama untuk kuartal jika dia mau.
Ketika Anda tidak dapat bersaing untuk spesialis terbaik dalam hal gaji, ada baiknya merekrut orang-orang dengan kepala yang cerdas yang tidak berhasil memilih bidang tersebut. Seorang pria merancang sirkuit mikro, dan sekarang memutuskan untuk mengubah area tersebut menjadi area yang lebih ekonomis? Kami mengambilnya.
2. CEO dari Narnia
Kesulitan kedua yang mungkin dihadapi oleh seorang pemimpin tim dalam sebuah startup adalah kacamata CEO merah muda. Rencana yang telah diajukan kepada klien atau investor tidak sesuai dengan kenyataan. Tim ditekan sesuai dengan tenggat waktu, mereka harus segera menunjukkan MVP, menambah fitur, sambil terus-menerus menetapkan tenggat waktu yang tidak realistis. Lapisan baru dan baru dari kode kruk tumbuh, utang teknis terakumulasi, dan pencipta startup yakin bahwa semuanya sudah beres - pengembang baik malas atau menyuarakan perkiraan pesimistis.
Seringkali situasi ini terjadi pada manajer penjualan. Dia sudah menjual kastil di udara - dan bagaimana membangun kastil ini sekarang, dia tidak terlalu peduli.
Ungkapan khas: "Saya menjual fitur-fitur ini, mereka akan muncul pada akhir minggu, bulan, tahun" (garis bawah seperlunya).
Kasus khas. CEO menginginkan pembebasan dalam tiga hari, pengembang mengevaluasi tugas dan memberi tahu pemimpin tim apa yang dapat ia lakukan dalam lima hari. Menjelaskan: “API yang Anda harus kerjakan sudah lama diintegrasikan. Jika API akan bekerja seperti yang dijanjikan oleh mitra, maka dalam tiga hari saya akan mendapatkannya. Tapi, dalam pengalaman saya, API dari mitra ini sering tidak memenuhi janji mereka, oleh karena itu - lima hari. " CEO menjawab: "Mitra berjanji bahwa semuanya akan baik-baik saja. Anda memiliki tiga hari, "kata CTO setelah pertemuan:" Saya tidak mengerti apa-apa dalam pengembangan, tapi saya hampir membagi dua penilaian tugas. "
Pengembang dari kasing ini mencoba dan menyelesaikan tugas dalam empat hari. Bagaimanapun, fakap itu terjadi, tetapi bahkan jika itu telah memenuhi tenggat waktu, itu tidak dapat berlangsung untuk waktu yang lama, ini adalah tahap akhir dari kesalahpahaman tentang bagaimana tim yang normal dan sehat harus bekerja.
Solusi Membahas waktunya adalah normal, tetapi harus menjadi diskusi yang beralasan. Gaya Tony Robbins menjawab: "Seminggu terlalu lama!" dan "Kamu harus berusaha lebih keras!" - Indikator kacamata merah muda. Untuk menghapusnya adalah ujian serius keterampilan komunikasi pemimpin tim.
Ini bukan tentang merobohkan harga dengan tawar-menawar, seperti di pasar di mana ada biaya dan margin yang lebih rendah yang didistribusikan dalam permainan zero-sum antara penjual dan pembeli. Ini membahas solusi teknik yang ingin Anda evaluasi, dengan mempertimbangkan faktor-faktor tambahan. Pengembang tidak menawar untuk dirinya sendiri lima hari kerja, tetapi memberikan penilaian berdasarkan pengetahuannya. Jika tekanannya baik, itu akan mengurangi waktu, tetapi kemungkinan besar, itu akan mengurangi semua risiko. Dan ketika terjadi kesalahan, rencana pasti akan berjalan. Inilah yang penting untuk disampaikan kepada CEO, dan jika Anda tidak ingin mengerti, melarikan diri, Anda bodoh.
3. Hutang teknis dengan bunga kredit mikro
Kisah penciptaan OS / 360, yang dijelaskan dalam buku "Mythical Man-Month" oleh Frederick Brooks, sangat mengungkap. Itu seharusnya menjadi sistem operasi paling keren saat itu. IBM menarik ribuan orang ke proyek dan masih ketinggalan dalam semua hal: waktu, fungsi, dan kemampuan dukungan.
Dari buku Brooks, jelas bahwa kemudian para pengembang menginjak semua kemungkinan garu, dan ini terlepas dari kenyataan bahwa mereka menggunakan Air Terjun dan cukup jelas mewakili tahap-tahap pengembangan. Dan hari ini, dengan penyebaran Agile yang luas, tim dan rencana arsitektur untuk jangka panjang sering tidak memilikinya - hanya tumpukan yang terdiri dari tugas-tugas bisnis dan sprint selama satu hingga dua minggu, sehingga arsitekturnya keluar sesuai.
Frasa khas: “Cat ulang tombol ini dengan warna biru? Ini akan memakan waktu seminggu
Dengan syarat, jika pembangunan tiga apartemen direncanakan dalam sprint pertama, maka pada sprint kedua sebuah gubuk atau gubuk sedang dibangun di dekatnya. Kemudian muncul tugas baru - untuk menutupinya dengan atap yang sama, dan jika itu adalah atap yang dipasang, ternyata akan ada lantai lain di atasnya dan seterusnya.
Di mana rumah sungguhan akan lama runtuh karena kesalahan kesalahan desainer, hutang teknis terbentuk dalam pengembangan. Dan jika pada awalnya pekerjaan pada proyek berjalan sesuai rencana, dan tidak ada yang melihat kruk menyebar, maka pada titik tertentu ternyata fitur sederhana, yang pada awalnya biaya hari pengembang, sekarang memakan waktu dua kali lebih banyak. Dan karena Anda harus berkeliling kruk berulang-ulang dan menambahkan kruk baru, dalam seperempat fitur akan dikenakan biaya lima kali lebih tinggi.
Solusi Seorang pemimpin normal membuat keputusan berdasarkan fakta dan angka. Datang dengan perhitungan: tunjukkan berapa banyak hutang teknis terbuka akan dikenakan biaya dalam sebulan, dalam seperempat, dalam satu tahun. Jadi, Anda akan memiliki kesempatan untuk menyesuaikan rencana, termasuk dalam sprint tidak hanya fitur baru, tetapi juga "pembayaran hutang" bertahap.
Tentu saja, ini bukan daftar masalah lengkap yang dihadapi tim di startup, tetapi ketiganya adalah yang paling akut dan sulit untuk dipecahkan.
Alexander Polomodov - kurator intensif
Weekle Teamlead di Distrik Biner; kursus berikutnya akan diadakan 15-16 Desember.