Teknologi interaksi dengan pelanggan internal. Manajemen proyek. Menginformasikan Pelanggan tentang teknologi manajemen proyek

Saya ingin fokus untuk menciptakan citra positif. Berdasarkan informasi awal yang dikumpulkan, kami memutuskan karyawan mana yang dapat dipercaya untuk mewakili perusahaan kami pada pertemuan pertama dengan klien. Ini adalah poin yang sangat penting. Misalnya, jika kami mengirim spesialis yang sangat baik untuk kontak pertama, tetapi ia memiliki anting-anting di telinganya, "juru masak" yang direndam dalam minyak, dll., Maka klien dapat melihat dan berkata: "Oh, ayolah!" Itu terjadi. Atau, misalnya, seorang yang rapi, rapi, dalam setelan jas dan dasi, tetapi seorang anak laki-laki berusia sekitar 20 tahun masuk. Dan klien melihat dan berkata: “Ini anak laki-laki, apa yang harus saya bicarakan dengannya? Bagaimana bekerja dengan mereka - mereka tidak menghormati saya sama sekali, mereka mengirim anak laki-laki kepada saya! Oleh karena itu, pengumpulan informasi ini diperlukan, antara lain, untuk memahami siapa yang harus dipercayakan dengan kontak pertama dan bagaimana berperilaku dengan kontak, bagaimana membangun legenda, bagaimana menampilkan diri.

Identifikasi pengambil keputusan

Pertanyaan berikutnya yang sangat penting adalah identifikasi orang-orang yang benar-benar membuat keputusan(yang disebut LPR). Tahap ini terdiri dari dua item:

• Ternyata, yang membuat keputusan sesuai dengan proyek kami.
• Dan poin kedua - orang yang mempengaruhi pembuat keputusan diidentifikasi.
  Apa artinya? Misalnya, diketahui bahwa keputusan di perusahaan dibuat oleh CEO, dan dia juga memiliki direktur keuangan dan akuntan. Bisa jadi akuntan yang melakukan semua yang dikatakan direktur dan duduk diam di sudut, atau mungkin sebaliknya, akuntan yang memberi tahu direktur apa yang harus dilakukan seperti ini dan direktur mematuhinya. Dan jika kami awalnya mengungkapkan bahwa orang ini memiliki pengaruh pada direkturnya, maka ini adalah kartu truf kami, oleh karena itu, kami perlu mencoba menjalin hubungan dengan akuntan ini. Saya dengan syarat mengatakan bahwa ini adalah seorang akuntan - bisa siapa saja (misalnya, kepala departemen penjualan atau beberapa wakil yang sepenuhnya dipercaya oleh direktur umum atau pemilik perusahaan). Hal ini diperlukan untuk membangun hubungan dengan orang yang mempengaruhi pembuat keputusan.

Tujuannya, seperti yang Anda lihat, adalah untuk mengidentifikasi pembuat keputusan. Dan hasilnya adalah daftar pembuat keputusan dan orang-orang yang mempengaruhi pengambil keputusan.

Pengalaman kami menunjukkan bahwa cobalah untuk bertemu dengan para pengambil keputusan sesegera mungkin- biasanya mereka adalah manajemen puncak atau pemilik perusahaan. Itu tidak harus terjadi pada kontak pertama, tetapi jika pertemuan seperti itu tidak terjadi pada tahap awal, maka, sebagai suatu peraturan, tidak ada hal baik yang akan datang dari proyek kami.

Membangun kemitraan

Tahap selanjutnya - membangun kemitraan.

• Kami awalnya melakukannya penekanan pada tanggung jawab bilateral: bahkan dalam kontrak, jika memungkinkan, kami tidak meresepkan Kontraktor-Pelanggan, tetapi “ Sisi pertama" (ini adalah Pelanggan) dan " Sisi kedua” (Ini Pelakunya). Benar, kadang-kadang beberapa struktur negara besar mengatakan bahwa departemen hukum tidak mengizinkan mereka melakukan ini, karena dokumen diperiksa oleh Departemen Keuangan, Kementerian Keuangan, dan lainnya. Dalam hal ini, kami meresepkan kata-kata standar - "Pelanggan dan Kontraktor". Tetapi jika memungkinkan, maka - "Pertama" dan "Sisi kedua".
• Dengan segala cara kami berusaha menyampaikan bahwa ini adalah kerja bersama. Pemimpin di kedua sisi bertindak sebagai pihak kontraktor tinggi - merekalah yang memutuskan untuk membuat proyek otomasi ini. Untuk proyek ini, mereka merekrut tim bagaimana dari staf pertama pihak, karyawan sisi kedua adalah yang disebut Kelompok Kerja Bersama", yang membuat proyek. Secara alami, masing-masing pihak menginvestasikan sumber dayanya dalam proyek: material, teknologi, metodologis, keuangan - karena, secara umum, kita berbicara tentang proyek yang cukup besar.
• Pekerjaan kelompok kerja bersama diawasi oleh« Komisi Pengawas Bersama" adalah badan pengendali tertinggi, biasanya terdiri dari manajemen puncak dari kedua belah pihak.
• Dan menandatangani tanggung jawab masing-masing pihak sehingga karyawan pelanggan memahami bahwa bukan hanya kami, tetapi juga mereka yang bertanggung jawab atas proyek tersebut. Kami menghabiskan banyak waktu dan upaya untuk menyampaikan kepada klien bahwa kami melakukan proyek ini bersama dengan karyawannya, dan bahwa pekerjaan mereka secara langsung tergantung pada kualitas apa dan, terutama, dalam kerangka waktu apa proyek akan selesai.

Sehat hasil tahap ini adalah fiksasi(formal atau tidak resmi) hubungan mitra setara:

• Fiksasi formal adalah kontrak.
• Dan informal - itu bisa berupa beberapa dokumen resmi di mana kami selalu mencoba untuk meresepkan "Sisi Pertama dan Kedua" dan hubungannya.

Menginformasikan Pelanggan tentang teknologi manajemen proyek

Tahap selanjutnya adalah menginformasikan pelanggan tentang teknologi.

