Nah, dimana dia?

Setelah menerbitkan resume orang itu , dua hal baik terjadi.

Pertama, pria itu mulai menerima banyak tawaran pekerjaan. Lebih dari sebelumnya.
Kedua, lebih dari setengah proposal ini terkait dengan manajemen - atau pengembangan produk, atau pengembangan layanan streaming, atau menyelesaikan tugas-tugas proyek.
Ketiga, banyak pesan datang - kali ini kepada saya - dengan permintaan untuk menyatakan metode untuk mempercepat pembangunan. Nah, itu yang membantu gadis itu .

Dan kemudian saya menemukan bahwa dalam publikasi tentang seorang gadis saya menipu semua orang. Saya katakan di sana bahwa dia membaca satu artikel dan berbicara dengan seorang pria sekali. Tapi, ternyata, dia masih membaca buku.

Saya sudah lama ingin mensistematisasikan praktik mempercepat pembangunan, tetapi tidak ada alasan. Dan kemudian satu perusahaan menoleh ke saya dan menawarkan untuk mengembangkan kursus, sehingga nantinya saya bisa menjualnya di lingkungan tertentu (yang sudah ada - 1Snoy). Seharusnya ini akan menjadi kursus video, dengan beberapa presentasi dan tugas - membosankan, secara umum. Saya memutuskan untuk membunuh dua burung dengan satu batu - menulis teks, seperti buku, dan kemudian membuat kursus video darinya. Dengan demikian, dua produk akan diperoleh. Dengan sedikit usaha, sepertiga akan keluar darinya.

Struktur buku telah lama diketahui, apa yang harus ditulis di sana - Anda juga hanya perlu duduk dan melakukannya. Saya telah menulis, pada saat ini, 6 bab dari 20, yaitu ~ 30%. Dan, sejak minuman keras itu pergi, taruh dalam bentuk artikel. Gadis itu, omong-omong, hanya membaca 3 bab.

Sekarang akan menjadi bab pengantar pertama. Ada kekhususan kecil - karena buku ini, pada kenyataannya, dibuat sesuai pesanan, maka ini adalah tentang pengembangan pada 1C. Setelah menghapus penyebutan 1C, saya akan membuat produk ketiga darinya - itu akan memakan waktu setengah hari.

Tapi sekarang saya tidak membersihkan apa pun - baca apa adanya. Jika menurut Anda pengembangan pada 1C dan javascript terlalu berbeda, maka jangan baca. Hidup saya telah menunjukkan bahwa dari sudut pandang peningkatan efisiensi, tentu saja, ada perbedaan - bahkan ada lebih banyak titik penerapan usaha dalam pengembangan javascript dan, karenanya, efek yang diharapkan lebih tinggi. Baiklah, ayo pergi.

Setelah Anda berkenalan dengan materi ini, saya dapat mengasumsikan salah satu dari dua opsi.

Yang pertama - seseorang membuatmu. Kepala, direktur, manajer proyek - tidak masalah.

Kedua, Anda mempelajari materi ini atas kehendak bebas Anda sendiri, karena Anda berusaha untuk meningkatkan efisiensi - pribadi atau tim yang Anda masukkan, atau bahkan mungkin memimpin.

Mudah untuk menebak siapa diri Anda: Anda adalah seorang programmer atau manajer programmer, atau Anda bekerja di sebuah perusahaan programmer, atau mungkin Anda memiliki perusahaan ini.

Mengapa saya berdebat tentang semua ini? Hanya untuk mengatakan: santai dan bersenang-senang. Informasi ini akan berguna bagi Anda, terlepas dari peran Anda di perusahaan.

Ini bukan panduan bagi manajer bagaimana memeras semua jus dari programmer yang tidak bahagia. Ini bukan panduan bagi programmer tentang cara menipu manajer. Ini bukan panduan untuk menipu pelanggan.

Ini adalah panduan untuk meningkatkan efisiensi. Pribadi Anda, kolega Anda, bawahan atau departemen, tim, atau perusahaan Anda secara keseluruhan. Itu ditulis oleh seorang programmer, dan paruh waktu sebagai proyek, tim, manajer produk. Jadi, saya berani berharap, saya mengerti dan secara pribadi mempertimbangkan minat Anda.

