Saya tampaknya berulang kali terjebak dalam situasi di mana tanggal rilis ditetapkan bukan berdasarkan apa pun teknis, tetapi karena seseorang di Penjualan telah berkomitmen untuk pelanggan saat itu. Berdasarkan diskusi dengan teman-teman dalam pengembangan di perusahaan lain, hal yang sama tampaknya terjadi.

"Ini adalah set fitur yang berkomitmen dan inilah tanggal rilis yang berkomitmen", dan sulit untuk berdebat karena pada titik ini ada uang naik di atasnya, dan itu mengalahkan segalanya.

Secara umum, apakah ada cara untuk menekan ini? Jika tidak untuk rilis ini, bagaimana dengan di masa depan? Masalah yang saya miliki adalah bahwa satu-satunya cara saya melihat satu cara untuk melakukannya, dan itu adalah dengan melakukan yang terbaik yang saya bisa, tetapi lepaskan perangkat lunak 'apa adanya', untuk berbicara.

Saya tidak ingin merilis perangkat lunak bug karena nama saya terlampir, tetapi melakukan 80 jam minggu selama berbulan-bulan hanya membuktikan tanggal rilis yang ditetapkan secara sewenang-wenang.

sunting: untuk catatan, saya tidak melakukan 80 jam minggu sekarang, hanya yang terlintas dalam pikiran seperti apa yang diperlukan untuk mencakup fitur yang diharapkan ditetapkan oleh tanggal rilis.

Berhentilah melakukan 80 jam minggu. Ini adalah penguatan positif . Karena mereka mendapatkan produk tepat waktu dengan biaya yang diharapkan, mereka akan terus melakukannya, apa pun yang terjadi pada Anda.

Jika mereka tidak dapat menganggarkan waktu dengan baik, maka itu kesalahan manajemen. Bukan milikmu.

Biarkan mereka melewatkan beberapa tenggat waktu.

Secara umum, apakah ada cara untuk menekan ini? Jika tidak untuk rilis ini, bagaimana dengan di masa depan?

Tentu saja ada: Biarkan mereka gagal dengan pendekatan ini. Tidak ada yang mengajar dan gagal.

Buat estimasi sendiri sebelum Anda mulai dan tunjukkan pada mereka. Kemudian lakukan yang terbaik, tulis kode yang baik, berhentilah mengompensasi kebodohan mereka dengan waktu luang Anda, dan ketika mereka mengeluh setelahnya, ingatkan mereka tentang perkiraan waktu yang Anda tunjukkan kepada mereka, berdasarkan pada prinsip-prinsip teknik.

Dan Anda lebih baik mulai melakukan ini dengan proyek saat ini.

Jika mereka terus menyalahkan Anda karena masalah tersebut, Anda sebaiknya mulai mencari pekerjaan baru, karena tidak ada yang akan meyakinkan mereka bahwa mereka adalah masalahnya.

Sebagai renungan, saya pikir pertanyaan ini benar-benar menjamin tautan ke kisah EA yang terkenal seperti yang ditampilkan dalam salah satu buku Joel: EA: The Human Story .

Ini umumnya terjadi karena insentif yang salah - tenaga penjualan dibayar berdasarkan komisi, sedangkan staf produksi dibayar berdasarkan gaji. Tenaga penjualan memiliki beberapa tuas untuk bekerja dengan: fitur, biaya, dan tanggal pengiriman. Mereka memiliki disinsentif yang kuat untuk menurunkan biaya, karena ini umumnya menurunkan komisi mereka, sehingga mereka cenderung untuk mengubah fitur UP dan tanggal pengiriman (dalam hal yang lebih awal). Mereka akan mendorong mereka setinggi mungkin untuk menutup kesepakatan.

