Manajemen pengaturan

Mari kita bicara tentang mengelola pengaturan. Kenapa ini tiba-tiba? Ya, karena kami di TeamLead Conf suka mendiskusikan rasa sakit dan masalah, tetapi kami tidak melupakan solusi. Tentunya setiap orang memiliki masalah yang terkait dengan pengaturan kerja.

"Pengaturan tidak sedang dilaksanakan," Kapten Evidence

Rasa sakit dengan mereka, pada awalnya, adalah bahwa perjanjian tidak terpenuhi - semua orang tahu ini, bahkan teman kita, Kapten Evidence, yang akan membantu kita dalam artikel ini.

Tampaknya, apa masalahnya? Banyak hal tidak berjalan seperti yang kita inginkan. Sebagai contoh, hari-hari yang cerah tidak selalu di St. Petersburg. Jadi apa, kota itu berdiri, orang-orang datang, menyukainya. Apa yang tidak terjadi seperti yang kita inginkan tidak selalu merupakan masalah yang sangat serius.

Namun, dalam kasus ini, Stas Mikhalsky mengklaim bahwa masalahnya lebih dari serius. Di bawah potongan, kita akan memahami apa yang mengarah pada fakta bahwa perjanjian tersebut tidak dilaksanakan, dan bagaimana, pada akhirnya, membuat mereka tidak bisa dihancurkan.


Tentang pembicara: Stas Mikhalsky telah terlibat dalam pengembangan web sejak tahun 1998. Dia beralih dari seorang programmer junior Perl menjadi direktur pengembangan di Biglion. Dia berpartisipasi dalam pengembangan beberapa lusin proyek dengan kehadiran tinggi dan memberikan dukungan mereka.

Mengapa ini menjadi masalah?

Bisnis dan kepemimpinan dari tim kami dan kami, sebagai pemimpin tim, sedang menunggu hasilnya. Menyelesaikan tugas tepat waktu mungkin tidak mengarah pada hasil, tetapi ini adalah cerita yang berbeda.

Bekerja dan hasilnya adalah dua hal yang berbeda, tetapi mari kita bicarakan ini lain kali.

Hasilnya adalah hasil pekerjaan - penyelesaian tugas, proyek, sub proyek. Pembagian yang berbeda dimungkinkan, tetapi dengan satu atau lain cara, pekerjaan terdiri dari beberapa tindakan, yang masing-masing sebenarnya merupakan konsekuensi dari suatu perjanjian.

Tampaknya - semuanya jelas: ketika kita tidak melakukan tindakan, kita melanggar perjanjian.

Mari kita perhatikan contoh-contoh standar. Kepatuhan dengan standar gaya kode adalah perjanjian dengan pengembang tertentu. Tidak seluruh tim menjawab dengan satu suara: "Ya, Kaa, kami akan mematuhi gaya kode," tetapi semua orang mengatakan secara pribadi bahwa ia berjanji untuk mematuhinya. Peluncuran rilis pada hari Jumat atau Senin juga merupakan kesepakatan. Apa pun yang kita lakukan, seseorang telah bertanya kepada kita tentang hal ini, atau kita sendiri telah memutuskan bahwa ini diperlukan untuk sesuatu, jika hasilnya diharapkan dari kita, maka ini adalah tindakan yang diambil sebagai bagian dari perjanjian.

- Jika kita sendiri memutuskan bahwa mereka mengharapkan ini dari kita - apakah ini kesepakatan?
- Ya, perjanjian dengan dirinya sendiri, tetapi ini adalah kasus khusus.

Sekarang hal yang paling menarik sebenarnya sebaliknya: perjanjian yang gagal = tindakan yang gagal.

Artinya, bukan perjanjian yang terganggu jika tindakan tidak dilakukan, tetapi tindakan yang tidak dilakukan adalah hasil dari perjanjian yang gagal . Kami tidak, karena kami tidak setuju, baik kami tidak benar-benar ingin, atau sesuatu yang lain. Di tengah adalah masalah dengan perjanjian. Dengan demikian, kita mendapatkan gambaran di mana kesepakatan yang gagal mengarah pada tindakan yang tidak terpenuhi, yang, tentu saja, mempengaruhi kualitas pekerjaan, dan akhirnya pada kurangnya hasil.

