Saya bekerja sebagai manajer proyek untuk Pengetikan Langsung. Tahun lalu, kami menulis di blog korporat kami bahwa jika tenggat waktu mogok, yang utama bukanlah membuat ini kejutan dan memperingatkan klien. Tetapi semakin lama kita bekerja, semakin kita menyadari bahwa tenggat waktu yang lebih buruk daripada yang rusak hanya dapat menjadi rumit, klien dan tim yang emosional terbakar di bawah tekanan mereka.
Perusahaan-perusahaan yang telah memperoleh beberapa pelanggan tetap selama bekerja, tahu cara memfilter prospek yang mencurigakan bahkan pada tahap panggilan pertama, dan dapat membelinya. Sayangnya, studio muda dalam mengejar pengalaman dan penghasilan, sayangnya, tidak dapat melakukannya tanpa klien seperti itu.
Sebelum masuk ke sepuluh besar dari berbagai peringkat industri,
Live Typing bekerja dengan klien yang mendemotivasi tim begitu banyak sehingga orang-orang mulai meninggalkan perusahaan. Untuk alasan yang akan saya bahas di bawah, kami sepakat dengan klien lagi. Khawatir dengan krisis baru dalam hubungan, saya mengembangkan taktik manajemen khusus untuk menjaga tim tetap aman dan sehat. Lagipula, menemukan pengembang yang keren itu sulit, dan melatih serta mengadaptasi karyawan baru lebih mahal daripada mempertahankan yang lama. Selain itu, spesifik dari outsourcing adalah bahwa setelah proyek ini, pengembang akan mengambil yang berikutnya, dan penting bahwa mereka melakukannya dengan otak yang belum sepenuhnya meledak.
Tentang bagaimana saya melakukannya, baca artikel itu.
Untuk alasan yang jelas, saya akan memanggil klien hanya "klien". Bahkan di proyek, dengan kerja sama berulang, kami di dalam tim tidak menyebutnya apa pun. Mengapa Tentang itu di bawah ini.
Latar belakang
Dua tahun lalu, sebuah proyek datang kepada kami. Sebelum sampai ke kami, sekitar lima tim mengerjakannya, dan dia mengumpulkan kode warisan yang layak.
Hubungan klien dengan tim-tim sebelumnya jauh dari hubungan mitra, jadi dengan dia ia memutuskan untuk secara otomatis mengambil posisi ofensif dan memagari dirinya sendiri dengan dinding ketidakpercayaan.
Untuk mempercepat komunikasi dan pengembangan, manajer proyek pertama membuat obrolan di Slack umum untuk klien dan tim - aplikasi tidak dikembangkan oleh kami dan menimbulkan banyak pertanyaan yang harus dengan cepat ditujukan kepada klien. Dalam kebanyakan kasus, metodologi ini mempercepat transfer informasi antara anggota tim, tetapi klien kami tidak menyangkal dirinya sendiri untuk membuat komentar kasar baik dalam obrolan atau secara pribadi kepada orang tertentu.
Klien beralih ke kepribadian, yang menghasilkan konflik terbuka, dan namanya terdengar bahkan dari mereka yang tidak terlibat. Akibatnya, perusahaan kehilangan setidaknya satu karyawan yang tidak tahan dengan sikap ini, dan beberapa lainnya pergi setelah beberapa bulan. Alasan formal untuk pergi tampaknya berbeda, tetapi kami tahu sesuatu.
Ketika klien kehabisan uang, kami putus. Uang, perlu dicatat, pergi, termasuk dukungan untuk kode lama dan pengembangan fungsionalitas demi fungsionalitas.
Pelanggan kemudian kembali. Dia meyakinkan kami bahwa dia ingin mengembangkan aplikasi dari awal, meninggalkan kode yang ketinggalan zaman, mengurangi fungsionalitas dan berkomunikasi dengan gaya yang berbeda. Kami menerimanya, tetapi setelah beberapa waktu cerita itu mulai terulang kembali.
Klien tidak mempercayai peringkat dan penawaran kami. Dia punya ide sendiri tentang bagaimana produk harus bekerja. Kami juga memiliki pemahaman tentang bagaimana melakukannya, tetapi klien tidak memahami argumen dan bukannya seorang mitra dengan keahlian dalam pengembangan aplikasi, ia melihat di tangan kami hanya tangan yang mengubah Wishlist-nya menjadi kehidupan. Kami tidak tahu alasan mengapa klien menempatkan dirinya dalam posisi seperti itu dan tidak akan berspekulasi.
Situasi semakin memanas. Mengingat bagaimana peristiwa berkembang di masa lalu, kami memprioritaskan dalam urutan yang tidak biasa bagi kami: pertama-tama, Anda perlu menyelamatkan tim, dan baru kemudian berhasil menutup proyek dan, jika mungkin, mempertahankan loyalitas pelanggan.
Taktik perlindungan untuk pelanggan yang kompleks
Sekarang mari kita lihat teknik-teknik yang membantu kami mencapai tujuan kami, kesalahan yang tidak boleh Anda ulangi, dan kesimpulan yang dapat Anda gunakan dalam pekerjaan Anda.
Jelaskan nilai desain
Jadi, proyek dimulai dari awal. Dalam konteks keputusan ini, sebuah proposal muncul untuk melakukan MVP dan membayar pekerjaan kami sesuai dengan model harga tetap. Ini tampak logis, karena jika tidak ada kode orang lain, maka tidak ada risiko dengannya.
Kelemahan dari harga tetap sebagai model pembayaran adalah bahwa hal itu mengurangi proyek fleksibilitas: ketika fungsionalitas sedang dilaksanakan, yang disetujui oleh para pihak dalam tugas teknis, pasar dapat berubah dan hasil kerja tidak akan lagi menyelesaikan masalah pengguna yang sebenarnya. Dimungkinkan untuk mengembangkan MVP dengan harga tetap hanya jika Anda telah menguji secara menyeluruh dan menyeluruh semua hipotesis, merancang spesifikasi teknis, dan menulis dokumentasi terperinci. Klien kami hanya mengabaikan desain, atau lebih tepatnya, mengambilnya sendiri.
Kisah dengan pilihan layanan untuk obrolan bersifat indikatif. Klien menyelidiki sendiri kemungkinan solusi teknis, dan memberi kami beberapa pilihan layanan: "Mana yang lebih baik?" Kami memilih layanan A karena cocok dengan proyek pada seperangkat metode API, dan dari sudut pandang pengembangan dan integrasi itu lebih baik daripada layanan B. Kami tidak merancang layanan untuk bekerja dengan infrastruktur kami dan tidak memeriksa apa pun selain kriteria formal ini: tidak ada stabilitas , tidak ada kecepatan respons, tidak ada - tidak ada anggaran. Obrolan akhirnya merespons lebih lambat daripada yang bisa terjadi jika ada waktu untuk memeriksa.
Jangan jatuh untuk manipulasi dalam semangat "Jika Anda membutuhkannya untuk menyelesaikan tugas, lakukanlah secara gratis! Anda harus melakukannya dengan baik! ”Jika ada: esensi pengembangan outsourcing adalah untuk menyelesaikan masalah klien untuk uang klien.
Analis harus merancang. Dia memiliki pengetahuan yang memungkinkan dia untuk memahami dan mengartikulasikan dengan jelas apa yang sebenarnya dibutuhkan klien di final, dan untuk membangun arsitektur sistem bersama: layanan apa yang akan ada dalam produk, apakah ada integrasi dengan sistem pihak ketiga, bagaimana permintaan berpindah antar layanan, di mana informasi disimpan, bagaimana itu disampaikan, dll. Ini perlu, pertama, agar produk klien bekerja dengan cepat dan andal, dan kedua, untuk memberi nasihat tentang apa yang dapat Anda hemat, dan apa yang sebenarnya tidak sepadan.
Jadikan makna MVP sama untuk semua orang
Apa arti MVP bagi kami:
- kami menyetujui fungsionalitas dasar aplikasi dan memoles dengan ideal hanya fitur-fitur yang berhubungan dengannya. Fitur-fitur lain harus berfungsi sehingga tidak ada keinginan untuk menutup aplikasi;
- kami membuat fungsionalitas minimum yang diperlukan untuk menyelesaikan masalah bisnis, dan tidak ada area admin yang dirancang;
- kami menunda penyesuaian hingga nanti, yaitu, kami menggunakan komponen dalam desain yang dapat digunakan kembali pada beberapa layar, menolak elemen tata letak yang rumit dan menyederhanakan desain jika perlu.
Tetapi klien MVP memiliki interpretasi yang berbeda. Apa artinya ini bagi kita:
- fungsi minimal untuk uang minimal.
Di masa depan, entah bagaimana terjadi bahwa "uang minimal" tetap dan posisi "kita tahu bagaimana melakukannya, jadi lakukan seperti yang kita katakan" ditambahkan.
Posisi seperti itu mengancam kemitraan normal. Ancaman hanya dapat dihilangkan dengan desain dan tugas fungsional, yang merinci segala hal yang harus dapat dilakukan aplikasi. Apakah ada persyaratan dan saran baru tanpa komitmen? Rujuk ke Undang-Undang Federal dan tawarkan untuk membeli waktu. Mungkin ini formalisme dan bukan tentang fokus pelanggan, tetapi adil dalam kaitannya dengan perusahaan Anda.
Sekali lagi: MVP dikombinasikan dengan perbaikan ketika ada desain. Kami tidak memilikinya, tetapi Anda harus memilikinya.
Biarkan pengembang berdebat dengan Anda
Dan tidak pernah bekerja dengan desain tanpa komitmen dari klien, bagaimana kami bekerja.
Pengembang paling sering terikat: segera setelah tugas ditetapkan, mereka akan melakukannya. Tetapi pada proyek-proyek dengan anggaran terbatas, pelaksanaan setiap tugas yang berpotensi kompleks harus dipertanyakan untuk melenturkannya dan memenuhi tenggat waktu.
Sumber tugas semacam itu secara tak terduga adalah desain yang ditangani oleh sisi klien. Pengembang kami diberitahu bahwa jika mereka meminta beberapa koreksi, mereka akan segera dikirim, jadi kami mulai bekerja bukan dengan versi statis desain, tetapi di editor Figma, di mana desain ini dibuat. Pengembang memberikan penilaian dan mulai bekerja.
Dan kemudian, satu per satu dalam desain, elemen mulai muncul yang tidak asli - ini bisa dilihat dari cadangan, yang saya buat berjaga-jaga. Tetapi sebelum memulai pengembangan, tidak mungkin untuk memeriksa apakah desain tertentu telah berubah - setidaknya karena pengembang mengambil tugas dengan urutan yang mudah untuk dirinya sendiri.
Identifikasi ketidakkonsistenan membantu kebebasan berbicara yang sama. Pengembang dapat mendatangi saya dan menarik tidak hanya elemen-elemen yang tidak dapat dengan cepat dibuat, tetapi juga elemen-elemen yang ada dalam desain klien - ini dapat dimengerti, karena desainer itu sendiri secara diam-diam memperkenalkan mereka di sana, tetapi tidak dalam salinan kami. Elemen-elemen ini tidak termasuk dalam penilaian, yang berarti bahwa kita tidak boleh menanganinya dengan biaya kita sendiri.
Dalam dunia perkembangan yang sehat, harga tetap tidak memungkinkan untuk meningkatkan jumlah pekerjaan dan mengubah kondisi saat bepergian.
Jauhkan klien dari tim
Terakhir kali kami menghubungkan pengembang dan klien secara langsung - ada tim di mana diyakini bahwa manajer pertama-tama harus memantau persyaratan dan anggaran, dan tidak berfungsi sebagai pemancar persyaratan klien.
Ini adalah metodologi yang hebat dengan kelebihannya: reaksi masing-masing pihak lebih cepat, tim lebih memahami tugas bisnis, wewenangnya tumbuh, dan manajer tidak mati sebagai pemancar. Tetapi mengetahui bahwa klien dapat menjadi pribadi, saya mengisolasinya dari tim. Hanya klien, manajer akun, dan manajer proyek, yaitu, saya, yang tetap ada dalam obrolan.
Apa yang memberi kita? Saya memoderasi komunikasi dan tidak membiarkan hubungan pribadi meracuni rutinitas kerja. Pada saat klien mengkritik tim dengan cara mereka, saya menjawab bahwa kami akan mengambil tindakan dan menghukum karyawan tersebut. Pengamatan menunjukkan bahwa untuk meyakinkan beberapa pelanggan, cukup untuk mengorbankan seseorang dari tim bahkan untuk bersenang-senang, sehingga karyawan terus bekerja dengan tenang dan bahkan tidak tahu bahwa dia dihukum.
Jika Anda mencurigai bahwa klien gelisah, maka jangan membawa tim bersamanya setidaknya untuk sementara waktu, sampai Anda yakin sebaliknya.
Merumuskan kembali umpan balik dari klien ke tim
Dalam suasana ketidakpercayaan dan kritik yang terus-menerus, tim tidak lagi mengelola untuk memproses umpan balik dalam bentuk umpan balik, dan klien mulai berpikir bahwa tim datang untuk bekerja hanya dengan niat jahat - dan mewujudkannya.
Apa yang harus dilakukan dengan manajer ini? Pengeditan kosmetik tidak ada salahnya: Saya menghapus penilaian kepribadian dari umpan balik, hanya menyisakan kata-kata kesalahan tanpa kehilangan makna. Dan karena Anda tidak mendapatkan pujian dari klien, saya tidak lupa untuk memberikan umpan balik saya sendiri kepada tim - untuk tugas-tugas yang tidak menimbulkan pertanyaan, yang berarti bahwa mereka dilakukan dengan baik dari sudut pandang klien.
Itu adalah:
"Aplikasi tidak bekerja pembayaran. Tangan apa yang kamu lakukan? ”Itu menjadi:
“Guys, aplikasi memiliki sesuatu untuk dibayar, klien meminta untuk mengetahuinya, berikut adalah screenshotnya. Dan dengan animasi yang tertinggal seminggu yang lalu, semuanya baik-baik saja. "Jangan terburu-buru untuk mendapatkan bug
Memasukkan bug ke dalam task manager segera setelah mereka diterima dari klien berasal dari pengalaman. Berbekal mata kritis, manajer akan membantu menghemat berjam-jam pengembang dan penguji. Hanya berbicara dengan klien atau meminta untuk memutar kembali tindakan yang mengarah ke kesalahan dan merekam video, Anda dapat memahami bahwa bug tersebut bukan prioritas atau muncul karena klien melakukan sesuatu yang salah - dan sekarang, Anda tidak perlu lagi mengeditnya. Jadi saya memilah seperempat bug yang masuk, dan bagian lain terkait dengan layanan dukungan layanan terintegrasi - ada cukup SDK pihak ketiga pada proyek.
Jangan menyebutkan nama pelanggan
Mungkin wawasan yang paling penting. Menurut ingatan lama tentang bagian dari tim, menyuarakan nama klien memicu sikap bias terhadap setiap komentar di pihaknya, tidak peduli seberapa memadai itu. Dan saya datang dengan memanggil klien hanya klien, yang mengurangi negatif. Tampaknya semua orang mengerti siapa yang mereka bicarakan, tetapi percayalah - nuansa ini telah meningkatkan ekologi proyek.
Kesimpulan
Untuk lebih jelasnya, saya memutuskan untuk mengurangi semua hal di atas menjadi sebuah tabel dengan prinsip "Bagaimana tidak dan bagaimana melakukannya."
Tetapi saran kami akan bermanfaat bagi Anda seminimal mungkin jika orang yang bertanggung jawab untuk bekerja dengan klien yang masuk di perusahaan Anda, atau manajer akun mengungkapkan kelemahan klien pada tahap negosiasi.
Berikut adalah beberapa poin penting yang sekarang kami perhatikan:
- Apa yang klien katakan tentang kontraktor sebelumnya, jika dia. Jika dia berbicara negatif tentang dirinya, ada kemungkinan dia tidak melihat pendapat selain dari pendapatnya sendiri dan akan memaksakan keputusannya.
- Apakah klien memiliki pengalaman di bidang TI. Untuk klien yang berpengalaman, proses pengembangan menimbulkan lebih sedikit pertanyaan.
- Apakah dia menawar untuk setiap sen atau tidak. Semakin tinggi keinginan klien untuk membayar lebih sedikit, semakin dia bersedia dan keras kepala.
Semoga artikel ini bermanfaat bagi seseorang. Dan jika Anda sudah berada di tempat saya, maka beri tahu kami bagaimana Anda menyelesaikan klien yang sulit.