Coba dan lihat dari sudut pandang mereka, hanya sesaat. Mereka punya keluarga untuk diberi makan juga - dan jika perbedaan antara menutup penjualan yang telah saya kerjakan selama berbulan-bulan hanya memotong beberapa minggu dari jadwal, maka itu adalah godaan yang luar biasa, terutama jika saya tidak sangat mengerti apa artinya itu.

Godaannya adalah untuk mengatakan "selalu begitu, dan akan selalu demikian." Tetapi satu tempat saya bekerja setidaknya memiliki solusi yang DIUSULKAN, jika tidak dilaksanakan ... seorang manajer akhirnya mengangkat tangannya dan berkata, "jika lembur programmer digunakan untuk menutup penjualan, maka mereka harus menerima sebagian dari Komisi." Itu tidak diterapkan, tetapi itu akan menyelaraskan insentif semua orang lebih dekat ... programmer akan senang mendengar tentang fitur baru yang harus keluar dalam waktu singkat, karena mereka akan mengantisipasi komisi, dan tenaga penjualan akan cenderung kurang untuk menciptakan keadaan itu, karena mereka akan cenderung bekerja untuk keuntungan mereka.

Tim pengembang harus dikonsultasikan dengan keputusan ini atau Anda tidak akan pernah keluar dari siklus itu. Jika Anda tidak mengelola tim, maka salah satu manajer lini Anda perlu melakukan advokasi untuk tim pengembangan. Jika mereka adalah bagian dari masalah, maka Anda mungkin ingin mempertimbangkan opsi pekerjaan lain.

Secara umum, Penjualan tidak boleh melakukan apa pun tanpa persetujuan Manajemen Produk, yang jelas harus berkonsultasi dengan tim pengembangan untuk jadwal waktu. Tidak ada alasan yang baik untuk melewati ini di perusahaan besar atau kecil karena pada akhirnya tim Penjualan akan mengambil sedikit panas untuk pengiriman rendah (baik dalam kualitas atau cakupan).

Ini hampir merupakan hal universal di perusahaan-perusahaan kecil karena mereka memiliki kebutuhan yang lebih besar untuk menutup kesepakatan. Sampai saya dibawa ke pertemuan penjualan di perusahaan saya, saya pahit tentang ini, tetapi saya setidaknya bisa mengerti bagaimana dan mengapa itu terjadi lebih sedikit.

Klien menginginkannya dengan cepat dan banyak yang akan bermain keras untuk mendapatkannya. Ini mendorong penjualan untuk tunduk pada komitmen waktu hanya untuk mendapatkan sesuatu yang ditandatangani. Kontrak yang ditandatangani adalah emas karena Anda dapat memperoleh modal atau kredit menggunakan satu. Kadang-kadang lebih baik untuk memiliki tenggat waktu yang ketat daripada tidak bekerja sama sekali.

Di lain waktu jika ini adalah pasar yang panas dan ada banyak pesaing maka perusahaan memiliki kebutuhan yang mendesak untuk mengeluarkan produk lebih cepat dari yang lain. Perusahaan yang lebih besar atau perusahaan dengan modal lebih banyak selalu dapat mempekerjakan lebih banyak sumber daya, yang lebih kecil tidak bisa.

Di mana scummy adalah ketika tenggat waktu benar-benar buatan dan didorong oleh penjualan dan manajemen untuk mengamankan bonus besar untuk diri mereka sendiri.

Jangan biasakan bekerja lebih dari 45 jam seminggu, itu buruk bagi kesehatan Anda dan itu yang lebih dulu.

Saya sudah bekerja di kedua sisi rumah. Ingat tanpa tenaga penjualan tidak akan ada pekerjaan atau proyek hilir.

Cara memerangi komitmen berlebih penjualan : Perkirakan, lalu ambil setidaknya 130% kelipatan (selalu rencanakan kontingensi minimum 30%). Berikan dan dokumentasikan estimasi tersebut. Sadarilah bahwa perkiraan usaha Anda akan berkurang dalam proses penjualan. Tidak apa-apa, hanya minta manajemen mengukir perjanjian lisensi / penjualan / komisi setiap pengurangan jam tersebut. Jika Anda adalah perusahaan publik, ini menjadi rumit dengan VSOE , tetapi sampai Anda menekan orang-orang penjualan dengan akuntabilitas kontrak di muka selama proses penjualan mereka, itu akan menjadi akuntabilitas Anda nanti.

