Sebagian besar proyek TI yang saya lihat dalam hidup saya sangat sukses. Mereka dilakukan di perusahaan yang berbeda, di berbagai platform, oleh orang yang sama sekali berbeda. Tetapi kesuksesan selalu datang, dengan pengecualian langka.
Setiap kali saya bertanya-tanya di mana tim TI memiliki tujuan yang sedemikian rupa, strategi dan penerapannya yang halus, pemahaman tentang situasi dan keinginan yang kuat untuk mengikuti jalur yang dipilih? Adakah rahasia untuk sukses?
Saya melihat, menganalisis, dan menyusun daftar algoritma yang berhasil mengarahkan proyek-proyek TI ke tujuan. Mari kita mulai dengan tujuan - mengapa ini berhasil dicapai?
Perhatian Artikel ini hanya untuk orang-orang IT. Jika Anda bukan dari IT, atau, Tuhan melarang, beberapa direktur atau pemilik, Anda sebaiknya tidak membaca artikel ini. Jika tidak, Anda merusak segalanya untuk kami.
Dan lagi perhatian . Artikel ini bukan sarkasme, bukan upaya untuk menghancurkan seseorang, bukan gradasi pasar, atau peningkatan FGM siapa pun, termasuk punyaku. Saya, seperti spesialis TI mana pun, dan perusahaan tempat saya bekerja, seperti perusahaan TI lainnya, sesuai dengan definisi dalam artikel ini.
Tujuan
Saya akan mencoba menjelaskan tujuan proyek TI. Tidak fiktif, diumumkan di surat kabar, di rapat umum, atau di kantor jenderal yang kaya perabotan. Tujuan nyata.
Tujuannya, kesadaran dan pemahamannya, sangat penting dalam aktivitas apa pun. Dan tidak masalah apakah tujuan sebenarnya dalam sistem nilai itu baik atau buruk. Jika satu tujuan dinyatakan, tetapi dalam kenyataan, atau bahkan di alam bawah sadar, yang
lain duduk, maka yang lain akan tercapai.
Tapi, sayangnya, stereotip yang salah telah dibuat dalam hubungan antara IT dan bisnis. Sebagian besar proyek TI dianggap gagal. Beberapa analis mengumpulkan statistik, menghitung sesuatu, kemudian menulis artikel yang menghancurkan tentang bagaimana TI tidak membantu bisnis, tidak mencapai tujuannya, menghasilkan pengganti, merampok jutaan perusahaan yang tidak bahagia dalam mata uang apa pun.
Kesalahan para analis ini sangat sederhana: mereka dinilai oleh bisnis. Otomatis, bukan otomatis. Proyek dievaluasi tidak dalam sistem koordinat di mana mereka dilaksanakan. Mereka melihat pencapaian tujuan yang pernah seseorang, sekali, di awal, untuk beberapa alasan katakan atau tulis. Dan mereka tidak tahu tentang tujuan nyata.
Singkatnya, tujuan sebenarnya dari proyek TI adalah empat:
1. tanaman;
2. untuk semen;
3. memeras;
4. untuk belajar.
Kaitkan dirimu
Untuk menanam - ini semua adalah proyek untuk implementasi 1C. Ini juga termasuk otomatisasi pada kerangka kerja atau perangkat lunak yang tidak terdistribusi dengan baik. Ini govnokod, "yang hanya aku yang tahu."
Setelah menerapkan 1C, klien selalu duduk pada apa yang disebut "Dukungan informasi dan teknologi." Dalam bahasa Rusia, ini adalah biaya berlangganan untuk akses ke pembaruan. Tidak ada gunanya untuk menantang perlunya pembaruan - itu dilemparkan oleh negara. 20% PPN, berbagai jenis undang-undang federal, meja kas online, EGAIS, dll. - semua ini tercermin dalam program 1C dan, oleh karena itu, perlu diperbarui.
Demikian pula - Bitrix. Siapa pun yang membangun situs di atasnya, seseorang harus membayar untuk pembaruan dan ketersediaan dukungan teknis.
Demikian pula dengan layanan online apa pun, baik itu manajemen dokumen elektronik, kartu, rekonsiliasi penyelesaian atau verifikasi rekanan. Sebagian besar dari mereka memerlukan beberapa pekerjaan untuk tertanam dalam sistem perusahaan, dan semakin banyak uang dan upaya yang dihabiskan untuk itu, semakin sulit pula untuk menolak.
Waktu di mana klien duduk bekerja melawannya dan keberhasilan penjual perangkat lunak atau layanan. Bahkan jika mereka hanya mengambil pembaruan, tanpa modifikasi pesanan, jumlah yang dibayarkan meningkat setiap bulan, dan penolakan terhadap perangkat lunak atau layanan akan berarti bahwa uang telah terbuang sia-sia.
Tujuannya sederhana - untuk memastikan bahwa klien, sekali bekerja dengan Anda, bahkan untuk tugas kecil, tidak pernah melompat dan terus memesan produk dan layanan baru dari Anda.
Dengan pendekatan yang tepat, ini bekerja lebih baik daripada untuk drag dealer - di sana Anda setidaknya dapat mengubah "pemasok", barang-barangnya sama. Tetapi jika Anda menulis kepada klien, misalnya, "mengoptimalkan pembongkaran barang ke situs", tetapi tidak lupa tentang kebingungan, dan menggunakan beberapa konstanta rumit yang hanya diatur dalam database khusus ini, maka klien adalah milik Anda.
Penting, seperti kata mereka, untuk
masuk . Tangkap, setidaknya untuk tepi.
Menanam mungkin adalah tujuan paling umum dari proyek TI.
Untuk semen
Semen adalah tujuan favorit otomasi internal. Perbedaan antara pemrogram pabrik, atau perbaikan, adalah bahwa mereka tidak menerima pendapatan dari pelaksanaan proyek. Tentu saja, ada bonus, tetapi jika Anda menodai mereka dari tahun ke tahun, Anda mendapatkan sangat kecil. Gaji jauh lebih sederhana dan lebih stabil, selain itu selalu ada kemungkinan pekerjaan paruh waktu.
Pemrogram pabrik berpikir seperti seorang prajurit yang sedang tidur, dan layanannya hidup. Karenanya, keinginan alami adalah meningkatkan efisiensi hari kerja Anda. Ingat apa itu efisiensi? Ini adalah biaya untuk menghasilkan hasilnya.
Hasilnya sama - gaji. Biaya adalah upaya. Gaji tidak dapat ditingkatkan, tetapi upaya dapat dikurangi. Inilah bagaimana efisiensi meningkat.
Cara paling sederhana adalah govnokod, "mencerminkan persyaratan pengguna sebanyak mungkin". Yang kami maksud dengan govnokod adalah kode itu sendiri, dan metadata, dan "tombolnya ada di sini." Tidak ada analisis persyaratan, kepatuhan dengan arsitektur dan strategi keseluruhan, "hanya untuk bekerja."
Ketika berhasil, itu semen. Semua orang takut menyentuh apa yang berhasil, baik programmer, pengguna, dan manajer. Setiap revolusioner yang mulai berteriak "kita perlu refactoring" akan diusir, dipermalukan, dipermalukan, dituduh ingin memperbaiki dirinya sendiri dan merusak bisnis kehidupan.
Jika "berhasil" - semuanya baik-baik saja dan pemrogram dilakukan dengan baik. Dia terus menerima gajinya. Semakin banyak area dalam sistem informasi yang "bekerja", semakin sedikit programmer memiliki pekerjaan. Yang tersisa hanyalah dukungan - jawaban untuk pertanyaan yang sama, demonstrasi bentuk dan alat yang sama, solusi untuk masalah yang sama. Sederhana dan stabil, seperti seorang prajurit.
Proyek otomasi tidak diremehkan oleh proyek otomasi oleh kontraktor eksternal, terutama pada akhirnya. Misalnya, suatu tindakan harus ditandatangani. Selama dua bulan mereka melakukan "seperti yang diharapkan", tetapi direktur dari pusat membutuhkan uang, kalau tidak, ia akan berhenti membayar gaji. Sangat mendesak untuk membuat klien bahagia. Bagaimana? Semen seperti pemrogram pabrik. Govnokodom.
Peras
Memeras adalah tujuan, sebagai aturan, bagi mereka yang tidak yakin dengan diri mereka sendiri. Misalnya, ada bola kecil pada implementasi 1C. Itu terganggu oleh pekerjaan kecil pada pembaruan dan formulir pencetakan, menjual kotak murah, konsultasi kebakaran kios selama pelaporan.
Dan di sini - ny, kebahagiaan jatuh. Proyek Saya tidak tahu di mana, mungkin - secara tidak sengaja, mereka dipercaya untuk memperkenalkan solusi besar dan serius. Apa yang harus dilakukan Tidak ada pengalaman, tidak ada spesialis juga.
Cobalah untuk secara bodoh meraih secara maksimal. Pembayaran - berdasarkan jam, atau tindakan singkat, tidak lebih dari sebulan. Tidak ada ikatan pembayaran dengan tujuan, indikator bisnis, kelengkapan dan bid'ah sejenisnya. Risiko minimum, uang maksimum.
Demikian pula, spesialis yang bukan spesialis, tetapi harus bekerja di tempat yang layak, misalnya, dengan gaji tinggi, melakukan hal yang sama. Mereka mencoba membusungkan pipi mereka, tidak mengkhianati ketidakmampuan mereka, mereka tidak pernah merinci, mereka selalu menunda membuat keputusan dan mulai bekerja.
Sebagai contoh, di salah satu perusahaan, direktur TI mengambil orang yang tidak melihat 1C di mata. Dan mereka mengambil untuk memecahkan masalah khusus - implementasi 1C. Pada wawancara ia berhasil berbelanja secara royal, ia diambil dengan gaji yang layak, dan ia bertahan satu tahun. Hanya ketika mereka menyematkannya ke dinding, dia mengakui bahwa dia tidak tahu 1C. Berhenti saja, dan pergi mencari perusahaan berikutnya yang bisa Anda peras.
Untuk belajar
Jarang, tetapi itu terjadi. Perusahaan muda ingin masuk ke pasar sistem ERP. Atau perusahaan lama ingin mengembangkan arah baru. Atau secara umum strateginya adalah melatih spesialis baru, memasukkan mereka ke dalamnya.
Kedengarannya indah - membuang panas. Seperti perumpamaan terkenal tentang cara belajar berenang, melempar ke air. Tetapi pada kenyataannya, jika Anda tidak membohongi diri sendiri, kami hanya melatih spesialis kami untuk mendapatkan uang dari pelanggan.
Mengapa menyembunyikannya - Saya sendiri telah berada dalam situasi yang sama. Hanya satu bulan telah berlalu sejak saya pertama kali melihat 1C di mata saya, dan sekarang saya sudah pada proyek untuk memperkenalkan konfigurasi yang paling kompleks (pada waktu itu) - "Manajemen Perusahaan Produksi". Hanya karena produk itu baru, baru saja muncul, dan proyek implementasi pertama perusahaan. Selain itu, dia adalah yang pertama di kota, dan mungkin di wilayah tersebut.
Tentu saja, saya belajar banyak dari proyek itu. Dan pelanggan membayar semua ini. Sudah cukup bagi manajer proyek pada pertemuan itu di mana mereka mewakili saya untuk mengangguk setuju sebagai jawaban atas pertanyaan "Apakah dia tahu yang delapan?"
Saya tidak mengutuk pendekatan semacam itu sama sekali - terutama karena saya sering menggunakannya sendiri, dan saya terus mempraktikkannya. Pelanggan, pada dasarnya, tidak tahu apa yang spesialis pahami. Biaya satu jam kerja sama untuk pemula dan satu bison. Seorang pemula akan melakukan seminggu, satu bison - dua jam. Pelanggan akan membayar seminggu. Apa yang salah
Ada proyek lain untuk dipelajari. Misalnya, pengenalan produk baru yang baru saja dikembangkan. Kebetulan pelanggan menerima produk ini secara gratis. Mungkin bahkan layanan implementasi, atau bagian dari mereka. Saya sendiri mengambil pendekatan ini. Gratis itu baik - itu menghilangkan risiko.
Kombinasi dan Transformasi
Tujuan proyek dapat berubah selama pelaksanaannya, tergantung pada situasinya. Ini adalah proses yang normal dan hidup.
Di atas, saya memberikan contoh bagaimana proyek dengan tujuan penanaman dapat mulai disemen - ketika perlu untuk menandatangani suatu tindakan. Ini biasanya terjadi ketika ada ancaman gangguan terhadap proyek.
Namun, tidak perlu untuk semen, mungkin untuk memeras. Misalnya, situasi - selama implementasi, beberapa tahap telah dimulai sekaligus. Di suatu tempat ada pelatihan, di suatu tempat pengujian, di suatu tempat operasi tes. Dan sekarang ada ancaman umum gangguan terhadap proyek - Anda tidak pernah tahu, pembuat keputusan telah berubah.
Sebagian langkah dapat disemen, jika memungkinkan. Semen cenderung mendapatkan jumlah penuh untuk fase proyek. Tetapi kebetulan bahwa tahap ini hanya pada tahap pengembangan, meskipun satu langkah dari produksi - maka masih jauh dari penyemenan, pelanggan bahkan belum melihat prototipe. Atau, Anda dapat mencoba memeras - menandatangani tindakan untuk bagian dari jumlah tersebut. Misalkan, hanya untuk pengembangan, menambahkan frasa "untuk waktu yang sebenarnya dihabiskan".
Ada juga transformasi terbalik - mereka mulai sebagai "pemerasan", dipikirkan sepanjang jalan, dan kami melakukannya "kaitkan pada diri kita sendiri". Atau begitu disemen sehingga tepat untuk memeras sisa makanan dan lari.
Sekarang setelah Anda mengetahui tujuan-tujuan ini, lihatlah proyek-proyek TI yang Anda lihat. Apakah mereka telah mencapai salah satu dari mereka?
Ringkasan
Percaya atau tidak, artikel itu lahir secara spontan. Saya duduk untuk menulis teks tentang berapa banyak integrasi mempengaruhi kompleksitas perubahan bisnis.
Dan kemudian saya berpikir - mengapa mengunyah sesuatu yang ingus? Sekali lagi, mengisap semacam manfaat bagi pelanggan yang tidak bahagia, dan bagaimana kita, IT, menghilangkan manfaat ini? Bukankah lebih baik melakukan kenyataan?
Realitas adalah ribuan implementasi sistem informasi, situs yang dikembangkan, layanan yang terhubung dan armada peralatan yang luas.
Ya, dalam banyak kasus, pelanggan merasa bahwa proyek TI belum mencapai tujuannya.
Itu mengingatkan seorang gadis romantis yang bermimpi berjalan bergandengan tangan dengan seorang pria, di padang rumput berbunga, dengan karangan bunga dandelion di kepalanya, dan agar matahari bersinar cerah, dan dia sudah ketinggalan jaman dalam kemeja putih salju, dia tersenyum, dan dia tidak perlu apa-apa, hanya untuk bersama Saya berada di dekat situ, berenang di samudera tanpa pesona pesona masa mudaku, keindahan dan kemurnian, dan seluruh dunia diciptakan hanya untukku, dan Dia juga untukku ...
Tidak, sayangku. Ia memiliki tujuan yang berbeda. Dan Anda tahu yang mana. Dia akan mencapai tujuannya. Jika tidak dengan Anda, maka di sisi lain. Dan lebih dari sekali.
Mengapa berfantasi jika ada kenyataan? Ya, ada proyek yang meningkatkan efektivitas pelanggan. Ya, pelanggan juga dapat meningkatkan laba - baik karena pertumbuhan pendapatan, atau melalui pengurangan biaya. Tetapi sebagian besar proyek TI adalah untuk penanaman, atau penyemenan, atau pemerasan, atau pembelajaran.
Jadi mengapa berfantasi, menyalahkan ketidakadilan, mendesak untuk berubah dan berubah, percaya pada kebaikan dan dongeng? Lebih baik untuk mencari cara menanam lebih banyak, lebih sedikit semen, jangan memeras sama sekali dan belajar dalam proses.
Saya mengusulkan untuk melakukan ini. Jika Anda tidak keberatan.