Dalam hidup saya, saya melihat dua jenis bisnis yang berkembang lebih buruk daripada orang lain - franchisee 1C dan penjual pohon Natal. Ini bukan tentang luasnya pembangunan, ketika hanya jumlah programmer tumbuh, tetapi tentang pengembangan internal. Tentang efektivitas, singkatnya.
Meskipun, mungkin, penjual pohon Natal dapat dikecualikan dari daftar ini, mereka berhasil mengejutkan saya sebelum Tahun Baru dengan menjual saya pohon cemara yang nyata. Sebelumnya, hanya pohon cemara dan cemara saja. Saya bahkan melihat di internet bagaimana membedakan pohon dari pohon cemara - sungguh, itu pohon cemara.
Jadi, hanya franchisee 1C yang tetap dalam daftar "Perusahaan Paling Berkembang". Banyak orang hebat bekerja di sana, tetapi lingkungannya seperti ini, atau tempat itu terkutuk - ada yang salah dengan mereka.
Mereka hanya memikirkan hari ini. Mungkin ikatan yang erat dengan satu vendor, yang mengembangkan kerangka kerja dan solusi aplikasi, yang harus disalahkan. Pada abad ke-21, tidak ada orang yang waras yang akan membangun bisnis jangka panjang terkait dengan satu bahasa pemrograman, satu lingkungan pengembangan, satu pasar? Tapi tempa seterika selagi panas - tolong. Ketika dingin, maka akan mungkin untuk memikirkan sesuatu yang serius.
Tetapi untuk beberapa alasan, menurut saya tidak semuanya hilang. Anda bisa melakukan yang lebih baik.
Berbagai metode peningkatan efisiensi tentu saja menarik. Tetapi kombinasi yang jauh lebih menarik dari metode-metode ini untuk kegiatan tertentu adalah kasus. Ini mencakup proses, motivasi, otomatisasi, tujuan, dan sistem manajemen. Tidak selalu semua komponen sekaligus - hanya apa yang Anda butuhkan.
Mari kita coba membuat case untuk bagian spesifik dari bisnis yang kita kenal - 1C: Franchisee. Dia akrab bagi kita karena dia memiliki pengalaman bekerja di waralaba lain selama beberapa tahun, ditambah - kita terus-menerus bertemu franc dalam pengaturan formal dan informal.
Kami akan merumuskan kasus berdasarkan pengalaman kumulatif - hampir semua yang kami tulis telah diuji pada diri kami sendiri. Kami tidak meyakinkan siapa pun tentang apa pun, murni kepentingan akademis. Meskipun, ada waralaba besar yang membawa kasus ini ke dalam layanan, dan mereka sendiri memperkenalkan sesuatu di sana.
Jika Anda tidak tahu apa itu 1C: Franchisee, maka baca seolah-olah kita berbicara tentang perusahaan tertentu yang menyediakan layanan untuk pengembangan, pemeliharaan, dan penyempurnaan perangkat lunak.Tujuan dari kasus ini sederhana - untuk meningkatkan produksi programmer dan, jika memungkinkan, pendapatan. Atau knalpot, ia punya opsi berbeda. Ayo pergi. Saya peringatkan Anda - Longrid.
Situasi awal
Ambil bukan seluruh waralaba, tetapi bagian dari itu, yang akan kita sebut departemen pengembangan. Ini adalah orang-orang, programmer 1C yang duduk di kantor, menerima tugas melalui sistem atau dari konsultan, memutuskan apakah mereka menyerahkan hasilnya kepada konsultan atau klien, dari jarak jauh.
Ada beberapa departemen dalam waralaba jaringan besar, ada persaingan di antara mereka, dan ketika mereka tidak memiliki sumber daya yang cukup, mereka secara aktif bertukar spesialis dan tugas. Mungkin bukan atas kehendaknya sendiri, tetapi ini bukan intinya - kita melihat departemen pengembangan sebagai unit bisnis, dan bukan sebagai sekelompok "programmer nyata".
Katakanlah departemen pengembangan kami terdiri dari lima orang. Total output bulanan rata-rata adalah 500 jam. Dari jumlah tersebut, 200 ditutup oleh Champion tertentu - pembuat kode yang paling berpengalaman dan cerdas. 100 jam menutup Yang Kedua, 80 - Yang Ketiga dan Keempat, 40 - Pemula.
Katakanlah satu jam kerja untuk klien berharga 2.000 rubel. Katakanlah kita memiliki laju internal tunggal untuk programmer - 500 rubel per jam. Perkiraan sederhana mengatakan bahwa pendapatan departemen adalah 1 juta rubel per bulan, gaji departemen hanya 25% dari pendapatan, dalam hal ini 250 ribu rubel. Total, perusahaan menerima 750 ribu rubel, yang membayar pajak pada programmer yang sama, baik, dan semua biaya lainnya. Kami tidak akan mempertimbangkan struktur laba, kami hanya mengerti bahwa itu non-linear, karena mengandung biaya tetap, seperti menyewa kantor dan membeli cookie.
Pengembangannya, misalnya, relatif stabil, tidak melonjak banyak. Kecuali, ketika sang Champion pergi berlibur, kita memiliki kegagalan 40 persen.Kadang-kadang itu terjadi dan 700 jam - ketika sebuah proyek bagus terjadi, dan para programmer bekerja pada akhir pekan.
Tujuan kasus
Segera saya akan memberi tahu Anda tujuan menggunakan kasing ini agar tidak menciptakan misteri. Kami ingin departemen pengembangan kami memberikan bukan 500, tetapi 1000 jam per bulan, yaitu dua kali lebih banyak. Untuk tarif per jam yang sama, dengan biaya tetap yang sama, dengan jumlah jam kerja yang sama. Kami dapat memberikan sedikit biaya waktu untuk proyek ini - misalnya, dalam 30-50 tr.
Penting untuk segera memutuskan apa yang akan kita lakukan dalam situasi target. Di satu sisi, kami menjual waktu spesialis - jam yang mereka habiskan untuk menyelesaikan masalah. Di sisi lain, kami menjual tugas yang diselesaikan, mengevaluasinya dalam hitungan jam. Semuanya tampak jelas, tetapi perbedaan antara kedua sistem peringkat cukup signifikan.
Katakanlah 500 jam per bulan adalah 500 jam kerja nyata untuk spesialis. Selama 500 jam ini, mereka memecahkan, katakanlah, 200 masalah, dengan banderol harga rata-rata 2,5 jam. Ternyata setiap tugas berharga rata-rata 5.000 rubel. Klien cukup siap untuk membayar uang sebanyak itu, dia tahu pasar, sisa waralaba memiliki harga yang sama.
Jadi kami belajar memecahkan masalah bukan dalam 2,5 jam, tetapi dalam 1,25 jam.
Pertanyaan kuncinya adalah berapa banyak yang bisa dijual kepada klien?Jika kami menjual waktu, adalah logis untuk menjual selama 1,25 jam. Klien akan sangat senang - lebih murah dan lebih cepat. Tetapi bagi kami, sebagai sebuah bisnis, hampir tidak ada manfaat dari skema semacam itu - hanya klien yang puas dan waktu luang para spesialis yang perlu mengambil sesuatu. Misalkan kami menemukan lebih banyak pelanggan, dan kami juga menjual tugas kepada mereka selama 1,25 jam. Alhasil, dalam sebulan, apa yang akan kita dapatkan? 500 jam yang sama untuk 2000 rubel. Tidak masuk akal.
Salah satu opsi adalah menaikkan tarif per jam. Tetapi kita memecahkan masalah lebih cepat dari pesaing? Pada pekerjaan kecil, tidak ada yang akan memperhatikan hal ini, tetapi pada tugas di 40 jam perbedaannya sudah akan terlihat.
Tetapi harga satu jam adalah perubahan nyata bagi dunia luar yang dapat membuat pelanggan baru dari kami putus asa. Mereka tidak tahu apa yang kita lakukan dua kali lebih cepat? Slogan-slogan yang ditulis di situs tidak terlalu meyakinkan.
Tampaknya lebih tepat untuk terus menjual tugas selama 2,5 jam. Klien tidak melihat apa-apa, dan kami mendapatkan hasil target yang normal - melakukan dua kali lebih banyak tugas, kami mendapatkan dua kali lebih banyak uang.
Anda dapat memilih opsi kompromi - untuk menjual, misalnya, dalam 2 jam. Kemudian klien melihat penghematan nyata (terutama pada volume besar), mendapatkan hasilnya lebih cepat, dan kita berada dalam kegelapan. Terlebih lagi, bahkan dengan pelestarian laju internal programmer.
Untuk kesederhanaan, kami akan mempertimbangkan opsi ketika kami terus menjual selama 2,5 jam. Kami mengevaluasi tugas yang masuk menggunakan algoritme yang sedikit lebih rumit - kami perlu memperkirakan waktu sebenarnya, dan mengalikannya dengan 2. Tetapi lebih banyak tentang itu nanti.
Ya, masih ada opsi eksotis untuk menggunakan waktu bebas, misalnya, memperkuat pengembangan internal. Ini akan menjadi akhir.
Nah, itu saja, tujuannya jelas, sekarang mari kita beralih ke analisis perubahan yang diperlukan.
Masalah utama
Mereka mengatakan bahwa selalu ada titik penerapan kekuatan di mana Anda perlu memasukkan tuas dan mendapatkan efek maksimal. Saya tidak setuju dengan ini - dalam arti bahwa hal seperti itu selalu ada. Tetapi dalam hal ini - sistem motivasi.
Sistem motivasi kami adalah tingkat individu, per jam untuk pekerjaan yang dilakukan.
Ada banyak keuntungan bagi programmer di dalamnya, sedikit untuk bisnis, tetapi ada banyak kekurangan.
Spesialis sama sekali tidak punya alasan untuk berbagi pengetahuan dan pengalamannya. Satu-satunya hal yang layak dilakukan adalah meningkatkan profil Anda. Jika semuanya sesuai dengan kepentingannya, maka itu kontraindikasi untuk berbagi pengalaman, dan bahkan lebih banyak lagi untuk membantu dalam memecahkan masalah. Jika Anda mengajar orang bodoh, ia akan menjadi pesaing Anda, dan dia bahkan tidak akan berterima kasih.
Jika Anda tahu benar, misalnya, gaji (ini adalah program semacam itu), sementara yang lain tidak tahu, Anda akan selalu memiliki roti dan mentega. Segera setelah gaji kedua muncul, Anda harus melakukan upaya untuk mendapatkan berita paling banyak dari pekerjaan.
Apa ini untuk bisnis? Jika spesialis tidak berbagi kompetensi, maka perhatian pelatihan jatuh di pundak perusahaan. Penting untuk menyelenggarakan kursus, atau membayar ke organisasi pihak ketiga (seperti 1C). Yang kedua adalah kemacetan dalam bentuk spesialis kunci. Jika dari 5 orang hanya satu yang mengetahui ERP (ini juga merupakan program seperti itu), maka Anda secara fisik tidak dapat mengambil lebih banyak pekerjaan ERP daripada yang dapat dicerna oleh karyawan ini. Bahkan jika itu adalah Juara, tidak akan ada lebih dari 200 jam per bulan. Baik, ambil risiko - ambil pekerjaan untuk mencari tahu nanti, di sepanjang jalan.
Sangat tidak mungkin membuat kompetensi berbagi. Visibilitas dapat dilakukan. Tapi, yang tadinya seorang programmer, dia tahu bahwa ada cara untuk memberikan bantuan sehingga Anda tidak akan lagi dihubungi untuk itu. Anda bahkan dapat memaksa sang Juara untuk mengadakan seminar atau pelatihan. Dia akan dengan jujur melaporkan materi - materi yang sangat mudah diakses di Internet. Dia akan meninggalkan pengetahuan yang nyata dan praktis untuk dirinya sendiri.
Nilai per jam individu seperti bisnis di dalam bisnis, dan "bisnis internal" ini selalu merupakan IP, bukan LLC.
Dan kompetensi itu penting, terutama di era perubahan yang terjadi secara berkala. Tentu saja ada jeda dalam beberapa tahun - misalnya, sebelum rilis ERP, ketika semua orang sudah tahu soft starter (ini juga sebuah program, tua tapi segar). Tetapi pada 2004-2010, misalnya, "insinyur proyek" yang memiliki pengetahuan tentang SCP adalah yang terbaik dari semuanya. Sekarang, mungkin, pakar ERP hidup lebih baik daripada orang lain - saya tidak tahu pasti.
Pekerjaan individu membunuh kemampuan untuk berbagi solusi kerja dan praktik terbaik, karena, sekali lagi, ini tidak masuk akal. Nah, Anda memberi orang Anda pemrosesan atau subsistem, ia menutup 40 jam setuju dengan klien dalam sehari, mengangkat 20 tr. Ada apa dengan itu? Anda dapat, tentu saja, mencapai kesepakatan dan menciptakan pasar gelap di dalam departemen, tetapi tidak masuk akal. Lebih mudah untuk mengatakan, "beri aku tugas, aku akan menyelesaikannya." Dalam situasi tanpa harapan, tentu saja, ia akan memberi, tetapi sebaliknya, ia akan menyerahkannya kepada dirinya sendiri, di luar prinsip.
Anda dapat melihat kompetensi secara berbeda: siapa pemiliknya? Katakanlah Juara Anda telah bersama perusahaan sejak 2010. Dia melakukan banyak pekerjaan pada ERP, memperoleh kompetensi. Mereka milik siapa?
Perusahaan akan mengatakan - mereka milik kita. Pelanggan kami, proyek kami, tugas kami. Berikan kompetensi. Bagaimana cara mengambilnya? Jangan tarik kutu? Ini bukan aset material. Dia ketakutan, dan kompetensi menangis.
Dan apa itu kompetensi? Produk. Atau tidak, penghasilan dari penjualan produk. Dikirim 200 jam oleh ERP, menerima dua keuntungan - 400 tr dan kompetensi. Uang - tentu saja, ini dia, pada akun saat ini. Anda dapat mentransfer, membelanjakan, berinvestasi. Di mana kompetensinya? Di kepala botak itu. Apa yang bisa dilakukan dengan mereka? Bahkan - tidak ada.
Ternyata pria itu belajar dengan biaya kami. Bukan berarti kami menginvestasikan uang dalam pelatihannya - tidak, itu baru saja terjadi. Tetapi kita bisa mendapatkan keuntungan ini hanya dengan satu cara - untuk terus mengeksploitasi kompetensi ini, mis. pada semua pekerjaan ERP biarkan saja. Baik, atau ambil peluang dan letakkan seorang pemula untuk mendapatkan sumber daya lain yang tidak dapat dipulihkan.
Alasan dari keadaan ini adalah basi - sistem motivasi yang salah. Bukannya itu tidak mendorong - itu langsung melarang seseorang untuk berbagi kompetensi.
Sistem motivasi - untuk apa ini? Sehingga seseorang itu sendiri, atas kehendaknya sendiri, dan dengan segala semangat, melakukan apa yang bermanfaat bagi perusahaan. Sistem motivasi harus menggantikan pemimpin yang berjalan, menendang, dan mencoba menunjukkan sesuatu setiap hari.
Bagaimana memastikan bahwa seseorang, atas kehendaknya sendiri, melakukan apa yang bermanfaat bagi perusahaan? Ya, pertama, tentu saja, untuk memahami apa yang bermanfaat bagi perusahaan. Kedua, memastikan bahwa manfaat perusahaan bermanfaat bagi orang tersebut. Bukan dalam bentuk misi dan slogan, tetapi nyata.
Kasing
Untuk kasus ini, saya memilih metode yang, dalam pikiran dan pengalaman saya, paling cocok untuk mencapai tujuan - menggandakan hasil. Secara umum, ada lebih banyak metode, tetapi di sini kita tidak terlibat dalam menulis, tetapi dalam perbuatan. Juga, perlu dicatat bahwa untuk menggandakan output tidak perlu menerapkan semua metode - seringkali hanya satu saja sudah cukup.
Perbedaan dalam kondisi awal perusahaan tertentu, yang saya tidak tahu apa-apa. Mungkin ada waralaba paling tolol di dunia, yang memiliki output terendah per karyawan. Anda bukan dari waralaba ini, jadi metrik Anda lebih tinggi. Tapi seberapa jauh lebih tinggi - saya tidak tahu. Tetapi fakta bahwa Anda dapat menggandakan output adalah fakta.
Jadi apa yang perlu Anda lakukan
dengan :
- Pilih, otomatisasi, dan tambahkan saldo awal ke sistem peringkat;
- Mengotomatiskan dan menambahkan saldo awal ke sistem kompetensi;
- Buat keputusan tentang sistem motivasi, otomatisasi;
- Pilih parameter strategi kompetensi;
- Tunjuk petugas jaga;
- Bicaralah dengan programmer.
Untuk melakukan:
- Diskusi umum tentang tugas yang masuk;
- Pemilihan pelaksana berdasarkan kompetensi sesuai dengan strategi;
- Manajemen dan akuntansi bantuan timbal balik;
- Kelola status tugas.
Sekarang saya akan menjelaskan secara singkat setiap item. Tetapi pertama-tama, penjelasan tentang otomatisasi.
Otomasi
Poin yang ada di hampir semua variasi casing adalah otomatisasi. Semua perubahan yang akan Anda lakukan pada proses, manajemen, dan motivasi, Anda perlu mengotomatisasi dengan cepat.
"Automate fast" sangat cepat, mis. siang hari (termasuk menunggu kesempatan untuk memperbarui konfigurasi basis data). Dari sini, kebutuhan segera muncul untuk melakukan otomatisasi ini oleh kekuatan dari tim yang sama, yang perkembangannya Anda semakin meningkat. Jika Anda adalah waralaba besar, dan Anda memiliki departemen lain yang tidak tunduk pada otomasi internal Anda, maka Anda tidak terlalu beruntung, tetapi ada solusi - otomatisasi rahasia.
Untuk semua yang ada dalam case ini, konfigurasi yang dijelaskan sendiri pada lutut sudah cukup. Kemudian, suatu hari, Anda akan memperbaikinya, membangunnya ke dalam sistem perusahaan Anda, membuat antarmuka yang ergonomis, dll. Sekarang kita membutuhkan data yang hampir kosong, tanpa kecantikan dan kenyamanan. Karena itu, jika Anda tidak memiliki akses untuk menyelesaikan sistem bersama, buat sendiri dan bagikan dalam tim.
Jika sistem manajemen tugas Anda tidak pada 1C, maka, sayangnya, Anda tidak beruntung - kemungkinan besar Anda harus membuangnya. Atau gunakan sebagai proksi untuk 1Snoy, jika klien terjebak di dalamnya - biarkan mereka mengemudikan tugas di sana, tetapi untuk sekarang, jadikan diri Anda sebuah sistem sendiri, pada 1C, dan unggah data ke dalamnya. Kalau tidak, tidak ada yang akan berhasil - para pengembang bitrix24, JIRA, Github dan sistem lainnya, saya minta maaf, mereka ingin peduli pada kebutuhan Anda. Jika ditambahkan. Anda masih dapat menambahkan properti ke tugas di sana, maka bagian tabular tidak mungkin, dan terlebih lagi laporannya.
Untuk mengotomatiskan kerja tim internal yang duduk bersebelahan, platform terbaik, sayangnya, adalah 1C.
Sistem penilaian
Kita membutuhkan sistem penilaian baru - tugas yang sekarang kita lakukan dalam 2,5 jam, kita harus lakukan dalam 1,25 jam, dan jual dalam 2,5 jam. Ternyata tugas di negara target kami akan memiliki dua peringkat - 2,5 dan 1,25 jam. Salah satunya adalah investasi waktu yang nyata, yang lain adalah penilaian tertentu untuk klien. Sekarang, dalam kondisi saat ini, kami percaya bahwa estimasi ini sama (rata-rata).
Saya pribadi tidak suka menyimpan dua peringkat dalam satu unit (jam). Saya tidak bisa berhenti bertanya-tanya bagaimana orang bisa menyukainya sama sekali. Pada kenyataannya, ada lebih banyak peringkat: jam untuk klien, jam yang dipanggil oleh programmer selama perencanaan, jam itu aktual. Lalu bagaimana menyatukan semuanya, entah bagaimana menganalisisnya - iblis mengenalnya.
Saya merekomendasikan sistem dari Scrum - perencanaan poker. Setiap tugas dievaluasi dalam poin yang diambil dari seri Fibonacci - 1, 2, 3, 5, 8, 13, 21, 34, dll. Penilaian mencerminkan visi komprehensif Anda dari tugas ini - kompleksitas pelaksanaan, dan biaya tenaga kerja, dan ketidakpastian, dan sifat bermasalah dari klien dalam pengiriman pekerjaan.
Cara termudah untuk memulai dengan "jangkar" adalah menentukan bahwa ada tugas 1 poin. Ini adalah tugas atom paling sederhana yang Anda selesaikan. Dengan demikian, tugas 2 poin adalah dua kali lebih sulit.
Perkiraan dibuat saat memproses aliran masuk, mis. saat tugas baru muncul. Setiap anggota tim memberi tanda, pada akhirnya kami memiliki - 5 nilai (untuk contoh yang dijelaskan oleh kami). Jika ada perkiraan yang berbeda dengan lebih dari satu elemen dari seri ini, maka kita perlu berbicara dan memahami mengapa ada perbedaan yang sangat besar, dan untuk menghilangkannya, salah satu terlalu tinggi atau yang lain terlalu rendah. Ketika semua ketidaksepakatan diselesaikan, rata-rata dianggap (jumlah peringkat dibagi dengan jumlah peringkat) - itu akan menjadi penilaian masalah.
Jika Anda memperkenalkan sistem "dari atas", maka sangat mungkin untuk tidak mengatur pemilihan, tetapi untuk menentukan peringkat sendiri. Kami tidak memiliki Scrum, kami menulis aturan sendiri.
Jika dalam proses penyelesaian masalah menjadi jelas bahwa perkiraan tersebut diremehkan atau diperkirakan terlalu tinggi, maka Anda dapat dengan aman mengubahnya. Tentu saja, pada saat tugas ditutup, nilai akhir harus diketahui.
Penilaian harus dimasukkan ke dalam sistem, dan disimpan dalam bentuk tugas alat peraga.
Jika Anda tidak suka poinnya, maka Anda bisa menggunakan semacam jam standar. Saya tidak merekomendasikan opsi ini, tetapi pendapat saya dapat diabaikan. Sebagai contoh, pada awal praktik, saya datang dengan penilaian seperti "untuk yang terbaik" - berapa jam yang akan dihabiskan oleh programmer terbaik untuk mengetahui tentang masalah, konteks, klien, fungsi, dll. ... Semua yang dibutuhkan "terbaik" seperti itu - tulis kode.
Sekarang sangat penting untuk memasukkan saldo awal - untuk mengevaluasi tugas selama 1-2 bulan yang telah Anda selesaikan, dan untuk membuat perkiraan dalam sistem. Pertama, latih dan kembangkan sistem penilaian Anda sendiri. Kedua, dan yang paling penting - dapatkan kecepatan saat ini dan "harga titik".
Sebagai contoh, ternyata Anda menjual 500 jam sebulan untuk 2.000 rubel, dan ini adalah 500 poin. Maka skor Anda saat ini adalah 2000 rubel. Setelah memperkenalkan perubahan, Anda harus menghasilkan 1000 poin, menjualnya untuk 2.000 rubel dan menerima pendapatan dua kali lebih banyak (baik perusahaan dan karyawan).
Sisa-sisa makanan awal sangat penting, karena tanpa mereka Anda tidak akan menjawab pertanyaan dasar - apakah itu berhasil atau tidak? Tolong, jangan malas.
Akan menggoda untuk tidak mengevaluasi tugas lama, tetapi untuk memulai dengan yang baru. , , , . – .
«», – .
, . , , ( ).
– . . , . , , .
– . – « » « », , .
– . – . , , , . – , . , , , , .. , .
, – . , . – , . , 10 . , , 100 %.
. . . . , , , .
« », . , - . – , , , , .
– , . , – .
– . , , , , , ( ). , – .
, – . «», «», .
. – . , , ( ). , , .. .
, , , , .
– «» , , . , , , , . , ( , – ).
, , , , « -». , , 10 , 2.
-. «», . «» – , , , . ? – . , 40 % — «». , 15 , , 2 , 500 . 2 . 60% = 600 , .. 266 (600 2.25 ). , 100 ( 10 , 1000 ).
«» 1600 ( 15 , 400 ). , . , .. , 500 , – 1600 . , – . , . , . , , -, .
, . , – . , 2 , 5 - . , , , .
, – , . , .
: – , «» . – , . , – , . .
, , . – , , , .
, . , .
, – - . , , , . , , , .
, . : . – , , , , .
: 70 % – , 30 % – . , . , . , , .
, – , , , ? , . -, . -, . , , . « » – « — ».
, , – , , . , – . . -, , . , , .
– , , . , – , .
«», , , . – , , , . – , , - . .
– , . , – – .
, , . , - «, , , . , . , , . , . „ “? ? , , , , 9-00 . , . – , ».
– , ( ). .
. , . , , , , . , , , . , , , , , .
- , . 5 15 . , – .
– , , . - , .
. , . , , « ».
, , . 1 – , . , , . , , – , , , – - «», , . 1 , - .
, , - , , . : .
– . , , . , – , , . .
, – , . , , . , « », - .
, , , - . , , , , .
. , , – , – . , , .
Banyak orang bertanya-tanya - bagaimana mungkin outputnya akan berlipat ganda? Karena apa? Apakah kita dapat menulis kode lebih cepat? Atau mengurangi kualitasnya? Tamparan dan produksi? Banyak, tentu saja, tidak diminta, tetapi hanya menyangkal dan menolak. Lagi pula, tidak mungkin ada metode percepatan ganda yang terbukti di suatu tempat, tetapi tidak ada yang tahu tentang itu?
Masalahnya, pada kenyataannya, adalah hal biasa - vektor perhatian yang salah. Atau, lebih sederhana, Anda tidak mencari di sana. Kami mempersempit topik menjadi programmer, meskipun prinsipnya universal.
Apa, menurut Anda, kecepatan ideal untuk memecahkan masalah klien oleh programmer 1C? Ini tentang tugas mengembangkan atau menyelesaikan. Pikirkan saat Anda membaca, jawabannya akan sedikit lebih rendah.
Mari kita lihat karya programmer 1C. Bagaimana menurut Anda, berapa persen dari waktu yang sebenarnya diprogramnya (termasuk semua aspek - menulis kode, membuat metadata, tata letak, dll.)? 100%? 50%? 20%?
Praktek menunjukkan bahwa itu terjadi dan 3%. Jika Anda tidak percaya, periksa sendiri - ada program khusus untuk pengukuran seperti itu. Tetapi ada cara yang lebih sederhana - lihat jumlah kode yang ditulis oleh programmer dalam sehari, dan bagi dengan kecepatan cetaknya. Angka yang dihasilkan mungkin mengejutkan Anda.
Pikiran programmer akan marah - baik, tetapi bagaimana dengan ukuran kode dan kecepatan cetak? Ada tugas di mana Anda perlu menulis bodoh dan banyak. Dan ada orang-orang di mana Anda perlu banyak membaca, berpikir, menganalisis dan mencoba, men-debug untuk waktu yang lama.
Ok, mari kita pergi ke sisi lain. Sepanjang hari programmer berpikir, menganalisis, mencoba. Akibatnya, ia menulis 50 baris kode, dan masalahnya terpecahkan. Bagus, kode yang benar, semuanya diperiksa dan berfungsi. Menghabiskan 8 jam.
Sekarang pertanyaannya adalah: pada jam berapa itu akan menyelesaikan masalah yang sama persis dari klien lain? Jika dia hanya mengambil solusi yang sudah jadi, maka sekitar 5 menit, kan? Nah, sementara konfigurator terbuka di sana, sedangkan yang kedua, saat menyalin, dll. Dan jika Anda menulis ulang, dengan pena? Setengah jam? Di perjalanan, ia juga akan melakukan review pada mesin, dan kode akan meningkat. 16 kali lebih cepat.
Yah, persetan dengan itu, dengan menyalin kode. Contoh lain. Anda, alih-alih memberi satu tugas pada programmer, berikan 10-20 - Anda berkata: ini adalah pelacak, pilih yang mana saja dan lakukan. Apa yang akan terjadi selanjutnya?
Programmer akan memilih. Dalam kode program, operator seleksi bekerja untuk sepersekian milidetik (jika bukan kondisi yang sangat sulit), tetapi seseorang bukan mesin. Baginya, pilihannya adalah proses yang terkadang berjalan sangat lambat.
Terkadang proses ini mengingatkan pada pengintaian dalam pertempuran: programmer tidak hanya membaca judul tugas dan deskripsi rinci, tetapi juga komentar, dan kemudian dia merangkak ke konfigurator untuk memahami konteksnya. Lihat, tersandung - Fu, katakanlah, ini adalah tugas tentang overall, di sana iblis akan mematahkan kakinya, di starter lembut ini. Tidak, biarkan Kolyan melakukannya. 15 menit hilang. Kalikan dengan 10-20, berapa hasilnya? Hingga 5 jam?
Ini bagus jika programmer cerdas dan memiliki konteks yang cukup untuk membuat keputusan. Tapi dia, katakanlah, penggemar berat Internet, dan pergi mencari solusi yang sudah jadi - di Infostart yang sama, atau konferensi afiliasi, atau di tempat lain. Waktu pilihan mulai tumbuh pada tingkat yang mengkhawatirkan.
Setengah hari akan memilih, setengah hari akan bekerja. Kerugian - 50%, mis. cukup bagi seseorang untuk mengeluarkan tugas dengan benar untuk menggandakan output.
Oke, kami tidak punya masalah seperti pilihan. Manajer, atau kepala programmer, memilih dan berkata - ini, lakukan ini. Tidak, saya tidak mau, saya tidak bisa, biarkan Kolyan melakukan yang lebih baik, jawab programmer. Lakukan, kataku! - Menegaskan kepala.
Selanjutnya, sesuai dengan pemahaman tentang hal utama, programmer duduk dan melakukannya. Biarkan tidak terlalu efektif, tetapi itu berhasil. Apa yang dia lakukan Terkadang - ya, itu memecahkan masalah. Terkadang dia duduk dan tersinggung. Atau mencari alasan untuk tidak melakukan tugas. Misalnya, ia sedang menyiapkan daftar masalah, "yang tanpanya tidak masuk akal untuk memulai." Atau internet itu bodoh, karena dunia ini tidak adil.
Saya akan menyelesaikan contoh, meskipun sebenarnya ada puluhan. Ternyata programmer memiliki dua negara - menulis kode atau tupit. Kata "tupit" digunakan tanpa konotasi negatif, ia tidak menemukan kata kerja yang lebih cocok dari kata benda "stupor".
Jadi prinsip utama diambil: lihat di mana itu bodoh. Tidak masuk akal untuk memulai pertumbuhan efisiensi dengan proses penulisan kode, memilih lingkungan pengembangan yang berbeda (seperti EDT), segala macam hal untuk mempercepat pengkodean, dll. Pertimbangkan bahwa ketika seorang programmer menulis kode, itu efisien. Itu benar ketika dia mengetuk dengan jari-jarinya di keyboard, atau menggambar dengan mouse bentuk dan menambahkan detailnya.
Sebagian besar waktu hilang ketika programmer bodoh, dan bukan di mana ia menulis kode. Saya mengatakan beberapa opsi.
Jika Anda adalah kepala programmer, berhentilah melihat pada coding, lihat downtime. Jika Anda seorang programmer, lihat diri Anda sendiri, pada waktu istirahat Anda. Ini adalah kunci untuk meningkatkan kecepatan pengembangan.
Kami kembali ke pertanyaan - berapa waktu yang ideal untuk menyelesaikan masalah klien oleh programmer 1C? Jawabannya jelas - nol. Benar-benar nol tidak ada, biarkan 5 menit. Bagaimana waktu ini tercapai? Anda sudah mengerti: dengan mengeluarkan solusi turnkey. Klien datang, mengatakan tugasnya, dan Anda segera memberitahunya - solusi yang sudah Anda miliki. Saya tidak tahu berapa banyak uang yang harus diambil, yah, tidak dalam 5 menit kerja spesialis, itu sudah pasti. Anda bisa berdebat dengan pernyataan ini, tetapi Anda bisa berpikir. Berapa kali Anda memecahkan masalah yang identik? Berapa persentase tugas yang Anda selesaikan untuk pertama kali, dan belum pernah mendengar hal seperti itu? Saya memiliki latihan kecil - baru berusia 13 tahun, tetapi bahkan dengan angka yang begitu sederhana, saya mengerti dan melihat bahwa saya telah menyelesaikan setengah dari masalah.
Jika Anda mempersenjatai diri dengan pendekatan ini, Anda perlu sedikit - menulis alat kustom abstrak (bukan govnokod kontekstual, sesaat) dan menyimpannya di suatu tempat. Yang pertama kita bahas, yang kedua memiliki banyak solusi.
Kemudian saya sedikit melampaui kasus ini. Saya tidak mendesak Anda untuk menyerahkan segalanya dan menangani solusi yang sudah jadi, saya hanya ingin menunjukkan yang ideal - akselerasi sebenarnya bukan pengembangan, tetapi penjualan puluhan atau ratusan kali. Dengan demikian, percepatan generasi pendapatan waralaba adalah ratusan kali. Meskipun kami akan berurusan dengan yang lebih kecil, kami akan mempercepat dua kali.
Anda memahami prinsipnya, maka semuanya akan menjadi jelas dan sederhana bagi Anda. Saya akan menjelaskan tindakan yang perlu dimasukkan dalam pekerjaan departemen, dengan satu tujuan - untuk mengurangi waktu yang membosankan, menggantikannya dengan pemrograman.
Diskusi umum tentang tugas yang masuk
Sederhana dan klise. Petugas, yang kita bahas dalam artikel sebelumnya, mengumpulkan semua programmer dalam tumpukan setiap pagi, dan mereka melihat bersama tugas-tugas baru.
Hal pertama yang harus diketahui adalah apakah seseorang telah memecahkan masalah yang sama. Jika Anda memutuskan, maka tunjuk dia konsultan, atau kurator - tidak masalah apa yang harus dihubungi. Penting bahwa kontraktor tahu siapa yang harus dihubungi.
Jika tidak ada yang melakukan ini, maka kami menyederhanakan kriteria sedikit - kami mencari mereka yang telah bekerja dengan subsistem ini, atau dokumen ini, atau mekanisme platform ini. Nah, Anda lihat - jika tugasnya adalah tentang menggambar Penjadwal, maka siapa pun yang telah menguasai mekanisme luar biasa ini akan melakukannya. Dia akan menjadi konsultan.
Jika tugas tersebut umumnya baru, dan bahkan tidak asing bagi siapa pun, maka Anda perlu memilih pemantik api - orang yang akan menjadi orang pertama yang memahami topik ini. Ada dua tugas utama: untuk memecahkan masalah dan mengembangkan kompetensi. Lain kali menjadi konsultan pada tugas serupa. Tentu saja, semua orang mengerti bahwa merokok dapat memakan waktu lebih lama dari yang disepakati dengan klien - ini normal, Anda berinvestasi dalam tim Anda.
Memiliki konsultan sangat penting bagi pemula. Bahkan jika, menurut strategi pengembangan kompetensi Anda, Anda melarang seorang pemula untuk bertanya kepada seorang kurator, fakta keberadaannya hanya akan memberikan dukungan moral yang sangat besar kepada seorang pemula.
Nah, jangan lupa untuk mengevaluasi tugas, dalam poin - bermain perencanaan poker.
Pemilihan pelaksana berdasarkan kompetensi sesuai dengan strategi
Semuanya sederhana di sini. Anda membuat pilihan - menyesuaikan penggeser antara pengembangan dan peningkatan kompetensi. Jadi pilihlah artis yang sesuai dengan strategi Anda.
Misalnya, Anda memutuskan bahwa pemula harus menyelesaikan masalah yang tidak dikenal 30% dari waktu. Dalam sistem, Anda sudah memiliki laporan yang menunjukkan persentase - berapa banyak teman, berapa banyak masalah yang tidak dikenal yang ia selesaikan. Lihatlah angka-angkanya dan putuskan pada titik mana untuk mengeluarkan tugas baru yang tidak dikenal.
Memiliki konsultan akan menghilangkan potensi kelebihan dari tugas, dan memberikan elemen proses permainan. Akan menarik bagi pemula untuk berurusan dengan mekanisme baru, karena dia akan tahu tentang ketersediaan dukungan dan merasakannya. Jika Anda menetapkan terlebih dahulu batas-batas penerapan dukungan ini, umumnya akan luar biasa: misalnya, berikan pemula untuk bekerja secara mandiri tidak lebih dari satu hari, setelah itu konsultan akan memutuskan.
Tingkat dan format dukungan dari konsultan adalah pilihan Anda sendiri, tidak ada yang rumit. Jika pendatang baru benar-benar baru, maka tidak masuk akal untuk memberinya tautan ke konferensi afiliasi, buku tebal tentang pengembangan dan untuk mendorong "ayo, bereskan, nak." Dia tidak bisa mencerna bagian yang begitu besar, dia tersedak, dan Anda bisa kehilangan karyawan. Dia tidak akan berhenti, tetapi akan menerima pukulan signifikan dalam arti pentingnya, mungkin menjadi tertutup dan lembam.
Tidak ada saran pasti untuk memilih "ukuran potong", karena semuanya benar-benar individual. Satu prinsip bersifat universal: ukuran ini perlu dipantau. Tentu saja, jika Anda ingin meningkatkan efisiensi, dan bukan kepentingan Anda sendiri. Cara ekspresi diri seperti menetapkan tugas yang tidak dapat diselesaikan terlalu banyak digunakan di kalangan programmer 1C untuk tidak membicarakannya.
Ada pengecualian - karyawan yang ingin mencari tahu sendiri. Mereka sangat ingin sehingga mereka dengan tegas menolak bantuan apa pun. Ini adalah cara mereka untuk meningkatkan signifikansi - “Saya bisa mengetahuinya sendiri,” dan semakin luas konteks yang ia pelajari, semakin besar ganjarannya adalah kepuasan diri. Ini adalah kualitas yang berguna, tetapi kadang-kadang berubah menjadi mania - lebih baik mengikuti ini, menetapkan batasan (pada waktunya, misalnya).
Jika tugas itu mendesak, atau klien penting bagi Anda, maka percobaan dimatikan, dan orang yang mengerti yang terbaik duduk di tugas itu. Yah, semua orang tahu itu.
Manajemen dan akuntansi bantuan timbal balik
Jika ada konsultan, alangkah baiknya untuk memotivasi dia - untuk memberikan persentase pembayaran per jam untuk menyelesaikan masalah. Jumlah bunga tergantung pada tingkat partisipasi.
Tentu saja, perlu untuk memastikan bahwa konsultan tidak menjadi kurang ajar, dan tidak menarik selimut ketika dirinya ditugaskan ke pendatang baru. Jangan lupa bahwa tujuan kita bukanlah manfaat langsung, tetapi kesuksesan jangka panjang.
Nah, Anda harus mengikuti pemula. Jika Anda memutuskan bahwa dalam tugas ini dia hanya tahu pekerjaan dengan Penjadwal, jangan biarkan dia mengambil sisa konteks tugas - biarkan konsultan memberitahunya.
Sebenarnya, tidak ada lagi yang bisa ditambahkan.
Kelola status tugas
Ada
artikel terpisah tentang topik ini, saya tidak akan mengulang semuanya. Kebetulan, artikel itu tidak terlalu tertarik pada 1Snikov, tetapi perwakilan dari ras pengembang lain menyukainya - kami secara aktif bekerja dengan mereka sekarang. Ini untuk mengatakan bahwa dalam dunia pemrograman 1C, sejauh ini tidak semuanya baik dengan metode peningkatan efisiensi.
Saat Anda memilih petugas jaga, beri dia tautan ke artikel di atas. Hal utama yang harus dia pahami, terima, dan penuhi adalah bahwa status tugas perlu dipantau.
Setiap pagi harus dimulai dengan ritual - tugas manajemen status. Ini sangat sederhana dan mudah untuk diotomatisasi. Di jendela pertama - tugas baru yang belum diambil untuk bekerja. Ini adalah daftar diskusi dengan tim yang kami ulas di atas. Hasil diskusi harus menjadi pengosongan jendela ini.
Di jendela kedua - tugas diterima ke dalam pekerjaan, tetapi tidak memiliki pelaksana. Dikosongkan dengan cara yang sama, setelah diskusi umum. Setelah diskusi, kedua daftar harus kosong. Waktu yang diizinkan untuk tugas berada dalam status "Tidak diterima untuk bekerja" dan "Tidak ditugaskan sebagai pelaksana" - tidak lebih dari satu hari kerja.
Jika tugas tidak jelas, dan klarifikasi pelanggan diperlukan - tugas, bersama dengan daftar pertanyaan, pindah ke jendela / status "Klarifikasi diperlukan" atau "Dikirim untuk revisi" - tidak peduli apa namanya. Determinisme itu penting.
Setelah diskusi (atau sebelum itu) petugas memeriksa daftar mereka yang dikirim untuk revisi sehingga tidak ada penundaan dalam status. Misalnya, tiga hari diberikan untuk mengklarifikasi pernyataan tersebut. Tiga hari telah berlalu - kita harus menulis kepada pelanggan agar tidak melambat. Kemungkinan besar, dia lupa menjawab.
Selama diskusi dengan programmer, kita melihat jendela "In Work". Kami memeringkatnya: semua orang memahami siapa yang terlibat dalam tugas apa. Oleh karena itu, ada waktu untuk tugas berada dalam status "Dalam pekerjaan", terikat dengan kontraktor, dan kali ini harus dipantau.
Basi - agar tidak ketinggalan batas waktu pengetahuan untuk seorang pemula. Jika dia diberi satu hari untuk keputusan independen, dan hari itu berlalu, maka dia, dengan probabilitas tinggi, tidak akan mengangkat tangannya dan tidak akan mengatakan bahwa dia tidak bisa mengatasinya. Akan bodoh sampai akhir. Kami tidak membutuhkan ini, sehingga kontrol dangkal atas status seumur hidup akan menyelamatkan kami dari kerugian yang tidak perlu, dan seorang pemula dari rasa bersalah atas kebodohan kami.
Jendela terakhir - menyelesaikan tugas yang membutuhkan penerimaan dari pelanggan. Di sini prinsipnya sama dengan yang dikirim untuk revisi - kami menetapkan tenggat waktu, misalnya, tiga hari, setelah itu kami mulai mengingatkan diri sendiri. Tenang, percaya diri, tapi gigih. Saya ulangi, pelanggan bisa saja lupa, dia sudah cukup punya urusan sendiri.
Terakhir
Nah itu saja, selesaikan kopernya. Tokoh utama yang dibahas adalah nilai intrinsik dari suatu unit kerja, yaitu titik. Saya berpendapat bahwa biaya ini dapat dikurangi setengahnya - untuk menghasilkan jumlah pekerjaan yang sama dalam separuh waktu.
Inilah jadwal kami untuk salah satu klien (yang utama saat ini):
Seperti yang Anda lihat, sebelum menerapkan kasing (mis., Hingga April), nilai titik tergantung pada tingkat yang sama. Ini berarti bahwa, menghabiskan jumlah jam yang sama, kami menghasilkan jumlah hasil yang sama - rata-rata 1 poin dalam 0,9 jam.
Pada bulan pertama penggunaan case, nilai poin turun tajam, menjadi 0,22 jam, yaitu sekitar empat kali. Bulan pertama, tentu saja, harus diperhitungkan, tetapi tidak dapat dipercaya sepenuhnya, karena ada lompatan tajam dalam pengiriman pekerjaan - beberapa tugas "mahal" yang, karena siklus tugas yang tidak terkontrol, diseret seperti karet, ditutup.
Bulan kedua lebih indikatif dan benar. Pertama, tidak ada lagi tugas lama yang akan ditutup - semua tugas yang ditutup pada bulan Mei lahir dalam dua bulan sebelumnya, yaitu selama penerapan kasus ini. Kedua, penggunaan kasus diselesaikan dan menjadi kebiasaan. Hasilnya - 0,33 jam untuk 1 poin, yang tiga kali lebih baik dari sebelumnya.
Nah, kemudian sosok itu mulai berkeliaran di sekitar rata-rata yang dijanjikan - setengah dari yang asli.
Tentu saja, hasil positif diperoleh tidak hanya untuk klien ini, tetapi juga untuk semua pekerjaan secara umum. Termasuk - di internal, yang kami punya cukup banyak - lebih dari untuk pelanggan eksternal.
Di sini, misalnya, adalah grafik dari jumlah total poin yang diperoleh:
Seperti yang Anda lihat, sebelum kasing kami rata-rata memberikan 400-500 poin sebulan, dan kemudian angka ini meningkat menjadi 1400 - peningkatan 3 kali lipat.
Kedua jadwal terputus pada bulan Oktober, sayangnya - kami dulu melakukan tugas di github, dan kemudian pindah ke Flowcon. Jadwal umum, dari dua sumber, menarik kemalasan.
Sangat menarik untuk memahami ketergantungan angka. Kami, Oknosoft, mencoba berbuat sedikit untuk layanan pelanggan, prioritas kami adalah pengembangan. Sebelum menggunakan kasing, kami memiliki masalah - butuh terlalu banyak waktu untuk pelanggan, dan sangat sedikit yang tersisa untuk pengembangan.
Penggunaan case memungkinkan kami untuk keluar dari jebakan ini - kami memiliki, meskipun masih belum cukup, tetapi lebih banyak waktu untuk pengembangan. Hasilnya tidak lama datang: kami menerapkan beberapa produk yang sangat penting bagi kami.
Yang pertama adalah situs proyek pemrograman bisnis kami (saya tidak akan memberikan tautan, jika tidak saya akan menerima email dengan subjek "nmivan, ayo ..."). Kata kuncinya adalah situs, karena sebelumnya kita hanya membuat aplikasi bisnis yang berfungsi melalui internet. Situs ini dibangun di atas platform metadata.js, tetapi kunci suksesnya bukanlah situs itu sendiri, bukan kontennya, melainkan penyempurnaan platform dan komponennya. Sekarang Anda juga dapat membuat situs di metadata.js. Selain itu, situs ini berisi fungsionalitas CMS dan layanan mikro.
Proyek kedua, yang tidak mencapai tangan untuk waktu yang lama, tanpa kertas, yaitu fungsionalitas pengiriman bengkel, bekerja melalui browser dan dengan visualisasi yang keren (ini penting untuk produksi jendela, misalnya). Karya tanpa kertas melalui browser - misalnya, menggunakan pemindai barcode yang terhubung ke TV - akan secara signifikan memperluas dan menyederhanakan kemungkinan menerapkan solusi pada metadata.js dalam produksi. Terutama dengan mempertimbangkan kesederhanaan bekerja dengan peristiwa eksternal dalam kode metadata.js, mereka dapat ditangkap di mana saja, dan tidak hanya dalam bentuk aktif, seperti dalam 1C.
Berbicara tentang proyek ketiga -
Flowcon.Life . Bagi kami, ini sangat penting, karena memberikan banyak tugas yang berguna untuk pengembangan platform. Ini adalah proyek pertama untuk orang, bukan untuk bisnis.
Yang keempat hampir tidak menarik bagi Anda - ini adalah Flowcon, konfigurasi untuk layanan manajemen tugas / tim / bisnis 1C +.
Nah, beberapa lagi - lebih kecil dan lebih membosankan, atau lebih besar dan lebih rahasia. Total, katakanlah, enam buah.
Apakah banyak atau sedikit? Saya akan mengklarifikasi untuk dua orang. Yang juga bekerja dengan klien pada proyek implementasi, menulis artikel, bersumpah banyak satu sama lain dan dengan seluruh dunia, dan bahkan malas ke neraka.
Semuanya relatif. Enam proyek dalam 9 bulan - banyak atau sedikit? , 6 ( ), – 0.15 0.66 .
, , — , . , , , . , – .
, , . , , .
, , , – . , , , – .
, . , . , , — , ? .
, , . , . , , , , . .
« »
. , , - .
, - – , , . . , – , .
, , . – , – . , – . , .
1 , , , 1 , ? , , - , – .
, , . – . 1.5 – . – . , , «, - , ».
1? Tidak ada , – , .
. , – . . , .
?
« , »
– . «» — . , , .
– , – , . , . , . .
, . – , . , , , – «, ?».
? , .. – , , . , , , – : , . , , – .
« , »
– , . . , .
« , -, »
, . , ? ? .
, « », – , .
, . , . ?
, .
« – »
. – , .
« / ///»
– . , , .
« , »
, – . , . , – .
. , . – , .
, – 1, , , . .
« ? ?»
, . – , , . , .
, – 1: , – . – , – .
« , …»
, . , – .
« ?»
. – , – . – .
. - , , .. – , , .. , .
, , . «» — , .
« ?»
, . .
, , – . . – . , , , , – .
, . , . – .. . - , . , .
, . , , . , .
, . , . , , , , .
, , .. , – – . , , , .
«?»
– , , , . – - .
1: , , , «», - . , , . , – , .
, . – , . , , .
(, -, ), 1: , . – , – . «» .
– . – . , «» .