Неліктен жоба бірнеше мердігер болғанда бәсеңдейді

ИТ-жобадағы мәселелер көбіне бір анық жұмыс блоктан пайда болмайды. Көбінесе бәрі өзара түйісу жерлерінде тоқтап қалады: жабдық жеткізу, лицензиялар, баптау және іске қосу арасында. Әр мердігер тек өз бөлігі үшін жауапты болғанда, жалпы нәтиже оңай тұралайды.

Типтік жағдай қарапайым. Жабдық нысанда тұр, бірақ енгізу басталмайды: активация кілттері дайын емес, конфигурация расталмаған, қолжетімдіктер берілмеген. Формальды түрде жоба жүріп жатыр. Шын мәнінде — тоқтап тұр.

Кешігулер әсіресе мынадай кезде белең алады:

жабдық жеткізілді, бірақ оның құрамы енгізу командасының күткеніне сай келмейді;
лицензиялар төленген, бірақ әлі активтелмеген немесе басқа схемаға рәсімделген;
интегратор басқа тараптан қолжетімдіктерді немесе келісімдерді күтуде;
монтажды бастауға болады, бірақ ешкім уақытынан бұрын тәуекел алғысы келмейді.

Сондықтан тапсырыс беруші тез арада диспетчерге айналады. Оған хаттарды ұштастыру, құжат нұсқаларын тексеру, кім не меңзегенін түсіну және қай кезеңде бәрі тоқтап қалғанын іздеу керек болады. Әр өзгеріске артық уақыт кетеді, себебі әр қатысушы тек өз бөлігін қарайды және соңғы нәтиже үшін жауапты емес.

Бұл әсіресе мемлекеттік органдар, мектептер, клиникалар және ірі компаниялар үшін айқын көрінеді, онда қабылдау формализацияланған. Бір мердігер: "біз жеткіздік" дейді. Екіншісі: "біз кезеңге қол қойылғаннан кейін бастаймыз" деп жауап береді. Үшіншісі алдыңғы жұмыстың жабылуын күтеді. Әдетте техникалық үлкен проблема жоқ болса да, мерзімдер артта қалады.

Ешкім бүкіл тізбекті түгелдей басқармайтын болса, жоба көбіне үзік-жұмсақ жүреді. Әсіресе жабдық пен лицензиядан бастап жүйеге пайдаланушыларды енгізуге дейінгі тізбек бойынша апта-тəптəктер жоғалады.

Қашан бір шарт-шарт тиімді

Бір шарт-шарт дайын нәтижеге нақты күнге дейін маңызды болған жерлерде әсіресе ыңғайлы. Жаңа офис, филиал, сынып немесе медициналық бөлмені "бөліп" ашуға болмайды. Іске қосу күнінде адамдарға жұмыс орындары, қолжетімдіктер, бағдарламалар және бапталған техника керек.

Бұл схема тапсырыс берушіге бір кесте, бір жауапты және бір нақты нәтиже береді. Бұл әрдайым арзан бола бермейді, бірақ басқара беру жағынан көп жағдайда оңайрақ.

Егер техника, лицензиялар және баптау бір жиынтық ретінде жүрсе, үйлесімділік, мерзімдер мен қабылдауда аз түсініспеушілік болады. Қай мердігер конфигурацияны тексеруі тиіс, кім жұмыс орындары образына дайындық жасайды және барлық сатып алынғаннан кейін іске қосу сәтсіз болса кім жауапты деген тұрақты сұрақтар туындамайды.

Бір шарт-шарт әсіресе мына кезде тиімді: іске қосу қатты күнге байланған, тез арада көп бірдей жұмыс орындарын орналастыру керек, ішкі командада үйлестіруге уақыт жоқ және іске қосу кейінгі тоқтап қалу қымбатқа түседі.

