Ing artikel iki, aku bakal nuduhake pengalaman babagan milih ide kanggo ngembangake fungsionalitas produk kita lan pitutur marang kowe carane njaga vektor utama pembangunan.
Kita ngembangake sistem penyelesaian otomatis (ACP) - tagihan. istilahe
Umur produk kita yaiku 14 taun. Sajrone wektu iki, sistem kasebut wis berkembang saka versi pisanan sistem tarif industri menyang kompleks modular sing dumadi saka 18 produk sing saling nglengkapi. Salah sawijining aspek sing paling penting babagan umur dawa kanggo program yaiku pangembangan terus-terusan. Lan pembangunan mbutuhake gagasan.
Gagasan
Sumber informasi
Ana 5 sumber:
- Kanca utama pangembang sistem informasi perusahaan yaiku pelanggan. Lan klien minangka gambar kolektif saka pembuat keputusan, sponsor proyek, pemilik lan pelaksana proses, spesialis IT ing omah, pangguna biasa lan akeh wong sing kasengsem ing macem-macem derajat. Iku penting kanggo kita sing saben wakil klien duweni potensi supplier gagasan. Ing kasus paling awon, kita mung nampa umpan balik negatif babagan masalah ing sistem. Ing kasus sing paling apik, ana wong ing sisih klien sing dadi sumber ide kanggo perbaikan, nyedhiyakake informasi terstruktur babagan kabutuhan klien.
- kita salespeople lan manajer akun minangka sumber ide paling penting nomer loro kanggo perbaikan. Dheweke aktif lan akeh komunikasi karo wakil industri lan nampa pitakon langsung babagan fungsi tagihan saka klien potensial. Penjual lan akun kudu ngerti kabeh owah-owahan sing signifikan ing fungsi lan nganyari paling anyar kanggo piranti lunak pesaing, lan bisa mbenerake pro lan kontra saka solusi sing beda. Iki minangka karyawan kita sing pisanan ngerti yen sawetara kemampuan tagihan dadi standar de facto, tanpa piranti lunak kasebut ora bisa dianggep lengkap.
- Product Owner - salah sawijining manajer paling ndhuwur utawa manajer proyek sing berpengalaman. Tansah tujuan strategis perusahaan lan nyetel rencana pangembangan produk selaras karo dheweke.
- Arsitek, wong sing ngerti kemampuan lan watesan saka solusi teknologi sing dipilih / digunakake lan pengaruhe ing pangembangan produk.
Pangembangan lan tim testing. Wong sing langsung melu pangembangan produk.
Klasifikasi panyuwunan
Kita nampa data mentah saka sumber - layang, tiket, panjaluk lisan. Kabeh
banding diklasifikasikakΓ©:
- Konsultasi kanthi teges "Carane?", "Carane?", "Kok ora bisa?", "Aku ora ngerti ...". Panjalukan saka jinis iki pindhah menyang Level 1 Dhukungan Line. Sampeyan bisa nglatih maneh konsultasi menyang jinis panjaluk liyane.
- Kedadeyan kanthi teges "Ora bisa" lan "Kesalahan". Diproses dening 2 lan 3 Dhukungan Lines. Yen koreksi cepet lan ngeculake patch perlu, bisa ditransfer saka dhukungan langsung menyang pembangunan. Sampeyan bisa klasifikasi ulang minangka panjalukan pangowahan lan dikirim menyang backlog.
- Panjaluk kanggo owah-owahan lan pangembangan. Dheweke mlebu backlog produk, ngliwati garis dhukungan. Nanging ana prosedur pangolahan sing kapisah kanggo dheweke.
Ana statistik babagan panjaluk: sanalika sawise diluncurake, jumlah panjaluk mundhak 10-15% kanggo wektu sing cendhak. Ana uga lonjakan panjaluk nalika klien anyar kanthi akeh pangguna teka ing layanan awan kita. Wong sinau nggunakake kemampuan piranti lunak anyar, dheweke butuh saran. Malah klien cilik, nalika miwiti kerja ing sistem, gampang ngobong luwih saka 100 jam konsultasi saben wulan. Mulane, nalika nyambungake klien anyar, kita tansah cadangan wektu kanggo konsultasi dhisikan. Asring kita malah milih spesialis tartamtu. Rega sewa, mesthi, ora nutupi biaya tenaga kerja kasebut, nanging suwe-suwe kahanan kasebut dadi rata. Periode adaptasi biasane njupuk saka 1 nganti 3 sasi, sawise iku perlu kanggo konseling suda sacara signifikan.
Sadurunge, kita nggunakake solusi sing ditulis dhewe kanggo nyimpen panjalukan. Nanging kita mboko sithik pindhah menyang produk Atlassian. Pisanan, kita nransfer pembangunan supaya luwih gampang makarya miturut Agile, banjur ndhukung. Saiki kabeh proses kritis manggon ing Jira SD, plus padha didhukung dening macem-macem Plugins kanggo Jira, plus Confluence. Solusi sing ditulis dhewe tetep mung kanggo proses sing ora kritis kanggo aktivitas perusahaan. Pranyata tugas kita saiki wis salib lan bisa ditransfer antarane dhukungan lan pangembangan tanpa mlumpat saka siji sistem menyang sistem liyane.
Saka tautan iki, kita bisa entuk data babagan kabeh tugas, biaya tenaga kerja sing direncanakake lan nyata, nggunakake macem-macem opsi rega kanggo klien lan ngasilake dokumentasi kanggo kabutuhan internal lan nglaporake menyang klien.
Ngolah panjalukan owah-owahan
Biasane, panjaluk kasebut teka kanthi syarat fungsionalitas. Analis kita nyinaoni panjaluk kasebut, nggawe spesifikasi lan spesifikasi teknis tingkat paling dhuwur. Nransfer spesifikasi lan spesifikasi teknis menyang wong sing ngirim panjaluk iki kanggo disetujoni - kita kudu yakin manawa kita nganggo basa sing padha karo pelanggan.
Sawise nampa konfirmasi saka pelanggan yen kita ngerti saben liyane kanthi bener, analis mlebu panjaluk kasebut menyang backlog produk.
Manajemen fungsi produk
Backlog nglumpukake panjaluk sing mlebu kanggo owah-owahan lan pangembangan. Dewan teknis, kalebu direktur, kepala dhukungan, pangembangan, penjualan lan arsitek sistem, ketemu saben nem wulan. Ing format diskusi, dewan nganalisa lan prioritizes aplikasi saka backlog lan setuju ing 5 tugas pembangunan kanggo implementasine ing release sabanjurΓ©.
AkibatΓ©, dewan teknis nanggapi panjaluk industri lan pasar kanthi mriksa kabutuhan sing dituduhake ing aplikasi. Kabeh sing kurang relevan tetep ana ing backlog lan ora tekan pembangunan.
Klasifikasi Panyuwunan Ganti lan Keuangan
Pembangunan larang. Mula, kita bakal langsung ngandhani pilihan apa sing bisa ditindakake yen panjaluk pangowahan kasebut saka klien lan dudu karyawan.
Kita nggolongake panjalukan owah-owahan kaya ing ngisor iki: kabutuhan industri utawa karakteristik individu perusahaan; jumlah pinunjul saka fungsi anyar utawa fix suntingan. Perbaikan cilik lan panjaluk individu diproses tanpa embel-embel. Panjaluk individu diwilang lan dileksanakake kanggo klien tartamtu minangka bagean saka karya proyek karo dheweke.
Yen iki dudu kabutuhan industri sing akeh lan volume fungsine gedhe, mula bisa uga keputusan kanggo ngembangake modul kapisah anyar sing bakal didol saliyane fungsi utama. Yen panjalukan kasebut ditampa saka klien, kita bisa nutupi biaya ngembangake modul kasebut, nyedhiyakake modul kasebut kanthi gratis utawa kanthi pembayaran sebagean, lan nyetel modul kasebut dhewe kanggo didol. Ing kahanan kaya mengkono, klien njupuk bagean saka beban metodologis lan ateges nindakake pilot implementasine saka modul ing awake dhewe.
Yen iki minangka kabutuhan industri sing akeh, mula bisa uga ana keputusan kanggo nyakup fungsi anyar ing produk dhasar. Biaya ing kasus iki tumiba tanggung ing kita, lan fungsi anyar katon ing versi saiki saka program.
Pelanggan lawas diwenehi nganyari.
Bisa uga ana sawetara pelanggan sing duwe kabutuhan sing padha, nanging ora cocog kanggo produk massal. Ing kasus iki, kita bisa ngirim spesifikasi menyang pelanggan kasebut lan nawakake pamisah biaya pangembangan ing antarane. Pungkasane, kabeh wong menang: para pelanggan nampa fungsi kanthi murah, kita nambah produk kasebut, lan sawise sawetara wektu, para peserta pasar liyane uga bisa entuk fungsi sing digunakake.
DevOps
Pangembangan nyiapake rong rilis utama saben taun. Ing saben rilis, wektu diwenehake kanggo implementasine 5 tugas sing ditampa saka dewan teknis. Mangkono, ing tengah-tengah rutinitas, kita ora bakal lali babagan pangembangan produk.
Saben rilis ngalami tes lan dokumentasi sing cocog. Sabanjure, rilis iki dipasang ing lingkungan tes pelanggan sing cocog, sing, kanthi teliti, mriksa kabeh lan mung sawise rilis kasebut ditransfer menyang produksi.
Saliyane sistem rilis, ana format kanggo ndandani bug kanthi cepet supaya klien ora urip kanthi kesalahan sajrone nem wulan. Format penengah iki bakal ngidini sampeyan nanggapi kanthi cepet babagan kedadeyan prioritas lan ngrampungake SLA sing wis kasebut.
Kabeh sing kasebut ing ndhuwur bener utamane kanggo sektor perusahaan lan solusi ing lokasi. Kanggo layanan maya sing dituju ing segmen SMB, ora ana kesempatan sing amba kanggo klien melu pangembangan produk. Format rental SMB malah ora nganggep iki. Tinimbang panjaluk owah-owahan ing wangun syarat sing jelas saka pihak perusahaan, ing kene mung ana umpan balik lan kepinginan kanggo layanan kasebut. Kita nyoba ngrungokake, nanging produk kasebut akeh banget lan kepinginan saka siji klien kanggo nggawa barang sing akrab saka sistem sejarah lawas bisa mbantah strategi pangembangan sistem kasebut kanthi wutuh.
Source: www.habr.com