• Pada proyek besar, kami, tanpa gagal, memiliki " Kursus kuliah dan seminar tentang pengenalan teknologi desain". Dalam kursus kuliah ini, kami menyampaikan kepada karyawan pelanggan bagaimana seluruh proses proyek akan berlangsung:
  • Bagaimana proyek dibuat menggunakan teknologi kami?
  • Siapa yang bertanggung jawab untuk apa?
  • Siapa yang melakukan apa?
  • Mengapa tindakan tertentu diambil?
  • Mengapa dokumen ini diperlukan? Apa yang dia berikan pada kedua belah pihak? (untuk memperjelas kepada karyawan bahwa kemitraan memberikan manfaat tidak hanya bagi kami, tetapi juga bagi pelanggan).
  • Di setiap kesempatan, kami Kami memberi tahu pembuat keputusan tentang semua masalah yang muncul dalam perjalanan kerja. Untuk melakukan ini, kami memiliki sejumlah dokumen harian khusus - misalnya, "Buku Harian Kontak" atau "Pernyataan Penyimpangan". Dan jika tidak setiap hari, tetapi setiap beberapa hari, manajemen pelanggan harus berkenalan dengan mereka. Dan karena, sebagai suatu peraturan, alasan segera ditemukan: saya sibuk, tidak membaca, dll., Maka, oleh karena itu, kita perlu terus-menerus mengingatkan tentang ini, bahkan mungkin mensimulasikan beberapa situasi yang memaksa manajemen untuk membaca dokumen-dokumen ini.

Hasil dari tahap ini adalah bahwa semua orang yang bertanggung jawab dari pelanggan telah menyelesaikan kursus kuliah dan, yang paling penting, bahwa manajemen memiliki gagasan yang jelas tentang bagaimana pekerjaan dilakukan (tentu saja, jika mengontrol proyek dengan cukup ketat).

Organisasi hubungan dengan Pelanggan

Tahap selanjutnya adalah pengorganisasian hubungan dengan Pelanggan. Di sini saya ingin memberi tahu Anda tentang satu "trik" yang menarik: kami memiliki peran seperti itu pada proyek (ini bukan posisi, tetapi peran) sebagai "Manajer Kontrak" dan "Manajer Objek" (paling sering mereka juga dapat digabungkan dan dengan beberapa tanggung jawab lainnya). Seperti yang ditunjukkan pada slide di sini, peran ini sesuai dengan definisi "buruk" dan "baik".

• Manajer kontrak buruk". Ini mungkin seorang individu atau salah satu manajer puncak. Paling sering, fungsi manajer kontrak dilakukan oleh manajer proyek (jika, tentu saja, ia mampu melakukan ini). Orang ini adalah "Tidak" - dia dapat datang ke pembuat keputusan dan berkata: "Ditulis seperti ini di bawah kontrak kami, tetapi sekarang Anda melakukannya secara berbeda, dan karena ini ada penyimpangan. Mari kita cari tahu." Dia selalu menunjukkan kekurangan, ketidakpatuhan dengan teknologi, mendesak untuk mematuhi dokumentasi Itu sebabnya dia selalu jahat.
• TETAPI manajer objek- yang ini bagus". Ini adalah orang yang, karena berbagai alasan, telah mengembangkan hubungan baik dengan pengambil keputusan dari pelanggan. Mungkin dia hanya kebetulan menyukainya. Atau, misalnya, mereka memiliki semacam ikatan (kerabat, klan, persahabatan - apa pun). Hal utama adalah bahwa klien berada di dekatnya.
  Objek manager sebenarnya memelihara objek ini. Harap dicatat bahwa ini bukan manajer proyek, ini adalah orang khusus yang melakukan apa menjaga hubungan baik dengan manajemen klien, dan ketika ada beberapa masalah akut, dia menghaluskannya.
  Misalnya, setelah manajer kontrak berbicara kepada klien tentang ketidakpatuhan terhadap beberapa persyaratan perjanjian kami (ini mungkin berakhir, secara umum, dengan semacam percakapan yang tidak menyenangkan bagi kami), manajer objek datang dan mulai menenangkan klien .
  Bukan tanpa alasan saya mengatakan bahwa objek manajer disebut "baik". Secara umum dikatakan bahwa menjadi "pria baik" bukanlah sebuah profesi. Tapi inilah profesi kami. Manajer objek adalah "orang baik". Dia mungkin bukan spesialis profesional dalam hal apa pun, tetapi klien merasa nyaman dengannya - dia datang, berbicara dengannya (mungkin tentang politik, sepak bola, dll.), dan klien merasa baik, sikapnya berubah. Sebelumnya, klien akan menegur kami untuk sesuatu, untuk menghukum kami untuk sesuatu, tetapi sekarang dia sudah mengerti segalanya, dia umumnya tidak nyaman berbicara buruk dengan kami.
  Ini adalah fungsi dari manajer objek. Itu ditugaskan untuk setiap klien yang cukup serius.

Tentu saja, semua yang saya bicarakan membutuhkan sumber daya dan biaya tertentu. Dan, tentu saja, tidak masuk akal untuk membuat semua struktur ini demi toko kecil - ini semua dilakukan hanya untuk objek yang cukup besar.

Hasil dari tahap ini adalah penunjukan kontrak dan manajer objek yang sesuai untuk klien ini, karena sangat penting untuk memilih orang-orang ini dengan benar.

Organisasi proses proyek

Tahap selanjutnya adalah organisasi proses proyek. Menurut saya, hanya ada dua di antaranya:

• Pemantauan kemajuan proyek;
• Dan pengambilan keputusan manajerial berdasarkan hasil pemantauan.

Yang paling penting adalah meyakinkan pelanggan untuk bekerja sesuai dengan teknologi kami. Prosedur ini dijelaskan kepada pelanggan baik dalam percakapan pribadi dengan pengambil keputusan dan ketika karyawan yang bertanggung jawab menghadiri kursus kuliah (ini menjelaskan bagaimana dan apa yang akan terjadi pada proyek - karyawan pelanggan harus menghadiri kursus ini tanpa gagal, di bawah tanda tangan).

