Xəbərlər
Podratçı tərəfindən layihə menecerlərinin tipik səhvləri
Tatyana Belova
Hər bir layihə meneceri bəzən səhvlərə yol verir. Bir səhv layihə və ya aşkar edilmiş tərəflərdən biri üçün nəticələrə gətirib çıxarır, digər səhvlər gözlənilmədən baş verir və ya asanlıqla düzəldilir. On ildən artıq bir müqavilənin hər iki tərəfində layihə meneceri kimi işlədiyim üçün bu məqalədə podratçı tərəfindən proseslərin avtomatlaşdırılması və avtomatlaşdırılmış sistem layihələrinin həyata keçirilməsində layihə menecerinin buraxdığı ümumi səhvlər haqqında şəxsi müşahidələrimi bölüşmək istəyirəm. .
Epiqraf
Ağıllı insan başqalarının səhvlərindən, axmaq isə öz səhvlərindən öyrənər... (müəllif naməlum)
"Bizim deyil"
Həyatdan eskiz.
Layihənin başlanğıcı. Sifarişçi və podratçının komandaları qarşılıqlı əlaqəni, işin həcmini, təxmini iş planını müzakirə edir və layihənin əhatə dairəsini aydınlaşdırır. Layihə meneceri müştərinin özünün yerinə yetirməli olduğu texniki işləri nəzərə alaraq iş qrafikini tərtib etməyi tələb edir. Sifarişçi öz tərəfindən iş baxımından bu cədvəlin hazırlanmasında fəal iştirak etməyə hazırdır, lakin o, təbii olaraq podratçının işini planlaşdıra bilməz. Podratçıdan olan layihə meneceri bildirir ki, “layihə bizim etməli olduğumuz işdir, qalanı isə mənim üçün maraqlı deyil”.
Bu mövqeyin səhvi nədir və bu hansı nəticələrə səbəb ola bilər? Avtonom sistemin tətbiqi layihələrinin əksəriyyəti yalnız proqram təminatının hazırlanmasını deyil, həm də digər vəzifələri tələb edir:
sistemin yerləşdirilməsi üçün avadanlıqların satın alınması;
Şöbələrdə təşkilati dəyişikliklər mümkündür;
istifadəçi təliminin keçirilməsi;
daxili normativ və metodiki sənədlərin işlənib hazırlanması;
və s.
Bütün bu vəzifələr layihənin əhatə dairəsinə daxildir. Və onların həyata keçirilməsi olmadan layihə uğurla başa çatmış hesab edilə bilməz. Tərtibatçı proqramı hazırlasa belə, layihə bitməmişdir. Və çox vaxt, avadanlıq işə salınana və istifadəçi təlimi tamamlanana qədər proqram təminatı istifadə olunmayacaq.
Buna görə də, podratçıdan olan layihə menecerinə ümumi layihə cədvəlini nəzərə almaq və işini ümumi istifadənin əsas mərhələləri ilə əlaqələndirmək tövsiyə olunur. Bu, müqaviləni düzgün tərtib etməyə kömək edəcək (müqavilə üzrə iş qrafiki) və yerinə yetirilən işin təklifi-qəbul edilməsi ilə bağlı problemlərin inkişafının qarşısını alacaqdır. Məsələn, inteqrasiya testi üzərində işə başlamaq üçün avadanlıqların artıq quraşdırılmış və konfiqurasiya edilmiş olması və tez-tez inteqrasiya edilməli olan sistemin plana uyğun olaraq yekunlaşdırılması lazımdır.
Beləliklə, məsləhət 1. “Layihə təkcə sizin həyata keçirdiyiniz bir şey deyil. Layihə müştərinin məzmununa (həcminə) daxil olan hər şeydir. Tamamlanması ilə əlaqəli olan, işinizi yerinə yetirmək imkanı üçün xüsusiyyətlərə malik olan işləri, xüsusən də onları qəbul etmək üçün nəzərə alın.
"Hər daxmanın öz çınqıltıları var"
Həyatdan eskiz.
Sistemin qəbul edilməsi üçün doğru vaxtdır. Tədbirin təfərrüatlarının müzakirəsi üçün iclas keçirilir. İfaçılar test prosedurlarına və sınaq ssenarilərinə uyğun olaraq bütün sistem funksiyalarının toplanması, yoxlanılması haqqında danışır və həmçinin qeyd edirlər ki, bunlar müəyyən edilmiş təhlükəsizlik, həcmdən qorxduqdan sonra sistemin bərpası və əvvəllər irəli sürülən digər qeyri-funksional tələblərə aiddir. İfaçı üçün testlərdə aktiv rolda iştirak etməsi sürpriz oldu - ardıcıl olaraq bütün addımlara yaxınlaşan, sistemi bərpa edən və bərpa edən və s. Həm də 2-3 tam gün ərzində iştirakçıların diqqətini çəkən gözlənilməz hadisə (onlar özləri üçün çox şey planlaşdırmırdılar).
Podratçının layihə rəhbərinin səhvi nədir və bunun qarşısını almaq üçün nə etmək lazımdır?
Düşünün, hamı üçün bir atalar sözünü toplayın: "Hər daxmanın öz çınqılları var." Hər bir təşkilatın gözlənilən sistemləri qəbul etmək üçün qaydaları və qaydaları var. Mən çox sadə və formal testlərlə tanış oldum, onlar əsasən funksionallığa görə və eksperimental yükə giriş haqqında Qanunun təsviri altında aparıldıqda, lakin sınaq əməliyyatında çoxlu sayda səhvlər və narazı istifadəçilər alırlar. GOST34-ün tələblərinə, Texniki Tapşırıqlara mütləq uyğunluğun yoxlanılmasını təmin etmək üçün Proqram və Metodlara tam cavab verən sınaqlar aparıldı və bu yoxlama faktiki olaraq həyata keçirildi, o cümlədən sistemin ehtiyat nüsxələrindən sonra bərpa müddəti yoxlanıldı. serverin "dağıdılması".
Yalnız qərar qəbul etmək üçün deyil, müxtəlif layihələr üçün sürprizlərin qarşısını almaq üçün, göstərilən müştəri ilə bu ilk layihənin icraçısı üçün sifarişçi tərəfindən təklif olunan layihəni, bütün normativ və normativ sənədləri işə salmaq tövsiyə olunur. razılaşdırılır, onların tətbiqi və inkişafı zamanı sistemlərin istifadəsini tənzimləyir , həmçinin müqavilə işləri, dəyişikliklərin əlaqələndirilməsi, ödəniş proseduru və s. Özünüz üçün çoxlu yeni və gözlənilməz şeylər öyrənə bilərsiniz, hətta sizə artıq dünyada hər şey olduğunuz kimi görünsə də.
Beləliklə, məsləhət 2. “Unutmayın ki, hər bir daxmanın öz çınqıltıları var. Müştəriyə “necəsən ...?” sualını verin. Siz işinizi planlaşdırmaq və onun mürəkkəbliyini qiymətləndirmək üçün çox vacib bir şey öyrənə bilərsiniz”.
“Səyahət zamanı it böyüyə bilərdi”
Həyatdan eskiz
Layihə Texniki Tapşırıqların hazırlanması üzrə yekunlaşma mərhələsindədir və təsdiqlənməkdədir. Podratçı "Sənədləşdirmə tələbləri" bölməsinə qeyd edir. Hazırlanan sənədlərin tərkibinə təcrübələri nəzərə alınmaqla müstəqil olaraq daxil edilən "standart" versiyalara müxtəlif əlavə sənədlər daxildir. "Başlanğıcda daxiletmə üçün hazırlıq tələb et" bölməsində gözlənilmədən istifadəçilər üçün təlimatın hazırlanmasını aktivləşdirmək xahiş olunur.
Nüsxələrin sayı "üzən" iş miqdarı mövzusunda pozulur. Podratçılar müştəriləri artan iştahda, müştərilər podratçıları tələbləri dəqiqləşdirməməkdə günahlandırır...
Geniş əhatə dairəsinin tətbiqi, təcrübədən göründüyü kimi, həqiqətən şərti olaraq iki qrupa bölünə bilər:
yeni tələblər və ya əvvəllər müəyyən edilmiş təhlükəsizlik tələblərinə əhəmiyyətli dəyişikliklər.
ifaçı tərəfindən buraxılmış və ya səhv başa düşülən iş, buna görə də yanlış qiymətləndirmələr, tələblər;
Müşahidə olunan hisslərə görə, bu səbəblərin hər ikisi eyni tezlikdə baş verir.
Dəyişən tələblər və ya müəyyən edilmiş yeni hallarla məşğul olmaq üçün alətlər və üsullar. Bu, dəyişiklik tələbidir və lazım gələrsə, əmək/xərc smetasıdır. Gələcəkdə bu dəyişikliklər, əgər belə imkanlar olarsa, müqavilələr bağlanır, əlavə şərtlər bağlanır, əks halda layihənin dəyərini artırmaq mümkün olmadıqda, uyğunluq tələblərindən az olan digər şərtləri istisna etmək üçün sifarişçi ilə mühüm məqsədlər güdülür. , yenilərini daxil etmək. Həmçinin, layihənin məzmununun (həcminin) dəyişməsi ilə bağlı gözlənilən risklər üçün, mümkünsə, layihənin nəticəsini nəzərə alaraq, çevik metodologiyaların tətbiqi tövsiyə olunur.
Layihə meneceri üçün daha tez-tez baş verən bir hadisə əvvəllər qəbul edilmiş işəgötürənlər tərəfindən səhv başa düşülür, səhv başa düşülür və ya müəyyən edilir. Belə bir vəziyyətdə müştəriyə məlum olur ki, bu yeni tələbə demək olar ki, rast gəlinmir və hətta onu izah etmək cəhdi də ziddiyyətli görünə bilər.
Bu səhvin qarşısını almaq və ya ifaçı üçün nəticələrini necə azaltmaq olar?
Ən aşkar üsullardan biri müştərinin bütün tələblərini mümkün qədər tez və mümkün qədər ətraflı şəkildə aydınlaşdırmaqdır. İlk növbədə, bu, podratçının analitikinin işinin keyfiyyətidir. Bu onun əsas vəzifəsidir.
Təhlükəsizliyin erkən təsdiqinin başqa bir yolu prototipləmə və ya çörək lövhəsidir. Sadə "kliklənən" displey tərtibatı tez-tez təhlükəsiz və gözlənilən istifadəçilərin ümumi üstünlüklərini aşkar etmək üçün möcüzələr yaradır.
Üçüncü yol, podratçının rolu üçün müvəqqəti ehtiyatın və idarəetmə ehtiyatının layihə büdcəsinə daxil edilməsidir. Layihənin icra müddəti üçün müavinət qurmaq hər bir layihə menecerinin etməli olduğu bir şeydir. Eyni zamanda, geniş ehtiyat imkanları həmişə həyata keçirilməyə bilər.
Qadağan olunmuş əsərlərlə bağlı problemlərin qarşısını almağın başqa bir yolu ifaçının şirkətində belə əsərlərin reyestrinin aparılmasıdır.
Məsələn, çox vaxt ifaçılar mümkün bir işə icazə verirlər:
müştəri tərəfində test mühitinin hazırlanması və qurulması və ya test mühitinin qurulması üçün idarəçilər üçün təlimatların hazırlanması;
müştəridə istifadəçi testindən əvvəl rol əsaslı girişin qurulması; çoxları müştərinin informasiya təhlükəsizliyinin ciddiliyini düzgün qiymətləndirmir;
istifadəçi təliminin və ya təlim materiallarının (təlim təqdimatları, video dərslər, pulsuz kurs və s.) aparılması;
sistemi sənaye qrupuna ötürməzdən əvvəl tədqiqatların aparılması: digər müştəri sistemlərinin döyüş, sınaqdan keçirilməmiş sxemləri ilə qurulması və sınaqdan keçirilməsi; sınaq və digər işlər zamanı aşkar edilən müxtəlif "stub"ların çıxarılması.
Bu cür məlumatların toplanması və icraçı şirkətdə bilik bazasının saxlanması proqnoz layihələrinin əhəmiyyətli təsiridir və hər bir layihə üçün işin həcmini daha yaxşı planlaşdırmağa imkan verir. Əgər belə bir bilik bazası şirkətinizə rəhbərlik etmirsə, təşəbbüsü əlinizə götürün - reyestrinizi daxil edin, həmkarlarınıza özünüzü təklif edin, onları paylaşmağı xahiş edin.
Beləliklə, məsləhət 3. "Layihələrin məzmununa nəzarət etmək, erkən sınaq üsullarından istifadə etmək, tələblərə uyğunluğu yoxlamaq, fərdi müştərilər üçün layihələrdə iş növlərinin reyestrinə nəzarət etmək".
"Gözləntilər"
Həyatdan eskiz
İfaçı ilə növbəti status görüşü. İcraçı layihə meneceri keçmiş dövr üçün yerləşdirmə və növbəti dövr üçün planlar haqqında hesabat verir. Məlum olur ki, müddəti 2 gün əvvəl keçən iş hələ tamamlanmayıb və cəmi 2 günə yekunlaşacaq. Müştəri etiraz edir. O, işin hələ tamamlanmamasından deyil, bundan əvvəl vəd etdiyi müddətdən cəmi 2 gün sonra xəbər tutmasından hiddətlənir.
Müştəri gözləntilərinin idarə edilməsi altında, ən çox layihənin nəticələrindən, onun məhsulundan gözləntiləri idarə etmək tələb olunur.
Çox nadir hallarda gözləntilərin idarə edilməsi layihə prosesi üçün gözləntiləri ehtiva edir.
Həyat eskizində təsvir olunan vəziyyət o qədər geniş yayılmışdır ki, layihə tərtibatçılarının bu cür gözləntiləri necə idarə etməyi unutduqları və ya zəruri hesab etmədikləri təəssüratını yaradır.
Belə bir vəziyyət nəyə gətirib çıxaracaq? Müştərinin təyin edilmiş podratçıya və xüsusi layihə menecerinə etimadsızlıq yaşına, layihə menecerinin layihəni və komandanı idarə etmədiyi, onunla nə baş verdiyini bilmədiyi və ümumiyyətlə peşəkar olmadığı təəssüratına. Bəzi hallarda belə bir vəziyyətdə sifarişçinin podratçının layihə rəhbərinin dəyişdirilməsini tələb etdiyi güman edilir. Bir hal müqavilənin ləğvi və icraçı şirkətin dəyişdirilməsi ilə nəticələndi.
Problemlərdən necə qaçınmaq olar? Resept mümkün qədər sadədir: sözünüzü tutun. Əgər son tarix obyektiv səbəbə görə pozulubsa və siz bu faktı bu son tarixdən əvvəl aşkar edirsinizsə - və daha tez-tez bu, məhz belə olur - müştərini əvvəlcədən xəbərdar edin. Son tarixlərin dəyişdirilməsinin səbəblərini və yeni son tarixləri bildirin. Ancaq bu yeni son tarix həmişə yerinə yetirilməlidir.
Aşağıda qıcıqlanma və sonradan müştəriyə və əhatə dairəsinə inamsızlığa səbəb olan halları sadaladım.
Tapşırığın son tarixinin istifadəsi ilə bağlı gec mesaj, xüsusən də son tarixə çatdıqdan sonra.
Sifarişləri yerinə yetirməkdən imtina etmək, müxtəlif iş görüşləri və status mitinqləri zamanı qazanc əldə etmək.
Əmək intensivliyinin düzgün qiymətləndirilməməsi səbəbindən eyni tapşırıq üçün son müddətin təkrar təxirə salınması. Bir dəfə səhv hesablanmış - inanırıq. Üç dəfə - artıq bacarıqsızlıqla tərcümə edilmişdir.
"Dumanın içində gizlənir." İfaçı tapşırığı aldı və həyata keçirildiyi bir ay ərzində yoxa çıxdı.
Menbe : https://pmmagazine.ru/articles/tipichnye-oshibki-rukovoditelej-proektov-so-storony-ispolnitelya/
30.01.2022