Saya ingin menyampaikan kepada Anda gagasan bahwa pengembang, back-end, front-end, penguji, pemimpin tim, manajer pengembangan adalah semua fungsi dan peran di mana kita melakukan sesuatu. Tetapi jika Anda terlihat sedikit lebih tinggi, maka semua pekerjaan kami adalah kesimpulan dari perjanjian dan implementasinya. Ini seperti UDP - yang lainnya dibungkus dalam perjanjian. Jika kita tidak tahu bagaimana menyimpulkan perjanjian dengan benar, maka kita bisa menjadi front-end atau back-end yang sangat baik, menulis kode yang sangat baik, tetapi tidak akan ada hasilnya.

Sebaliknya, jika kita belajar cara membuat pengaturan yang tepat, maka:

• menghemat banyak waktu;
• secara signifikan mengurangi overhead untuk semua kontrol, pembongkaran, dll.
• kita benar-benar dapat melakukan pekerjaan kita.

Apa yang harus dilakukan

“Pastikan pengaturannya diterapkan”

Bukti Kapten

Ini jelas bagi semua orang, bahkan kapten Bukti, Anda hanya perlu memastikan bahwa perjanjian itu dilaksanakan, dan Anda tidak perlu melakukannya sehingga tidak dilaksanakan.

Model klasik tentang bagaimana ini dapat dicapai:

1. Pahami alasannya.
   
2. Identifikasi dan ambil tindakan untuk mengatasi penyebab ini dan ubah hasilnya.
   

Mari kita bicara sedikit lebih detail. Ada tiga aktor:

1. Pengaturan untuk ditangani.
   
2. Gangguan itu terjadi pada suatu pengaturan.
   
3. Alasan kegagalan.
   

Jika Anda melihat semua ini dari semua sisi, maka Anda mungkin dapat memahami apa masalahnya dan bagaimana memperbaiki situasi. Saya harap situasinya memerlukan intervensi, semua orang setuju.

Apa itu pengaturan?

Pengaturan ini terdiri dari dua bagian: komitmen dan janji. Perbedaan di antara mereka adalah bahwa komitmen dibuat, janji dibuat .

Sebuah janji adalah jeroan, itu adalah pesan kepada seseorang bahwa saya membuat komitmen. Pada prinsipnya, itu bahkan tidak dapat diberikan, karena ini hanya pesan notifikasi. Tapi saya melakukan kewajiban ini. Karena itu, komitmen tanpa janji jauh lebih baik daripada janji tanpa komitmen. Kami sering bertemu yang terakhir.

Jujur, menurut saya seluruh masalahnya adalah tidak semua (dan kita juga) dan tidak selalu, ketika kita membuat kesepakatan, memikirkan kewajiban. Kami tidak selalu membuat keputusan secara sadar dan benar-benar memahami apa yang mengancam janji ini dengan kami. Kami hanya mengangguk: “Ya, ya,” kami pergi, tetapi kami tidak membawa kewajiban kami - dan ini adalah masalah besar.

Bahkan, masih jauh lebih rumit, karena pengaturannya berbeda dalam jenis:

• Sebagai bagian dari tanggung jawab langsungnya , misalnya, menulis komentar dalam kode, selesaikan rilis ke lingkungan.
• Di luar pekerjaan utama , misalnya, untuk memantau relevansi informasi dalam wiki, baca buku, masuk ke kursus.
• Ubah perilaku , misalnya, mulai datang untuk bekerja pada jam tertentu, atau melacak waktu yang dihabiskan untuk tugas tersebut.

Ini adalah perjanjian yang sama sekali berbeda, orang memperlakukannya secara berbeda, dan Anda perlu bekerja dengannya dengan cara yang sama sekali berbeda.

Sebagai aturan, ruang lingkup pekerjaan utama melampaui pertanyaan, yang dalam arti lebih penting, menurut saya, daripada tingkat pengkodean saat ini dari pengembang, karena ia dapat ditransformasikan melalui mereka. Jika seseorang tahu cara belajar, ini sama sekali berbeda dengan jika dia baru belajar kode dengan cepat dan tanpa kesalahan dalam 10 tahun. Kadang-kadang setuju dengan pengembang untuk membaca buku bisa jauh lebih sulit daripada mengharuskannya untuk mendokumentasikan kode. Tapi itu bahkan lebih menyenangkan ketika datang untuk mengubah perilaku.

