Pemberdayaan Penjualan

Singkatan: Apa singkatan dari DEAD dan DITO?

Saya telah mengembangkan, mendefinisikan, mengintegrasikan, dan memperkirakan proyek selama lebih dari satu dekade. Setelah bekerja dengan ratusan perusahaan serta dengan banyak pengembangan internal dan perusahaan konsultan eksternal, saya selalu kagum pada betapa salahnya industri ini dalam menetapkan perkiraan penyelesaian dan tenggat waktu penyelesaian. Sebagai hasilnya, saya telah menemukan perhitungan DEAD dan DITO baru untuk estimasi dan penyelesaian proyek. Di sini mereka:

MATI: Perkiraan dan Batas Waktu Pengembangan:

  1. Manajemen penjualan: Harapan klien akan diambil 25% lebih lama untuk dikembangkan dari proyek sebenarnya yang dijanjikan oleh Salesman.
  2. Persyaratan Fungsional: Persyaratan fungsional yang Anda tetapkan tidak akan benar-benar berfungsi. Menambahkan 25% lebih banyak waktu perencanaan untuk memastikan persyaratan fungsional benar-benar dapat diterapkan berdasarkan arsitektur sistem dan antarmuka aplikasi Anda.
  3. Persyaratan Fungsional: Persyaratan fungsional yang Anda tetapkan tidak akan benar-benar dikembangkan seperti yang Anda harapkan. Ini ada hubungannya dengan hambatan bahasa Klingon vs. Inggris (atau sebaliknya) antara Pengembang dan Manajer Produk. Menambahkan 25% lebih banyak waktu pengembangan untuk proyek Anda, pra-rilis untuk memastikan bahwa itu dikembangkan sesuai dengan kebutuhan Anda.
  4. Manajemen Proyek: Perkembangan sebenarnya akan memakan waktu 25% lebih lama untuk dikembangkan dari perkiraan proyek yang sebenarnya.
  5. Gunakan Kasus: Kasus penggunaan bisnis yang Anda tetapkan hanya terdiri dari 25% dari kasus penggunaan aktual yang akan terjadi. Tambahkan 50% lebih banyak waktu pengembangan untuk proyek Anda, setelah rilis, untuk menyesuaikan penggunaan aktual vs. penggunaan yang diharapkan. Ini termasuk fungsionalitas serta kinerja.

MATI Diterapkan:

  1. Proyek diperkirakan dan terjual selama 10 hari kerja selesai.
  2. Sebenarnya dibutuhkan waktu 12.5 hari untuk menyelesaikannya seperti yang dijanjikan.
  3. Sebenarnya diperlukan waktu 15.625 hari untuk mengklarifikasi masalah dengan persyaratan yang salah atau terlewat.
  4. Sebenarnya dibutuhkan waktu 19.53125 hari untuk menyelesaikan proyek sebagaimana ditentukan dengan benar.
  5. Jadi… proyek selesai dalam ~ 20 hari.
  6. Setelah diluncurkan, diperlukan 10 hari lagi untuk memperbaiki masalah yang belum terselesaikan.
  7. Total waktu Proyek adalah 30 hari.

DITO: Pengembang Insomnia dan Take Out.

Untungnya, perusahaan kami memiliki faktor kompensasi DITO untuk diterapkan, menyimpan proyek, dan mengutip proyek berikutnya.

DITO Diterapkan:

  1. Pengembang luar biasa yang Anda pekerjakan sebenarnya penderita insomnia dan sering kali dapat memperpanjang 8 jam kerja menjadi lebih banyak, termasuk akhir pekan. Keuntungan 100% dalam penghematan produktivitas: ~10 hari. Sekarang kita hanya terlambat 10 hari.
  2. Dengan membujuk programmer dengan makanan Take-Out, Anda bisa mendapatkan akhir pekan dan bekerja melalui makanan. (Pengembang adalah orang-orang yang brilian tetapi saya selalu bertanya-tanya mengapa seorang programmer $75/jam akan bekerja selama satu jam makan siang untuk pizza $10… siapa tahu?!). Penghematan: ~ 25%. Sekarang kita hanya terlambat 5 hari.
  3. Saat tenggat waktu semakin dekat dan klien semakin marah, Anda perlu menambahkan Mountain Dew ke Take-Out, tetapi ini terkadang akan menghasilkan pemrograman langsung 24 hingga 36 jam. Solusi yang dihasilkan akan dirilis, dengan bug (kadang-kadang karena remah-remah kerak pizza di keyboard) tepat waktu.
  4. DITOmenerapkan hasil pasca-rilis dalam penghematan 5 hari pada peningkatan pasca-rilis.

Menggabungkan MATI dan DITO Perhitungan menghasilkan kelipatan 1.5 sederhana pada penyelesaian proyek. Selalu terapkan 50% lebih banyak waktu untuk menyelesaikan proyek daripada yang Anda harapkan.

CATATAN: Akronim MATI berlaku karena Pengembang akan meninggal rata-rata 25% lebih cepat daripada karyawan biasa karena komplikasi yang diakibatkan oleh tidak tidur, tekanan darah tinggi, diabetes, dan masalah berat badan dari Pizza, Donat, Mountain Dew, dan Kopi yang dibeli oleh Perusahaan. DITO berlaku karena staf Penjualan Anda akan menerapkan perkiraan awal pada proyek yang terjual berikutnya.

Douglas Karr

Douglas Karr adalah CMO dari Buka WAWASAN dan pendiri dari Martech Zone. Douglas telah membantu lusinan startup MarTech yang sukses, membantu uji tuntas lebih dari $5 miliar dalam akuisisi dan investasi Martech, dan terus membantu perusahaan dalam menerapkan dan mengotomatiskan strategi penjualan dan pemasaran mereka. Douglas adalah pakar dan pembicara transformasi digital dan MarTech yang diakui secara internasional. Douglas juga merupakan penulis panduan Dummie dan buku kepemimpinan bisnis.

Artikel terkait

Kembali ke atas tombol
Penyelesaian

Adblock Terdeteksi

Martech Zone dapat memberi Anda konten ini tanpa biaya karena kami memonetisasi situs kami melalui pendapatan iklan, tautan afiliasi, dan sponsor. Kami akan sangat menghargai jika Anda menghapus pemblokir iklan saat Anda melihat situs kami.