Xəbərlər
Müştəri İT layihələrində tam hüquqlu bir texniki xüsusiyyət yaratmalıdırmı?
Müştəri İT layihələrində tam hüquqlu bir texniki xüsusiyyət yaratmalıdırmı?
Bu sualın arxa planı və indi və 10-20 il əvvəlki cavabı bir qədər fərqlidir. Əlbəttə ki, düzgündür, hər şeydən əvvəl müqaviləyə baxmaq və bitmiş məhsulun texniki şərtləri və qəbulu haqqında orada yazılanları öyrənmək olardı. Ancaq fakt budur ki, bizdə həm o vaxt, həm də indi əksər xarici layihələr sabit qiymət müqavilələri əsasında həyata keçirilir ki, bu da proqram inkişafında Çevik yanaşmaların tətbiqini əhəmiyyətli dərəcədə çətinləşdirir.
Xarici bir müştəri üçün (bir PM olduğum yerdə) layihələrimdən birində (çox böyük bir şirkətin daxili korporativ portalının hazırlanması və yerləşdirilməsi) maraqlı bir hal oldu. Müştərinin müqavilə sənədlərinə müştəri tərəfindən hazırlanmış TT (texniki tələblər) (təxminən 10 səhifə) daxildir. Bundan əlavə, analitik sistemin dizayn / dizayn mərhələsində komandamız çox ətraflı texniki spesifikasiya (təxminən 300 səhifə) hazırladı. İnkişaf mərhələsində belə detallara baxmayaraq, müştəri müəyyən bir interfeysin tətbiq olunan funksionallığının fikirlərinə uyğun olmadığını bildirdi Arqument olaraq, TK -da analitik tərəfindən yazılan formülasyonların, hədəf olaraq gördüyü də daxil olmaqla, funksionallığın fərqli şərhlərinə imkan verdiyini söylədi. Və bu, TK -nın mübahisəli hissəyə düzəlişlər də daxil olmaqla bu nöqtəyə qədər bir neçə düzəliş və təsdiqdən keçməsinə baxmayaraq. Müştəri ilə münasibətlərin hüquqi və konseptual aspektlərinə girməyəcəyəm, çünki bunu hələ layihədə etməmişəm. Bunun əvəzinə, komandamız hazır məhsulu hazırlamaq və çatdırmaq üçün qurduğumuz praktikanı dəyişdirməyə davam etdi. Daha sonra mübahisəli interfeysin inkişaf etdiricisini müştərinin yerinə qoyduq (əlbəttə ki, mənim nəzarətimlə) və bu interfeys üçün tam inkişaf yolu keçdik (indiki kimi müştəri ilə birlikdə), vizual dizayndan, prototipdən, dizayn, inkişaf, sınaq və qəbul. Əmək xərcləri planlaşdırılana nisbətən artdı, amma nəticədə - əhəmiyyətsiz. Üstəlik, geliştirici tək başına daha tam bir sınaq keçirməli idi, lakin keyfiyyəti daha yüksək idi - müştəri ilə "dörd əlində" getdiyi üçün. Bu interfeys üçün dəyişikliklər artıq lazım deyildi, müştəri məmnuniyyətlə qəbul etdi.
Bu layihədə daha maraqlı idarəetmə halları var idi və var idi, amma bu başqa bir hekayədir.
05.09.2021
Xəbərlər
Layihə İdarəetməsində Etik Dəyərlər
Layihə idarəetməsinin dinamik və mürəkkəb dünyasında etik prinsiplərə riayət etmək bir ...
Xəbərlər
Layihə İdarəetməsində 80/20 Qaydası (Pareto Prinsipi): ...
Layihə idarəetməsində 80/20 qaydası (və ya Pareto prinsipi) geniş şəkildə istifadə ...