Contoh klasik, ketika dulu tidak penting untuk pergi ke 10 atau 12, karena, jika ada, Anda dapat berlama-lama dan memperbaiki, dan sekarang Anda harus berada di tempat kerja selambat-lambatnya 11, karena proses dan sebagainya. Jika seseorang setuju: "Ya, saya akan datang jam 11 besok" - ini bukan perubahan perilaku, tapi prestasi. Jika ternyata untuk ini perlu, mungkin, untuk membangun kembali kehidupan - untuk tidur lebih awal atau tidak untuk bermain Warcraft, maka itu berarti orang itu sendiri harus berubah. Ini sulit, dan yang paling penting, tidak dapat dikendalikan, seperti proyek apa pun.

Karena itu, sangat penting untuk memahami perjanjian seperti apa yang sedang kita bicarakan. Tingkat elaborasi tergantung pada jenis perjanjian apa yang kami coba simpulkan.

Gangguan

Tidak hanya perjanjian mogok, mereka mogok, pertama, tiba-tiba, dan kedua, di garis finish - karena jauh lebih menyenangkan. Meskipun ini tidak terduga, biasanya pada titik yang dapat diprediksi. Saya selalu tahu kapan perjanjian akan pecah.

Kami sekarang bekerja dalam tim, usia lajang dan komputer garasi telah berlalu. Kami memiliki tim, proses, dan setiap pengaturan, dalam sebuah rantai. Jika runtuh, maka semuanya runtuh. Jika seseorang tidak membaca buku itu, maka, pada prinsipnya, tidak ada yang akan menjadi buruk atau rusak, tetapi dalam setahun tim Anda tiba-tiba tidak akan lebih baik dari sekarang. Bagi saya, file ini jauh lebih besar dari dua jam kegagalan semua sistem.

Gangguan juga berbeda.

Kegagalan adalah jenis kegagalan favorit saya, paling jujur ​​dan paling tidak berbahaya. Kami setuju, orang itu berjanji dan tidak - itu terjadi. Ini adalah gangguan sederhana, karena semuanya jelas dengannya.

Ada opsi yang lebih tidak menyenangkan, seperti eksekusi formal.

Eksekusi formal adalah ketika pada Jumat malam pengembang (untuk pod bir untuk inspirasi) menyebar 40 jam waktu kerja untuk tugas-tugas yang dia lakukan dalam seminggu. Bahkan, orang yang membuat perjanjian ini dengan Anda tidak menerima apa pun saat ini. Jika pencatatan waktu tidak diperlukan untuk menekan semua orang ke paku, tetapi untuk memahami secara statistik berapa banyak waktu dari berbagai jenis tugas, apa kesalahan rata-rata, dll., Maka eksekusi seperti itu menghancurkan seluruh inisiatif. Tidak akan ada statistik, karena data diambil dari kepala. Akibatnya, perjanjian itu tidak terpenuhi, meskipun sesuatu tampaknya dilakukan, dan semuanya baik-baik saja.

Masalahnya adalah bahwa kita tidak selalu mendaftarkan pemenuhan formal sebagai perjanjian yang rusak. Apalagi jika Anda sendiri tidak terlalu tertarik. Misalnya, saya seorang pemimpin tim, direktur mengatakan kepada saya dari atas: "Tulis arloji, kalau tidak saya akan menghukum semua orang!" Saya datang ke tim dan menyiarkan bahwa saya perlu merekam jam, jika tidak semua orang akan dihukum. Akibatnya, jam entah bagaimana direkam, saya puas - saya punya sesuatu untuk ditunjukkan kepada sutradara. Saya sendiri berpartisipasi dalam sabotase ini, dan bagi saya eksekusi formal itu penting. Untuk penyedia tugas, itu tidak dapat diterima.

Substitusi sedikit berbeda dari implementasi formal formulir, tetapi pada kenyataannya itu adalah upaya yang sama untuk melanggar perjanjian. Hanya alih-alih visibilitas tugas yang diselesaikan, substitusi dibuat. Menggunakan contoh pencatatan waktu, kedengarannya seperti ini: “Untuk merekam waktu setiap tugas, saya perlu 5 menit. Secara total, ini adalah dua jam seminggu. Oh, baiklah dia. Saya telah melakukan tugas yang tidak saya inginkan, dalam 4 jam. Tetapi saya melakukan lebih dari yang saya janjikan, atau bahwa saya tidak menggadaikan waktu.

Ini adalah upaya untuk memberi Anda sesuatu sehingga Anda berada di belakang dengan cek, tetapi sebenarnya itu juga merupakan gangguan. Masalahnya adalah, sebagai suatu peraturan, kita memiliki banyak hal lain, waktu tanpa jaminan bukanlah yang terburuk. Kami memaafkan diri sendiri.