Ada banyak strategi yang bisa Anda gunakan, tetapi biasanya Anda perlu persetujuan atau persetujuan dari manajemen.

1. Membayar pengembang lembur dengan laju yang ditingkatkan. Bekerja lembur tidak terlalu buruk ketika Anda menghasilkan banyak uang ekstra untuk melakukannya. Dan jika hal itu mulai memengaruhi manajemen, perusahaan akan menerapkan tekanan pada penjualan untuk melakukan estimasi pekerjaan yang lebih baik.

2. Membayar tenaga penjualan berdasarkan pada laba, bukan dari penjualan kotor. Setiap jam kerja yang tidak mereka sertakan dalam taksiran mereka akan memengaruhi komisi mereka.

3. Batasi jumlah jam pengembang dapat bekerja hingga 40 (atau apa pun minggu kerja standar di bagian dunia Anda).

4. Buat orang-orang penjualan bekerja setiap jam di mana para pengembang bekerja. Jika mereka ingin Anda bekerja lembur untuk menyelesaikan proyek mereka, mereka juga harus ada di sana. Temukan sesuatu yang berguna untuk mereka lakukan, seperti menulis dokumentasi atau memproduksi salinan Pola Desain yang kaligrafi dan disinari dengan tangan dan Perpustakaan Template Standar C ++ .

5. Mintalah pengembang memperkirakan setiap pekerjaan alih-alih membiarkan tenaga penjualan melakukannya. Setidaknya dengan cara ini Anda mendapatkan beberapa kemampuan untuk membuat jadwal lebih masuk akal. Ini bukan solusi yang hebat, meskipun ... pengembang sering kali kesulitan dalam memperkirakan pekerjaan yang diperlukan. Sekalipun perkiraannya masuk akal, kejadian tak terduga dapat mencegah Anda mengenai target Anda. Juga, kita semua cenderung untuk tidak bekerja di awal proyek panjang dengan urgensi yang sama yang kita lakukan ketika tenggat waktu semakin dekat. Ini adalah faktor-faktor yang memotivasi siklus pengembangan singkat yang didukung oleh para pendukung Agile.

6. Ambil pendekatan "gesit" dan tolak untuk berkomitmen. Menjadi lincah akan membutuhkan lebih banyak keterlibatan pelanggan, tetapi juga dapat memberikan pelanggan lebih banyak fleksibilitas karena mereka tidak perlu harus berkomitmen di muka untuk bentuk akhir dari proyek baik. Penjualan mungkin tidak senang dengan hal itu pada awalnya, tetapi mereka mungkin mengubah nada ketika mereka menyadari bahwa hal itu dapat memberikan banyak peluang untuk menjual lebih banyak pekerjaan.

Saya pikir solusi yang paling tidak menarik adalah apa pun yang membuat tim penjualan terlihat buruk di mata pelanggan potensial. Tim penjualan adalah wajah perusahaan. Membuat mereka tampak buruk menyakiti seluruh perusahaan, dan itu mungkin tidak menyelesaikan masalah - mereka mungkin merasa perlu membuat kesepakatan yang lebih baik bagi pelanggan untuk mendapatkan kembali kepercayaan mereka.

Berhenti

Ada banyak saran yang masuk akal dalam jawaban yang sudah ada, yang diharapkan dapat membantu menyelesaikan hubungan yang tidak berfungsi ini. Tetapi pada akhirnya, Anda memutuskan seberapa banyak Anda ingin bekerja.

