Бұл жазба автоматты түрде аударылған. Бастапқы тіл: Орысша
Сәлем! Мен Тимур Драгуновпын. IT саласында 10 жылдан астам жұмыс істеймін. Ол мансабын интернет-жобаларды жасаушы ретінде бастады. Кейінірек ол ресейлік PDF commander редакторының командасына қосылды. Соңғы жылдары әріптестерім екеуміз корпоративтік сегментке назар аудардық. Нарықтың бұл бөлігі дәстүрлі түрде қарапайым пайдаланушылар үшін жобаларды орындаудан гөрі тиімді болып саналады. Сонымен қатар, әлеуетті клиенттердің едәуір бөлігі ірі халықаралық компаниялардың шешімдеріне балама сұранысқа ие болды.
Алайда, жұмыс бағытының өзгеруіне осы екі фактор ғана әсер еткен жоқ. Корпоративтік клиенттердің талаптары қатаң және нақты міндеттерді шешуге сұраныс бар. Бұл біз үшін үлкен сынақ болды және кәсіби дамудың жаңа жолдарын табуға көмектесті. Мен ұйымдарға арналған бағдарламалық жасақтаманы әзірлеу кезеңдері туралы толығырақ айтып беремін. Егер сіз және сіздің командаңыз өз іс-әрекеттеріңізді қайта бағыттауды жоспарласаңыз, бұл ақпарат пайдалы болады.
Бағдарламалық жасақтаманың өмірлік циклі (SDLC — Software Development Lifecycle) — бұл кез-келген бағдарламалық жасақтаманы құруды шешкен кезде басталып, қосымшаны немесе қызметті әзірлеу, қолдау және енгізу толығымен тоқтатылған кезде аяқталатын уақыт кезеңі.
Адамдар ондаған жылдар бойы бағдарламалық жасақтаманы, соның ішінде барлық ұйымдарды құрумен айналысады. Осы уақыт ішінде әртүрлі SDLC модельдері мен жобаларды басқару әдістері қалыптасқаны заңды.
Топ өздігінен пайда болатын идеялармен айналысатын ретсіз даму кейде кейбір нәтижелерге әкелуі мүмкін. Бірақ тек шағын стартаптарда және негізгі мүшелер ынталы болғанша. Бұл ресурс тез жұмсалады. Сонымен қатар, Қарлы кесек ретінде жағымсыз әсерлер өседі. Қателер саны көбейеді, қызықты функционалдылық бастапқы күйінде қалады, соңғы өнімнің жалпы көрінісі жоғалады. Нәтижесінде пайдаланушылар көңілі қалып, бәсекелестерге кетеді.
Кодты және компьютерлік бағдарламалық жасақтаманың басқа элементтерін әзірлеуді ұйымдастыруды мүмкіндігінше тезірек ұйымдастыру қажет. Негізгі тәсілдерге қысқаша тоқталайық.
- Каскадты модель(waterfall, сарқырама моделі). Бүкіл процесс бірнеше қатаң кезеңдерге бөлінеді. Келесі кезеңге өту алдыңғы кезеңдегі барлық жұмыстар толығымен аяқталған кезде ғана болады.Іс жүзінде әдіс таза түрінде салыстырмалы түрде шағын және қарапайым жобаларға ғана жарамды. Клиенттердің сұраныстары нарықтағы барлық жағдай сияқты мезгіл-мезгіл өзгеріп отырады. Сондықтан, қажеттіліктердің бір бөлігін біржола жабатын (мысалы, PDF файлдарымен жұмыс істеу) және айтарлықтай жаңартуларды қажет етпейтін бағдарламалық жасақтаманы тез және қолайлы бюджетке құру өте қиын.
- V-модель (V-модель, VEE моделі). Сонымен қатар, әзірлеу және тестілеу кезеңдері өткізіледі. Бұл жағдайда екі тармақтың бірінде алынған мәліметтер екіншісіне әсер етеді. Мысалы, ұсынылған негізгі модель талданады және салалық стандарттарға сәйкестігі тексеріледі. Нәтижелері бойынша-пысықталып, күрделене түседі. Дәл осындай жағдай архитектурада, прототипте, соңғы өнімнің қосымша компоненттерінде болады.Тәсіл көп ресурстарды қажет етеді, бірақ сапаны сенімді бақылауды қамтамасыз етеді. Бұл әдіс тіпті кішігірім қателіктер өлімге әкелетін салдарға (ғарыш, авиация, атом энергетикасы және т.б.) жүгінеді.
- Итеративті модель. Жұмыстар қатар жүргізіледі, алынған нәтижелер, соның ішінде аралық нәтижелер үздіксіз талданады және осы ақпарат негізінде ағымдағы және болашақ міндеттер түзетіледі. Бұл тәсіл қазір басым. Оның негізінде көптеген басқа әдіснамалар пайда болды — Agile, SCRUM, Канбан және басқалар.Модель өзгермелі жағдайларға тез бейімделуге мүмкіндік береді. Алайда, бюджетті және жобаны іске асыру мерзімдерін дұрыс есептеуде проблемалар туындауы мүмкін. Сондай-ақ, кейінгі өзгерістермен кейде бастапқы архитектураны байыпты түрде қайта құру қажет.
- Спиральды модель. Итеративті және каскадты тәсілдердің сәтті элементтерін біріктіреді. Бағдарламалық жасақтаманы әзірлеу және енгізу циклдарда жүзеге асырылады. Әрқайсысының басында қол жетімді ресурстар, тәуекелдер және әлеуетті мүмкіндіктер бағаланады. Осы мәліметтер негізінде белгіленген күнге дейін нақты орындалатын жұмыстардың тізімі жасалады.Модельдің негізгі кемшілігі-келесі циклге өту сәтін дұрыс анықтау әрдайым мүмкін емес. Сондай-ақ, кейде команда тым көп араласады және өнімді шамадан тыс оңтайландыруды жүзеге асырады.
Таңдалған SDLC әдіснамасына қарамастан, алдымен не және кім үшін жасау керектігін шешу керек.
Ұқсас функционалдығы бар бағдарламалық жасақтаманы ұсынатын кем дегенде бірнеше жеке компаниялар немесе әзірлеушілер бар. Мысалы, PDF операцияларын біздің PDF commander, Adobe Acrobat, Foxit шешімдерінде, Microsoft Office пакетінде немесе оның LibreOffice аналогында жасауға болады.
Құралдар жинағы сіздікіне ұқсас бағдарламалық жасақтама тізімін және олардың әзірлеуші компанияларын жасаңыз. Осы бағдарламалық жасақтаманың барлық ерекшеліктерін мұқият зерттеңіз. Оның қалай дамитынын талдаңыз. Болашақта қандай өзгерістер болатынын болжауға тырысыңыз және осылайша бизнесіңіз үшін тәуекелдерді талдауды орындаңыз.
Нарыққа тапсырыс бойынша ауқымды зерттеулер жүргізетін ұйымдар бар. Жеткілікті бюджетпен Сіз олардың қызметтеріне жүгіне аласыз. Алайда, бұл компанияларға толықтай сенудің қажеті жоқ. Әзірлеуші ретінде сіз бәсекелестердің ұсыныстарымен жеке танысуыңыз керек. Тек осылай ғана сіз не және қалай жасау керектігін түсінесіз.
Сіздің бағдарламаңыз пайдалы болуы мүмкін клиенттердің санаттарын анықтаңыз. Жалпы, дерексіз тұжырымдар ("кім жесе де"," жеген барлық пайдаланушылар") сіз үшін қате және пайдасыз.
Неғұрлым сәтті мысал: штаттық саны 50 адамға дейін, азық-түлік емес тауарлар саудасы саласындағы ұйымдар А, В және С қосымшаларын пайдаланады.
Нарықты және әлеуетті клиенттерді зерттей отырып, сіз толығымен қанағаттандырылмаған немесе толық қанағаттандырылмаған пайдаланушылардың қажеттіліктерін орнатасыз. Сондай-ақ, сіз бәсекелестердің қателіктері мен мәселелерін анықтайсыз.
Осының арқасында сіз мүлдем ерекше өнім жасай алмайсыз. Дегенмен, сіз негізгі (осы сегмент үшін) тапсырмалар жиынтығын шешіп қана қоймай, сонымен қатар ауыр мәселелерді шешетін өнімді ұсына аласыз.
Жоғарыда мен бағдарламалық жасақтаманы техникалық әзірлеу процесі хаотикалық болмауы керек екенін айттым. Команданың өзін ұйымдастырумен байланысты сәттерден басқа, бұл талап барлық күнделікті міндеттерге де қатысты.
Пайдаланушы бағдарламалық жасақтаманы іске қосқан кезде, ол кейбір мәселелерді шешеді. Әдетте, бұл жалғыз емес және көптеген қосымша әрекеттерден тұрады.
Осындай ықтимал міндеттерді мүмкіндігінше болжап, клиенттің талаптарын талдау қажет. Содан кейін-мұның бәрін нақты әрекеттер тізбегі ретінде ұсыныңыз. Сонымен қатар, тұжырымдамалар нақты өмірге байланысты болуы керек.
Жаман мысал: пайдаланушы құжатты өңдеуі керек, ол үшін файлды ашып, оған түзетулер енгізеді.
Неғұрлым сәтті: клиент келісімшарт жобасын контрагенттен PDF-ке алды. Бұл келесі әрекеттерді қамтиды:
- Құжат файлы бағдарламада ашылады. Материалды әртүрлі бағдарламалық жасақтамада бірнеше рет қайта импорттаудың қажеті болмас үшін редактор мен шолғышты біріктірген дұрыс. Сонымен, қолданба жүктеуді ұзақ уақытқа созбау үшін жеткілікті жеңіл болуы керек.
- Құжат қаралады. Айналдыру және масштабтау опциялары қажет. Түсініктемелер мен белгілердің функциясын қосқан жөн-егер оқу кезінде ойлар мен ескертулер пайда болса, оларды бірден қосуға болады.
- Құжатқа түзетулер енгізіледі. Өңдеу функциялары қажет-фрагменттерді жою, жаңа мәтін енгізу. Егер мазмұн танылмаса, OCR (оптикалық таңбаларды тану) құралы қажет.
- Соңғы нұсқа сақталады. Стандарттың барлық талаптарын сақтай отырып, PDF-ке дұрыс экспорттау қажет. Клиентке құжатты басқа форматта сақтау қажет болуы мүмкін. Бұл DOCX, RTF, JPEG және PNG болуы мүмкін.
- Клиент контрагенттің ұсынысымен келіседі және Шартқа қол қоюға дайын. Принтерде басып шығару функциясы қажет. Электрондық құжатқа факсимиль мен мөрдің суреті қосылған кезде іскерлік тәжірибе бұл опцияны қабылдай алады. Электрондық қолтаңбалар да жиі қолданылады.
Осындай сценарийлердің көмегімен клиенттердің нақты қажеттіліктерін түсіну және соның негізінде ыңғайлы және функционалды шешімдер ұсыну оңайырақ.
Әдетте техникалық тапсырма жобаның құжаттамасы болып табылады. Бұл егжей-тегжейлі дәрежеде ерекшеленеді. Егер әзірлеу жеке келісімшарттар бойынша жүзеге асырылса, техникалық тапсырма-бұл іске асыру мерзімдерін көрсететін клиенттің талаптарының сипаттамасы.
Бірінші және салыстырмалы түрде аз құжатта қосымшаның немесе веб-қызметтің жалпы көрінісі көрсетілген. Платформа, негізгі функциялар тізімі, USP, бәсекелес шешімдер тізімі, тәуекелдерді бағалау, пайдаланушының портретін сипаттайды. Бұл құжат командаға немен жұмыс істеу керектігін айту үшін қажет (жиналыстар кезінде айтылатын нәрсе бірден ұмытып кетеді). Оның негізінде инвесторлар үшін Презентация дайындауға болады.
Келесі құжат функционалдылықты егжей-тегжейлі көрсетеді. Егер бағдарламалық жасақтама салыстырмалы түрде қарапайым болса, сіз бір файлды жүргізіп, біртіндеп толықтыра аласыз. Басқа жағдайларда әр функция үшін (ұқсас функциялар тобы) жеке құжат жүргізген жөн. Мұнда әр құралдың архитектурасы, жұмыс принципі егжей-тегжейлі сипатталған. Жақсы түсіну үшін пайдаланушы интерфейстерінің схемаларын, кестелерін, инфографикасын, макеттерін қосыңыз. Осы құжаттаманы ашқаннан кейін команданың әрбір мүшесі өнімнің қалай жұмыс істейтінін және тапсырма бойынша нақты не істеу керектігін тез түсінуі керек.
Құжаттама командаға түсінікті және ыңғайлы болуы керек. Үнемі тәжірибе жасамаңыз және қабылданған форматтардан бас тартпаңыз. Сонымен қатар, құжаттама тұрақты емес. Абсолютті қалыпты тәжірибе — нақтылау мен толықтырулар сұрау, сындарлы ұсыныстар мен ескертулер беру.
Толық құжаттама SDLC ағымдағы қайталануын ескере отырып жасалады. Мысалы, егер сіз осы спринтте немесе майлстоунда Мәтінді пішімдеу опцияларын енгізсеңіз, оларды сипаттау керек. Әрі қарай, құжаттаманың тиісті бөлімдеріне сілтемелерді нақты тапсырмаларға бекіту жақсы тәжірибе болады.
Сондай-ақ салыстырмалы түрде ұзақ мерзімді даму жоспарларын (жол карталары немесе roadmap) жасаған жөн. Олар белгілі бір күндерге байланысты болашақ функционалдылықты көрсетеді. Мысалы, Наурыз-кестелерді қосу, сәуір-кеңейтілген пішімдеу, сканерлерді қолдау, мамыр — OCR, т. б.
Roadmap - лар ресурстарды бөлуге, команданың қызметін үйлестіруге, архитектураны жақсы ойластыруға, өнімді уақтылы енгізуге көмектеседі. Алайда, олар әрдайым өзгеріссіз қала бермейді. Кейде сыни қателіктер пайда болады, оларды жоюға көп уақыт кетеді. Маңызды клиент белгілі бір функцияны қосуды сұрауы мүмкін.
Прототип-бұл өнімнің алғашқы нұсқасы. Ол белгілі бір итерацияға жоспарланған негізгі опциялардың жұмысын көрсетеді. Тұрақтылық пен көрнекі тартымдылық маңызды емес. Бұл кезеңде нақты бағдарламалық жасақтаманың не істейтінін және оны пайдалану қаншалықты ыңғайлы екенін көрсету қажет.
Макеттер-алдын-ала макеттер немесе интерфейс тұжырымдамалары. Олар қолданбаның қалай көрінетінін көрсетеді. Макеттер өнімді ұсыну, кейбір гипотезаларды тексеру және құжаттамада иллюстрация ретінде қажет.
Интерфейс функционалдылықты және басқа техникалық ерекшеліктерді ескере отырып жасалады. Бұл пайдаланушылардың белгілі бір санатының әдеттері мен қалауларын ескереді.
Интерфейс макеттері негізгі терезенің (басты беттің), әр мәзірдің, қойындының, кеңестердің және т.б. көрінісін көрсетеді.
Әрі қарай егжей — тегжейлі, бренд стилінің элементтерін-тән палитраны, пішіндерді, логотиптерді, қаріптерді және т.б. әкелген жөн. Көрнекі сурет брендті танымал етеді және жарнамалауға көмектеседі.
Ең дұрысы, өнімді пайдалану эстетикалық рахат әкелуі керек. Бұл жағдайда тепе-теңдікті сақтау маңызды. Ұзақ анимациялар мен обсессивті эффектілерді тіркемеңіз — көп ұзамай олар тітіркендіре бастайды.
Танымал, тартымды және ыңғайлы дизайн тұжырымдамаларын әзірлеу өте қиын міндет. Тіпті халықаралық корпорациялар оны үшінші тарап мамандарына тапсырудан тартынбайды.
Жасалған прототиптер нақты сценарийлерде тексерілуі керек. Әзірлеудің бастапқы кезеңдерінде тестілеуді топ мүшелері және олардың жақындары (отбасы, достары) жүргізеді. Болашақта көбірек тәуелсіз адамдарды тартқан жөн. Достар мен отбасы мүшелері жақындарын ренжіткісі және ренжіткісі келмейді, сондықтан олар кемшіліктер туралы хабарламауы мүмкін.
Тестілеудің көптеген әдістері бар. Олар әртүрлі бұрыштардан бейне түсіруді және экранды түсіруді, сауалнаманы, еркін формадағы шолуларды, ұзақ сұхбаттарды қамтамасыз ете алады. Қатысуға болашақ пайдаланушылардың портретіне барынша сәйкес келетін адамдар тартылады. Студент, үй шаруасындағы әйел және кеңсе қызметкері мәтін редакторы қандай болуы керек екендігі туралы әртүрлі түсініктерге ие. Бұл жағдайда құжаттардың үлкен көлемімен үнемі жұмыс істейтін ірі, шағын және орта компаниялардың қызметкерлерін тестілеуге шақырған дұрыс.
Тестілеуді аутсорсингке беруге болады. Егер сіз шағын провинциялық қалада болсаңыз және жақын жерде жеткілікті адамдар болмаса, үшінші тарап қызметтеріне жүгінуге тура келеді. Немесе сіз сыртқы нарықтарға шығасыз ба
Әзірлеу процесінде құжаттама мен барлық идеялар кодқа еніп, біртіндеп өнімнің бір немесе басқа нұсқасына айналады.
Әзірлеушілер тобының құрамы жүйенің функционалдығы мен архитектурасына байланысты. Бағдарламалық жасақтама инженериясының заманауи тәсілдерін ескере отырып көбінесе қызмет үш бағытта жүзеге асырылады:
- Артқы жағы. Сервер бөлігі (клиент-сервер архитектурасында) және бағдарламалық жасақтаманың ішкі логикасы. Артқы әзірлеушілер деректер құрылымын бағдарламалаумен, оларды сақтаумен және белгілі бір алгоритмдер бойынша өңдеумен айналысады.
- Алдыңғы. Клиент бөлігі (клиент-сервер архитектурасында) және бағдарлама интерфейсі. Алдыңғы әзірлеушілер барлық тізім-мәзір түймелерінің дұрыс жұмыс істеуін, бастапқы деректерді ішкі логикаға дұрыс жіберуді және пайдаланушыға соңғы нәтижені қайтаруды қамтамасыз етеді.
- Интеграция. Қосымшаның басқа бағдарламалық жасақтамамен өзара әрекеттесуі. Бұл плагиндер, белгілі бір бағдарламалық интерфейстер (API), үшінші тарап кітапханалары, импортталатын мазмұн және т. б. болуы мүмкін.
Олар SDLC ұйымдастырудың тәсілдерімен бірдей. Әдістемені дамудың алғашқы кезеңдерінде немесе команда құру кезінде таңдаған жөн және өте қажет болмаса өзгертпеңіз.
Ұзақ уақыт бойы басқа тәсілдерге көшу барлық әрекеттерді паралич етеді. Әріптестердің бірі бейімделгісі келмейді және компаниядан кетеді. Қолданба архитектурасын қайта жобалау қажет болуы мүмкін. Яғни, іс жүзінде бұрын жасалған барлық нәрсені қайта жасаңыз.
Модульдік тестілеу (блоктық немесе Бірлік-тестілеу) — кодтың жекелеген оқшауланған бөліктерінің жұмысқа қабілеттілігін тексеру. Процесс барысында әзірлеушілер әр түрлі модульдер барлық қажетті әрекеттерді орындайтындығына, бағдарламалық жасақтаманың басқа бөліктерімен дұрыс әрекеттесе алатындығына және белгілі бір жүктемелерге төтеп бере алатындығына көз жеткізеді.
Бағдарламалық жасақтаманы әзірлеу құралдары үшін дайын бірлік тестілеу кітапханалары бар. Мысалы, C# үшін NUnit немесе Java үшін JUnit.
Бағдарламаны тестілеу және күйін келтіру тек ерте прототиптермен шектелмейді. Ол өмірлік циклдің әр кезеңінде үнемі өткізіліп тұрады.
Мен оны жоғарыда айттым. Бұл тест иерархиясындағы бірінші кезең. Әрдайым дерлік заманауи бағдарламалық жасақтама көптеген салыстырмалы түрде кішкентай модульдерден тұрады. Олардың әрқайсысының жұмысын уақтылы тексеру қажет. Бұл бүкіл бағдарламаның жоспарланғандай жұмыс істейтініне толық кепілдік бермейді. Дегенмен, сіз кейбір қателіктерден алдын ала құтылып, кодтың бір бөлігін қайта пайдалана аласыз (әрине, егер ол бірлік сынақтарынан сәтті өтсе).
Әдетте, бірлік тестілеу код жазылғаннан кейін басталады. Сәтті тексеру кезінде ол нұсқаны басқару жүйесіне жүктеледі.
Әзірлеушілер әр түрлі модульдердің бір-бірімен өзара әрекеттесуге қабілеттілігін және бұл процестің қаншалықты дұрыс жүретіндігін тексереді. Ол үшін үздіксіз интеграция жүйелері (CIS) қатысады. Олар нұсқаны басқару жүйесіндегі өзгерістерді бақылайды. Содан кейін жеке компоненттерді тексеру басталады. Егер бұл кезең сәтті өтсе, компиляция жасалады және модульдердің өзара әрекеттесуі тексеріледі. Нәтижелер бойынша есеп жасалады.
Бұл кезеңді бүкіл өнім тексерілетін жүйелік тестілеумен шатастыруға болмайды.
Мұнда олар өнімділік пен ыңғайлылықты зерттейді. Қателерді іздеумен QA инженерлері немесе тестерлері айналысады. Олар интерфейстің әр элементінің өз орнында болуын тексереді (тіпті тәжірибелі команда кейде маңызды батырманы қосуды ұмытып кетеді немесе дұрыс емес терезеге қойынды қояды) және қажетті әрекетті орындайды. Бұл ретте құжаттаманы басшылыққа алады.
Пайдаланушылардың фокус-тобы ыңғайлылық пен жалпы сезімді (немесе UX) бағалайды. Бұл тестілеу ашық (барлығы қосылады) немесе жабық (жеке таңдалған адамдар мен ұйымдар қатысады) болуы мүмкін.
QA және UX тестілеуін мердігерлерге тапсыруға болады. Бұл, әсіресе, көптеген сценарийлерде ауқымды тексерулер қажет болған кезде ақталады.
Тестілеу сәтті аяқталған кезде қосымша нарыққа шығуға дайын.
Мобильді қосымшалар көп жағдайда тиісті платформалардың кіріктірілген дүкендері арқылы таратылады. IOS және iPad OS үшін бұл жалғыз мүмкін нұсқа (микробағдарламаны бұзу және әртүрлі күрделі схемалар қарастырылмайды). Android жүйесінде қолданбаларды APK файлдарынан орнатуға болады. Алайда, бұл әдіс тек нақты жағдайларға жарамды. Мысалы, бағдарлама тек Тапсырыс берушілермен жеке келісімшарттар бойынша таратылады.
Бағдарламалық жасақтаманы тараптарға орналастыру үшін Сіз әзірлеушінің есептік жазбасын (App Store, Google Play) тіркеуіңіз керек. Процесс барысында сіз сауалнаманы толтырып, аз ақы төлеуіңіз керек.
Ол арқылы компьютерлерге арналған бағдарламалық жасақтама таратылады. Жеке ресурсты іске қосуға немесе әзірлеушінің веб-сайтында қосымша бөлім жасауға болады. Бағдарламалық жасақтама және оның құны туралы толық ақпарат, құжаттама және төлемдерді өңдеу мүмкіндігі бар себеттің функционалдығы және лицензиялық кілттерді немесе дистрибутивтерді автоматты түрде жіберетін беттер қажет болады.
Жарнамалар әдетте шығарылымға дейін басталады. Маркетингтік стратегиялар сіз өнімді орналастыратын нарық сегментіне байланысты. Ірі корпоративтік клиенттерге арналған шешімдер офлайн іс-шараларда ұсынылады. Кейбір клиенттерді көрмелерде, салалық басылымдарда жарияланғаннан кейін және коммерциялық ұсыныстарды жібергеннен кейін алуға болады.
Кішігірім клиенттерге арналған бағдарламалық жасақтаманы Профильді блогерлер арқылы жылжытуға болады. Мазмұнды маркетинг жақсы нәтиже көрсетеді. Бұл сіздің қосымшаңыздың мақсатына сәйкес келетін пайдалы материалдарды үнемі орналастырудан тұрады. Мысалы, егер бағдарлама PDF құжаттарын жасауға және өңдеуге мүмкіндік берсе, қағаз материалдарын цифрландыруға, әртүрлі форматтарға түрлендіруге, электрондық қолтаңбаларды қосуға арналған мақалалар мен бейнелерді орналастыруға болады. Осылайша, ілгерілеумен бір мезгілде пайдаланушыларды оқыту жүргізіледі.
Мазмұнды маркетингтің әсері бірден байқалмайды. Әдетте-алты айдан бір жылға дейін емес. Сонымен қатар, сайттар мен әлеуметтік желілерде жарнамалау кезінде SEO және SMM әдістерін қолдану қажет.
Мониторинг үшін өздерінің аналитикалық құралдарын, мобильді Тараптар ұсынатын функционалдылықты және басқа әдістерді қолданыңыз. Жүктеп алу, орнату және іске қосу, Лицензия Сатып алу және ресімделген жазылымдар санын, сеанстардың ұзақтығын, орнатудан бірнеше күн өткен соң қайта іске қосу санын, серверлердің күйін және журналдардың мазмұнын зерттеңіз. Айқын дабыл-ашуланған пікірлер және техникалық қолдау туралы өтініштер.
Шығарылғаннан кейін бағдарламалық жасақтама тоқтамайды. Көптеген заманауи әдістемелерге сәйкес, әзірлеу, негізінен, өнімге сұраныс болғанша немесе сіз ауыстыруды ұсынғанға дейін шексіз циклдар бойынша жүзеге асырылады.
Пікірлер тараптардың функционалдығы және кері байланыс нысандары арқылы жіберіледі. Сондай-ақ, клиенттер әлеуметтік желілердегі ресми беттердегі түсініктемелерде, электрондық пошта арқылы және техникалық қолдау арналары арқылы өз пікірлерін айта алады.
Тараптар қосымшаның орташа бағасын және әзірлеушінің шолулармен өзара әрекеттесуін бағалайды. Бұл деректер автоматты ұсыныстар мен жылжыту жүйелері үшін, соның ішінде фичеринг үшін қолданылады. Оң нәтиже түсініктемелерге жауап береді (олар әрқашан сыпайы болуы керек).
Пайдаланушыларды пікірлерімен бөлісуге ынталандыруға болады-пайдалану процесінде тиісті ұсыныстары бар терезелерді шығару, қалған байланыс деректері бойынша хабарламалар жасау. Алайда, тым интрузивті болмаңыз.
Маңызды қателер мен осалдықтарды түзету мүмкіндігінше қысқа мерзімде қамтамасыз етіледі. Жоспарлы жаңартулар кестесі негізгі клиенттермен келісімдермен және таңдалған әзірлеу әдістемесімен анықталады. Әдетте-әр 3-4 апта сайын немесе одан аз.
Корпоративті бағдарлама үшін жиі жоспарлы жаңартулар қажет емес. Әдетте, ұйымдардағы жаңартуларды орталықтандырылған және жүйелік әкімшілер жүргізеді. Алдын ала ішкі тестілеу және қауіпсіздік тексерулері жүргізілуі мүмкін. Бұл көп уақытты қажет ететін және ұзақ процесс болғандықтан, басқа біреудің уақытына құрметпен қараңыз.
Жаңартулар міндетті түрде құжатталады. Тараптардағы беттерде, Сайтта және әлеуметтік желілерде тиісті жаңалықтар орналастырылады. Сондай-ақ, ресми онлайн-ресурстарда егжей-тегжейлі патчтар (өзгерістер тізімдері) орналастырылған. Сонымен қатар анықтамалық материалдар өзектендіріледі. Ақпаратты қайталаған жөн. Тараптардағы таңбалар санына шектеулерге байланысты шығарылымның барлық ерекшеліктерін бояу әрдайым мүмкін емес, ал барлық тапсырыс берушілер әлеуметтік желіге қол қоймайды.
VIP клиенттерге бастапқы техникалық құжаттама және жоба менеджерімен және әзірлеушілермен тікелей кеңес қажет болуы мүмкін. Өзара іс — қимыл схемаларын алдын-ала келісу керек-келісімшарттар жасасу кезінде.
Пайдаланушыларды қолдау процесінде алынған ақпарат белгілі бір кемшіліктерді тікелей көрсете алады. Дегенмен, деректерді жан-жақты бағалау және қосымша сынақтармен екі рет тексеру қажет.
Талаптарды жинау кері байланыс арналары арқылы да жүргізілуі мүмкін. Оларға жаңа функциялар туралы тілектер жиі келеді. Тиісті жаңартуларды шығару әрқашан мүмкін емес немесе орынды емес. Кейде бұл архитектураны толығымен қайта құруға және қымбат зерттеулер жүргізуге тура келеді.
Ішкі аналитика құралдары өнімді дамыту үшін баға жетпес ақпарат береді. Олар әр функцияның белсендіру санын, барлық сеанстардың ұзақтығын, терезелерді қарауды, аппараттық құралдардың сипаттамаларын және т.б. бақылайды. Егер опциялардың кез-келгені әрең қолданылса, бірқатар анықтамалық басылымдар шығарылуы мүмкін (қызығушылықты ояту үшін) немесе оларды одан әрі дамыту үшін ресурстарды уақытша ысырап етпеу керек. Алайда, мұндай аналитикалық құралдар офлайн өнімдерге, жабық инфрақұрылымда іске қосылатын Бағдарламалық жасақтамаға немесе клиенттер үшін максималды құпиялылық маңызды болса, жарамайды
Мен бағдарламалық жасақтама жасаушылардың корпоративті бағдарламалық жасақтаманы қалай жасайтыны туралы негізгі ақпаратпен бөлістім. Мұның бәрі әдіснаманы таңдаудан басталады. Соңғы онжылдықтарда спиральды және итеративті тәсіл басым болды. Әрі қарай, сіз нарықты мұқият зерттеп, әлеуетті тапсырыс берушінің портретін жасауыңыз керек. Осы деректерге сүйене отырып, сіздің ұсынысыңызды бәсекелестер массасынан ерекшелендіретін USP ерекшеліктерін тұжырымдаңыз.
Тікелей әзірлеу тестілеумен қатар жүреді, оның ішінде нақты пайдаланушыларды тарту. Өнімді шығару жобаның аяқталуы емес. Маркетингтік әрекеттер, тұрақты жаңартулар, көрсеткіштерді бақылау және кері байланыс қажет.
Приветствую! Я Тимур Драгунов. Уже более 10 лет работаю в сфере IT. Карьеру начинал как разработчик интернет-проектов. Позже присоединился к команде российского редактора PDF Commander. В последние годы мы с коллегами сфокусировались на корпоративном сегменте. Эта часть рынка традиционно считается более доходной, чем выполнение проектов для обычных пользователей. К тому же у значительной части потенциальных заказчиков появился спрос на альтернативы решениям от крупных международных компаний.
Впрочем, на смену направления работы повлияли не только эти два фактора. У корпоративных клиентов требования жестче и есть запрос на решение специфических задач. Для нас это стало серьезным вызовом и помогло найти новые пути профессионального развития. Я расскажу подробнее про этапы разработки программного обеспечения для организаций. Эта информация пригодится, если вы с командой планируете переориентировать свою деятельность.
0 этап: что нужно знать про жизненный цикл корпоративного ПО
Жизненный цикл ПО (SDLC — Software Development Lifecycle) — это период времени, который начинается в тот момент, когда вы решаете создать какой-либо софт, а заканчивается, когда разработка, поддержка и реализация приложения или сервиса полностью прекращаются.
Люди занимаются созданием ПО, в том числе для всевозможных организаций, десятилетиями. Вполне закономерно, что за это время сформировались разные модели SDLC и методы управления проектами.
Хаотичная разработка, когда команда занимается спонтанно возникающими идеями, иногда может приносить некоторые результаты. Но только в небольших стартапах и до тех пор, пока основные участники полны энтузиазма. Этот ресурс быстро расходуется. Параллельно как снежный ком растут негативные эффекты. Множится число багов, интересный функционал остается в зачаточном состоянии, теряется общее видение конечного продукта. В итоге пользователи разочаровываются и уходят к конкурентам.
Необходимо как можно скорее упорядочить организацию разработки кода и других элементов компьютерного программного обеспечения. Кратко остановимся на основных подходах.
- Каскадная модель (waterfall, модель водопада). Весь процесс делится на несколько жестких стадий. Переход к следующей фазе происходит только тогда, когда будут полностью выполнены все работы на предыдущем этапе.
На практике в чистом виде метод подходит только для относительно небольших и простых проектов. Запросы клиентов периодически меняются, как и вся ситуация на рынке. Поэтому крайне сложно быстро и за приемлемый бюджет создать софт, который раз и навсегда закроет какую-то часть потребностей (например, работу с PDF-файлами) и не понадобятся существенные модернизации. - V-образная модель (V-Model, VEE модель). Параллельно проводятся этапы разработки и тестирования. При этом данные, полученные на одной из двух ветвей, влияют на другую. Например, предложенная базовая модель анализируется и проверяется на соответствие отраслевым стандартам. По результатам — дорабатывается и усложняется. То же самое происходит с архитектурой, прототипом, дополнительными компонентами финального продукта.
Подход требует много ресурсов, но обеспечивает надежный контроль качества. К методу прибегают в отраслях, где даже незначительные ошибки приводят к фатальным последствиям (космос, авиация, атомная энергетика и т.п.). - Итеративная модель. Работы ведутся параллельно, полученные результаты, включая промежуточные, непрерывно анализируются, и на основе этой информации корректируются текущие и будущие задачи. Этот подход сейчас преобладает. На его основе возникло множество других методологий — Agile, SCRUM, Канбан и другие.
Модель позволяет быстро адаптироваться к меняющимся условиям. Однако возможны проблемы с правильным подсчетом бюджета и сроков реализации проекта. Также при последующих изменениях иногда приходится серьезно переделывать изначальную архитектуру. - Спиральная модель. Сочетает в себе удачные элементы итеративного и каскадного подходов. Разработка и внедрение программного обеспечения ведется циклами. В начале каждого оцениваются доступные ресурсы, риски и потенциальные возможности. На основе этих данных составляется список работ, которые реально выполнить к назначенной дате.
Основной недостаток модели заключаются в том, что не всегда удается правильно определить момент перехода на следующий цикл. Также иногда команда слишком увлекается и проводит избыточную оптимизацию продукта.
1 этап: работа над концепцией и идеей
Независимо от выбранной методологии SDLC, сперва нужно определиться с тем что и для кого создавать.
Исследование рынка и конкурентов
Существует как минимум несколько компаний или разработчиков-одиночек, которые предлагают софт с похожей функциональностью. Например, операции с PDF-файлами можно выполнять в нашем PDF Commander, Adobe Acrobat, решениях от Foxit, пакете Microsoft Office или в его аналоге LibreOffice.
Составьте список ПО, инструментарий которого похож на ваш, и их компаний-разработчиков. Досконально изучите все особенности этого софта. Проанализируйте, как он развивается. Постарайтесь спрогнозировать, какие изменения произойдут в будущем, и тем самым выполните анализ рисков для своего бизнеса.
Существуют организации, которые проводят масштабные исследования рынка на заказ. При достаточном бюджете можно обратиться за их услугами. Однако полностью полагаться на эти компании не стоит. Вам как разработчику нужно лично знакомиться с предложениями конкурентов. Только так вы будете понимать, что и как создавать.
Составление портрета пользователя
Определите категории клиентов, которым может пригодиться ваше ПО. Общие, абстрактные формулировки («все, кто…», «все пользователи, которым…») ошибочны и бесполезны для вас.
Более удачный пример: организации со штатной численностью до 50 человек, в сфере торговли непродовольственными товарами, используют приложения А, В и С.
Определение уникального торгового предложения (USP)
Изучив рынок и потенциальных клиентов, вы установите потребности пользователей, которые не удовлетворены совсем или удовлетворены не полностью. Также вы определите ошибки и проблемы конкурентов.
Благодаря этому вы вряд ли создадите абсолютно уникальный товар. Однако сможете предложить продукт, который не только решает основной (для этого сегмента) набор задач, но и устраняет наболевшие проблемы.
2 этап: планирование и проектирование
Выше я уже упоминал, что процесс технической разработки программного обеспечения не должен быть хаотичным. Помимо моментов, связанных с организацией самой команды, это требование также касается всех повседневных задач.
Составление пользовательских сценариев
Когда пользователь запускает ПО, он собирается решить некоторую задачу. Как правило, она не одна и состоит из множества дополнительных действий.
Необходимо предугадать как можно больше таких возможных задач и провести анализ требований клиента. Затем — представить все это в виде четкой последовательности действий. Причем формулировки должны быть конкретными, привязанными к реальной жизни.
Плохой пример: пользователю необходимо отредактировать документ, для этого он открывает файл и вносит в него правки.
Более удачный: клиент получил проект договора в PDF от контрагента. Это предполагает следующие действия:
- Файл документа открывается в программе. Лучше совместить редактор и просмотрщик, чтобы материал не пришлось по несколько раз переимпортировать в разном софте. Значит, приложение должно быть достаточно легковесным, чтобы загрузка не происходила слишком долго.
- Документ просматривается. Нужны опции для скроллинга и масштабирования. Желательно добавить функцию комментариев и пометок — если при чтении появятся мысли и замечания, их можно сразу же добавить.
- В документ вносятся правки. Требуются функции редактирования — удаление фрагментов, вставка нового текста. Если содержание не распознано, нужен инструмент для OCR (оптического распознавания символов).
- Финальный вариант сохраняется. Необходим корректный экспорт в PDF с соблюдением всех требований стандарта. Возможно, клиенту нужно сохранить документ в другой формат. Вероятнее всего, это DOCX, RTF, JPEG и PNG.
- Клиент согласен с предложением контрагента и готов подписать договор. Нужна функция печати на принтере. Деловая практика может допускать такой вариант, когда в электронный документ добавляется факсимиле и изображение печати. Также часто используются электронные подписи.
При помощи подобных сценариев проще понять реальные потребности заказчиков и на основе этого предлагать удобные и функциональные решения.
Разработка ТЗ: структура, требования, ограничения
Обычно техническое задание — это документация по проекту. Она различается по степени детализации. Если разработка выполняется по индивидуальным контрактам, техзадание — это спецификация требований клиента с указанием сроков реализации.
В первом и относительно небольшом по объему документе излагают общее видение приложения или веб-сервиса. Приводят платформу, список основных функций, USP, перечень конкурирующих решений, оценку рисков, описывают портрет пользователя. Этот документ нужен, чтобы сообщить команде, над чем предстоит работать (то, что просто проговаривается во время собраний, имеет свойство тут же забываться). На его же основе можно подготовить презентацию для инвесторов.
Следующий документ детализирует функционал. Если ПО относительно простое, можно вести и постепенно дополнять один файл. В остальных случаях желательно под каждую функцию (группу схожих функций) вести отдельный документ. Здесь подробно описывают архитектуру, принцип работы каждого инструмента. Для лучшего понимания добавляют схемы, таблицы, инфографику, мокапы пользовательских интерфейсов. Открыв эту документацию, каждый член команды должен быстро понять, как работает продукт и что именно нужно делать по задаче.
Документация должна быть понятной и удобной для команды. Не стоит постоянно экспериментировать и отказываться от уже принятых форматов. Кроме того, документация не статична. Абсолютно нормальная практика — просить уточнений и дополнений, высказывать конструктивные предложения и замечания.
Детальную документацию составляют с учетом текущей итерации SDLC. Например, если в этом спринте или майлстоуне вы внедряете опции форматирования текста, именно их и нужно описывать. Далее хорошей практикой будет прикреплять к конкретным задачам ссылки на соответствующие разделы документации.
Также желательно составлять относительно долгосрочные планы развития (дорожные карты, или roadmap). В них отражают будущий функционал с привязкой к определенным датам. Например, март — добавление таблиц, апрель — расширенное форматирование, поддержка сканеров, май — OCR, и т.д.
Roadmap-ы помогают распределять ресурсы, координировать деятельность команды, лучше продумывать архитектуру, своевременно начинать внедрение продукта. Однако они не всегда остаются в неизменном виде. Иногда появляются критические баги, на устранение которых уходит много времени. Важный клиент может попросить добавить определенную функцию.
Создание прототипов или мокапов
Прототип — это ранняя версия продукта. В нем демонстрируется работа основных опций, запланированных на определенную итерацию. Стабильность и визуальная привлекательность не имеют значения. На этом этапе необходимо продемонстрировать, что делает конкретное ПО и насколько удобно им пользоваться.
Мокапы — предварительные макеты или концепты интерфейса. Они демонстрируют, как будет выглядеть приложение. Мокапы нужны для презентации продукта, проверки некоторых гипотез и в качестве иллюстраций в документации.
3 этап: разработка интерфейса и пользовательского опыта (UI/UX)
Интерфейс создается с учетом функционала и других технических особенностей. При этом учитываются привычки и предпочтения конкретной категории пользователей.
Создание визуальных концепций
Макеты интерфейса демонстрируют внешний вид основного окна (главной страницы), каждого меню, вкладки, всплывающих подсказок и т.д. Их разрабатывают с учетом пользовательских сценариев, документации, принципов дизайна и эргономики.
При дальнейшей детализации желательно привнести элементы фирменного стиля — характерную палитру, формы, логотипы, шрифты и прочее. Визуальный образ делает бренд узнаваемым и помогает в продвижении.
В идеале пользование продуктом должно приносить эстетическое удовольствие. При этом важно соблюдать баланс. Не стоит прикреплять долгие анимации и навязчивые эффекты — совсем скоро они начнут раздражать.
Разработка узнаваемых, привлекательных и удобных концепций дизайна — крайне сложная задача. Даже международные корпорации не стесняются поручать ее сторонним специалистам.
Тестирование прототипов с участием пользователей
Созданные прототипы необходимо проверять в реальных сценариях. На начальных этапах разработки тестирование проводится членами команды и их близкими (семьей, друзьями). В дальнейшем желательно привлекать больше независимых людей. Друзья и члены семей не хотят обижать и расстраивать своих близких, поэтому могут не сообщать о недостатках.
Существует множество методик тестирования. Они могут предусматривать видеосъемку с разных ракурсов и захват экрана, анкетирование, отзывы в свободной форме, продолжительные интервью. К участию привлекаются люди, максимально соответствующие портрету будущих пользователей. У студента, домохозяйки и офисного служащего разные представления о том, каким должен быть редактор текстов. В этом случае лучше пригласить на тестирование сотрудников крупных, мелких и средних компаний, которые регулярно работают с большими объемами документов.
Тестирование можно отдать на аутсорс. К услугам сторонних компаний придется прибегнуть, если вы находитесь в небольшом провинциальном городе и поблизости нет достаточно числа подходящих людей. Или собираетесь выходить на иностранные рынки
4 этап: разработка и код
В процессе разработки документация и все идеи обрастают кодом и постепенно превращаются в ту или иную версию продукта.
Работа программистов: фронтенд, бэкенд, интеграция
Состав команды разработчиков зависит от функционала и архитектуры системы. С учетом современных подходов к программной инженерии чаще всего деятельность ведется по трем направлениям:
- Бэкенд. Серверная часть (при клиент-серверной архитектуре) и внутренняя логика ПО. Бэкенд-разработчики занимаются программированием структуры данных, их хранения и обработки по определенным алгоритмам.
- Фронтенд. Клиентская часть (при клиент-серверной архитектуре) и интерфейс программы. Фронтенд-разработчики делают так, чтобы все кнопки-списки-меню правильно функционировали, корректно отправляли исходные данные во внутреннюю логику и возвращали пользователю конечный результат.
- Интеграция. Взаимодействие приложения с другим ПО. Это могут быть плагины, определенные программные интерфейсы (API), сторонние библиотеки, импортируемый контент и т.п.
Методологии
Они идентичны подходам к организации SDLC. Методологию желательно выбирать на самых ранних стадиях разработки или еще при формировании команды и не менять без крайней необходимости.
Переход на другие подходы на достаточно долгое время парализует всю деятельность. Кто-то из коллег не захочет адаптироваться и покинет компанию. Существует вероятность, что вам даже придется заново проектировать архитектуру приложения. То есть фактически заново пересоздавать все проделанное ранее.
Проведение первых модульных тестов
Модульное тестирование (блочное или юнит-тестирование) — проверка работоспособности отдельных изолированных частей кода. В процессе разработчики удостоверяются, что различные модули выполняют все нужные действия, способны корректно взаимодействовать с другими частями ПО и выдерживают определенные нагрузки.
Для инструментов разработки программного обеспечения есть готовые библиотеки юнит-тестирования. Например, NUnit для C# или JUnit для Java.
5 этап: проверка работоспособности, безопасности, производительности
Тестирование и отладка программы не ограничиваются ранними прототипами. Оно регулярно проводятся на каждом этапе жизненного цикла.
Юнит-тестирование
Я уже упоминал его выше. Это первая фаза в иерархии тестов. Почти всегда современное ПО состоит из множества относительно мелких модулей. Необходимо своевременно проверять работоспособность каждого из них. Это не дает полной гарантии, что вся программа будет функционировать, как задумано. Однако вы сможете заранее избавиться от некоторых багов и повторно использовать часть кода (конечно, если она успешно пройдет юнит-тесты).
Обычно юнит-тестирование запускается после написания кода. При успешной проверке он загружается в систему контроля версий.
Интеграционное тестирование
Разработчики проверяют, способны ли разные модули в принципе взаимодействовать друг с другом и насколько корректно происходит этот процесс. Для этого задействуются системы непрерывной интеграции (CIS). Они отслеживают изменения в системах контроля версий. Затем запускают проверки отдельных компонентов. Если эта фаза пройдена успешно, выполняется компиляция и тестируется взаимодействие модулей между собой. По результатам генерируется отчет.
Этот этап не стоит путать с системным тестированием, на котором проверяется весь продукт.
Тестирование интерфейса и UX
Здесь изучают работоспособность и удобство. Поиском багов занимаются QA-инженеры или тестировщики. Они проверяют, чтобы каждый элемент интерфейса был на своем месте (даже опытная команда иногда забывает добавить важную кнопку или вставляет вкладку не в то окно) и запускал нужное действие. При этом руководствуются документацией.
Удобство и общие ощущения (или UX) оценивает фокус-группа пользователей. Это тестирование может быть открытым (присоединяются все желающие) или закрытым (участвуют индивидуально отобранные люди и организации).
QA и UX-тестирование можно поручать подрядчикам. Это особенно оправдано, когда требуются масштабные проверки во множестве сценариев.
Этап 6: финальный релиз продукта
При успешном завершении тестирования приложение готово к выходу на рынок.
Загрузка приложения в магазины (App Store, Google Play)
Мобильные приложения в большинстве случаев распространяется через встроенные магазины соответствующих платформ. Для iOS и iPad OS это единственный возможный вариант (взлом прошивки и разные достаточно сложные схемы не рассматриваем). В Android приложения можно устанавливать из APK-файлов. Однако этот способ подходит только для специфических случаев. Например, программа распространяется только по индивидуальным контрактам с заказчиками.
Чтобы размещать софт в сторах, нужно зарегистрировать аккаунт разработчика (App Store, Google Play). В процессе придется заполнить анкету и внести небольшую плату.
Создание сайта десктопного продукта
Через него распространяется софт для компьютеров. Можно запустить отдельный ресурс или сделать дополнительный раздел на сайте разработчика. Потребуются страницы с подробной информацией о ПО и его стоимости, документацией и функционал корзины с возможностью обработки платежей и автоматической рассылкой лицензионных ключей или дистрибутивов.
Презентация и маркетинговые кампании
К продвижению обычно приступают до релиза. Маркетинговые стратегии зависят от того сегмента рынка, на который вы позиционируете продукт. Решения для крупных корпоративных заказчиков презентуют на офлайн-мероприятиях. Некоторое число клиентов можно получить на выставках, после публикаций в отраслевых изданиях и рассылки коммерческих предложений.
ПО для более мелких заказчиков можно продвигать через профильных блогеров. Неплохие результаты показывает контент-маркетинг. Он заключается в регулярном размещении полезных материалов, тематика которых совпадает с назначением вашего приложения. Например, если программа позволяет создавать и обрабатывать PDF-документы, можно выкладывать статьи и ролики с советами по оцифровке бумажных материалов, конвертации в разные форматы, добавлению электронных подписей. Таким образом, одновременно с продвижением ведется обучение пользователей.
Эффект от контент-маркетинга проявляется не сразу. Обычно — не ранее чем через полгода-год. Параллельно нужно задействовать приемы SEO и SMM при продвижении на сайтах и в соцсетях соответственно.
Мониторинг первых дней работы
Для мониторинга используют собственные инструменты аналитики, функционал, который предоставляют мобильные сторы, и другие методы. Изучают количество скачиваний, установок и запусков, покупок лицензий и оформленных подписок, продолжительность сессий, число повторных запусков спустя несколько дней после инсталляции, состояние серверов и содержание логов. Очевидный тревожный сигнал — гневные отзывы и обращения в техподдержку.
7 этап: сбор обратной связи, исправление багов, добавление нового функционала
После релиза создание ПО не останавливается. По многим современным методологиям, разработка в принципе ведется по бесконечному количеству циклов, пока на продукт есть спрос или вы не предложите замену.
Мониторинг отзывов
Отзывы отправляются через функционал сторов и формы обратной связи. Также клиенты могут высказывать свое мнение в комментариях на официальных страницах в соцсетях, по электронной почте и через каналы техподдержки.
Сторы оценивают среднюю оценку приложения и взаимодействие разработчика с отзывами. Эти данные используются для систем автоматических рекомендаций и продвижения, в том числе фичеринга. Позитивный эффект дают ответы (они всегда должны быть вежливыми) на комментарии.
Можно стимулировать пользователей делиться мнением — в процессе эксплуатации ПО выводить окна с соответствующим предложениям, делать рассылки по оставленным контактным данным. Однако не будьте слишком навязчивыми.
Выпуск обновлений
Исправления критических ошибок и уязвимостей предоставляют в максимально сжатые сроки. График плановых обновлений определяют соглашения с ключевыми клиентами и выбранная методология разработки. Обычно — каждые 3-4 недели или реже.
Слишком частые плановые апдейты для корпоративного ПО нежелательны. Как правило, обновления в организациях проводятся централизованно и системными администраторами. Предварительно могут выполняться внутренние тестирования и проверки безопасности. Поскольку это трудоемкий и длительный процесс, относитесь с уважением к чужому времени.
Обновления обязательно документируют. На страницах в сторах, на сайте и в соцсетях размещают соответствующие новости. Также на официальных онлайн-ресурсах выкладывают подробные патчноуты (списки изменений). Одновременно с этим актуализируют справочные материалы. Желательно дублировать информацию. Из-за ограничений на количество символов в сторах не всегда удается расписать все особенности релиза, а на соцсети подписаны не все заказчики.
VIP-клиентам может требоваться исходная техническая документация и консультации непосредственно с менеджером проекта и разработчиками. Схемы взаимодействия необходимо согласовывать заранее — при заключении договоров.
Оценка пользовательских данных для улучшений
Информация, полученная в процессе поддержки пользователей, может прямо указывать на определенные недостатки. Однако данные нужно оценивать комплексно и перепроверять дополнительными тестами.
Сбор требований может проводиться и через каналы обратной связи. На них нередко приходят пожелания о новых функциях. Выпускать соответствующие обновления не всегда возможно или целесообразно. Иногда для этого приходится полностью переделывать архитектуру и проводить дорогостоящие исследования.
Бесценную информацию для развития продукта дают инструменты внутренней аналитики. Они отслеживают количество активаций каждой функции, длительность всех сессий, просмотра окон, характеристики аппаратного обеспечения и прочее. Если какие-то из опций почти не используются, можно выпустить ряд справочных публикаций (чтобы стимулировать интерес) или временно не тратить ресурсы на их дальнейшее развитие. Однако такие инструменты аналитики не подходят для офлайновых продуктов, софта, который запускается в закрытой инфраструктуре, или если для клиентов принципиальна максимальная конфиденциальность
Резюмирую
Я поделился основной информацией о том, как разработчики программного обеспечения создают корпоративный софт. Все начинается с выбора методологии. В последние десятилетия преобладают спиральный и итеративный подход. Далее нужно тщательно изучить рынок и составить портрет потенциального заказчика. На основе этих данных сформулировать USP — особенности, которые выделят ваше предложение из массы конкурентов.
Непосредственно разработка сопровождается тестированием, в том числе с привлечением реальных пользователей. Выпуск продукта не является завершением проекта. Необходимы маркетинговые активности, регулярные апдейты, мониторинг метрик и обратной связи.