Terkadang sangat sulit untuk meyakinkan pelanggan untuk bekerja dengan teknologi kami. Misalnya, kami memiliki satu klien - perusahaan IT yang sangat besar. Selain itu, dia sendiri terlibat dalam otomatisasi di MS Navision, tetapi karena alasan tertentu dia memutuskan untuk menghubungi kami sehingga kami dapat mengotomatiskannya di 1C. Jadi, bekerja dengan mereka adalah mimpi buruk yang nyata - semua orang menangis, baik manajer maupun programmer. Karena itu adalah perusahaan yang sangat besar (kami kecil dibandingkan dengan mereka), dan mereka pikir mereka tahu segalanya dan mencoba mengajari kami. Mereka terus-menerus berkata: "teman-teman, Anda tidak melakukan semuanya seperti itu, ada teknologi ini dan itu, Anda harus melakukannya dengan cara ini." Secara alami, ini hanya terjadi di tingkat menengah, kepala (yang merupakan pemilik utama dan direktur umum perusahaan), tentu saja, memahami semuanya dengan sempurna, dan setelah intervensinya semuanya diputuskan, tetapi sangat sulit untuk mendapatkannya. Dan di tingkat menengah ada masalah terus-menerus, upaya terus-menerus untuk mengajar.

Kami berada di setiap proyek, tanpa gagal, Kami mencoba menyampaikan kepada klien gagasan bahwa dalam bisnisnya dia adalah seorang profesional (dan kami, tentu saja, tidak pergi ke sana), dan dalam hal otomatisasi kami adalah profesional, jadi kami perlu percaya dan tidak mencoba memberi tahu kami apa yang harus dilakukan dan bagaimana melakukannya. Apalagi jika mereka tidak hanya memberi tahu kami, tetapi mencoba memaksa kami: "ayo lakukan dengan cara yang berbeda, karena saya mau." Ini adalah hal-hal yang kami coba hentikan sekarang. Tentu saja, "berhenti" adalah kata yang kuat, bagaimanapun, cobalah untuk menjelaskannya dengan cukup ringan. Jika kami menyetujui proyek ini, memutuskan bahwa itu cocok untuk kami, terlibat dalam "pertempuran" ini, sekarang, tentu saja, kami harus bekerja dengannya.

Batasan keinginan klien

Tahap selanjutnya adalah keterbatasan keinginan klien. Semua orang, mungkin, menghadapi ini (ketika apa yang disebut "Daftar Keinginan" dimulai - semakin banyak, semakin banyak). Di sini kita melakukannya dengan cukup sederhana:

• Misalnya, ketika klien mengatakan bahwa dalam anggaran dan tenggat waktu yang ditentukan, ini dan ini juga harus dilakukan, maka itu cukup sering dimulai, yang sulit menjelaskan bagaimana semuanya bekerja. Kami mengingatkan klien bahwa kami memiliki anggaran dengannya, orang-orang dialokasikan (kelompok kerja bersama), setiap sisi proyek menginvestasikan sumber dayanya. Karena itu, jika pekerjaan tambahan muncul, maka jam tambahan, orang tambahan diperlukan. Dari mana harus membawa mereka?
  Atau jika klien menunda proyek, maka kami dan orang-orangnya menganggur, dan mereka dibayar uang. Di mana mendapatkan sumber daya ini? Saya tidak berbicara tentang fakta bahwa orang-orang ini tidak hanya menerima gaji, tetapi juga membawa keuntungan bagi perusahaan. Tentu, perusahaan tidak ingin kehilangan keuntungan ini. Itu dijelaskan dengan cukup detail kepada klien, dan klien biasanya merespons dengan sangat baik.
• Kami menjelaskan kami memberikan tata letak digital terperinci- di mana, apa, ke sen. Dan kami mengatakan itu jika Anda ingin kami melakukan ini juga lalu tolong itu akan memakan waktu berjam-jam dan mereka harus dibayar. Pada akhirnya, klien setuju dengan kami dan menolak "Daftar Keinginan" atau membayar jam tambahan. Tentu saja, itu terjadi dengan cara yang berbeda - sekarang saya mengidealkan gambarnya sedikit.

Di sini saya ingin memberikan contoh lain tentang hubungan. Kami bekerja dengan satu perusahaan yang sangat besar (mereka sudah dalam tahap pemeliharaan), dan beberapa tugas untuk perbaikan muncul secara berkala di sana: misalnya, untuk membuat semacam laporan yang rumit atau yang lainnya. Jadi, kepala akuntan perusahaan mempercayakan kami dengan pekerjaan tertentu, dan kami melakukannya. Dan ketika tiba saatnya untuk membayar, dia berkata: "Secara umum, saya salah, kita tidak membutuhkan semua ini sama sekali." Tetapi pekerjaan itu selesai, oleh karena itu, perlu untuk membayar. Dan dia berkata: "Tidak, saya tidak akan membayar untuk ini, tetapi saya tidak dapat pergi ke presiden perusahaan dan mengatakan kepadanya bahwa saya bodoh dan memesan hal yang salah." Selain itu, perusahaan itu sangat besar, perusahaan minyak, hubungan baik dengannya dan dengan orang ini. Dan kami tidak bersikeras - dia tidak membayar, dia tidak membayar. Meskipun, karena ini, kami kehilangan jumlah uang yang cukup besar untuk kami saat itu (tahun 2004). Pada akhir tahun ada denominasi (manat Azerbaijan membuang angka nol). Dan untuk semua klien yang berada di layanan kami, kami melakukan perhitungan ulang ini dalam urutan kerja - tidak ada uang tambahan. Tetapi kepada akuntan ini (pada waktu itu secara harfiah kurang dari satu tahun telah berlalu sejak kejadian itu), kami mendekati dan berkata: “Ingat, Anda tidak membayar kami? Kami kemudian pergi menemui Anda. Sekarang, denominasi. Mari kita lakukan ini secara gratis?" Tidak ada pertanyaan yang diajukan - kami mengeluarkan faktur, dia membayar.

Mengapa saya memberikan contoh ini? Tentang pentingnya hubungan yang baik. Jika kami kemudian bangkit dan menuntut untuk membayar kami jumlah ini, maka kami akan memiliki risiko kehilangan klien yang baik. Jadi kami terus berhubungan dengannya.

Siapa yang bertanggung jawab untuk menjelaskan anggaran ini?:

• Ini dalam cara bisnis; dalam pekerjaan biasa bertunangan Manajer proyek- kepala kelompok kerja bersama, yang, pada kenyataannya, melaksanakan proyek.
• Jika dia gagal, maka dia terhubung manajer kontrak, yang menjelaskan dengan angka dan mengatakan bahwa ini adalah - pelanggaran kontrak, pelanggaran kesepakatan.
• Dalam kasus yang paling sulit menghubungkan manajer objek yang mencoba menjelaskan (sudah, tentu saja, tanpa kerangka kerja yang kaku) kepada pelanggan mengapa dia perlu membatasi keinginannya.