Sangat mudah untuk mendapatkan tekanan oleh rekan kerja untuk bekerja terlalu keras. Tetapi Anda mengorbankan kehidupan pribadi Anda saat melakukannya.

Inilah yang dapat Anda lakukan:

• Katakan kepada bos Anda, "Saya harus bekerja lebih banyak lembur daripada yang saya inginkan di sini. Mulai sekarang, saya tidak akan bekerja lebih dari X jam per bulan."
• Seperti yang disarankan orang lain, perkirakan berapa jam hal akan berlangsung di depan. Ingatkan mereka bahwa "pada batas X jam saya per bulan, saya mungkin tidak akan menyelesaikan ini pada batas waktu." Masukkan ini dalam email untuk referensi nanti.
• Lihat email itu ketika batas waktu berlalu. "Lihat? Seperti yang diproyeksikan, kita tidak bisa mencapai batas waktu ini dalam jam kerja yang masuk akal."
• Jika mereka terus menekan Anda untuk bekerja lembur dan semua upaya komunikasi gagal, berhentilah.

Pengalaman pribadi

Saya keluar dari pekerjaan terakhir saya karena saya selalu bekerja lembur dan selalu diminta untuk bekerja lebih banyak. Saya mengatakan kepada mereka dengan jelas dalam wawancara keluar saya bahwa saya menyukai banyak hal tentang pekerjaan itu, tetapi tidak melihat ada akhir dari lembur yang terlihat.

Saya juga dengan jelas menyatakan keinginan itu dalam wawancara saya untuk pekerjaan baru saya, dan mendapat tanggapan yang antusias. Mereka berpegang teguh pada kata-kata mereka: Saya jarang diminta bekerja lembur di sini.

Mantan majikan saya memiliki tingkat turnover pengembang yang tinggi, dan merasa lebih sulit untuk merekrut hari ini karena mereka memiliki reputasi untuk bekerja berlebihan. Mungkin biaya tambahan untuk perekrutan dan pelatihan akan memberi mereka pelajaran. Tetapi jika tidak, itu bukan masalah saya.

Pertama-tama, mari kita ingat bahwa kita semua pada umumnya memiliki pekerjaan untuk mendukung penawaran yang dilakukan oleh orang-orang penjualan daripada membangun seni pemrograman yang sempurna secara teknis. Jika mereka tidak melakukan transaksi Anda tidak memiliki pekerjaan.

Yang mengatakan triknya adalah menemukan cara untuk bekerja dengan penjualan untuk membuat semua orang terlihat baik. Proses di mana tim teknologi setidaknya dapat menyuarakan pendapat tentang proposal sebelum mereka keluar pintu adalah kuncinya. Menemukan cara-cara kreatif untuk menangani kompensasi juga membantu banyak - jika penjualan harus "memberi tahu" rekayasa ketika rekayasa menimbulkan kerja lembur besar-besaran membuat jadwal kerja yang tidak realistis tampaknya mengurangi secara drastis frekuensi proyek mars kematian.

Ini adalah sesuatu yang perlu Anda bawa ke manajer Anda (ada manajer pengembangan, kan?) Dan jelaskan masalahnya. Ini adalah perubahan yang perlu terjadi pada level organisasi - penjualan perlu mendapatkan dukungan dari pengembangan sebelum membuat komitmen, dan sebelum itu terjadi, mereka perlu mendapatkan arahan dari bos mereka.

Tidak ada yang dapat Anda lakukan untuk benar-benar membuat perubahan terjadi, tetapi Anda harus membawanya ke manajer Anda.

