Artikel Seorang programmer seharusnya tidak memecahkan masalah bisnis yang menyebabkan diskusi yang kuat (dan bahkan jawaban dengan pernyataan sebaliknya).Dan, itu lucu bahwa semuanya berujung pada alasan dogmatis dari kategori "programmer must", atau "business should". Seolah, kita berbicara tentang sistem yang berfungsi untuk tujuan bersama, dan satu-satunya masalah adalah mengkonfigurasinya dengan benar.Faktanya, semuanya jauh lebih rumit, dan bisnis dengan seorang programmer memiliki tujuan yang sangat berbeda. Oleh karena itu, berbicara tentang siapa, siapa, dan apa yang harus, sepertinya pernyataan bahwa pembeli tidak boleh mencuri barang di toko. Ya, seharusnya tidak. Lebih tepatnya, dia tidak boleh mencuri, jika dia berbicara sesuai dengan aturan logika formal. Sederhana, dapat dimengerti, diterima oleh mayoritas. Terus? Apakah ini berarti toko dapat memecat penjaga dan menurunkan kamera?Dalam artikel pertama saya di Habré, saya mempertimbangkan situasi dari sudut pandang majikan (bisnis), dan menjelaskan prinsip-prinsip yang saya ikuti untuk menemukan orang yang akan menyelesaikan masalah bisnis . Dan mengapa ini sangat penting.Tetapi ada satu peringatan, dan itu adalah bahwa orang-orang yang tidak diambil oleh pewawancara seperti saya, dengan ketangkasan karena, mencapai lebih dari mereka yang mendapat manfaat. Dan ada alasan bagus untuk ini - mereka berhasil memaksimalkan keterampilan yang paling berkorelasi dengan pendapatan programmer - kemampuan untuk menjual diri sendiri. Bagaimana, - Saya akan ceritakan pada postingan ini.Disclamer, . . , , , , Junior -> Middle -> Senior -> Lead dev -> Tech lead -> Architect -> Chief architect -> CTO.
Perumusan masalah
Pertama-tama, kami akan mencari tahu apa yang ingin dicapai oleh masing-masing pihak:Bisnis menginginkan solusi yang murah dan tepat waktu untuk tugas-tugas TI, memenuhi harapan, dan, dalam hal manajemen yang maju, juga menciptakan peluang pengembangan bisnis baru.Programmer ingin menumbuhkan nilainya di pasar tenaga kerja, memaksimalkan kondisi kerja (termasuk $, jadwal, kontrol ketat, manfaat & fasilitas), memecahkan masalah dengan mana Anda dapat meningkatkan kredibilitas Anda, dan mendapatkan kepuasan dari solusi.Konflik
Sebenarnya, mudah untuk memberikan contoh di mana ada win-win, seperti mengembangkan kernel DBMS, di mana seorang programmer memecahkan aplikasi atipikal dari tingkat Olimpiade, menyeret dirinya sendiri dari ini, berbicara di konferensi, dan kemudian penjualan meningkatkan penjualan, menunjukkan kepada pelanggan cara efisiensi dan stabilitas inti daripada pesaing, mereka akan menghemat infrastruktur.Tetapi kami tidak akan membicarakan kasus seperti itu. Mari kita bicara tentang kasus-kasus yang dihadapi oleh sebagian besar programmer yang membuat keputusan biasa berulang-ulang. Toko online lain, kasino online lain, hari operasi lain untuk bisnis perbankan non-teknologi biasa ...Dan ada konflik akut. Karena solusi yang tepat waktu, andal, dapat diprediksi, murah, dan didukung dengan baik dibuat berdasarkan teknologi yang telah teruji waktu. Secara kondisional, jika panel admin toko online Anda dengan inti ASP.NET ditulis dalam WebForms, dan pembuat kode masih tidak akan meninggalkan Anda, maka panel kontrol dari sistem rekomendasi yang baru dibuat juga harus ditulis dalam WebForms, meskipun bundel .NET Core + Angular + TypeScript 1000 kali lebih baik, dan memang WebForms berantakan. Bagaimanapun, tim yang menulis 500 formulir akan menulis 501 dengan cepat, andal, melewati penggaruk. Dan bisnis akan mendapatkan solusi yang baik.Untuk programmer yang telah menyadari nilai WebForms di pasar, menulisnya bisa seperti penyiksaan, karena mereka sangat memahami bahwa selama penulisan formulir ini, mereka akan meningkatkan nilai bisnis, tetapi pada saat yang sama menurunkan nilai mereka, karena saat Anda diam, industri berlari melewati Anda. Oleh karena itu, dalam situasi ini, setiap programmer yang waras (meskipun ia adalah co-owner, bagaimanapun juga, tidak ada yang akan menjamin bahwa toko akan hidup selamanya, dan akan sangat menyakitkan untuk mencari pekerjaan jika terjadi kebangkrutan toko) akan mencoba entah bagaimana mendapatkan hak untuk menyelesaikan tugas pada sesuatu kemudian segar dan laris, tentu saja, menghabiskan lebih banyak waktu pada saat yang sama, memungkinkan lebih banyak bug, menginjak lebih banyak garu.Jelas bahwa situasi ini dilebih-lebihkan. Tetapi esensinya tetap sama terlepas dari domain dan teknologi.Kode sederhana pada solusi tim yang teruji waktu, non-HYIP, yang terkenal memberikan prediktabilitas dan keandalan bisnis, dan tim tersebut mengalami penurunan. Kode pada kerangka hype baru dan / atau dengan kompleksitas algoritme tinggi memberikan pengembangan kepada tim, tetapi bisnis menanggung risiko untuk ini. Fokus pada pemahaman mendalam tentang area subjek oleh programmer dapat secara signifikan meningkatkan nilai bisnis (untuk menulis apa yang diperlukan dan tidak menulis apa yang tidak perlu), tetapi tidak meningkatkan nilai programmer (pengetahuan akuntansi jarang ditanyakan di atas di pasar untuk programmer) pada teknologi dan algoritma, sebaliknya.Lagi pula, seorang programmer yang sangat memahami algoritma dan teknologi dengan mudah menemukan pekerjaan dengan dorongan, sedangkan untuk bisnis sebagian besar pengetahuan itu berlebihan dan tidak dapat diterapkan. Dan layanan yang ditulis pada kerangka kerja modis dengan penggunaan pola yang benar dan kompleksitas algoritme yang benar tidak akan banyak membantu bisnis jika tidak melakukan apa yang diharapkan.Ya, ada beberapa faktor samping. Sebagai contoh, topik-topik hype menyederhanakan perekrutan, dan warisan neraka mengurangi arus personel yang ada (orang ingin pergi, tetapi tidak ke mana-mana), tetapi ini adalah nuansa, dan itu tidak begitu penting.Solusi
Jadi, mari kita bayangkan saat ketika programmer menyadari bahwa bisnis ingin sedikit menghadiahinya (oke, katakanlah, menunda perkembangannya) demi tujuan bersama. Apa yang bisa dilakukan?Mematuhi. Dan kalah dalam kepentingan mereka sendiri. Komentar berlebihan.Langsung menuju konflik. Jadi bisa dikatakan, mereka bilang aku bukan budak bagimu. Jika Anda menginginkan kode copy-paste primitif dengan pengetahuan akuntansi yang mendalam, cari orang bodoh. Saya tidak akan melakukannya. Mungkin sekali naik. Tetapi tidak perlu membicarakan karier di sini.Untuk meyakinkan bisnis bahwa mereka membutuhkan apa yang Anda butuhkan.Ini adalah salah satu opsi yang benar untuk programmer. Ya, sulit untuk mencapai dengan manajer tingkat teknis yang tinggi dan keterampilan persuasi yang rendah dari programmer. Tapi selalu patut dicoba. Setelah kalah, Anda selalu dapat memilih p1, dan menyimpan hingga waktu berikutnya. Dan dengan menang, Anda mendapatkan rasa hormat dan rasa nilai dari bisnis dan pertumbuhan profesional Anda secara bersamaan.Satu-satunya pertanyaan adalah bagaimana cara mendapatkan grail suci ini?Di sini kita akan melihat beberapa kisah menarik.Sejarah 1. Tentang kepala departemen dengan mudah
Vasily adalah salah satu programmer paling berpengalaman di perusahaan. Selama karir dua puluh tahun, ia telah berkembang dari seorang programmer junior menjadi kepala departemen. Dia memiliki 40 orang dengan bawahan langsung, menyelesaikan masalah langsung dengan pendiri, dan tidak dengan CEO dan wakilnya, seperti manajer lain di levelnya. Dan masih kencing kode untuk tetap bugar. Dia membuat kariernya karena dia memiliki kecerdasan yang luar biasa, dan, di samping itu, bisnis dapat berkomunikasi dengannya dalam bahasa yang sama. Sebelum ini, Vasily berada dalam perlombaan yang konstan. Dia membuat janji, dan dengan sekuat tenaga mencapainya. Untuk ini dia dipuja. Ya, dikabarkan bahwa ia selalu meminta tenggat waktu terlalu lama, tetapi, di sisi lain, ia jarang memindahkannya lebih sering daripada kepala departemen lainnya.Dan kemudian dia diakui sebagai manajer terbaik tahun ini, mereka mulai menetapkan semua orang sebagai contoh, dan Vasily (yang dalam hatinya tidak pernah berhenti menjadi seorang programmer) menyadari bahwa sudah waktunya untuk mempelajari teknologi baru, dan dengan mengorbankan bawahannya untuk bereksperimen dengan pendekatan baru, khususnya, dengan DDD.Produk unggulan dari departemen Vasily, stasiun kerja otomatis (AWP) dari pedagang berjangka, membantu menghasilkan banyak uang, dan selama bertahun-tahun beroperasi hampir semua bug terperangkap di dalamnya dan dipoles hingga bersinar. Masalahnya adalah itu adalah aplikasi desktop untuk Windows (sementara semua orang di sekitar beralih ke web), dan menggunakan MSSQL sebagai DBMS, yang, menurut Vasily, juga merupakan zaman batu, karena DBMS relasional digunakan ketika orang-orang tidak belajar cara membuat pangkalan normal.Dan sekarang kita berbicara tentang perlunya menulis tempat kerja otomatis untuk trader opsional. Proyek itu sekitar 6 bulan, termasuk memasuki topik tim baru dan pengujian beta, jika kita memotong lobak terminal berjangka, dan mengganti sejumlah modul. Tapi, sialnya, untuk membuat produk lain menggunakan teknologi yang sudah ketinggalan zaman ... Yah ini tidak menarik. Ya, dan orang-orang harus berburu di atas pasar, karena tidak ada yang ingin memanfaatkan hal-hal seperti itu (dan kemampuan untuk berburu dan menjaga orang 20% di bawah pasar adalah fitur pembunuh Vasily), dan karena itu, fakta perburuan di atas pasar akan mengguncang reputasinya.Oleh karena itu, apa yang dilakukan Vasily - dia meyakinkan CEO bahwa demi keuntungan dan stabilitas bisnis, semuanya harus ditulis dengan 0, tim baru, selalu di bawah web, dan bukan satu byte dari solusi lama, walaupun itu akan memakan waktu 2 tahun. Mengingat reputasi dan pengalaman kariernya, itu tidak sulit.Dua tahun kemudian, keputusannya diambil. Kerangka kerja baru, MongoDB, DDD, bekerja dari browser, bukan byte tunggal dari terminal untuk masa depan ... Benar, pegunungan copy-paste, arsitektur yang tidak memungkinkan pengintegrasian algoritma tanpa kruk, ditulis ulang dari 0 modul, di mana algoritma elegan dari workstation futures digantikan oleh banyak kode boilerplate. Basil, bagaimanapun, mengangkat otoritasnya dengan cukup baik. Workstation opsional telah lama dikutip sebagai contoh bagi manajer lain. Setelah beberapa tahun, Vasily masih merasa malu, tapi itu cerita lain.Secara total, intinya: Dengan mudah menemukan teknologi baru, menggembungkan staf, meningkatkan kepentingannya, dan bisnis tetap sepenuhnya yakin bahwa itu membantu bisnis dan sekali lagi memenuhi janjinya.Sejarah 2. Tentang perawan utama Anton
Anton, yang berusia 30-an, gemar mempelajari teknologi baru dan memecahkan masalah olimpiade. Dia menempati tempat yang hampir ideal untuk tipenya, - adalah pemimpin utama tim infrastruktur. Anton tahu spesifikasi dan tren arsitektur terbaru dengan sangat baik. Dan tantangan intelektual favorit Anton adalah mengemukakan alasan mengapa teknologi hype akan membantu bisnis, dan di mana tepatnya layak untuk mendorongnya. Dalam hal ini ia didukung oleh sang arsitek, yang juga tidak segan-segan menyelidiki rake baru dengan dahi Anton. Alhasil, Anton diundang untuk berbicara dengan FAANG, di mana ia melewati seluruh bagian teoretis tanpa masalah, dan dengan cemerlang menyelesaikan tugas merancang arsitektur Ebay (meskipun tidak ada hal semacam itu diperlukan dalam karya sebelumnya). Kemudian dia berlayar di AS, dan meninggalkannya 3 modul yang sangat dimuat di prod, yang sekarang tidak ada yang ingin mempertahankan dan mengembangkan,karena tidak ada yang mengerti bagaimana (dan mengapa) mereka bekerja.Total, pada intinya: Anton jelas tahu apa yang diinginkannya dan mencapai tujuannya, mengambil yang maksimum dari atasannya. Bisnis itu juga yakin bahwa anton adalah karyawan yang sangat berharga, karena, seperti yang telah saya sebutkan, dia selalu dengan hati-hati memikirkan alasannya, bahkan ketika mereka liar untuk orang-orang dalam subjek.Kisah arsitek Ivan
Timlid Ivan dan Timlides Vladimir dan Yuri menggergaji produk di bawah kepemimpinan arsitek Sergey. Sergey membawa mereka bertiga ke perusahaan, dan mereka berempat membuat keputusan penting. Setelah produk mulai dijual dalam 4 tahun beroperasi, tetapi masih jauh dari stabilitas, kepemimpinan menyerang Sergey dan dia pergi dengan kepala terangkat tinggi. Mengikutinya, Vladimir dan Yuri pergi.Pada satu titik, Ivan menjadi satu-satunya pembawa pengetahuan tentang apa yang ditulis (kecuali untuk senior dan menengah, yang Sergei tidak secara khusus mengabdikan diri pada visi umum). Merasa bahwa itu berbau goreng, pimpinan menunjuk Ivan sebagai seorang arsitek dengan staf yang sesuai dengan harapan bahwa ia tidak akan pergi. Untuk yang dikatakan Ivan, mereka berkata, ini, tentu saja, bagus, tetapi ini tidak cukup sehingga saya tidak pergi. Jika Anda ingin saya mendukung apa yang kami lihat dengan Sergey, maka izinkan saya menulis ulang semuanya dengan 0. Bisnis dengan enggan disetujui. Ivan menerima gaji, posisi, dan kemampuan untuk menulis semuanya mulai dari 0 dalam satu hari.Total: Ivan memahami dengan benar apa masalah bisnisnya - bisnis itu panik karena apa yang mereka lihat selama waktu Sergey mungkin gagal, dan tidak ada yang mengatasinya. Dan dia menekan bisnisnya secara maksimal.Total
Apakah Anda menginginkannya atau tidak, tetapi demi karier, $ dan kesempatan untuk melakukan hal-hal yang menarik bagi diri Anda sendiri, Anda setidaknya harus berbicara dan memikirkan nilai bisnis. Ya, Anda bisa membawanya, tidak membawanya, atau bahkan membawa yang negatif. Tetapi dalam sistem hubungan ini, semakin lama rantai nilai yang Anda kontrol untuk orang yang membayar terlihat semakin lama, semakin kuat akan posisi negosiasi dan kemampuan untuk melakukan apa yang Anda inginkan, daripada menyatakan.