Biasanya, jika angka-angka ditulis dengan sangat rinci, maka tata letak ini dan penjelasannya sudah cukup.

Pengiriman karya

Pengiriman karya. Di sini, secara umum, biasanya tidak ada masalah besar, karena Tata cara serah terima pekerjaan sangat detail di kami relevan dokumen.

Namun pada tahap ini, unsur informalitas ( hubungan baik), tentu saja juga membuat hidup lebih mudah bagi kami dan pelanggan juga.

Tujuan dari tahap ini adalah untuk mencapai pengiriman pekerjaan yang sepenuhnya sesuai dengan aturan yang ditetapkan dalam dokumen terkait, yang merupakan lampiran dari kontrak yang ditandatangani oleh klien dan kami. Dengan demikian, seseorang selalu dapat menunjukkan bahwa ada aturan seperti itu.

Hubungan pasca-proyek

Dan akhirnya, hubungan pasca-proyek. Ini juga merupakan bagian yang sangat penting. Apa yang harus kita tuju di akhir proyek? Untuk kesimpulan dari kontrak layanan, tentu saja. Tapi ini tidak selalu terjadi. Karena ada konsep "hasil", dan ada konsep "hasil" - dan ini adalah hal yang sedikit berbeda.

Saya akan memberi Anda sebuah contoh. Kami memiliki proyek dengan satu perusahaan yang sangat serius, dan hasil dari proyek itu sangat brilian bagi kami - ini adalah salah satu kasus yang jarang terjadi ketika kami benar-benar memenuhi anggaran dan tenggat waktu, persis seperti yang direncanakan semula. Ini adalah hasilnya. Dan hasil dari proyek itu adalah perjanjian layanan tidak ditandatangani. Selain itu, pelanggan mengatakan bahwa dia tidak akan pernah bekerja dengan kami lagi. Inilah hasilnya. Dengan kata lain, hasilnya brilian, tetapi hasilnya sangat menyedihkan.

Kenapa ini terjadi? Karena tidak ada hubungan informal. Kami baru saja mengembangkan teknologi dokumentasi desain kami pada waktu itu, dan ini adalah klien di mana semua teknologi ini, dalam kejayaannya, didemonstrasikan. Dan ketika kami bertanya kepada pelanggan: "Yah, Anda tidak akan bekerja dengan kami - tetapi apakah ada klaim terhadap kami?" Dan kami diberitahu melalui gigi terkatup dengan kemarahan: “Itulah masalahnya, bahwa kami tidak dapat membuat klaim apa pun - apa pun yang Anda katakan, Anda memiliki selembar kertas untuk semuanya, dan kami tidak dapat melakukan apa pun. Kami tidak puas dengan ini, dan kami tidak akan bekerja dengan Anda lagi. Perusahaan lain dapat diminta untuk melakukan sesuatu tambahan, tetapi Anda menolak - ini adalah anggaran Anda, di sini Anda memilikinya sebagaimana mestinya, inilah tenggat waktunya. Minggir - dan Anda segera menunjukkan selembar kertas dengan tanda tangan kami.

Jadi hasilnya menyedihkan. Tetapi sekali lagi saya tekankan bahwa hasil seperti itu disebabkan oleh fakta bahwa tidak ada hubungan informal.

Artikel ini berdasarkan laporan yang dibacakan penulis pada IE Infostart Conference 2014 29-31 Oktober 2014.

Kami mengundang Anda ke konferensi baru.

Selamat tinggal! Hari ini saya ingin berbicara tentang cara klien berinteraksi dengan perusahaan outsourcing, dan juga menerima komentar dari Anda tentang bagaimana Anda berinteraksi dengan klien/pengembang perangkat lunak. Artikel ini ditulis berdasarkan pengalaman dan, sebagian besar, ditujukan untuk pelanggan perangkat lunak. Tujuannya adalah untuk menemukan "kemacetan" dalam hubungan antara pelanggan dan perusahaan yang menawarkan layanan pengembangan perangkat lunak.

Izinkan saya untuk memperkenalkan diri: Saya Yury Korkhov dan artikel ini adalah yang pertama di Habré saya. Lulus dari Universitas Teknik Nasional Belarusia (insinyur keamanan), Universitas Negeri Belarusia (manajer investasi). Pengalaman kerja - lebih dari 6 tahun di bidang TI di hampir semua posisi: webmaster, perancang tata letak, perancang web, programmer, manajer proyek dan pengembang UI paruh waktu, kepala departemen ... Secara total, selama ini, lebih dari 80 proyek telah diimplementasikan: dari situs kecil, game untuk ponsel hingga portal Internet besar ... Profil utama adalah pengelolaan pengembangan proyek di bidang TI. Dia bekerja di sisi pelanggan dan di sisi pengembang, baik di pasar Rusia maupun di luar negeri.

Latar belakang pembuatan postingan atau Terima Kasih Wargaming.

Melewati sejarah pembuatan postingan ini tentu tidak baik, karena. Saya sudah lama membaca habr, tapi tangan saya tidak sempat menulis artikel, tapi ini soal “kebetulan” dan sekarang artikel sudah siap.

Saya telah mengambil istirahat dari pekerjaan selama beberapa bulan sekarang, karena saya lelah outsourcing, saya memutuskan untuk menemukan makna hidup dan perlahan-lahan mempersiapkan proyek saya untuk diluncurkan, dan suatu hari telepon berdering. Seorang perekrut Wargaming (pendiri "tanchiki" dan, menurut saya, salah satu perusahaan terbaik di Minsk) menelepon saya dengan tawaran wawancara untuk lowongan Manajer Penjual (harus dikatakan di sini bahwa saya tidak mencari pekerjaan , dan, dilihat dari kekosongan mereka, saya tidak cocok dengan mereka). "Itu menarik!" - Saya berpikir dan memutuskan untuk menyelesaikan tugas tes, terutama karena itu cukup menarik bagi saya. Perekrut mengatakan bahwa mereka memiliki semua kondisi untuk pekerjaan yang menyenangkan, sehat (kebugaran, asuransi, dll.) dan dibayar dengan baik dan, paling tidak, saya membutuhkan waktu sekitar 3 jam untuk menyelesaikan tugas tes. Saya ragu ada orang yang bisa menyelesaikan seluruh tugas tes dalam waktu yang ditentukan, seperti bagi saya - totalnya butuh sekitar 6 jam.