Мысалы, 50 қызметкерге арналған жаңа филиалды елестетіңіз. Компьютерлер әкелініп, серверлік немесе бұлт инфрақұрылымы дайындалып, лицензиялар орнатылып, пайдаланушылар қосылып, желі, басып шығару және негізгі қауіпсіздік саясаттары тексерілуі керек. Егер бұларды үш түрлі компания басқаратын болса, тапсырыс беруші бүкіл маршрутты өз бетімен үйлестіруі тиіс. Бір команда жеткізу мен енгізуді өз мойнына алса, іске қосу әдетте тегіс өтеді.

Тағы бір артықшылығы — мәселелер тезірек шешіледі. Орнатудан кейін "темір біздікі, баптау біздің шаруамыз емес" деген дау басталмайды. Тапсырыс беруші үшін маңыздысы — жұмыс істейтін сервис, ұзақ хат алмасу емес.

Бұл тәсіл ішкі IT-команда шағын немесе ағымдағы тапсырмаларға жүктелген жерде өте пайдалы. Онда ондай жағдайда келіссөздер орнына бір байланыс сызығы және аз қолмен бақылау қалады.

Осындай жобалар үшін жабдықты, лицензияларды және енгізуді бір жүйеде жаба алатын серіктес ыңғайлы. Қазақстанда бұл модельді мысалға GSE.kz қолдайды: компания компьютерлер мен серверлер шығарады, жүйелік интеграциямен айналысады және ел бойынша сервис желісі арқылы жұмыс істейді. Бұл бір шарт әрдайым жақсы деген сөз емес, бірақ "нақты күнге" жасалатын іске қосулар үшін мұндай формат көбіне сенімдірек болады.

Қашан лоттарды бөлу тиімді

Лоттарды бөлу де ақылға қонымды болуы мүмкін. Бұл тапсырыс берушінің ішкі командасы мықты және жобаны толық басқаратын мердігер қажет болмаса пайдалы.

Егер сіздің мамандарыңыз сәулет шешімдерін өздері қабылдап, мерзімдерді бақылай алса және жеткізушілерді үйлестіре білсе, сатып алуды бірдей басқарумен бірге алу қажеттілігі жоқ. Ондай жағдайда жабдық, лицензиялар және енгізу бөлек сатып алынуы мүмкін.

Бөлуге жиі себеп — әртүрлі бюджеттік бағандар. Серверлер мен жұмыс станциялары бір мақаладан, лицензиялар — басқа мақаладан, ал енгізу мен баптау — үшінші мақаладан өтеді. Мұны бір шартқа біріктірмек болғанда келісім одан да ұзаққа созылуы мүмкін.

Әр бөлікті бөлек алу әдетте ондаған жағдайларда ақталады, егер бір бөлік стандартты болса, ал екіншісі сирек мамандандыруды талап етсе. Негізгі инфрақұрылым, жұмыс орындары немесе серверлерді ірі өндірушіге немесе жүйелік интеграторға беріп, ал салаға тән медициналық, банктік немесе өндірістік жүйені дәл сол бағыттағы профильдік командаға тапсыру орынды.

Бөлу әдетте мына үш шарт орындалғанда жақсы жұмыс істейді: сіздің командаңыз блоктар бойынша жобаны жүргізген тәжірибесі бар; жауапкершілік шекаралары алдын ала жазылған; кезеңдер арасындағы тәуелділік төмен. Осы шарттардың бірі болмаса, үнемдеу орнына орындаушылар арасында даулы жағдайға тап болу оңай.

Тендер ережелері мен ішкі сатып алу саясаттарын да ескеру керек. Кейде жабдыққа арналған лот жеткізу мерзімі, локализациясы мен сервисі бойынша негізделуі оңай, ал енгізу лоты — команда құзыреті мен жүйедегі тәжірибеге байланысты. Формализацияланған сатып алулар үшін бұл жиі бір үлкен келісімнен гөрі практикалық болады.

Мысал ретінде: компания компьютер паркін жаңартады, сервер сатып алып, лицензияларды ұзартуда, сонымен қатар салаға тән жүйені енгізіп жатыр. Стандартты жабдықты бөлек лотқа шығарып, ерекше шешімді профильдік мердігерге қалдыру орынды болуы мүмкін. Негізгі шарт — жобаны форма үшін емес, нақты бюджеттеу, бақылау және дұрыс мамандарды таңдау жеңілдейтін кезде бөлісу.