Selain mencoba mengubah budaya (semoga sukses), kapan pun mereka mendatangi Anda dengan tenggat waktu yang tidak dapat Anda penuhi, dorong kembali - dengan angka. Hancurkan proyek dan tunjukkan pada mereka perkiraan waktu Anda. Jika itu proyek enam minggu, beri tahu mereka. Jika sudah dijanjikan kepada klien dalam empat minggu, Anda tidak bisa melakukannya, dan Anda perlu menyebarkan informasi itu secepat mungkin. Mudah-mudahan, tenaga penjualan Anda akan dapat kembali ke klien dan menetapkan harapan yang lebih baik, atau bekerja sama dengan Anda untuk menghadirkan fitur yang lebih kecil yang dapat diatur untuk dikirimkan dalam jangka waktu yang dijanjikan, dengan fitur tambahan yang akan ditambahkan kemudian.

Sunting untuk ditambahkan: Jangan biarkan mereka menurunkan perkiraan Anda. Yakinlah bahwa itu benar, dan patuhi itu. Mereka akan mencoba untuk tawar-menawar dengan Anda, tetapi jangan biarkan mereka.

Satu saran yang belum muncul: retrospektif .

Jangan katakan "tidak, saya tidak melakukan lembur," yang selalu mendorong pengembang lain untuk masuk dan membuat Anda terlihat buruk.

Tetapi katakan dengan sangat jelas kepada manajemen Anda bahwa setiap kali Anda harus melakukan lebih dari 40 jam seminggu untuk mendapatkan pekerjaan, semua orang yang terlibat dalam proyek harus duduk di sebuah ruangan setelah produk dikirim , mencari tahu apa yang salah dan apa yang bisa kita lakukan untuk menghentikannya terjadi lagi. Atau, lebih baik lagi, setiap proyek harus memiliki retrospektif untuk membahas apa yang berjalan dengan baik dan apa yang salah.

Jika Anda benar dan itu penjual berlebihan maka ini akan menjadi sangat jelas sangat cepat. Tapi jangan mendahului kesimpulan dan jangan bermusuhan di depan fakta. Bicarakan tentang hal-hal yang dapat dilakukan tim Anda agar tepat waktu tanpa lembur.

Anda tidak pernah tahu, Anda bahkan dapat menemukan perbaikan pada proses Anda sendiri yang dapat membuat estimasi tenaga penjual lebih layak.

Sama sekali tidak ada cara untuk melawan ini sepenuhnya. Sifat penjualan yang berlebihan. Sebagai tenaga penjualan Anda di sana untuk membuat masalah calon pelanggan secara ajaib hilang. Tenaga penjualan yang baik hanya akan sedikit melebih-lebihkan, yang buruk akan menyebabkan diri mereka sangat malu.

Apa pun yang Anda lakukan hanya akan menyebabkan kejengkelan atau ketegangan antara orang-orang produk dan orang-orang penjualan (setidaknya). Anda dapat berusaha sangat keras untuk mencegah kesalahan yang sangat buruk pada bagian tenaga penjualan Anda, tetapi pada akhir hari para pengembang dan tenaga penjualan dibayar dari rekening bank yang sama. Perusahaan Anda akan berhasil atau gagal sebagai satu unit sehingga memulai perang saudara dengan penjualan tidak akan membantu.

Jika Anda memiliki satu atau lebih tenaga penjualan yang biasanya mempermalukan diri mereka sendiri, maka manajemen penjualan akan mengatasi masalahnya. Sebagai seorang pengembang, Anda tidak akan memiliki pengaruh untuk melakukan apa pun tentang hal itu sehingga Anda harus fokus pada memberikan produk terbaik yang Anda bisa dengan waktu dan sumber daya yang mereka berikan kepada Anda.

Sulit untuk menjawab tanpa mengetahui struktur perusahaan Anda.

Beberapa alat umum untuk membantu adalah:

• Telah menyetujui (tetapi yang bertanggung jawab, bukan penjualan) kontrol kualitas
• Memiliki peta jalan produk (internal dan eksternal)

Dengan menyetujui kontrol kualitas , Anda memiliki alasan yang digerakkan oleh bisnis karena tidak dapat merilis perangkat lunak kereta. Anda mungkin perlu meyakinkan bos Anda mengapa ini penting (semoga tidak), tetapi ada banyak literatur di luar sana untuk membantu dalam hal ini.