Saya ulangi: perjanjian yang belum selesai adalah kerja minus, hasil minus.

Bagaimana cara bertahan hidup di dunia pengaturan yang tidak terpenuhi?

Anda hanya dapat mengingatkan : "Apakah Anda ingat bahwa kami mencatat jam?". Ketika datang untuk mengubah perilaku, maka pengingat adalah garis besar yang baik. Poster menggantung paling licik yang mendukung model perilaku: "Waktu yang dijanjikan - menyelamatkan berang-berang!". Bahkan, kami hanya mengingatkan Anda bahwa ada perjanjian, tanpa memeriksa statusnya saat ini.

Anda bisa sedikit lebih gigih dan bertanya bagaimana perjanjian itu dilaksanakan, apakah orang tersebut telah melakukan sesuatu. Ini berbeda dari pengingat karena ini memaksa Anda untuk memberikan semacam jawaban yang jelas. Tetapi Anda menempatkan orang tersebut di atas pilihan: berbohong atau tidak berbohong. Omong-omong, jawabannya, tidak jelas bagi semua orang. Dalam arti tertentu, Anda mendorong seseorang untuk berbuat jahat. Bertanya adalah jenis kontrol laten - tampaknya ditanyakan, tetapi tidak dicentang. Pria itu berbohong, tetapi kita membiarkannya dengan hati nuraninya.

Anda dapat memeriksa :

• dengan hasil;
• langkah demi langkah;
• tentang dinamika.

Verifikasi oleh hasil yang telah kita bahas. Pertanyaannya adalah apa yang harus dilakukan jika hasilnya tidak memuaskan, tetapi kami akan kembali ke sini nanti.

Dengan langkah-langkah dan dinamika, dimungkinkan untuk memeriksa pemenuhan perjanjian masuk dan keluar dari pekerjaan. Misalnya, kami membujuk seseorang untuk mengisi basis pengetahuan, menjabarkan rencana dengan dia, dan pergi sesuai dengan rencana itu - ini masih hilang. Tetapi bagaimana dengan perubahan perilaku? Seseorang mencatat waktu atau tidak mencatat; entah datang tepat waktu atau tidak. Adalah konyol untuk melacak transformasi ini dengan langkah-langkah dan dinamika - hari ini setengah jam terlambat, besok 25 menit, lusa 20.

Masalah validasi terbesar adalah bahwa ini tidak selalu mungkin. Mengingat bahwa perjanjian dibuat sepanjang waktu dan dengan banyak orang, ini juga sangat padat karya .

Model manajemen di mana hampir setiap waktu yang dihabiskan manajer untuk kontrol pelaksanaan tugas ada, tetapi tidak berfungsi dengan baik di TI. Ya, dan ini adalah abad terakhir. Saya berharap bahwa pendekatan manajemen seperti itu suatu hari akan mati, seperti dinosaurus terakhir.

Daripada mengendalikan, lebih baik kita mengerti mengapa gangguan itu benar-benar terjadi - mengapa orang yang membuat janji kepada kita tidak memenuhinya.

Alasan kerusakan

Ini mungkin daftar yang tidak lengkap, tetapi di sini adalah contoh yang paling mencolok:

• Persetujuan tidak masuk akal. Seseorang setuju, karena itu memalukan untuk menolak: Anda adalah pemimpinnya atau hanya orang yang dihormati, atau dia dengan tulus ingin membantu Anda, dia menyukai Anda, atau dia tidak suka menolak sama sekali.
• Kesalahan dalam penilaian. Seseorang mungkin berpikir, setuju, tetapi membuat kesalahan dalam penilaian. Kemudian dia akan datang dan berkata: "Ya, saya berjanji, tetapi pekerjaan itu dua kali lebih banyak dari yang saya harapkan."
• Perubahan prioritas: "Saya hampir selesai, tetapi kemudian Vasya datang, ia memiliki masalah yang lebih penting, jadi saya minta maaf."
• Kurangnya sumber daya - hanya tidak cukup waktu.
• Keadaan yang tidak terduga - piano jatuh dari atas.
• Sabotase