Saya menyesal, umpan balik dari perusahaan dalam percakapan telepon dan diungkapkan dalam frasa kering "semuanya baik-baik saja, semua orang menyukainya" (Saya tidak ingat kata demi kata, tetapi intinya adalah ini) dan tanpa spesifik. Saya ragu bahwa saya dapat menunjukkan semua "kemacetan" utama; tidak baik untuk menyia-nyiakan pekerjaan, saya memutuskan untuk memposting jawaban untuk tugas tes (dengan sedikit perubahan, untuk kenyamanan) kepada publik dan saya akan berterima kasih kepada audiens habra untuk penambahan dan komentar yang sehat untuk artikel tersebut.

Skema interaksi antara pelanggan dan pengembang perangkat lunak dari pertemuan pertama hingga akhir hubungan.

1. Pengembang perangkat lunak mampu menyelesaikan proyek.
2. Sebelum itu, kontrak tidak ditandatangani dengan pengembang perangkat lunak dan tidak ada proyek.
3. TK-nya siap.
4. Ketentuan pembayaran diatur oleh kontrak.
5. Sistem manajemen proyek dan metodologi pengembangan perangkat lunak (XP, Scrum, Lean, Kanban, ScrumBut, dll.) digunakan.
6. Mengisi aplikasi dengan konten (jika perlu) dilakukan oleh klien.

Aspek kontrak antara vendor pengembangan perangkat lunak dan pelanggan menguntungkan bagi vendor untuk dihindari (menyederhanakan, menghapus kontrak sama sekali).

1. Tanggung jawab untuk memenuhi tenggat waktu terletak pada pengembang, dan jika tenggat waktu terlewatkan pada saat terakhir (yaitu pengembang tidak memberi tahu sebelumnya bahwa ia tidak punya waktu sebelum penutupan), hukuman harus dijatuhkan (ada banyak pilihan dari pilihan).
   Alasan: kegagalan untuk memenuhi tenggat waktu adalah salah satu masalah terbesar dan menyebutkannya dalam kontrak tidak terlalu menarik, karena. Untuk sebagian besar, kegagalan untuk memenuhi tenggat waktu terletak di pihak pengembang. Di sini perlu diperhitungkan bahwa sulit untuk menghitung dengan tepat, tetapi perlu untuk memperingatkan terlebih dahulu bahwa pengembang tidak punya waktu untuk menyelesaikan tahap pengembangan dalam jangka waktu tertentu dan ini harus ditentukan dalam kontrak. .
2. Kondisi jaminan untuk memperbaiki "bug" karena kesalahan pengembang yang tidak terdeteksi tepat waktu. Masa garansi yang biasa adalah 3 bulan.
   Alasan: sering terjadi bahwa beberapa "bug" belum diperbaiki atau sudah muncul dalam proses pengerjaan, sehingga item ini sering dicoba untuk tidak menunjukkan atau mengurangi waktu garansi. Menurut saya, kurang dari 3 bulan tidak cukup.
3. Hak untuk mengembangkan perangkat lunak, modul, blok, dll. milik pelanggan dan tidak dapat digunakan untuk penjualan kembali berikutnya.
   Alasan: Adalah menguntungkan bagi pengembang untuk memiliki hak kekayaan intelektual atau dapat menjual / menggunakan pengembangan untuk klien lain, yang pada gilirannya dapat menempatkan pelanggan dalam situasi yang tidak nyaman di pasar.
4. Saat mengembangkan modul baru dalam sistem yang memengaruhi pengoperasian modul lain atau seluruh sistem, pengembang harus memastikan berfungsinya seluruh sistem.
   Alasan: seringkali pengembangan satu modul dapat membahayakan pengoperasian modul lain atau keseluruhan sistem secara umum, dan perbaikan lebih lanjut dapat dibebankan pada "bahu" (secara finansial) klien. Pengembang berkewajiban untuk mempertimbangkan struktur seluruh sistem dan, dalam kasus "bug" yang ditemukan oleh klien, memperbaikinya secara gratis.
5. Dokumentasi teknis untuk pengembangan harus disiapkan dengan mempertimbangkan persyaratan pelanggan.
   Alasan: menguntungkan bagi pengembang untuk mengikat diri sepenuhnya dengan pelanggan dan sering terjadi dokumentasi tidak dipelihara.
6. Dalam hal mengembangkan situs web, kontraktor harus memperhitungkan optimasi SEO untuk situs, yaitu: deskripsi gambar, halaman…
   Alasan: menghemat waktu untuk "hal-hal kecil", yang, tergantung pada ketentuan kontrak, dapat menyebabkan kerugian finansial bagi pelanggan (pengembang perangkat lunak menghemat waktu / keuangan).
7. Pengujian sistem harus disediakan oleh pengembang sistem.
   Penerimaan oleh pelanggan atas modul yang sudah jadi tidak boleh berubah menjadi pengujian sistem, mis. pengembang berkewajiban untuk melakukan penghapusan "bug" yang diidentifikasi oleh klien dengan biaya sendiri. Ini diperlukan untuk memastikan pengujian kualitas produk oleh pengembang. Pada saat pengembang mengatakan "selesai" dan pengujian sisi klien dimulai, "bug" diperbaiki secara gratis.
8. Tanggung jawab untuk menghosting proyek di sisi pelanggan ditanggung oleh pengembang. Dalam hal ini, pelanggan berkewajiban untuk memastikan bahwa persyaratan teknis untuk situs terpenuhi.
   Alasan: menghosting proyek di sisi pelanggan terkadang dapat menyebabkan kesulitan tertentu, yang dapat menyebabkan "hatting", sehingga tanggung jawab untuk meng-hosting dan mengonfigurasi server harus berada di pihak pengembang perangkat lunak.
9. Jika pengembang perangkat lunak terpaksa menggunakan bantuan spesialis di luar timnya, ia berkewajiban untuk mengambil semua risiko terkait kebocoran, kehilangan data, atau kerusakan lain apa pun yang dapat disebabkan oleh karyawan luar karena tindakan atau kelambanannya.
   Alasan: kebetulan seorang pengembang bisa sakit, berhenti, dll. salah satu karyawan. Dalam hal ini, pelanggan harus diasuransikan.