Dengan memiliki peta jalan produk , Penjualan tahu apa yang bisa dan tidak bisa mereka janjikan kepada pelanggan. Jika mereka ingin mengubah peta jalan, mereka harus meningkatkannya dengan Manajer Produk / Manajer Proyek / Manajer Pengembangan atau siapa pun yang mengubahnya.

Jika mereka menjanjikan sesuatu kepada pelanggan yang belum disetujui, sial. Semoga peta jalan Anda didasarkan pada data pasar tentang kebutuhan pelanggan. "Apa sebenarnya yang Anda usulkan agar kami lepaskan dari 8 fitur prioritas tinggi lainnya yang kami miliki bukti yang dibutuhkan basis pelanggan kami?"

Terakhir, seperti yang sudah diperkirakan, jangan bekerja 80 jam minggu. Anda bahkan tidak membantu perusahaan dengan melakukan itu karena Anda hanya membantu mereka menggali lubang yang lebih dalam.

Tidak

Saya mencoba membuat ini sebagai jawaban dua huruf dan tumpukan tidak membiarkan saya ... tetapi jawabannya adalah

Tidak

Yang, tidak sepenuhnya benar jika Anda memiliki / menjalankan perusahaan, tentu saja. Jika Anda berada di bahwa posisi Anda dapat menarik tim penjualan oleh telinga dan "memiliki pembicaraan". Namun, jika dan seperti yang saya duga, Anda hanyalah orang teknis "rendahan", satu-satunya jalan Anda adalah mengadu "UP" rantai komando. Yang sedang berkata, pengalaman saya adalah bahwa di perusahaan di mana ini terjadi, manajemen menyadari situasi dan tidak peduli.

Tunjukkan pada mereka gambar ini (atau ini ) dan beri tahu mereka bahwa Anda bekerja dengan segitiga mustahil.

  ·-----------------------·
 / \                       \
·   \   ·-------------------·
 \   \   \                 /
  \   \   \-----------·   /
   \   \   \     /   /   /
    \   \   \   /   /   /
     \   \   \ /   /   /
      \   \   /   /   /
       \   \ /   /   /
        \   ·   /   /
         \     /   /
          \   /   /
           \ /   /
            ·---·

Dalam proyek apa pun, jika Anda memperbaiki dua sudut dari tiga ini:

• Waktu
• Cakupan
• Kualitas

... maka yang ketiga adalah satu-satunya yang fleksibel. Apa yang membuatnya tidak mungkin adalah harapan. Jika mereka selalu memperbaiki Waktu terlalu pendek dan Lingkup terlalu besar, maka Kualitas akan selalu menderita. Dalam proyek yang gesit, ketiga sudut lebih atau kurang fleksibel.

(Penafian: Saya mengecualikan faktor Biaya dari segitiga proyek tradisional dan membuat Kualitas sudut. Waktu adalah Biaya dalam proyek perangkat lunak.)

Saya harap Anda berhasil membuat jalan Anda ke manajemen proyek yang lebih gesit.

Beberapa jawaban yang sangat bagus sudah ada di sini. Saya hanya akan menambahkan bahwa Anda tidak harus didorong untuk memenuhi tenggat waktu untuk merugikan Anda sendiri. Juga, saya pasti akan berbicara dengan penjual dan mengingatkan dia bahwa jika dia terlalu janji dan perusahaan tidak dapat memenuhi janjinya maka dia (dan perusahaan) tidak akan dipercaya di masa depan, kehilangan dia komisi di masa depan (dan mungkin pekerjaannya), jadi itu adalah kepentingan terbaiknya untuk menjadi realistis (yaitu berkonsultasi dengan staf pemrograman) sehingga ia mendapatkan kepercayaan pada perusahaan. Dalam jangka pendek ia mungkin memperoleh keuntungan dengan menjadi tidak realistis, tetapi dalam jangka panjang ia akan kalah dengan merusak reputasinya dengan pelanggan, majikannya dan majikan masa depan melalui referensi yang buruk.