Seringkali di balik semua alasan terletak raja perjanjian frustrasi - sabotase . Ketika kita tidak ingin melakukan dan tidak mau mengakui bahwa kita tidak ingin melakukannya, kita mendapat sabotase. Minum 40 jam seminggu untuk tugas menggunakan metode poke adalah sabotase. Datang bekerja pada jam 9 pagi dan minum kopi adalah sabotase. Ini didasarkan pada keengganan untuk melakukan, yang belum diungkapkan secara eksplisit.

Bahkan, ada lebih banyak penyebab sistemik dari kerusakan . Apa yang kami katakan terletak di permukaan, dan jika Anda menggali lebih dalam, hanya ada tiga alasan:

1. Jenis pengaturan tidak diperhitungkan.
   
2. Jenis pengaturan tidak disetujui.
   
3. Janji tanpa kewajiban.
   

Selain itu, paragraf pertama dan kedua dapat hadir sekaligus. Saat kami membuat perjanjian, kami tidak memikirkan apa yang kami setujui. Seringkali ini terdengar seperti ini:

- Aegeus, lakukan!
- OK, aku akan melakukannya! - dan melarikan diri.

Ini dapat dilakukan ketika kita berbicara tentang pekerjaan dalam pekerjaan, misalnya, tentang menulis modul: "Lakukan tugas dengan cepat 28." Tapi ini tidak bisa dilakukan ketika harus mempersiapkan pertemuan di rapat umum, misalnya. Dalam cara yang baik, untuk mempersiapkan pidato di sebuah rapat, Anda perlu duduk, menyelesaikannya, menjelaskan betapa pentingnya hal itu, dll. Tetapi seringkali kita melakukan semuanya dalam ritme yang sama : "Lakukan ini" atau "Lihat, jangan terlambat lagi!" - dan berlari .

Kebetulan kami setuju, berada dalam pemahaman yang berbeda tentang jenis perjanjian. Contoh klasik adalah dokumentasi kode. Selama masa lalu, mungkin semuanya telah berubah, tetapi ketika saya menemukan ini, rekan saya dan saya terus berdebat tentang apakah pengembang harus mendokumentasikan kode atau tidak. Sebagai seorang pemimpin, saya pikir saya harus. Pengembang, percaya bahwa kode ini berfungsi, dan baik, mengingat beban kerja dan prioritas yang terus berubah.

Konflik pemahaman tentang jenis pengaturan tidak selalu terungkap. Kita sering percaya bahwa perjanjian ini tidak perlu diklarifikasi, diperkuat, karena semuanya sudah jelas: ambil dan lakukan saja. Bawahan percaya bahwa dari dia mereka ingin dari atas apa yang tidak ingin dia lakukan. Dan kemudian sabotase dimulai .

Situasi yang paling populer, seperti yang saya katakan, adalah janji tanpa kewajiban. Perjanjian yang memunculkan janji, tetapi tidak memunculkan kewajiban, tidak akan dipenuhi karena satu dan lain alasan: piano akan jatuh, seseorang akan teralihkan, sesuatu yang lain akan terjadi.

Bahkan, dalam kondisi kompleksitas sistem, intensitas perubahan: ketika kita semua menulis dengan tergesa-gesa, cepat-cepat meluncurkannya, mengulangnya, dengan kata lain, dalam kondisi entropi, sesuatu dapat selalu terjadi yang akan mencegah pemenuhan perjanjian. Tentu saja, Anda dapat mengontrol setiap langkah, memanfaatkan setiap kasus dari masing-masing bawahan Anda, mencoba membantunya mencapai implementasi perjanjian kami. Tetapi kemudian tidak akan ada cukup waktu untuk melakukan hal lain selain menarik semuanya sendiri.

Satu-satunya kesempatan bahwa perjanjian itu akan dipenuhi adalah bahwa seseorang ingin memenuhinya.

Jika saya memiliki keinginan untuk memenuhi perjanjian, saya akan berurusan dengan semua masalah yang muncul: dengan piano yang jatuh, fakta bahwa saya membuat kesalahan dalam mengevaluasi, dll.

Ini mirip dengan ideologi Scrum, sama seperti kompleksitas tugas tidak sepenuhnya diketahui. Kami membuat beberapa asumsi dengan kesalahan pada pengalaman sebelumnya, mengevaluasi, dan kemudian hanya melakukan segalanya untuk menutup sprint. Kami mengakui bahwa ya, itu akan sulit, bahwa kami dapat membuat kesalahan di suatu tempat dalam penilaian, bahwa sistem mungkin mengejutkan kami, tetapi kami hanya akan melakukannya untuk menyelesaikan masalah.