10. Salinan cadangan proyek harus disediakan di pihak pengembang setidaknya sekali sehari. Setiap masalah dengan hilangnya data pada proyek harus diambil alih oleh pengembang.
    Alasan: di sini Anda perlu menunjukkan siapa yang bertanggung jawab atas keselamatan proyek jika terjadi kegagalan.
11. Pengembang harus melanjutkan dari popularitas menggunakan teknologi yang dia gunakan saat memilih.
    Alasan: mengikat teknologi mereka sendiri, yang akan memperumit hidup jika pelanggan pindah ke pengembang lain.

Cara-cara yang dikenal untuk melebih-lebihkan biaya pekerjaan outsourcing relatif terhadap kenyataan.Saya kira ada lebih banyak dari mereka.

• Estimasi dangkal dari biaya pengembangan proyek secara keseluruhan, tanpa membaginya menjadi beberapa tahap, yang dapat menyebabkan kelebihan biaya proyek 2x-3x.
• Kegagalan untuk memberikan laporan tentang pekerjaan yang dilakukan dalam periode yang ditentukan oleh kontrak atau ketidakmampuan untuk mengontrol kemajuan pengembangan oleh klien
• Pilihan teknologi yang salah dalam implementasi bagian teknis dapat secara signifikan meningkatkan biaya pengembangan.
• Kurangnya spesialis yang tepat dalam tim pengembangan, yang meningkatkan waktu dan biaya pengembangan.
• Biaya tetap untuk pengembangan proyek atau modul dan peningkatan biaya lebih lanjut untuk setiap hal kecil yang dipahami secara berbeda oleh kedua belah pihak.
• Penetapan biaya pengembangan proyek tetap - risiko yang lebih tinggi mengharuskannya untuk dimasukkan ke dalam biaya proyek.
• Saat mengembangkan desain, pembuatan prototipe tidak digunakan, dan pengembangan desain dilakukan berdasarkan TOR teks, yang pada akhirnya mengarah pada sejumlah besar perbaikan / koreksi dan, karenanya, peningkatan biaya proyek.
• Menambah / memperumit fungsionalitas. Anda bisa membuatnya lebih mudah - membuatnya lebih sulit.
• "Cantik" di mana mereka tidak diperlukan (Anda dapat mengatakan tentang admin. Bagian dari situs, jika Anda dapat menggunakan kerangka kerja css untuk penyesuaian cepat bagian admin - mereka mulai berkembang dari awal).

Pola hubungan 'pelanggan - vendor pengembangan perangkat lunak', yang menurut saya paling dekat dengan penggunaan praktis.

Banyak perusahaan outsourcing memilih untuk tidak memberikan akses ke sistem manajemen proyek mereka tanpa memberikan informasi rinci, saya pribadi percaya bahwa akses harus diberikan atas permintaan pelanggan. Klien bertanggung jawab atas implementasi proyek dan melihat kemajuan pengembangan secara real time adalah penting!
Juga, saya pikir mengembangkan perangkat lunak dengan mempertimbangkan perhitungan total biaya proyek adalah buang-buang uang dan saraf, pengembangan seperti itu biasanya mengarah pada situasi konflik.

1. Pembayaran untuk pekerjaan berdasarkan upah per jam untuk pekerjaan karyawan atau biaya rata-rata pekerjaan spesialis dari seluruh tim pengembangan. Evaluasi tahapan pembangunan sangat diperlukan. Mengapa menurut saya bentuk penetapan harga ini optimal:
   • Itu tidak memerlukan pendekatan yang sangat teliti dalam evaluasi proyek, yang hampir tidak mungkin untuk membuat 100% akurat. Jika penilaian dibuat secara tidak benar dan pengembang perangkat lunak mulai memahami hal ini, maka fungsi tersebut "dilanggar" sedapat mungkin, yang pada akhirnya akan memengaruhi kegunaan.
   • Meningkatkan saling pengertian antara pengembang perangkat lunak dan klien, sebagai tugas utama direduksi menjadi prinsip - "lakukan dengan efisien dan cepat", dan bukan "berinvestasi dalam anggaran yang ketat dan bagaimana itu akan bekerja dengan baik".
   • Klien, berdasarkan laporan harian tentang jam yang dihabiskan, dapat melihat berapa banyak waktu yang dihabiskan karyawan di berbagai blok selama pengembangan, yang memberikan pemahaman tentang kecepatan dan kualitas kerja karyawan pengembang perangkat lunak.
   • Interaksi antara pelanggan dan manajer proyek dilakukan selangsung mungkin, mis. saat menggunakan skype, telepon, dll.
2. Hanya laporan dan rencana 2 minggu yang harus dikirim melalui pos (untuk kontrol).
3. Klien menyediakan prototipe aplikasi atau dikembangkan oleh tim pengembangan perangkat lunak, jika perlu:
   • Menyederhanakan pemahaman tentang fungsi utama proyek.
   • Meningkatkan kecepatan keseluruhan pengembangan proyek.
   • Persyaratan yang jelas untuk fungsionalitas pelanggan dan pengembang.
   • Pemahaman yang jelas tentang kemana proyek akan dipindahkan.
4. Sistem manajemen proyek untuk melacak kemajuan proyek dan kemampuan untuk memantau proses, waktu pengembangan yang dihabiskan untuk setiap tugas secara terpisah. Sayangnya, pengembang jarang memberikan akses.
5. Sangat diharapkan bahwa seluruh proyek dilakukan oleh satu tim, yaitu. seharusnya tidak satu tahap dilakukan oleh satu perusahaan, yang lain oleh yang lain, dan seterusnya.
6. Pos pemeriksaan (“berjalan”) setiap 2 minggu adalah waktu optimal untuk mengontrol proyek.
7. Dalam pengembangan, preferensi diberikan pada kerangka kerja yang terkenal, juga untuk adaptasi yang lebih mudah dalam situasi apa pun ketika perlu untuk mentransfer proyek ke pengembang lain.
8. Pengujian kualitas di pihak pengembang adalah tanggung jawab langsung. Saat mentransfer proyek atau sebagian darinya ke klien, semuanya harus diperiksa secara menyeluruh.
9. Mendukung browser yang berbeda adalah tugas langsung dari pengembang