Қалай шешім қабылдау: қадамдар

Бастау керек нәрсе — позициялар тізімінен емес, соңғы нәтижеден. "50 ПК, сервер және лицензия сатып алу" деп емес, "филиалды 1 қыркүйекке дейін іске қосу: қызметкерлер бірінші күннен бастап есеп жүйесінде, пошта және қорғалатын желіде жұмыс істесін" деп ойлану. Мақсат осылай қойылғанда, тек жабдық жеткізу емес, оны баптау, үйлесімдікті тексеру және жұмысқа тапсыру маңызды екені көрінеді.

Сосын жұмыстарды міндетті және қосымшаға бөліп алу пайдалы. Міндеттілерге әдетте жабдық пен лицензияларды жеткізу, монтаж, базалық баптау, қолданыстағы инфрақұрылымға қосу және қабылдау сынақтары жатады. Басты іске әсер етпейтіндерді негізгі келісімге артық жүктемеу жөн.

Келесі қадам — тәуелділіктерді бағалау. Егер серверлер, жұмыс станциялары, лицензиялар мен енгізу тығыз байланысты болса, мердігерлер арасындағы үзіліс тәуекелдерді көбейтеді. Ал егер жеткізу стандартты болса және енгізу белгілі бір жеткізушіге қатты тәуелді болмаса, бөліп алу тыныш өтуі мүмкін.

Келесі бірнеше сұраққа жауап беру жеткілікті:

қандай нәтиже нақты мерзімге дайын болуы тиіс;
іске қосу үшін қандай жұмыстар міндетті;
қай жерде бір орындаушының екіншісіне тәуелділігі критикалық;
нәтижені түгелдей кім қабылдайды, бөліп емес;
тәуекелдер мен мерзімдер тұрғысынан не тиімдірек: бір мердігер ме, әлде бірнеше ме.

Қабылдау мәселесі аса маңызды. Егер жоба толық жұмыс істеп тұрғанын растайтын адам немесе команда жоқ болса, жақсы жеткізу өзін өзі құтқармайды. Құжаттар жабылады, ал пайдаланушылар әлі де қолжетімдіктерсіз, баптауларсыз немесе қолдаусыз қалып кетуі мүмкін.

Алдын ала не жазып қою керек

Жоба бір мердігер арқылы жүрсе де, анықталмаған келісімдер оның бағытын бұзуы мүмкін. Бірыңғай жауапкершілік тек не кіретіні, қандай мерзіммен және қандай ережелер бойынша жоба аяқталғаны алдын ала анықталған кезде ғана жұмыс істейді.

Бірінші бекіту керек нәрсе — жеткізу құрамы. "Сервер мен лицензиялар" деп емес, нақты модельдер, саны, конфигурациялары, бағдарламалық редакциялары, лицензиялардың мерзімі және қызметтер тізімі. Егер жобаға серверлер, жұмыс станциялары, операциялық жүйелер, офис пакетi, монтаж, пусконаладка және оқыту кіреді — әр блокты бөлек атау керек.

Екінші міндетті құжат — күнтізбелік жоспар. Онда тек соңғы іске қосу күні ғана емес, бақылау нүктелері маңызды: спецификация қашан бекітіледі, жабдық қашан келеді, лицензия қашан дайын, баптау қашан басталады, деректерді көшіру қашан өтеді және қабылдау қашан болады. Осы ориентирлерсіз талас әдетте "біз ойладық, бұл кейін" деген сөзден басталады.

Рөлдерді алдын ала белгілеу де өте маңызды. Қайсысы жабдықты орнатады, кім жүйені баптайды, деректерді кім әкеледі, пайдаланушыларды кім қосады, кім оқытады. Егер кейбір жұмыстар тапсырыс берушінің өзімен жасалса, оны да нақты көрсету керек.

