• İş saatları 09:00 - 18:00

    Bazar ertəsi - Cümə

  • Bakı, Azərbaycan

    8 Noyabr prospekti, 25
    Bakı Ağ Şəhər biznes mərkəzi

Xəbərlər

Layihədə qazanılmış biliklər

Layihədə qazanılmış biliklər

Aleksey Kim - Məqalədə iki layihə vəziyyətinin təsviri, oxşar layihələr üçün nəticələr və tövsiyələr təqdim olunur.

 Vəziyyət bir.  Qızıl örtük və “əlavə”nin təhlükələri haqqında

 Bir qayda olaraq, işlərin az-çox normal rejimdə aparıldığı altı aydan çox davam edən informasiya sistemlərinin tətbiqi layihələrində podratçının (icraçı şirkətin) və sifarişçinin nümayəndələri dostluq münasibətləri qurmağa nail olurlar.  Bu, sirr deyil və bu ona görə baş verir ki, layihə üzrə sifarişçi və podratçının nümayəndələri birgə problemləri həll edir, kompromislərə gedir və bir-birini başa düşməyə çalışırlar.  Bir qayda olaraq, bu cür əlaqələr layihə menecerləri, eləcə də layihə işində fəal iştirak edən layihə komandasının nümayəndələri tərəfindən qurulur.  Bu cür tərəfdaşlıqlar layihə üçün faydalıdır, motivasiyanı, səmərəliliyi artırır, əlavə olaraq, bir-biri ilə ünsiyyət qurmaqla, komanda üzvləri bir-birinin bilik və təcrübəsini qazanır, ixtisas səviyyəsini yüksəldir, lakin bəzən belə əlaqələr zərərli ola bilər.  Mən belə bir vəziyyəti nəzərdən keçirməyi təklif edirəm.

 Bir şirkətdə, deyək ki, çoxdan əziyyət çəkən "Buynuzlar və Dırnaqlar" da yeni bir ERP sisteminin tətbiqi qərara alındı.  Məsələyə ciddi yanaşılıb, mövcud sistemlərin təhlili aparılıb, sistem və icraçı şirkətin seçimi üzrə müsabiqə, GAP təhlili aparılıb və nəhayət, layihə icra mərhələsində olub.  İcra iki mərhələdə baş verir.  Birinci mərhələ ERP sisteminin faktiki təkmilləşdirilməsi, onların sınaqdan keçirilməsi və podratçı tərəfdə sazlanması, ikinci mərhələ isə sifarişçi tərəfində sınaqdan keçirilməsi və istifadəçinin qəbulunun sınaqdan keçirilməsidir.  Sifarişçi tərəfindən sistemin sınaqdan keçirilməsi zamanı podratçının nümayəndələri, təbii ki, sifarişçinin şirkətində iştirak edirlər.

 Və nəhayət, müştəri tərəfindən texniki sınaq anı gəlir.  Horns and Hooves-də texniki sınaqlar şirkətin biznes proseslərini yaxşı bilən analitiklər tərəfindən həyata keçirilir.  Test skriptləri yazılmış və skriptlər sistemdə işə salınmışdır.  Test zamanı analitiklərdən biri müəyyən etdi ki, sınaqdan keçirdiyi hissə texniki tapşırıqlara uyğun işləsə də, işi daha səmərəli etmək üçün dəyişdirilə bilər.  O, bu sualla layihə rəhbərinə yaxınlaşıb.  Layihə meneceri seçim problemi ilə üzləşir.  Bir tərəfdən, təkmilləşdirmələr göz qabağındadır, onlar son istifadəçilərlə razılaşdırıla bilər, digər tərəfdən, rəhbərlik tərəfindən dəyişiklik tələblərinin təsdiqlənməsi, podratçı tərəfindən sorğunun sonradan qiymətləndirilməsi, reqressiya testi və s. - layihə gecikəcək və büdcə artacaq.  O, podratçının layihə rəhbəri ilə məsləhətləşmək qərarına gəlir.

 Görüş nəticəsində sifarişçi və podratçı tərəfdən layihə menecerləri belə qənaətə gəliblər ki, dəyişiklik etməyə dəyər, lakin rəsmiləşdirmə yoxdur.  Çünki  sistemdə edilən dəyişiklik minimal idi və bir neçə saat sonra podratçının tərtibçisi bu dəyişiklikləri edən kiçik proqram təminatını podratçının layihə menecerinə göndərdi və o, onu diskdə müştəriyə təhvil verdi.  Yamaq ayrıca test mühitində quraşdırıldı (biz onu bir neçə günə yaratmağa müvəffəq olduq) və sınaqdan keçirildi.  Sistem lazım olduğu kimi işləyirdi.  İstifadəçi testi zamanı istifadəçilər dəyişikliklərdən çox sevindilər, çünki.  işi asanlaşdırdılar.  Sistem təhvil verildi (döyüş mühitinə yamaq quraşdırılaraq), layihə uğurla başa çatdı, hamı xoşbəxtdir.  Bir istisna ilə.

 Sistemin kommersiya fəaliyyətində işlədiyi üç aydan sonra hesabatlarda və işlərin real vəziyyətində uyğunsuzluqlar aşkar edilib.  Hadisəni daha bir həftə araşdırdıqdan sonra məlum olub ki, edilən dəyişikliklər sayəsində sistem hələ də düzgün işləmir.  Yuvarlaqlaşdırma.  Sistem yuvarlaqlaşdırmanı texniki tapşırıqda göstəriləndən fərqli şəkildə həyata keçirir.  Test zamanı bu hiss olunmadı, çünki.  sınaq buna baxmayaraq, az miqdarda məlumat üzərində aparıldı, lakin sistem kommersiya istifadəsinə verildikdə, yuvarlaqlaşdırma nəticəsində əldə edilən məcmu cəmindəki uyğunsuzluqlar əhəmiyyətli məbləğlərə çatdı.  Podratçı tərəfindən sınaq üçün təqdim olunan test sistemini arxiv nüsxəsindən bərpa etdikdən sonra, yamaq quraşdırılmamışdan əvvəl sistemdə yuvarlaqlaşdırmanın düzgün olduğu məlum oldu.  Səhv barədə podratçı şirkətin texniki dəstəyinə məlumat verildi, lakin tezliklə cavab alındı ​​ki, müqavilənin şərtlərinə əsasən, şirkətə təqdim olunan sistemin versiyası sifarişçi tərəfindən dəyişdirilmədən dəstəklənir və texniki dəstək xidmətinə bildirilən xəta müştərinin kodun dəyişməsi nəticəsində yaranıb.  Podratçı əlavə ödəniş müqabilində xətanı düzəltməyə razılaşdı, lakin yeni funksionallıq itirildi və səhv məlumatların düzəldilməsinə ehtiyac yaranarsa, onun düzəldilməsi xərcləri yüksək idi.  Müştərinin düzəlişləri ödəməkdən başqa çarəsi yox idi.

 “Əlavə” funksionallıq asanlıqla zərərli ola bilər.  Bu, bir çox cəhətdən yarana bilər, heç bir halda yalnız yuxarıda sadalananlar, bir şeyi təkmilləşdirmək üçün koda dəyişiklik etmək qərarına gələn və sənədsiz dəyişikliklər tələb edən müştəri ilə bitən bir tərtibatçıdan yarana bilər.  Onun zərəri də müxtəlif ola bilər.  Yuxarıdakı nümunədə olduğu kimi, müqavilə üzrə xidmətdən imtinadan, buraxılmış son tarixlərə və artan büdcəyə qədər.  Nümunə əlavə funksionallıqdan bəhs etsə də, planlaşdırılan keyfiyyət səviyyəsini aşmağa icazəsiz cəhd, daha qısa müddətə çatmaq və daha çox şey zərər verə bilər.  Əlbəttə ki, əlavə fayda gətirə bilər, lakin əlavə bir şey xatirinə layihənin planlaşdırılan nəticəsini əldə etmək üçün risk etmək lazımdırmı?  Məncə, buna dəyməz.

 

 Vəziyyət iki.  Əsas istifadəçilər, texniki dəstək komandası və uğurlu icra

 Bu qısa qeyddə bir icra layihəsinin müsbət təcrübəsindən danışmaq istərdim.  Bir qayda olaraq, mənfi məqamlar xatırlanır, lakin müsbət təcrübədən gələcək layihələr üçün mənfidən daha çox fayda var.

 Çox vaxt informasiya sistemlərinin tətbiqi layihələri zamanı layihənin uğuru üçün əsas istifadəçilərin və texniki dəstək xidmətlərinin rolu lazımi səviyyədə qiymətləndirilmir.  Təbii ki, çoxları sistemin istifadəçilərinin ayrılacağını, sistemin və sistemdə proseslərin həyata keçirilməsinin konkret insanların ehtiyaclarına yönəlməməli olduğunu, texniki dəstək mərhələsinin layihənin tamamlanmasından sonra gəldiyini deyəcək.  Yuxarıda göstərilənlərin hamısı düzgündür.  Ancaq buna baxmayaraq, əsas istifadəçilərə və texniki dəstəyə diqqət yetirmək çox vacibdir.  Axı biz sırf “göstəriş üçün” qurulacaq sistemi deyil, məmnuniyyətlə istifadə olunacaq və istifadə olunacaq sistemi təqdim etmək istəyirik.  Ardıcıllıqla başlayacağam.

 Bir şirkətdə (həmişə olduğu kimi, "Buynuzlar və Hooves" şirkəti idi) böyük və iddialı bir proqram açdı.  Proqram yeni biznes xəttinin açılmasını nəzərdə tuturdu ki, bunun üçün başqa şeylərlə yanaşı, yeni İT sisteminin alınması və tətbiqi zəruri idi.  Sistemin tətbiqi layihəsi uğurla başladıldı, məsləhətçilər işə götürüldü, tender keçirildi, sistem seçildi və həyata keçirilməyə başlandı.  Təbii ki, modifikasiya olmadan böyük bir sistemi həyata keçirmək mümkün deyil.  Buna görə də sistemin funksionallığı ilə biznes tələbləri arasında boşluq təhlili (GAP analizi) aparılmışdır.  Tapılan hər bir boşluq üçün texniki şərt yazılmışdır və sistemin özünün parametrləri üçün texniki tapşırıq yazılmışdır.  Texniki tapşırıqlar yazıldıqdan sonra layihə öz sahələrində mütəxəssis olan bir qrup işçi tərəfindən fəal şəkildə istifadə edilmişdir.  Bu ekspertlər sistemin əsas istifadəçiləri kimi planlaşdırılırdı.  Məhz onlar gələcəkdə sistemdə işləməyi öyrənməli, İT sistemində şirkətin müəyyən ekspertiza mərkəzini formalaşdırmalı idilər.  Və belə də oldu.  Sistemdə işləməyi öyrənmək anı texniki spesifikasiyalar və texniki tapşırıqların təsdiqindən əvvəl idi, buna görə də qrup yekunlaşdırılaraq işə salınmazdan əvvəl sistem haqqında anlayış formalaşdırdı.

 Sistemin əsas istifadəçiləri qrupunun təlimi iki mərhələdə həyata keçirilib.  Birinci mərhələdə istifadəçilərə sistemin standart funksionallığı öyrədilirdi.  Artıq bu mərhələdə çoxlu sayda suallar yarandı və boşluqların siyahısı tamamlandı.  Bu təlimin nəticəsi sistemin prinsiplərini, onda nəyin həyata keçirilə biləcəyini və nəyin olmadığını başa düşmək idi.  İkinci mərhələdə təlim şirkət üçün yaradılmış prototip sistem üzrə baş tutub.  Təlimin bu mərhələsində incə nüanslar "üzə çıxdı" və ilk təlim nəticəsində əldə edilən sistemin işləməsi haqqında kifayət qədər xaotik bir anlayış quruldu.  Nəticədə, şirkətin biznesinin müxtəlif sahələri üzrə ekspertlər qrupu sistem ekspertlərinə çevrilib.  Onlar texnologiya və texniki nüansların vəhşiliyinə getmədilər, lakin sistem parametrlərini mükəmməl başa düşdülər və funksionallıqdan istifadənin incəliklərini bilirdilər.  Bundan əlavə, uzunmüddətli birgə məşqlərin əks təsiri komanda qurmaq, komanda ruhunun meydana çıxması, həyata keçirməyə maraq idi.  Sonradan bu əsas istifadəçilər tətbiq olunan sistem baxımından öz şöbələrində əsas dayağa çevrildilər.  Onlar analitik və məsləhətçi kimi fəaliyyət göstərmiş, öz biznes bölmələrinin tələblərini sistem üçün funksional tələblərə uyğunlaşdırmış, istifadəçiləri öyrətmiş və sistemin gələcək inkişafı haqqında düşünmüşlər.  Tətbiq edildikdən sonra Baş direktorun əmri ilə bu əsas istifadəçilər sistemin müxtəlif funksional sahələrinə cavabdeh şəxslər təyin edilib.

 Uğurlu həyata keçirilməsində ikinci amil sistem istehsalçısının texniki dəstək komandasının erkən cəlb olunması idi.  Layihənin texniki dəstək mərhələsinə keçidi adətən ağrılı prosesdir.  Layihə meneceri artıq səlahiyyət və məsuliyyətdən azad edilib, istifadəçilər artıq sistemdə səhvlər tapmağa başlayıblar və texniki dəstək hələ ki, sistemin təkmilləşdirilməsi sahəsində təcrübəyə malik deyil.  Adətən, belə olur.  Bu layihə bir az fərqli şəkildə həyata keçirilib.  Müştəri tərəfdən texniki dəstək qrupu layihəyə texniki tapşırığın yazılması mərhələsindən (çox orta miqdarda olsa da), istehsalçıdan - sistemin sınaqdan keçirilməsi mərhələsindən cəlb olunmağa başladı.  Texniki dəstək qruplarının sistem üzərində işə erkən cəlb edilməsi istifadəçilər tərəfindən müəyyən edilmiş səhvləri tez bir zamanda düzəltməyə imkan verdi (sistemin hərtərəfli sınaqdan keçirilməsi nəticəsində layihənin sonuna qədər onların sayı azaldı), eləcə də bütün problemləri tənzimlədi. xidmət səviyyəsi müqaviləsində göstərilməyən mübahisəli inzibati məsələlər.

 Beləliklə, şirkətin biznesinin bütün sahələrində təcrübəyə malik, səriştəli, sistem üzrə təlim keçmiş əsas istifadəçilərin mövcudluğu, onların layihənin ilkin mərhələlərində cəlb edilməsi və texniki dəstək xidmətləri uğurlu icrası üçün əsas amillər idi.  Sistem təkcə tətbiq olunmayıb, həm də tələblər çərçivəsində və istifadəçilərin gözləntilərinə uyğun olaraq həyata keçirilib.

 

 Mənbə: https://pmmagazine.ru/articles/usvoennye-uroki-proektov-2/ © pmmagazine.ru

22.01.2022

Layihələrin idarə olunmasında əlaqələr və nişan

Xəbərlər

Layihələrin idarə olunmasında əlaqələr və nişan

Layihələrin idarə olunmasında əlaqələr və nişan Daha çoxu üçün bizi sosial ...

MERCEDES layihəsi necə yarandı?

Xəbərlər

MERCEDES layihəsi necə yarandı?

MERCEDES layihəsi necə yarandı? Daha çoxu üçün bizi sosial şəbəkələrdə izləyin ...