Ketika orang-orang penjualan memahami uang lebih dari apa pun, berbicaralah kepadanya dalam istilah-istilah itu.

Dengan pengembangan Agile kami melihat titik penjualan konsultan masing-masing ~ 1000-1500. Jika Anda dapat mengubah proses penjualan ke tempat mereka harus menjual berdasarkan skala poin maka tim penjualan akan dipaksa untuk bekerja dengan tim pengembangan untuk menghasilkan perkiraan yang masuk akal.

Itu semua bermuara pada satu titik kritis; Jika Anda tidak berpikir Anda dapat mempertahankan langkah yang diperlukan untuk memenuhi jadwal yang dijanjikan Penjualan, maka jangan berkomitmen untuk pekerjaan itu. Jika Penjualan berlebihan, itu bukan masalah Anda, sampai Anda menyetujui pekerjaan itu. MAKA itu masalahmu. Ingatkan atasan Anda bahwa yang harus dilakukan oleh para tenaga penjualan adalah mengatakan ya dan mereka mendapatkan cek; kaulah yang benar-benar memenuhi janji, jadi jika Anda mengatakan itu tidak berhasil, atasan Anda harus mendengarkan. Jika Anda memiliki nasib buruk memiliki manajer yang mendengarkan tenaga penjualannya lebih dari kekuatan pengembangannya mengenai apa yang mungkin dan tidak mungkin, maka Anda memiliki PHB Dilbert-esque, dan Anda harus memperbarui resume Anda.

Ini adalah salah satu alasan saya suka Agile; tim pengembangan terlibat dalam proses dari diskusi desain awal. Anda dapat mengkalibrasi "titik" dari kedua ujungnya; tim pengembang memutuskan (baik secara eksplisit atau empiris) kira-kira berapa banyak jam kerja pengembangan yang melekat dalam suatu titik, yang kemudian dapat digunakan manajemen untuk menghitung poin per minggu, poin per bulan, dll yang mengarah ke angka dolar. Pada titik itu, tim penjualan Anda sekarang memiliki angka yang berkaitan dengan biaya dan waktu yang diperlukan untuk tingkat staf saat ini untuk menyelesaikan jumlah ruang lingkup saat ini. Jika mereka melakukan overpromise begitu mereka memiliki angka-angka itu, mereka keluar di pantat mereka.

Tentukan pekerjaan setelah mereka memberikannya kepada Anda dan beri tahu mereka berapa lama. Lalu ketika mereka berkokok tentang hal itu memberitahu mereka.

"Aku minta maaf kamu membuat komitmen itu tetapi diberikan sumber daya yang aku miliki. Butuh waktu X jam untuk menyelesaikannya"

Lakukan ini setiap kali ... itu berhasil untuk saya.

Pada dasarnya katakan kepada mereka bahwa mereka dapat memilikinya Cepat, Murah dan Bagus, pilih dua.

Sebenarnya ada cara - cara nyata, bukan kata-kata kosong - tetapi Anda mungkin tidak menyukainya.

Minta seseorang dari tim pengembangan terlibat dalam proses penjualan .

Sekarang jelas Anda membutuhkan seseorang dengan keterampilan orang-orang baik, seseorang yang tidak akan dipermalukan oleh orang-orang penjualan untuk ikut dalam perjalanan. Dan orang ini perlu memiliki pemahaman yang luas tentang jenis pekerjaan yang Anda lakukan. Mereka tidak perlu menjadi ninja kode, mereka hanya perlu sedikit pemahaman tentang pengkodean secara umum dan proses pengembangan Anda pada khususnya, dan cukup baik dalam memperkirakan pekerjaan.