Jadi, mari kita bicara tentang efisiensi.

Lihatlah ke sekeliling pada programmer di sekitar Anda. Yang mana dari mereka yang bekerja secara efisien saat ini?

Orang itu di sana, katakanlah, bermain tank. Apakah ini efektif saat ini? Mungkin tidak. Anda dapat, tentu saja, menangkap telinga Anda dan mengatakan bahwa ia begitu santai setelah menyelesaikan tugas yang sulit, dan dalam setengah jam, dengan semangat baru, ia akan masuk ke pemrograman. Tapi kemungkinan besar, setelah tank, dia akan merokok.

Dan keduanya yang berdebat dengan bersemangat tentang sesuatu? Tampaknya tentang arsitektur beberapa solusi? Apakah ini efektif?

Sekilas, ya, tentu saja. Bagaimanapun, desain arsitektur, dan bahkan dalam diskusi kelompok, melalui brainstorming, adalah penting dan bermanfaat. Seperti yang mereka katakan, satu kepala baik, dan dua lebih baik. Tapi mari kita dengarkan kata-kata mereka.

Satu kata - perlu untuk melakukan daftar akumulasi. Teriakan lain - tidak, apa daftar akumulasi, mengapa Anda, sepatu bot? Hanya mendaftar informasi! Sudah berapa lama ini berlangsung? Setengah jam? Jam? Anda menjaga mereka di sana, kalau tidak mereka akan bertarung.

Dan yang itu, orang bijak, tidak berdebat dengan siapa pun. Duduk di headphone, menopang kepalanya di tangannya. Tidak memprogram, ini terlihat jelas. Apa yang dia lakukan Tanya

Katanya dia merancang arsitektur solusi. Sekali lagi. Mendesain langsung? Apakah Anda menggambar diagram di kepala Anda? Tidak, katanya, saya pikir - daftar akumulasi, atau pilih daftar informasi. Pernahkah Anda berpikir? Sekitar dua jam sudah, seluruh kepala saya patah. Pilihannya sama dalam hal biaya tenaga kerja, dan tidak ada yang memiliki keunggulan khusus. Dan klien itu penting, apakah itu register akumulasi, atau register informasi? Ya, seperti tidak. Kliennya adalah Klavdia Eliseevna, seorang akuntan, yang baginya tidak ada bedanya.

Orang ini menghabiskan waktu secara efektif, bagaimana menurutmu?

Nah, itu dia. Tangan dengan cepat memutar roda pada mouse, pandangan terfokus tertuju pada monitor. Apa yang dia dapatkan di sana? Ya, daftar yang familier ... Ini adalah tugas kita! Apa yang dia lakukan Tanya

Tugasnya, kata, saya pilih. Saya tidak tahu harus mulai dari mana. Separuh tidak jelas, setengah dalam bentuk tebal, dan saya tidak mengenal mereka, karena saya masih muda. Di sini Anda perlu tahu SKD, tapi saya ... Ya, itu ... Begini-begitu.

Apakah ini efektif?

Mari kita lihat juara kita. Yang ini pasti efektif! Dia mengeluarkan keputusan seperti itu, Anda akan bergoyang! Dalam satu proyek yang paling sulit menarik! Ada apa dengannya? Hmm, seperti semacam tata letak menarik. Hei juara, apa yang kamu lakukan? Apakah Anda memperbaiki TORG-12? Dan apa yang salah di sana? Apakah perlu bahwa alih-alih nama kontrak, nomor dan tanggal ditampilkan? Benarkah? Tugas seperti itu?

Ya, kami, tentu saja, mengerti - pelanggan bertanya, itu perlu - itu berarti itu perlu. Tetapi mengapa Anda, juara, memecahkan masalah ini? Anda tampaknya memiliki tugas yang cukup besar dan serius, tingkat subsistem dan konfigurasi baru. Apa, tidak ada orang lain yang memperbaiki TORG-12? Mungkin lebih baik pria yang tidak bisa memilih tugas bisa menanganinya?

Juara itu efektif, bagaimana menurut Anda?