Dengan pengaturan itu, hal yang sama harus terjadi seperti halnya sprint di Scrum. Seseorang yang telah berkomitmen untuk melakukan sesuatu harus melakukannya. Semuanya sederhana!

Ringkasnya, apa yang dikatakan tentang alasan kegagalan perjanjian:

• Janji bukanlah jaminan.
• Kontrol sulit.
• Kegagalan terungkap berdasarkan fakta.

Jelas apa yang perlu dilakukan: cukup buat perjanjian abadi yang mudah dikelola dan akhirnya pergi ke Bahama.

Bukti Kapten

Dengan kata lain:

• As Is - sistem sekarang terlihat seperti ini: pengaturan agak rapuh yang sulit dikelola.
• Untuk Menjadi - itu harus: perjanjian tidak bisa dihancurkan, manajemen yang transparan dan tidak melelahkan.

Untuk situasi analisis GAP standar, "Menjadi" adalah tujuan akhir yang kami perjuangkan, tetapi bukan fakta bahwa kami akan mencapai. Tetapi kita harus berusaha.

Masih mencari tahu apa kesepakatan yang kuat dan bagaimana mengelolanya.

Kesepakatan yang kuat

Kesepakatan yang kuat - ini adalah kewajiban nyata yang disimpulkan dengan orang yang mengikat. Ini sangat penting. Kami berbicara tentang kewajiban, seperti beberapa paket yang perlu ditransfer, dan sekarang kami akan berbicara sedikit tentang operator paket ini.

Pengaturan yang dibuat dengan orang opsional menyebabkan inkonsistensi. Jika Anda membayangkan pekerjaan dalam bentuk aliran perjanjian yang didistribusikan dalam arah yang berbeda dengan paket, maka ketika Anda mencoba untuk menyimpulkan perjanjian dengan orang opsional, bersiaplah untuk kenyataan bahwa dengan probabilitas 50% Anda akan kehilangan waktu. Karena itu, hal pertama yang harus dimulai adalah menaikkan harga sebuah kata.

Harga kata

Setiap kolega Anda idealnya memahami bahwa kewajiban melayani adalah pekerjaan utama mereka. Inilah esensi karyanya. Kode tertulis, rilis kempes adalah turunan dari kewajiban yang dipenuhi. Oleh karena itu, saya mencoba untuk berbicara dengan orang-orang secara khusus tentang kewajiban dan masalahnya bukan pada kode yang tidak ditulis atau tidak ada hasil. Ini adalah konsekuensi dan banyak rasa sakit. Tetapi inti dari masalahnya adalah bahwa, setelah menjalankan kewajiban, kami tidak menemukan cara untuk memenuhinya.

Jika Anda belum pernah membicarakan hal ini dengan orang-orang, maka ini, pada umumnya, tidak begitu jelas. Saya menduga bahwa untuk membicarakan hal ini, mungkin Anda harus terlebih dahulu menjalankan tangga dari awal laporan "hasil - kerja - tindakan - perjanjian" dan sebaliknya. , , — , , , .

, , . - . , , 10 3. , — .

, .

, — . — , .

, , .

, — : « , ».

— , . , — . , .

— . , .

, , , .

, - — .

« » . , — . , , . , . , - . , , , , :

1. , .
   
2. , .
   

, , . — — , . - . , , , . , . .

, , «» :

• .
• .
• .

— , , , , , .

, . , .

, .

. , , : , , . , , , , . , — , - , . — .

, . — , «» . , — . - , . :

— , !
— .

-: «, , . 10:55. , ».

, , 5 — , , . , : , .

— — , .

?

, : ? 4 , , - :

1. ?
   
2. ?
   
3. , ?
   
4. , ?
   

. , . , .

: «, - , , , !» , , , .

, . . - , , , , .

« » . — . , , — .

« » , - , . , , — . , . , , .

, :

• .
• .
• , , — , .
• « » . , .

, Excel, : , , , . , .

?

, , , . , …

? ? — : — , — , — .

, «» , , . «» — - . « » , « ?» « ?»

…

Tetapi pilihan untuk pergi ke TeamLead Conf atau tidak, menurut pendapat saya, sudah jelas. Apalagi programnya hampir siap. Tetapi Anda dapat memilih Moskow pada bulan Februari atau Peter pada bulan September, dan mendaftar untuk buletin sehingga Anda tidak ketinggalan video dan artikel baru, pembukaan Call for Papers dan tanggal-tanggal penting.