Ini benar-benar pekerjaan untuk analis bisnis atau manajer proyek. Ada alasan mengapa pekerjaan ini membayar dengan sangat baik di banyak perusahaan; mereka menggabungkan dua set keterampilan yang sangat penting dan berbeda. Jika Anda tidak memiliki BA atau PM asli tetapi memiliki dev atau arsitek senior dengan keterampilan sosial, mereka juga dapat melakukannya.

Anda juga perlu memberikan panduan yang jelas untuk tenaga penjualan. Secara efektif, Anda (seperti dalam tim dev Anda) mengirim seseorang untuk bernegosiasi atas nama Anda. Jika Anda tidak memberi mereka parameter apa pun, mereka hanya akan menegosiasikan apa yang tampaknya baik bagi mereka. Itu sebabnya Anda selalu memberi mereka parameter.

Setelah Anda memahami ruang lingkup proyek, cari tahu berapa banyak waktu yang Anda ingin miliki untuk membangun, menguji, perubahan ruang lingkup, dan sebagainya, ditambah jumlah buffer tertentu, kemudian berikan nomor itu bersama dengan "minimum resmi" - the terendah yang mungkin mereka dapat lakukan sebelum menempatkan proyek dalam risiko besar. Mengharapkan mereka untuk melemahkan bahwa jumlah dengan jumlah tertentu juga, sehingga membuat minimum Anda sedikit lebih tinggi daripada yang sebenarnya perlu.

Yakinlah bahwa manajemen mereka melakukan hal yang sama. Manajer penjualan tidak ingin rekanan penjualan yang menjual penawaran yang tidak menguntungkan. Mereka memasuki setiap negosiasi dengan sejumlah angka yang sesuai dengan target profitabilitas dan profitabilitas minimum.

Anda mungkin bukan manajer mereka, tetapi jika Anda mendokumentasikan semua ini secara tertulis sebelum mereka bahkan mulai bernegosiasi, maka Anda berada di tanah yang lebih kokoh dengan manajemen tingkat atas ketika orang-orang mulai bertanya tentang mengapa proyek ini terlambat. Tapi ini bukan hanya tentang CYA; tim penjualan dengan jujur ​​tidak memiliki petunjuk berapa lama hal-hal tertentu akan berlangsung, dan Anda melakukannya dengan memberi mereka informasi yang komprehensif.

Satu hal lagi: Jangan berharap tim penjualan membuat tim Anda terlibat hanya untuk itu. Anda juga memerlukan dukungan dari manajer penjualan dan eksekutif. Seharusnya tidak terlalu sulit untuk mendapatkannya, jika Anda mendekatinya dari sudut pandang risiko. Anda tidak ingin menjual kegagalan, bukan? Pikirkan biaya untuk reputasi perusahaan. Pikirkan biaya gugatan . Seseorang teknis harus menjadi bagian dari negosiasi apa pun sebelum kesepakatan apa pun dapat ditandatangani.

Dan jika Anda benar-benar, jujur ​​tidak dapat menjual manajemen pada gagasan itu, maka dapatkah saya menyarankan mencari majikan baru? Karena milikmu mungkin sudah tidak ada lagi.

Ketidaksepakatan seperti ini biasanya disebabkan oleh kurangnya komunikasi. Entah mereka tidak mengerti tekanan yang mereka berikan kepada Anda atau Anda tidak mengerti apa yang sebenarnya mereka minta. Either way, untuk mengatasi masalah ini, Anda perlu memahami situasi dari sudut pandang lain.

Pernahkah Anda mencoba menjual perangkat lunak? Ini mungkin bukan jawaban terbaik bagi banyak pengembang, tetapi sampai Anda sudah mencobanya, akan sulit untuk melihat bisnis dari sisi penjualan. Jika Anda adalah pengembang hebat, tulis sesuatu yang benar-benar ingin Anda tulis dan jual. Anda mungkin melihat bahwa mereka memiliki beberapa poin yang valid atau Anda mungkin melihat bahwa mereka tidak memiliki!