Kesimpulan: hal utama adalah untuk mematuhi kemitraan / hubungan saling menguntungkan dan saling percaya dengan pemahaman bahwa pengembang adalah orang yang sama dan memperumit hidup mereka memperumit hidup untuk diri sendiri! Setiap orang harus bertanggung jawab atas bagian pekerjaan mereka, klien harus bertanggung jawab untuk memberikan spesifikasi teknis yang jelas dan segera menanggapi pertanyaan yang muncul, tidak lupa membayar pekerjaan, dan pengembang - untuk kualitas, waktu, kecepatan. Idealnya, tentu saja, belum tercapai, tetapi kami berada di jalur yang benar.

saya suka

Dalam berbagai sumber literatur tentang penjualan, Anda dapat menemukan sejumlah tahapan penjualan yang berbeda. Setiap penulis mempertimbangkannya dari sudut pandangnya sendiri.

Saya mengusulkan untuk mempertimbangkan tahapan kunci dalam bekerja dengan Klien>:

Tahap 1 "Membuat kontak" atau "Membangun kontak"

Setiap penjualan dimulai dari tahap ini.

Tujuan dari tahap ini: memenangkan Klien dan menarik minatnya untuk kontak lebih lanjut.

Saat menjalin kontak dengan Klien, penting untuk menyapanya dan memperkenalkan dirinya.

"Selamat sore. Nama saya Mikhail, saya adalah manajer perusahaan "Windows Plus".

Sebelum memulai percakapan tentang kebutuhan Klien, disarankan untuk berbicara dengannya tentang topik abstrak (teknik "Bicara Ringan"), atau menawarkan teh, kopi, Anda dapat membuat pujian, atau menggunakan sejumlah teknik lain pada tahap membangun kontak.

“Apa yang Anda ketahui tentang perusahaan kami? Mengapa memilih kami? Apa yang Anda berencana untuk membeli?

Adalah penting bahwa manajer, dengan perilaku non-verbalnya, menunjukkan minat untuk berhubungan dengan Klien, keinginan untuk membantunya, niat baik. Perilaku nonverbal meliputi gerak tubuh terbuka, postur tubuh, senyum, kemiringan tubuh terhadap klien, pandangan terbuka.

Dimungkinkan untuk menentukan apakah kontak dengan Klien telah terjalin atau tidak oleh perilaku Klien. Jika dia bereaksi positif terhadap kata-kata manajer, merasa santai, mengajukan pertanyaan sendiri, kita dapat mengasumsikan bahwa kontak telah terjalin. Jika Klien tidak mempertahankan kontak mata dengan manajer, tegang, tidak menjawab pertanyaan atau menjawab dengan enggan, maka masuk akal untuk mencurahkan lebih banyak waktu ke tahap menjalin kontak.

Tahap 2 "Identifikasi kebutuhan"

Tujuan dari tahap ini: untuk menentukan kebutuhan Klien.

Semakin akurat manajer menentukan kebutuhan Klien, semakin efektif dia akan melakukan presentasi barang dan jasa, yang selanjutnya akan menghasilkan kesepakatan.

Saat mengidentifikasi kebutuhan, penting bagi seorang manajer untuk dapat mengajukan pertanyaan dan mendengarkan Klien.

Saat berinteraksi dengan Klien, penting agar dia berbicara lebih banyak, dan bukan manajer; untuk ini, manajer disarankan untuk mengatur lebih banyak pertanyaan-pertanyaan terbuka.

Jendela apa yang Anda rencanakan untuk dibeli? Di mana Anda akan mengubah jendela? Apa iklim di apartemen di musim dingin dan musim panas? Siapa lagi yang tinggal di apartemen? Atas dasar apa Anda memilih jendela?

Pertanyaan tertutup manajer memungkinkan untuk menentukan kebutuhan Klien.

“Apakah Anda sering membuat ventilasi ruangan? Apakah Anda memiliki hewan? Apakah nyaman bagi Anda jika pengukur kami tiba besok jam 9 pagi?

Pertanyaan alternatif menawarkan pelanggan pilihan pilihan.

“Apakah nyaman bagi Anda untuk meminta pengukur datang di pagi atau sore hari? Apakah kita berencana untuk menginstal windows baru minggu ini atau berikutnya?”

Selama seluruh pertemuan dengan Klien, sangat berguna untuk mendengarkannya dengan seksama, karena Klien sering berbicara secara terbuka tentang kebutuhan mereka sendiri. Jika beberapa kata Klien tidak jelas bagi manajer atau dia mendengarkannya, disarankan untuk mengajukan pertanyaan klarifikasi kepada Klien:

“Apakah saya mengerti dengan benar bahwa Anda membutuhkan jendela dengan insulasi suara yang ditingkatkan? Sejauh yang saya mengerti, Anda ingin satu selempang jendela diputar dan yang lainnya dimiringkan dan dibelokkan?”

Hal ini diinginkan untuk meringkas hasil antara setelah setiap masalah yang dibahas. Apalagi jika manajer membahas beberapa produk atau layanan dengan Klien.

“Jadi, kami sepakat bahwa kami akan mengukur besok, dan kami akan menginstal windows minggu depan pada hari Jumat. Jadi, Anda berencana untuk memasang dua jendela baru: di dapur, jendela dua daun dengan ikat pinggang yang bisa dimiringkan, dan di sebuah ruangan, jendela tiga daun, di mana dua ikat pinggang dimiringkan dan dibelokkan. salah satunya adalah "tuli".

Penting untuk secara akurat mengidentifikasi kebutuhan klien dan baru kemudian melakukan presentasi barang dan jasa.

Tahap 3 "Presentasi"

Target: menawarkan produk atau layanan yang paling sesuai dengan kebutuhan Klien.

Penyajian produk dan jasa berisi uraian tentang karakteristik barang dan jasa, manfaat dari penggunaannya oleh klien dan manfaat yang diterima konsumen.

Sangat berguna untuk memulai presentasi dengan manfaat utama Klien, yang mengikuti kebutuhan pembeli, yang diidentifikasi oleh manajer pada tahap sebelumnya.

Penting untuk membedakan bagaimana manfaat suatu produk atau layanan berbeda dari manfaat.

Keuntungan adalah manfaat yang diterima setiap Pelanggan dengan menggunakan produk atau layanan ini.

"Dengan layanan ini, Anda dapat menghemat waktu dan memangkas biaya sebesar 10%." "Fitting ini memungkinkan Anda untuk mengurangi jumlah penyesuaian."