Dan apa yang orang itu lakukan? Mengapa dia duduk di dekat telepon dan memandangnya seperti seorang prajurit di kutu? Apakah ada panggilan menunggu? Sepertinya tidak, manajer kantor menerima semua panggilan ... Bertanya?

Ups. Dia harus memanggil klien, tetapi dia takut. Selama dua jam sekarang dia telah duduk dan menciptakan skenario percakapan, dia bahkan menulis sesuatu di buku catatan - beberapa frasa, jawaban yang diprediksinya sendiri. Kenapa dia harus memanggil pelanggan? Dia adalah seorang introvert ke sumsum tulang. Jadi, hentikan, bersama kami semua orang berkomunikasi dengan kliennya. Ada yang salah di sini, sepertinya ...

Yah, ini bisa dimengerti. Apa yang aku lakukan Saya menulis unggahan dari SCP ke Accounting 3.0. Tidak ada cara untuk menggali - efektif sekali. Atau tidak? Mengapa ada keraguan samar dalam jiwa? Mungkin alasan mereka adalah karena kami telah melakukan pembongkaran dari SCP ke Accounting 3.0? Dan lebih dari sekali. Mengapa saya menulisnya lagi? Mengapa tidak mengambil yang sudah jadi? Konfigurasi khas. Sial, aku harus bekerja denganku ...

Anda dapat menggunakan ad infinitum. Jika Anda tidak melihat orang, selalu terlihat bahwa mereka bekerja secara efisien. Ya, atau setidaknya mereka bekerja. Faktanya, kami bahkan tidak berpikir bahwa mereka efektif - kami berharap mereka efektif.

Kami ingin seperti ini, kalau tidak hal terburuk akan terjadi - kita harus menyelami itu . Memahami, mengukur, menganalisis, berpikir, dan mencoba mengubah sesuatu. Apakah jauh lebih mudah untuk meninggalkan semuanya apa adanya? Dan jika seseorang tidak berhasil bekerja secara normal, itu adalah kesalahannya sendiri! Bawa dia ke neraka, dan itu akhirnya!

Yah, semua orang tertawa, dan sekarang serius. Efisiensi adalah masalah yang tidak mungkin tercapai, seperti matahari terbenam. Tidak ada yang begitu efektif sehingga tidak ada yang bisa diperbaiki. Anda selalu bisa menjadi lebih baik.

Jadi di mana efisiensi hilang? Pertama-tama, di mana seseorang tidak bekerja . Dalam kasus kami, di mana orang tersebut tidak memprogram . Meskipun, seperti yang Anda pahami, pemrograman bisa jadi tidak efisien.

Jika kita melihat rantai nilai - dari munculnya masalah hingga menerima uang untuk solusinya - kita akan melihat banyak tempat gelap di mana tidak ada hal berguna yang terjadi. Penelitian saya sendiri telah menunjukkan bahwa programmer biasa dapat kehilangan hingga 97% dari waktunya.

Dia dapat memilih tugas, berdebat, berpikir, memilih dari dua solusi yang setara, takut akan sesuatu, mencoba memenuhi tenggat waktu, mengulang kode yang sudah ditulis, dan seterusnya, hingga tak terbatas. Ada banyak opsi untuk kehilangan efisiensi.

Anggap saja sebagai aksioma - seorang programmer selalu tidak efektif. Dan Anda - termasuk. Dan saya juga.

Jika Anda menolak aksioma ini, muncul dengan alasan, berdebat, dan mencoba membuktikan sesuatu - kepada saya atau kolega Anda - Anda tidak akan pernah menjadi efektif.

Saya mengerti bahwa pernyataan seperti itu - “Saya tidak efektif” - dapat sangat memengaruhi harga diri. Tapi kami sepakat sedikit lebih awal bahwa Anda akan santai dan menikmati. Pada akhirnya, Anda tidak dapat mengubah apa pun, meninggalkan segalanya seperti apa adanya dan hidup sendiri, bahagia dalam kebodohan.

Tetapi patut dicoba. Apakah kebetulan pesaing Anda juga mempelajari materi ini? Jika mereka tidak menolak, dan menjadikan efisiensi sebagai misi? Bukan selembar kertas yang indah di dinding di koridor, tetapi benang merah nyata dari semua aktivitas Anda? Kemudian aturan seperti "percaya - tidak percaya" atau "ingin - tidak mau" akan berhenti berlaku - hukum pasar yang keras dan tak terhindarkan akan mulai berlaku.

