Sa artikulong ito, ibabahagi ko ang aking karanasan sa pagpili ng mga ideya para sa pagbuo ng functionality ng aming mga produkto at sasabihin sa iyo kung paano panatilihin ang mga pangunahing vectors ng pag-unlad.
Bumubuo kami ng isang automated settlement system (ACP) - pagsingil. Termino
Ang buhay ng aming produkto ay 14 na taon. Sa panahong ito, ang sistema ay nagbago mula sa mga unang bersyon ng isang sistema ng taripa ng industriya tungo sa isang modular complex na binubuo ng 18 mga produkto na umakma sa isa't isa. Ang isa sa pinakamahalagang aspeto ng mahabang buhay para sa mga programa ay ang patuloy na pag-unlad. At ang pag-unlad ay nangangailangan ng mga ideya.
Mga Ideya
pinagmumulan
Mayroong 5 mga mapagkukunan:
- Ang pangunahing kaibigan ng isang corporate information systems developer ay kostumer. At ang kliyente ay isang kolektibong imahe ng mga gumagawa ng desisyon, mga sponsor ng proyekto, mga may-ari at tagapagpatupad ng mga proseso, mga in-house na espesyalista sa IT, mga ordinaryong gumagamit at isang malaking bilang ng mga interesadong indibidwal sa iba't ibang antas. Mahalaga sa amin na ang bawat kinatawan ng kliyente ay potensyal na tagapagtustos ng mga ideya. Sa pinakamasamang kaso, nakakatanggap lang kami ng negatibong feedback tungkol sa mga problema sa system. Sa pinakamagandang kaso, mayroong isang tao sa panig ng kliyente na palaging pinagmumulan ng mga ideya para sa pagpapabuti, na nagbibigay ng nakabalangkas na impormasyon tungkol sa mga pangangailangan ng kliyente.
- Ang aming mga salespeople at account manager ay ang pangalawang pinakamahalagang mapagkukunan ng mga ideya para sa pagpapabuti. Aktibo at malawak silang nakikipag-ugnayan sa mga kinatawan ng industriya at tumatanggap ng mga unang katanungan tungkol sa functionality ng pagsingil mula sa mga potensyal na kliyente. Dapat malaman ng mga nagbebenta at account ang lahat ng makabuluhang pagbabago sa kanilang functionality at ang pinakabagong mga update sa software ng mga kakumpitensya, at magagawang bigyang-katwiran ang mga kalamangan at kahinaan ng iba't ibang solusyon. Ito ang aming mga empleyado na unang nakadarama kung ang ilang mga kakayahan sa pagsingil ay naging de facto na pamantayan, kung wala ito ay hindi maituturing na kumpleto ang software.
- May-ari ng produkto β isa sa aming mga nangungunang tagapamahala o isang napakaraming tagapamahala ng proyekto. Pinananatili sa isip ang mga madiskarteng layunin ng kumpanya at inaayos ang mga plano sa pagbuo ng produkto alinsunod sa mga ito.
- Arkitekto, isang taong nakakaunawa sa mga kakayahan at limitasyon ng mga solusyon sa teknolohiya na pinili/ginamit at ang epekto nito sa pagbuo ng produkto.
Mga pangkat ng pagbuo at pagsubok. Mga taong direktang kasangkot sa pagbuo ng produkto.
Pag-uuri ng mga kahilingan
Nakatanggap kami ng hilaw na data mula sa mga mapagkukunan - mga liham, tiket, mga kahilingan sa salita. Lahat
inuri ang mga apela:
- Konsultasyon na may kahulugang "Paano ito gagawin?", "Paano ito gumagana?", "Bakit hindi ito gumagana?", "Hindi ko maintindihan...". Ang mga kahilingan ng ganitong uri ay mapupunta sa Level 1 Support Line. Posibleng sanayin muli ang konsultasyon sa iba pang uri ng mga kahilingan.
- Mga pangyayari na may kahulugang "Hindi gumagana" at "Error". Pinoproseso ng 2 at 3 Mga Linya ng Suporta. Kung kinakailangan ang agarang pagwawasto at paglabas ng isang patch, maaari silang ilipat mula sa suporta nang direkta sa pag-unlad. Posibleng i-reclassify ito bilang isang kahilingan sa pagbabago at ipadala ito sa backlog.
- Mga kahilingan para sa mga pagbabago at pag-unlad. Nakapasok sila sa backlog ng produkto, na nilalampasan ang mga linya ng suporta. Ngunit mayroong isang hiwalay na pamamaraan ng pagproseso para sa kanila.
Mayroong mga istatistika sa mga kahilingan: kaagad pagkatapos ng paglabas, ang bilang ng mga kahilingan ay tumaas ng 10-15% sa maikling panahon. Mayroon ding mga pagdagsa sa mga kahilingan kapag may dumating na bagong kliyente na may malaking bilang ng mga user sa aming mga serbisyo sa cloud. Ang mga tao ay natututong gumamit ng mga bagong kakayahan ng software, kailangan nila ng payo. Kahit na ang isang maliit na kliyente, kapag nagsimulang magtrabaho sa system, madaling magsunog ng higit sa 100 oras ng mga konsultasyon bawat buwan. Samakatuwid, kapag kumokonekta sa isang bagong kliyente, palagi kaming naglalaan ng oras para sa mga paunang konsultasyon. Kadalasan ay pumipili pa kami ng isang partikular na espesyalista. Ang presyo ng pag-upa, siyempre, ay hindi sumasakop sa mga gastos sa paggawa, ngunit sa paglipas ng panahon ang sitwasyon ay lumalabas. Ang panahon ng pag-aangkop ay karaniwang tumatagal mula 1 hanggang 3 buwan, pagkatapos nito ay makabuluhang nabawasan ang pangangailangan para sa pagpapayo.
Noong nakaraan, gumamit kami ng mga self-written na solusyon upang mag-imbak ng mga kahilingan. Ngunit unti-unti kaming lumipat sa mga produkto ng Atlassian. Una, inilipat namin ang pag-unlad upang gawing mas madali ang trabaho ayon sa Agile, pagkatapos ay suporta. Ngayon lahat ng mga kritikal na proseso ay nakatira sa Jira SD, kasama ang mga ito ay suportado ng iba't ibang mga plugin para sa Jira, kasama ang Confluence. Ang mga self-written na solusyon ay nanatili lamang para sa mga prosesong hindi kritikal para sa mga aktibidad ng kumpanya. Lumalabas na ang aming mga gawain ngayon ay cross-cutting at maaaring ilipat sa pagitan ng suporta at pag-unlad nang hindi tumatalon mula sa isang sistema patungo sa isa pa.
Mula sa link na ito makakakuha tayo ng data sa lahat ng mga gawain, binalak at aktwal na mga gastos sa paggawa, gumamit ng iba't ibang mga opsyon sa pagpepresyo para sa mga kliyente at makabuo ng dokumentasyon para sa mga panloob na pangangailangan at pag-uulat sa mga kliyente.
Pinoproseso ang mga kahilingan sa pagbabago
Karaniwan, ang mga naturang kahilingan ay dumating sa anyo ng mga kinakailangan sa pag-andar. Pinag-aaralan ng aming analyst ang kahilingan, lumilikha ng isang detalye at mga nangungunang teknikal na detalye. Inilipat ang detalye at teknikal na mga detalye sa taong nagsumite ng kahilingang ito para sa pag-apruba - dapat nating tiyakin na nagsasalita tayo ng parehong wika sa customer.
Pagkatanggap ng kumpirmasyon mula sa customer na naiintindihan namin ang isa't isa nang tama, ipinapasok ng analyst ang kahilingan sa backlog ng produkto.
Pamamahala ng functionality ng produkto
Ang backlog ay nag-iipon ng mga papasok na kahilingan para sa pagbabago at pag-unlad. Ang teknikal na konseho, na binubuo ng direktor, mga pinuno ng suporta, pag-unlad, pagbebenta at ang arkitekto ng system, ay nagpupulong tuwing anim na buwan. Sa isang format ng talakayan, sinusuri at binibigyang-priyoridad ng konseho ang mga aplikasyon mula sa backlog at sumasang-ayon sa 5 mga gawain sa pagpapaunlad para sa pagpapatupad sa susunod na paglabas.
Sa katunayan, ang teknikal na konseho ay tumutugon sa mga pangangailangan ng industriya at merkado sa pamamagitan ng pagrepaso sa mga pangangailangang ipinahayag sa mga aplikasyon. Lahat ng maliit na kaugnayan ay nananatili sa backlog at hindi umabot sa pag-unlad.
Pag-uuri ng mga Kahilingan sa Pagbabago at Pananalapi
Mahal ang development. Samakatuwid, agad naming sasabihin sa iyo kung anong mga opsyon ang maaaring mayroon kami kung ang kahilingan para sa pagbabago ay nagmula sa isang kliyente at hindi isang empleyado.
Inuuri namin ang mga kahilingan sa pagbabago tulad ng sumusunod: pangangailangan sa industriya o indibidwal na katangian ng negosyo; isang malaking halaga ng bagong pag-andar o isang maliit na pag-aayos. Ang mga menor de edad na pag-aayos at mga indibidwal na kahilingan ay pinoproseso nang walang anumang mga frills. Ang mga indibidwal na kahilingan ay kinakalkula at ipinatupad para sa isang partikular na kliyente bilang bahagi ng proyekto sa kanya.
Kung hindi ito isang napakalaking pangangailangan sa industriya at malaki ang volume ng functionality, maaaring gumawa ng desisyon na bumuo ng bagong hiwalay na module na ibebenta bilang karagdagan sa pangunahing functionality. Kung ang naturang kahilingan ay natanggap mula sa isang kliyente, maaari naming sakupin ang mga gastos sa pagbuo ng module, ibigay sa kliyente ang module nang libre o may bahagyang bayad, at ilagay ang module mismo para ibenta. Sa ganoong sitwasyon, ang kliyente ay tumatagal sa bahagi ng methodological load at mahalagang nagsasagawa ng pilot na pagpapatupad ng module sa kanyang sarili.
Kung ito ay isang napakalaking pangangailangan ng industriya, kung gayon ang isang desisyon ay maaaring gawin upang isama ang bagong functionality sa batayang produkto. Ang mga gastos sa kasong ito ay ganap na nakasalalay sa amin, at ang bagong pag-andar ay lilitaw sa kasalukuyang bersyon ng mga programa.
Ang mga lumang customer ay binibigyan ng update.
Maaaring may ilang customer din na may katulad na pangangailangan, ngunit hindi ito kwalipikado para sa isang mass product. Sa kasong ito, maaari naming ipadala ang detalye sa mga customer na ito at mag-alok na hatiin ang mga gastos sa pagpapaunlad sa pagitan nila. Sa huli, lahat ay mananalo: ang mga customer ay tumatanggap ng functionality sa murang halaga, pinagyayaman namin ang produkto, at pagkaraan ng ilang panahon, ang ibang mga kalahok sa merkado ay maaari ding makakuha ng functionality para sa kanilang paggamit.
DevOps
Ang pag-unlad ay naghahanda ng dalawang pangunahing paglabas sa isang taon. Sa bawat paglabas, oras ay nakalaan para sa pagpapatupad ng 5 mga gawain na natanggap mula sa teknikal na konseho. Kaya, sa gitna ng nakagawian, hindi namin nakakalimutan ang tungkol sa pagbuo ng produkto.
Ang bawat release ay sumasailalim sa isang naaangkop na hanay ng pagsubok at dokumentasyon. Susunod, ang release na ito ay naka-install sa pagsubok na kapaligiran ng kaukulang customer, na, sa turn, ay maingat na sinusuri ang lahat at pagkatapos lamang na ang release ay inilipat sa produksyon.
Bilang karagdagan sa sistema ng paglabas, mayroong isang format para sa mabilis na pag-aayos ng bug upang ang mga kliyente ay hindi mabuhay nang may mga error sa loob ng anim na buwan. Ang intermediate na format na ito ay magbibigay-daan sa iyong mabilis na tumugon sa mga unang-priyoridad na insidente at matupad ang mga nakasaad na SLA.
Ang lahat ng nasa itaas ay totoo lalo na para sa sektor ng korporasyon at mga solusyon sa nasasakupan. Para sa mga serbisyo ng ulap na naglalayong sa segment ng SMB, walang ganoong malawak na pagkakataon para sa mga kliyente na lumahok sa pagbuo ng produkto. Ang format ng pagpaparenta ng SMB ay hindi rin ito ipinapalagay. Sa halip na isang kahilingan sa pagbabago sa anyo ng malinaw na mga kinakailangan mula sa partido ng korporasyon, dito mayroon lamang ordinaryong feedback at mga kahilingan para sa serbisyo. Sinusubukan naming makinig, ngunit ang produkto ay napakalaki at ang pagnanais ng isang kliyente na magdala ng isang bagay na pamilyar mula sa kanilang lumang makasaysayang sistema ay maaaring sumalungat sa diskarte sa pag-unlad ng system sa kabuuan.
Pinagmulan: www.habr.com