Қабылдау өлшенетін болуы тиіс. "Жүйе енгізілді" деп емес, анық көрсеткіштер: жабдық орнатылды, лицензиялар активтелді, пайдаланушылар жүйеге кірді, басып шығару жұмыс істейді, деректер көшірілді, ескертпелер жабылды немесе бөлек кезеңге шығарылды. Критерийлер неғұрлым нақты болса, финиште дау аз болады.

Тағы бір маңызды бөлім — іске қосқаннан кейінгі қолдау. Кім өтініш қабылдайды, жабдыққа кепілдік кім береді, лицензиялар бойынша кім жауап береді, енгізудегі қателерді кім түзетеді және қандай мерзімде — бәрі алдын ала жазылуы тиіс. Осы ережелер болмағанда жоба формальды түрде ертерек аяқталып, нақты мәселелер жұмысқа енгізгеннен кейін басталуы мүмкін.

Практикалық мысал

Мысалы, мектеп жаңа компьютерлік сыныпты 1 қыркүйекке ашқысы келеді. Жай ғана техниканы әкеліп қана қоймай, әр жұмыс орнын дайын қылып, мұғалімдер мен оқушылар бірінші күні сабақ бастай алатындай ету керек.

Мұнда әдетте үш тәуелді этап болады: компьютерлерді жеткізу, лицензияларды активтеу және әр орынды баптау. Бір қадам кешігсе, қалғандары да тұралады. Қораптар сыныпта тұрса да, оларда жұмыс істеуге әлі болмайды.

Егер сатып алуды бөлек лоттарға бөлсе, жиі мынадай жағдай шығады: бір жабдық жеткізуші компьютерлерді уақытында әкелді, екіншісі лицензияларды әлі келісуде, үшіншісі баптау үшін техника мен қолжетімдіктерді күтуде. Формальды түрде әркім өз бөлігін орындағанмен, сынып әлі де дайын болмайды.

Ал жабдықты, лицензияны және пусконаладканы бір мердігерге тапсыратын болса, жалпы кестені ұстау әлдеқайда жеңіл. Мектепке кімнің жауапты екенін анықтаудың қажеті жоқ: бір ғана жауапты бар және ол кез келген мәселені түзету мерзімін біледі.

Білім саласындағы типтік жобалар үшін бұл көбіне бірнеше мердігерді басқарудан гөрі ыңғайлы: тапсырыс беруші бөлек этаптар емес, жұмысқа дайын сыныпты қабылдайды.

Жобаны біріктіру кезінде жиі жіберілетін қателер

Негізгі қате — техниканы, лицензияларды және енгізуді бір келісімге әкеліп, іске қосуға арналған жалпы жоспарды жазбау. Қағазда бәрі тәртіпте көрінеді, бірақ практикалықта тез үйлесімсіздік басталады: жабдық келді, лицензиялар дайын емес, енгізу тобы қолжетімдіктер мен келіспеулерді күту үстінде.

Екінші қате — тапсырыс берушінің ішкі жобалық иесі жоқ болуы. Тіпті мердігерден бірыңғай жауапты нүкте болса да, ұйым ішінде күнделікті шешім қабылдайтын адам болмаса, сұрақтар IT-қызмет, сатып алу, қауіпсіздік және басшылық арасында іліп қалады.

Тағы бір қате — типтік жеткізуді және анықталмаған доработкаларды бір кезеңге араластыру. ПК, серверлер, стандартты лицензиялар мен типтік баптауды алдын ала жоспарлауға болады. Даулы интеграциялар мен стандарттан тыс талаптарды бөлек кезеңге шығару арқылы бүкіл іске қосуды тежемеу керек.

Соңында, тек баға бойынша схеманы таңдау қауіпті. Төмен баға сервистің әлсіздігін білдіруі мүмкін: жауаптардың баяу болуы, жауапкершілік шекараларының анықталмауы, мерзімдік қорының жоқтығы немесе іске қосқаннан кейін әлсіз қолдау. Ондай жағдайда бастапқы үнемдеу эксплуатация кезінде шығындарға тез айналуы мүмкін.