Nah, itu saja, saya tidak akan membuang waktu lagi untuk meyakinkan. Jika Anda suka ada kepala di pasir, seperti burung unta, maka Anda tidak bisa belajar lebih lanjut. Saya yakin Anda ingin menjadi lebih efektif.

Ada hal seperti itu - perbaikan berkelanjutan, berasal dari manajemen kualitas. Mereka mungkin mendengar tentang siklus Deming, yang dikenal sebagai PDCA.



Poin utama dari siklus ini adalah dalam isolasi . Sebenarnya, itu sebabnya ini disebut siklus, dan bukan proses yang memiliki awal dan akhir. Siklus Deming mendorong kesempurnaan yang berulang, dan karenanya tak terbatas.

Jika Anda terbiasa dengan teori keterbatasan Goldratt, maka inilah gambarannya untuk Anda.



Kata-katanya ditulis berbeda, tetapi artinya sama - siklis . Tingkatkan, dan tingkatkan, dan tingkatkan. Tidak ada batasan untuk kesempurnaan.

Setiap iterasi adalah eksperimen untuk memperkenalkan perubahan. Ini meningkatkan efisiensi atau tidak. Jika meningkat, ia tetap menjadi bagian dari proses. Jika tidak meningkat, maka dibuang - ini normal, percobaan juga tidak berhasil. Lebih tepatnya, mereka mengarah pada hasil negatif, secara negatif mempengaruhi fungsi tujuan, tetapi secara umum, eksperimen seperti itu sukses, karena dia membebaskan kita dari metode yang tidak efektif.

Saya akan menawarkan dua lusin percobaan. Masing-masing dari mereka, secara individual, dapat meningkatkan efisiensi programmer. Atau mungkin tidak meningkatkannya - itu tergantung pada lingkungan di mana implementasi berlangsung, dan pada orang yang mengimplementasikannya.

Anda dapat mencoba semua metode, Anda hanya dapat berpisah. Ada kalanya penggunaan hanya satu metode meningkatkan efisiensi beberapa kali. Ini disebut "prinsip leverage" ketika penyebab utama masalah ditemukan dalam sistem dan solusinya secara tepat dicocokkan. Tetapi, seperti yang sudah Anda pahami, tidak ada batasan untuk kesempurnaan.

Beberapa metode dirancang untuk implementasi dalam tim. Jika Anda tidak memiliki tim, Anda sendirian, dan Anda hanya akan terlibat dalam efektivitas Anda, maka metode ini tidak akan membantu Anda.

Jika Anda memiliki tim, maka Anda beruntung. Anda dapat mencapai apa yang disebut sinergi. Meskipun kata tersebut dimanjakan oleh pemasar, juga kata "efisiensi", tetapi artinya belum hilang. Sebuah tim dapat memberikan efisiensi lebih dari jumlah efektivitas anggotanya.

Ada formula sinergi yang terkenal: 1 + 1 = 11. Ini secara harfiah berarti bahwa menggabungkan upaya dua orang dapat memberikan hasil berkali-kali lebih besar daripada jumlah yang sederhana. Jelas bahwa pemasar menghasilkan formula ini - tidak ada yang bisa membuktikannya dalam praktik. Tetapi pesan yang dia berikan benar - sebuah tim dapat melakukan lebih dari satu tim.

Oleh karena itu, kami akan mencurahkan banyak waktu untuk pekerjaan tim. Pertama-tama, ini tentu saja adalah metode yang didasarkan pada interaksi, pertukaran pengalaman dan bantuan timbal balik.

Ringkasan

1. Setiap orang, pada waktu tertentu, bekerja dengan tidak efisien;
2. Hampir setiap tindakan manusia dapat menyembunyikan hilangnya keefektifan;
3. Jika Anda secara proaktif terlibat dalam efisiensi, maka itu tidak akan berubah;
4. Efektivitas setiap orang memiliki potensi tanpa batas untuk perbaikan;
5. Efektivitas tim mungkin lebih tinggi daripada jumlah efektivitas anggotanya.