Бұл мақалада мен өнімдеріміздің функционалдығын дамыту идеяларын таңдаудағы тәжірибеммен бөлісемін және негізгі даму векторларын қалай сақтау керектігін айтамын.
Біз автоматтандырылған есеп айырысу жүйесін (АБЖ) – биллинг әзірлеудеміз. Мерзімі
Біздің өнімнің қызмет ету мерзімі - 14 жыл. Осы уақыт ішінде жүйе өнеркәсіптік рейтингтің алғашқы нұсқаларынан бірін-бірі толықтыратын 18 өнімнен тұратын модульдік кешенге көшті. Бағдарламалардың ұзақ өмір сүруінің маңызды аспектілерінің бірі - үздіксіз даму. Ал идеялар даму үшін қажет.
Ойлар
Ақпарат көздері
5 дереккөз бар:
- Корпоративтік ақпараттық жүйелерді әзірлеушінің басты досы болып табылады клиент. Ал клиент шешім қабылдаушылардың, жоба демеушілерінің, процестердің иелері мен орындаушылардың, ішкі IT мамандарының, қарапайым пайдаланушылардың және әртүрлі дәрежеде қызығушылық танытатын көптеген адамдардың ұжымдық бейнесі болып табылады. Біз үшін клиенттің әрбір өкілі әлеуетті идеялар жеткізушісі болуы маңызды. Ең нашар жағдайда, біз жүйедегі мәселелер туралы тек теріс пікірлер аламыз. Ең жақсы жағдайда, клиент жағында клиенттің қажеттіліктері туралы құрылымдық ақпаратты ұсынатын, жақсартуға арналған идеялардың тұрақты көзі болып табылатын адам бар.
- Біздің сатушылар мен есеп менеджерлері жақсартуға арналған идеялардың екінші маңызды көзі болып табылады. Олар сала өкілдерімен көп және белсенді түрде байланысады, әлеуетті тұтынушылардан есепшот ұсыну мүмкіндігіне бірінші қолмен сұраулар алады. Саудагерлер мен тіркелгілер өздерінің функционалдық мүмкіндіктеріндегі барлық елеулі өзгерістерді және бәсекелестердің бағдарламалық жасақтамасының соңғы жаңартуларын білуі керек, әртүрлі шешімдердің оң және теріс жақтарын негіздей алуы керек. Кейбір есеп айырысу мүмкіндіктері де-факто стандартқа айналатынын, онсыз бағдарламалық жасақтаманы толық деп санауға болмайтынын бірінші болып біздің қызметкерлер сезінеді.
- Өнім иесі біздің топ-менеджерлеріміздің бірі немесе өте тәжірибелі жоба менеджері. Компанияның стратегиялық мақсаттарын есте сақтайды және оларға сәйкес өнімді дамыту жоспарларын түзетеді.
- Сәулетші, таңдалған/қолданылатын технологиялық шешімдердің мүмкіндіктері мен шектеулерін және олардың өнімді әзірлеуге әсерін түсінетін адам.
Әзірлеу және тестілеу топтары. Өнімді әзірлеуге тікелей қатысатын адамдар.
Хиттердің классификациясы
Біз дереккөздерден – хаттардан, билеттерден, ауызша сұраулардан аламыз. Барлық
өтініштер жіктеледі:
- Консультациялар «Қалай істеу керек?», «Бұл қалай жұмыс істейді?», «Неге жұмыс істемейді?», «Мен түсінбеймін...». Осы түрдегі қоңыраулар 1-деңгейдегі қолдау желісіне өтеді. Кеңес беруді өтініштердің басқа түрлеріне қайта даярлауға болады.
- Оқиғалар «Жұмыс істемейді» және «Қате» мағынасында. 2 және 3 тірек сызықтары арқылы өңделеді. Егер патчты жылдам түзету және босату қажет болса, оны қолдаудан тікелей әзірлеуге ауыстыруға болады. Оны өзгерту сұрауына қайта жіктеп, артта қалуға жіберуге болады.
- Өзгерістер мен дамуға сұраныстар. Қолдау желілерін айналып өтіп, өнімнің артта қалу тізіміне кіріңіз. Бірақ олар үшін бөлек өңдеу процедурасы бар.
Хиттердің осындай статистикасы бар - шығарылғаннан кейін бірден қысқа уақыт ішінде хит саны 10-15% -ға өседі. Сондай-ақ, бұлттық қызметтерімізге пайдаланушылар саны көп жаңа клиент келгенде, қоңыраулар жиі болады. Адамдар бағдарламалық жасақтаманың жаңа мүмкіндіктерін пайдалануды үйренуде, оларға кеңес қажет. Тіпті кішкентай клиент жүйеде жұмыс істей бастағанда, айына 100 сағаттан астам кеңестерді оңай жағады. Сондықтан, жаңа клиентті қосқанда, біз әрқашан бастапқы консультациялар үшін уақытты сақтаймыз. Көбінесе біз нақты бір маманды бөліп аламыз. Жалдау ақысы, әрине, бұл еңбек шығындарын өтемейді, бірақ уақыт өте келе жағдай қалпына келеді. Бейімделу кезеңі, әдетте, 1 айдан 3 айға дейін созылады, содан кейін кеңес беру қажеттілігі айтарлықтай төмендейді.
Бұрын біз қоңырауларды сақтау үшін өздігінен жазылған шешімдерді қолдандық. Бірақ біртіндеп Atlassian өнімдеріне көшті. Біріншіден, әзірлеу Agile-де жұмыс істеуді жеңілдету үшін ауыстырылды, содан кейін қолдау. Қазір барлық маңызды процестер Jira SD жүйесінде өмір сүреді, сонымен қатар олар Jira үшін әртүрлі плагиндермен және Confluenceпен қамтамасыз етілген. Өздігінен жазылған шешімдер компания қызметі үшін маңызды емес процестерде ғана қалды. Біздің міндеттеріміз енді бір жүйеден екінші жүйеге секірмей-ақ қолдау мен даму арасында ауысуға болатыны белгілі болды.
Осы топтамадан біз барлық тапсырмалар, жоспарланған және нақты еңбек шығындары туралы деректерді ала аламыз, клиенттер үшін әртүрлі есепшот нұсқаларын пайдалана аламыз және ішкі қажеттіліктер үшін құжаттаманы және клиенттерге есеп жасай аламыз.
Өзгерту сұрауларын өңдеу
Әдетте, бұл сұраулар мүмкіндік талаптары түрінде келеді. Біздің талдаушы сұранысты зерттейді, спецификацияны және жоғары деңгейлі TOR жасайды. Осы сұрауды мақұлдауға жіберген адамға спецификация мен TOR береді - біз тұтынушымен бір тілде сөйлесетінімізге сенімді болуымыз керек.
Тұтынушыдан бір-бірімізді дұрыс түсінгендігіміз туралы растауды алғаннан кейін, талдаушы сұранысты өнімнің артта қалдырылуына енгізеді.
Өнім мүмкіндіктерін басқару
Ары қарай өзгертулер мен даму үшін алынған сұраулар жинақталады. Жарты айда бір рет директордан, техникалық қызмет көрсету, әзірлеу, сату бөлімінің басшылары мен жүйе сәулетшісінен тұратын техникалық кеңес жиналады. Талқылау пішімінде кеңес артта қалған өтінімдерді талдайды және оларға басымдық береді және келесі шығарылымда іске асыру үшін 5 әзірлеу тапсырмасын келіседі.
Шын мәнінде, техникалық кеңес өтінімдерде жазылған қажеттіліктерді ескере отырып, сала мен нарықтың талаптарына жауап береді. Маңыздылығы аз нәрсенің бәрі артта қалып, дамуға жетпейді.
Өзгерістер туралы өтініштердің жіктелуі және қаржы
Даму қымбатқа түседі. Сондықтан, өзгерту туралы сұрау қызметкерден емес, клиенттен келсе, бізде қандай опциялар болуы мүмкін екенін бірден айтамыз.
Өзгерістер туралы сұраныстар келесідей жіктеледі: салалық қажеттіліктер немесе кәсіпорынның жеке сипаттамалары; жаңа функционалдылықтың айтарлықтай көлемі немесе шағын түзету. Кішігірім түзетулер мен жеке сұраулар еш қиындықсыз өңделеді. Жеке сұраныстар нақты клиент үшін онымен жобалық жұмыстың бөлігі ретінде есептеледі және жүзеге асырылады.
Егер бұл ауқымды салалық қажеттілік болмаса және функционалдық көлемі үлкен болса, онда негізгі функционалдылыққа қосымша сатылатын жаңа жеке модульді әзірлеу туралы шешім қабылдауға болады. Клиенттен мұндай сұраныс түссе, біз модульді әзірлеу шығындарын өтей аламыз, клиентке модульді тегін немесе ішінара төлеммен қамтамасыз ете аламыз және модульді сату үшін қоғамдық игілікке қоя аламыз. Мұндай жағдайда клиент әдістемелік жүктеменің бір бөлігін алады және шын мәнінде модульді пилоттық енгізуді жүргізеді.
Егер бұл үлкен салалық қажеттілік болса, онда негізгі өнімге жаңа функционалдылықты қосу туралы шешім қабылдануы мүмкін. Бұл жағдайда шығындарды толығымен өзіміз көтереміз және жаңа функционалдық бағдарламалардың ағымдағы нұсқасында пайда болады.
Ескі тұтынушыларға жаңартулар беріледі.
Сондай-ақ, бірнеше тұтынушылардың ұқсас қажеттілігі болуы мүмкін, бірақ ол жаппай өнімді тартпайды. Бұл жағдайда біз осы тұтынушыларға спецификацияны жібере аламыз және олардың арасында әзірлеу шығындарын бөлісуді ұсына аламыз. Соңында барлығы жеңеді: тұтынушылар функционалдылықты арзан бағамен жүзеге асырады, біз өнімді байытамыз, біраз уақыттан кейін нарықтың басқа қатысушылары да оларды пайдалану үшін функционалдылықты ала алады.
DevOps
Әзірлеу жылына екі негізгі шығарылымды дайындайды. Әрбір шығарылымда техникалық кеңестен алынған 5 тапсырманы орындауға уақыт бөлінеді. Осылайша, тауар айналымының артында біз өнімді дамытуды ешқашан ұмытпаймыз.
Әрбір шығарылым тиісті сынақтар мен құжаттамалар жинағынан өтеді. Әрі қарай, бұл шығарылым сәйкес тапсырыс берушінің сынақ ортасында орнатылады, ол өз кезегінде бәрін мұқият тексереді, содан кейін ғана шығарылым өндіріске беріледі.
Шығарылым жүйесінен басқа, тұтынушылар алты ай бойы қателермен өмір сүрмейтіндей, қателерді жылдам түзету пішімі бар. Бұл аралық пішім бірінші басымдықтағы оқиғаларға жылдам әрекет етуге және көрсетілген SLA орындауға мүмкіндік береді.
Жоғарыда айтылғандардың барлығы, ең алдымен, корпоративтік секторға және жергілікті шешімдерге қатысты. SMB сегментіне бағытталған бұлттық қызметтер үшін тұтынушылар үшін өнімді әзірлеуге қатысу үшін мұндай кең мүмкіндіктер жоқ. SMB үшін жалға алу пішімі тіпті мұны ұсынбайды. Корпоративтік тараптың нақты талаптары түріндегі өзгерту сұрауының орнына тек қызметке әдеттегі кері байланыс пен тілектер бар. Біз тыңдауға тырысамыз, бірақ өнім ауқымды және бір клиенттің өзінің ескі тарихи жүйесінен таныс нәрсені әкелуге ұмтылуы жалпы жүйенің даму стратегиясына қайшы келуі мүмкін.
Ақпарат көзі: www.habr.com