Keuntungan adalah karakteristik atau keunggulan yang memungkinkan Anda memenuhi kebutuhan spesifik Klien.

Dengan demikian, karakteristik atau keuntungan apa pun dapat menjadi manfaat, asalkan Klien membutuhkannya.

"Anda ingin jendela mudah dibuka dan ditutup, perlengkapan berkualitas Eropa dapat menyediakannya." "Anda mengatakan bahwa apartemen itu terletak di lantai pertama dan Anda takut akan keamanan apartemen, saya sarankan Anda memasang perlengkapan anti-pencurian di jendela baru."

Selama presentasi, manajer perlu menyertakan Klien dalam dialog aktif menggunakan pertanyaan.

“Bagaimana perasaan Anda tentang proposal saya?”, “Apa pendapat Anda tentang ini?”, “Bagaimana Anda menyukai proposal saya?”

Tahap 4 "Bekerja dengan keberatan"

Target: untuk menghilangkan keraguan Pelanggan tentang pembelian dan menghilangkan negatif terkait dengan produk atau layanan.

Untuk mengurangi jumlah keberatan dari Klien, akan berguna bagi manajer untuk mencurahkan lebih banyak waktu ke tahap sebelumnya. Seringkali keberatan Klien terkait dengan fakta bahwa kontak dengannya tidak terjalin dengan baik, kebutuhannya diidentifikasi sebagian, atau penyajian barang dan jasa tidak menarik bagi Klien, terlalu lama dan tidak memenuhi kebutuhannya.

Penting untuk memahami keberatan Klien sebagai sinyal bahwa manajer perlu memperbaiki perilakunya (terutama jika ada banyak keberatan).

Keberatan dari Klien juga dapat muncul pada tahap penjualan sebelumnya. Bagaimana cara mengatasi keberatan yang muncul?

Secara efektif mematuhi skema penanganan keberatan:

1. mendengarkan Klien;

2. menetralisir emosinya dengan menggunakan ungkapan pemahaman;

"Saya mengerti Anda", "Ya, saya setuju bahwa itu tidak menyenangkan ..."

3. mengklarifikasi, jika perlu, informasi dengan menggunakan pertanyaan;

4. menawarkan solusi yang konstruktif atau membuat proposal alternatif.

Ada 4 jenis keberatan pelanggan:

1. keberatan terkait perubahan.

"Mengapa saya membutuhkan ini", "Saya tidak melihat intinya dalam hal ini"

Dalam menghadapi keberatan seperti itu, manajer harus menjelaskan kepada Klien bahwa risiko dikecualikan, menunjukkan konsekuensi jika situasi berlanjut, memberikan contoh pengalaman positif dalam menggunakan sesuatu untuk pertama kalinya.

"Dengan membeli jendela dengan perlengkapan Eropa, Anda dijamin terlindung dari angin, penyesuaian tambahan tekanan selempang, kemacetan mekanisme penutupan."

2. keberatan terkait harga.

"Itu terlalu mahal untukku".

Dalam argumentasi, manajer harus memperhatikan manfaat tambahan yang diterima Klien, Anda dapat membandingkan biaya barang dengan biaya hal lain yang tidak terlalu diperlukan atau membagi biaya dengan jangka waktu tertentu.

“Ketika Anda membeli jendela dari perusahaan kami, Anda mendapatkan kit perawatan jendela sebagai hadiah, serta kesempatan untuk menggunakan penyesuaian perlengkapan gratis”, “Jendela baru yang indah di dapur hanya akan dikenakan biaya 300 rubel. dalam sehari".

3. keberatan terkait dengan pengalaman negatif.

"Kudengar profilmu buruk."

Hal ini berguna bagi manajer untuk mengklarifikasi informasi dengan mengajukan pertanyaan kepada Klien, untuk menunjukkan kepada Klien bahwa Anda memahaminya dan mengakui fakta-fakta dari peristiwa yang tidak menyenangkan (jika memang benar terjadi) dan kemudian menawarkan solusi alternatif.

“Ya memang, kami memiliki sejumlah profil yang rusak, yang kami kembalikan ke pemasok. Saat ini, kami telah menerima batch baru, telah memproduksi dan menginstal lebih dari 30 jendela, semua Klien puas. ”

4. keberatan terkait keputusan tersebut.

“Saya perlu berpikir”, “Saya perlu berkonsultasi dengan istri saya.”

Dalam menghadapi keberatan tersebut, manajer dapat sekali lagi mengklarifikasi apa hubungannya dengan keputusan tersebut, memastikan bahwa klien telah menerima dan memahami semua informasi, dan juga menggunakan metode untuk menyelesaikan transaksi.

"Jika kami menandatangani perjanjian dengan Anda sekarang, maka pada akhir minggu Anda akan dapat mengagumi jendela baru di dapur." "Hanya sampai akhir bulan kami ada diskon untuk produk ini."

Tahap 5 "Penyelesaian transaksi"

Target: mendorong Klien ke transaksi dan mengkonfirmasi kebenaran keputusan yang dibuat olehnya.

Sebelum menyelesaikan kesepakatan (menandatangani kontrak), manajer perlu memastikan bahwa Klien siap untuk membuat kesepakatan.

Hal ini dapat dilihat dari sinyal yang ditunjukkannya:

• umpan balik positif tentang produk atau layanan;
• Klien menyatakan persetujuan atas kata-kata manajer (menyetujui, menganggukkan kepala, dll.);
• langsung mengatakan bahwa dia setuju;
• mengajukan pertanyaan klarifikasi.

Metode penyelesaian transaksi:

1. metode pembatasan kondisi dan waktu.

"Jika Anda menandatangani kontrak hari ini, kami memberi Anda diskon jendela 20%."

2. metode pujian.

"Kamu benar-benar membuat pilihan yang tepat."

3. alternatif menang-menang.

"Apakah Anda akan dipesan untuk pengukuran pada hari Selasa atau Rabu?"

Sebagai kesimpulan, saya ingin mengatakan bahwa efektivitas penjualan tergantung pada keterampilan manajer. Semakin banyak metode dan teknik penjualan yang dimiliki seorang manajer, semakin fleksibel dan sukses dia saat berinteraksi dengan Klien. Profesi manajer penjualan membutuhkan pengembangan keterampilan dan peningkatan diri yang konstan. Kami berharap Anda sukses di jalur pertumbuhan profesional dan peningkatan penjualan.