Көп кездесетін қателер келесідей көрінеді:

тек келісімнің күнін бекітіп, әр кезеңнің дайын болу күнін жазбайды;
міндетті минимумды қосымша жұмыстардан ажырата алмайды;
іске қоспадан кейінгі сервистің кімге тиесілі екенін тексермейді;
мәселе туындаса эскалация тәртібін сипаттамайды.

Бастамас бұрын жылдам тексеріс

Келісімге отырмас бұрын қысқа тексеріс өткізу пайдалы. Ол жобаның іске қосуға дайын ба, әлде болашақта кешігулер жасалған ба тез көрсетеді.

Алдымен нәтижені қарапайым сөзбен анықтаңыз. "Жабдық пен лицензияларды жеткізу" емес, мысалы, "100 жұмыс орны жұмысқа дайын, пайдаланушылар жүйеге кірді, пошта және қажетті бағдарламалар бапталған" деп нақты айту керек.

Содан соң жалпы жоспар бар-жоғын тексеріңіз. Серверлерді жеткізу, лицензияларды активациялау, баптау, тестілеу және іске қосуды бөлек кестелерде ұстап, бір финиш нүктесі болмаса, бәрі әр түрлі бөлінген болуы мүмкін.

Одан кейін тағы үш сұраққа жауап беріңіз. Жобаның маршрут-ботасының барлық бөлігін кім жинайды? Негізгі, жиі ұмытылатын блоктар — базалық баптау, деректерді көшіру, оқыту және қабылдау тесттері — ескерілген бе? Және іске қосқаннан кейінгі қолдау кімге тиіс: өтініштерді кім қабылдайды, ақауларды кім жояды және қандай мерзімде?

Егер осы сұрақтардың екеуіне де нақты жауап жоқ болса, жоба әлі дайын емес. Бастапқыда бір күн келісімге жұмсау кейінгі аптадағы мердігерлер арасындағы дау-жанжалдарға қарағанда әлдеқайда тиімді.

Келесі қадамдар

Мердігерді таңдаудан бастамаңыз. Алдымен жобаның қысқа картасын жасаңыз: қандай жабдық қажет, қандай лицензиялар керек, қандай жұмыстар күтіледі және қай күнге дейін қай нәрсе жұмыс істеуі тиіс. Тіпті бір беттік қарапайым тізім мерзімдер, үйлесімділік және жауапкершілік тәуекелдерін бірден көрсетеді.

Сосын жобаны әдеттегідей емес, логика бойынша бөліңіз. Егер серверлер, жұмыс орындары, лицензиялар мен енгізу бір-біріне тығыз тәуелді болса, жауапкершіліктің бірыңғай нүктесі уақыты үнемдеуі мүмкін. Ал егер бөліктер өзара тәуелсіз өмір сүрсе, лоттарды бөліп алу тәуекелсіз өтуі ықтимал.

Қазақстандағы жобалар үшін тәжірибелік сұрақ қоя аласыз: серіктес жабдықтау ғана емес, енгізуді және кейінгі қолдауды да қамтамасыз ете ала ма? Бұл мемлекеттік, білім, медицина және ірі корпоративтік жобалар үшін маңызды, себебі тоқтап қалу мен жауапкершіліктің анық еместігі қымбатқа түседі.

Уәделерге емес, мердігердің нақты мүмкіндіктеріне қараңыз: өзінің сервис базасы бар ма, интеграция тәжірибесі бар ма, қолдау схемасы оқшауланбаған ба және мерзімде іске қоса алатын ресурстары жеткілікті ме. Қарапайым әрі тиімді келесі қадам: төрт бағаннан тұратын кесте жасаңыз — техника, ПО, жұмыстар, қолдау — және әр бағанға бір жауапты немесе неге сол блокты бөлек лотқа беру қажет екенін көрсетіңіз. Бұдан кейін шешім әлдеқайда айқындалады.