Rusia tidak rasional. Ada praktik-praktik yang benar, ada seratus kali perasaan menyapu, tetapi tetap saja, sesuatu yang epik terjadi dengan keteguhan yang patut ditiru. Terkadang karena alasan: "Ya, tentu saja akan membuat saya marah," kadang-kadang: "Selalu berhasil, dan bekerja," kadang-kadang hanya karena kesalahan. Mungkin dalam gen.
Contoh nyata pertama dari game luar biasa (detail sedikit berubah atas permintaan personel keamanan). Pelanggan terlibat dalam konstruksi modal. Saya memesan sistem beberapa tahun yang lalu dari kontraktor yang mengelola semua ini (khususnya, perkiraan pekerjaan). Sistem ini diinstal pada selusin objek yang agak besar, dan diperkenalkan. Tiba-tiba, pelanggan memutuskan untuk memintanya memberinya kode sumber. Ternyata, kontraktor mereka yang ada memiliki rencana bagi mereka untuk mengembangkan perangkat lunak dan kemudian menjual hasilnya sebagai SaaS di pasar. Kontrak tidak mengatakan apa-apa tentang kode tersebut. Kami bertengkar.
Ketika mereka memanggil kami untuk memahami, ada sekitar 10 versi perangkat lunak yang berbeda (rilis dari 0,9 menjadi 2,4). Ada 1,5 sumber, versi ini dikumpulkan sekali dari mereka. Tidak ada dokumentasi. Dan sistem perlu dikembangkan dan dikembangkan. Mereka menghitung "menulis ulang semuanya lagi" dan "menyelesaikan 1,5" dan menentukan yang kedua - TtM tiga hingga empat bulan terhadap tahun itu. Mereka mengajari kami cara mengumpulkan spesialis dukungan, mengoreksi sumber, mengurangi basis kode, membuat infrastruktur, mengatur satu "casting", di mana sumber diterima, dikumpulkan dan didistribusikan di sana. Itu biaya kami dan pelanggan banyak wasir.
Masuklah, saya akan menunjukkan kepada Anda sesuatu tentang bagaimana Anda dapat membuat kesalahan dengan proses pengembangan, dan apa konsekuensi menarik dari hal ini.
Contoh lain
Pelanggan - juga perusahaan yang agak besar - meluncurkan rilis ERP. Dan leluconnya adalah bahwa sistem ini sangat sehat sehingga tidak ada tempat untuk mengujinya dengan basis penuh atau yang serupa. Tidak ada infrastruktur sama sekali. Lebih tepatnya, ada, tetapi tidak mungkin untuk melakukan tes beban, hanya hal-hal kecil lokal yang diperiksa. Pembebasan meningkat - dan tidak ada yang tahu bagaimana dia akan berperilaku dalam praktik. Suatu ketika, semuanya jatuh begitu jelas sehingga ketika rilis tidak berperilaku seperti yang diinginkan. Pada akhirnya, mereka mengundang kami untuk menonton apa yang bisa dilakukan. Kami membahas bahwa mereka ingin melihat HP Performance Center, membuat pilot, kemudian terintegrasi, dilatih, dikirim. Sekarang lepaskan melalui itu. Operasi yang dinormalisasi ini diuji, ringkasan dari operasi SLA.
Atau, pelanggan negara telah datang untuk mengimpor substitusi. Bisnis datang kepada kami dan berkata: spesialis IT kami memberi tahu kami bahwa sangat sulit untuk mengganti basis Oracle dengan Postgress. Kami tidak percaya mereka, berkonsultasi. Dua minggu proses - dan hasilnya: “Ya, ya, mengubah basis itu mudah. Saat itu Anda harus menulis ulang seluruh level aplikasi. Sedikit. Sekitar 90%. Anda memiliki paket besar, Anda perlu mentransfer lapisan logika bisnis - dan datang. Pengembang yang menulis kernel tidak dapat ditemukan lagi, karena sistemnya berumur delapan tahun. " Mereka mempercayai tim IT. Ternyata mereka hanya berdebat dengan tidak jelas.
Kami mencari tempat yang aman, di
sini adalah contoh epik . Untungnya, yang ini masih sederhana, tidak ada yang melakukan apa pun selama lima tahun, dan bisnisnya tidak berskala federal.
Contoh berikut. Kami menempatkan cerita yang sama dengan penerimaan rilis. Situasi ideal: kontraktor pihak ketiga menulis kode, meneruskannya untuk pengujian, lulus tes, memasukkan semuanya ke dalam repositori, dan dari sana mengumpulkan dan mendistribusikannya. Apakah itu indah Bagus Kami telah tinggal di dalam perusahaan kami selama tiga tahun tanpa kecuali (sebelum itu, tidak ada semua departemen dan tim). Tetapi pelanggan memiliki "dana algoritma dan program". Di sana, setiap artis mengirimkan blanko atau daftar kode sumber. Mereka membara di sana. Ternyata selama audit, anime direkam pada satu disc pada umumnya. Dan bahkan jika ada kode de facto dalam dana tersebut, maka tidak masuk akal.
Pelanggan serupa lainnya. Mereka memiliki rasa sakit yang khas - banyak kontraktor. Mereka membuat integrator intra-industri, mereka memeriksa apakah kontraktor membawa perangkat lunak yang benar. Ada masalah di mana ada hak-hak pihak ketiga (perpustakaan open source dengan lisensi virus terbuka, misalnya) - kontraktor yang tidak bermoral dapat memberikan semua ini tanpa lisensi. Dalam kasus open source, Anda masih bisa mengatasi masalah tersebut, tetapi kadang-kadang perpustakaan komersial menemukan. Bersalah siapa yang akan - tebak tiga kali. Kemudian salah satu kontraktor mereka bangkrut, dan pelanggan hidup dengan kode ini. Situasi seperti itu harus ditangkap pada tahap awal. Kami membantu mengatur proses dengan benar. Kami memiliki solusi seperti otomatisasi dana algoritma dan program. Dokumentasi teknis, versi, kode sumber, kontrak, dan semua tautan ke tender. Dengan kehidupan CIO rata-rata dua hingga tiga tahun, itu benar-benar membantu yang berikutnya untuk segera mengetahuinya.
Kami juga memperkenalkan lincah di Rusia. Saya tidak menertawakan sirkus sekarang. Hampir setiap kali itu dimulai sebagai cerita modis tentang digitalisasi bisnis. Hal utama adalah bahwa setiap orang berusaha memahami apa kata-kata ini. Tapi tidak ada yang mengerti. Konsep memesan, merekrut orang asing. Mereka mengatakan kata-kata “sepertinya”, “hipotesis”, para startup diundang, akselerasi menjadi kacau, smoothie dalam keadaan mabuk - secara umum, semuanya memiliki tanda-tanda lahiriah dari semacam lembah. Kemudian Agile mulai berlaku, tetapi tidak lepas landas. Jika Anda membuat sistem yang serius, Anda perlu memeriksanya untuk waktu yang lama. Jika Anda tidak menempatkan proses, maka sprint akan lama (satu atau dua bulan), jika Anda mengatur prosesnya, Anda harus mulai dengan infrastruktur pengujian, devoop, membuat pipa pengiriman, proses kerja antara tim dan dalam tim. Dan semua ini biasanya dilupakan. Jika proses Old Believers adalah 98%, maka proyek itu tidak akan selesai. Pada akhirnya, kemudian kita menyapu dan berlari. Secara umum, kami tidak mengeluh: roti juga. Tapi kadang-kadang saya hanya ingin menjelaskan, atau apa, bahwa TI pertama-tama merupakan infrastruktur, dan kemudian mempercepat TtM. Dan bukan sebaliknya.
Apa yang biasanya salah? Kumpulan contoh
Rekan-rekan saya dan saya telah berkumpul di sini serangkaian masalah luar biasa yang tidak terlalu objektif, tetapi menggambarkan situasi dengan sangat baik. Tentu saja, kami hanya pergi ke tempat-tempat di mana itu buruk, dan tidak perlu mengekstrapolasi ke keadaan industri. Tapi tetap saja, saya yakin Anda akan belajar sesuatu dari perusahaan Anda. Sebagian kecil. Secara umum, semuanya dijelaskan oleh kata-kata: "proses inefisiensi, karyawan yang tidak termotivasi, alat yang buruk atau alat yang digunakan buruk." Nah, sekarang - contoh.
1. Hukuman untuk kesalahan dalam perangkat lunak yang dikontribusikan oleh pengembang.Saya bahkan tidak tahu bagaimana menggambarkannya secara rasional. Hanya denda untuk bug yang diidentifikasi. Hiduplah sekarang dengan pengetahuan ini. Secara alami, setiap rilis (bahkan kecil) dirilis sepuluh kali lebih lambat dari yang seharusnya.
2. Rapat dari pagi hingga sore.Pengembang harus menghadiri mereka. Dia diam dan menganggukkan kepalanya ke telepon. Ini adalah pertemuan yang sama ketika seluruh tim proyek dibutuhkan pada pertemuan tersebut, ditambah kepala departemen untuk mengendalikan. Mustahil untuk tidak datang. Tetapi hampir tidak ada gunanya berpartisipasi. Ini adalah kesalahan tradisional manajer proyek, yang disebut "kontrol berlebihan."
3. Kultus kargo. Kami mengambil metodologi yang fleksibel dan menerapkannya dengan kaku.Yang terbaik yang pernah saya lihat: diimplementasikan gesit, tetapi bekerja seperti sebelumnya. Mereka hanya membuat pengembang datang ke stand-up harian. Mereka dibangun dan mengatakan: Saya tidak melakukan apa pun. Itu terjadi setiap hari.
4. Alat: kami menerapkan untuk melaporkan yang diterapkan."Kami memiliki server Integrasi Continious, dan hanya administrator yang dapat menambahkan tugas." "Kami telah menerapkan repositori rakitan biner, dan ada disk yang sangat kecil, Anda perlu menghapus yang lama, dan hanya ada tiga versi terakhir." Atau di sini: sistem manajemen tugas dalam file-ex pada disk bersama. Jadi jaminan sering memimpin bahkan di perusahaan besar, terlepas dari kenyataan bahwa ada Jira. Dalam hal ini, sampai tugas jatuh ke file ini, tidak ada yang akan melakukannya. Dia resmi.
Perusahaan lain memiliki basis pengetahuan internal, tetapi semuanya disimpan langsung dalam sistem kontrol versi: lebih nyaman bagi manajer. Distribusi sistem operasi bahkan menambahkan di sana. Ketika tidak ada orang yang bertanggung jawab atas sistem kontrol versi, manajer dapat meletakkan file gigabyte untuk mentransfernya ke rekanan, karena di Dropbox tempat itu telah habis.
5. Standar pengkodean: ditulis tanpa pemahaman atau tidak diperbarui selama 10 tahun.Hanya beberapa contoh: kami memerlukan 100% cakupan kode dengan tes dan dokumentasi. Secara khusus, semua perpustakaan pihak ketiga. Kelemahannya adalah tidak adanya tes standar. Baru-baru ini saya melihat bagaimana seorang insinyur menggunakan sistem, dan pengguna tidak dapat masuk, karena kunci dari tes ke prod tidak berubah.
Sekali lagi saya melihat bagaimana pemimpin menulis kode di Notepad.exe, lalu melemparkannya ke kompiler tanpa kesalahan. Dia masih belajar dengan kartu punch. Keterampilan seperti itu tentu patut dihormati. Tetapi hanya sampai deformasi profesional ini mulai mempengaruhi standar untuk departemen pengembangan lainnya.
6. Kesalahan regulasi.Misalnya, waktu makan siang yang tetap, yang sepenuhnya berjalan. Ini adalah gejala. Saya bertanya mengapa. Mereka menjelaskan: jika Anda duduk di tempat kerja saat makan siang, maka Anda adalah targetnya. Harus merespons surat dalam lima menit dan seterusnya.
Birokratisasi yang berlebihan: seringkali mengikuti prosedur terdokumentasi yang mengarah ke tumpukan kertas. Rencana tes yang sama untuk setiap bersin. Dan ini adalah deskripsi setiap filter, termasuk tipe data di setiap bidang antarmuka, panjang bidang, dan sebagainya. Ini biasanya diselesaikan dengan contoh, dan bukan dengan detail lengkap.
Di satu perusahaan tidak ada orang yang bertanggung jawab atas rilis saat ini, kadang-kadang tenggat waktu untuk merilis produk selama dua minggu telah rusak.
Komunikasi: sesuatu datang dari pelanggan melalui pos. Selain itu, ia menulis surat kepada orang yang terakhir berbicara dengannya. Bahkan jika Anda ingin melakukan ini, komentar tentang tugas tersebut dapat di tempat yang berbeda, termasuk pengirim pesan instan. Lalu seseorang pergi, seseorang datang, seseorang menghapus surat - itu saja.
7. Memerangi penjaga keamanan.Ini termasuk pembaruan manual dari semua sistem (dan Anda harus secara otomatis menumpahkannya, ini menghemat banyak waktu), solusi fisik dengan flash drive melalui node jaringan, alokasi port selama tiga minggu, dan sebagainya.
8. Komunikasi antara pengembang dan analis tidak terjalin.Ini adalah tiang tembok yang diulang pada setiap proyek kelima. Hanya analis yang menulis apa yang dibutuhkan, pengembang mengembangkannya dan sebulan kemudian menunjukkan siap. Analis berjalan ngeri karena dia tidak bermaksud ini. Selama tiga minggu bulan ini, pengembang bekerja dengan sia-sia, meskipun ia dapat menunjukkan bagian dari proyek, dan analis dapat bertanya bagaimana keadaannya. Ada metodologi yang hanya menutup ini, tetapi masalahnya adalah bahwa dalam situasi ini kedua belah pihak tidak mengerti mengapa proyek diperlukan dan bagaimana kelanjutannya.
9. Pembangunan Berbasis Konferensi.Pemimpin melihat sesuatu yang keren di konferensi, dan mereka memperkenalkannya tanpa jejak. Tiga bulan kemudian diulang. Hasilnya, laporan itu indah, tetapi pekerjaan itu sepadan.
Karena konferensi internal, masih memungkinkan untuk membawa ke hasil sesuai dengan skema "Selalu 80% siap". Pada laporan publik - "Hampir selesai," dan itu tidak ada habisnya. Membawa 100% tidak pernah terjadi. Mengapa Misalnya, lihat poin 1.
Secara terpisah, saya perhatikan pemeriksaan sistem pihak ketiga. Anda membaca artikel - wow, keren, mari kita gunakan, lalu pelajari caranya. Dan Anda menemukan banyak batasan, karena penjual hanya menuangkan madu ke telinganya hanya pada dua pertemuan pertama. Kami sendiri melangkah menyapu. Ada implementasi internal sistem untuk toko online dokumentasi tentang desain infrastruktur, termasuk. Pusat data untuk objek yang sangat menarik. Kasus pembatasan biaya barang 100 juta ditemukan. Kuncinya adalah bahwa di area subjek harga unit dokumen lebih tinggi. Dan di sana, sistem harus menyekop indeks untuk mencari, dan kami memiliki investasi 1 gigabyte dalam dokumen. Dan waktu pengindeksan yang diharapkan adalah satu bulan. Penjual tidak memperingatkan tentang ini.
10. Menakutkan untuk melakukan perubahan.Ada keadaan proyek seperti itu: Anda perlu refactoring, kembali dalam sebulan. Tetapi tidak ada tes, tidak ada dokumen, tidak ada. Dan para pengembang duduk: "Kami takut melakukan perubahan, kami takut merusak segalanya."
Saya juga melihat bagaimana satu perusahaan mengembangkan integrasi dengan sistem yang tidak dapat digunakan di sisi pengembang, karena sangat sulit. Penguji menguji transfer data oleh layanan (sejauh mungkin). Keluar ke tempat pelanggan sebelum pengiriman - dan dua minggu perbaikan lagi, karena model transaksi salah. Ini adalah praktik yang baik untuk membuat tulisan rintisan untuk sistem ini yang mengembalikan beberapa jenis jawaban. Hasilnya, mereka melakukannya, jadi lebih mudah untuk menguji dan menerima.
Pelanggan lain dapat menulis deskripsi ekonomi dalam bahasa biasanya. Pada proyek itu, kami memberikan semacam konstruktor semu-bahasa (seperangkat standar), yang kemudian dikonversi menjadi data analis. Dalam semangat "Jika Vanya sedang cuti sakit, maka dia tidak akan bisa pergi ke produksi."
Dan akord terakhir. Orang lain dalam satu perusahaan mengkodekan langsung pada prod. "Ada satu biola kecil, aku tahu apa yang aku lakukan." Terima kasih, kawan, tetapi jika saya menemukan Anda, saya bahkan tidak tahu apa yang harus dilakukan dengan Anda.
Secara umum, berbicara. Jika Anda menemukan masalah Anda, tulis ke oeremeev@croc.ru. Untuk bisnis besar, kami memiliki hampir pilot gratis dengan diagnostik ekspres (mencari kemacetan dalam 3-5 hari). Jika seseorang dari bisnis Anda perlu dijelaskan bahwa tidak mungkin untuk membayar hutang teknis, - tulis juga, kita dapat menghitung ini secara normal.