Müştəriyə brifinin yanlış olduğunu dedikdə nə baş verir (və niyə bunu həmişə edirik)

Proqram təminatı tərtibatı sahəsində standart iş qaydası «hə» deməkdir. Şirkət brif təqdim etdikdə, əksər studiyalar funksiyalar siyahısı ilə razılaşır, icra müddəti təklif edir və kod yazmağa başlayır. Proqram təminatı layihələrinin yalnız 29%-i uğurlu — vaxtında, büdcə daxilində və qənaətbəxş nəticə ilə tamamlanmış hesab olunub — Standish Group CHAOS Report, 2015.

Webiland-də əməliyyat modelimiz fərqli bir prinsip üzərində qurulub: «Koddan əvvəl tədqiqat». Praktikada bu o deməkdir ki, biz tez-tez potensial müştərinin brifinə baxır və fərziyyələrinin yanlış olduğunu, funksiyalar siyahısının hələ tez olduğunu və ya seçilmiş texnologiya stekinin biznes məqsədlərinə uyğun gəlmədiyini deyirik.

«Hə» deyən studiyaların problemi

Brifi yoxlamadan onunla razılaşmaq müştərinin öz biznes problemini texniki arxitekturaya qüsursuz çevirdiyini fərz etmək deməkdir. Bu, hətta yüksək texniki hazırlıqlı komandalar üçün də nadir hallarda belə olur.

Studiya yoxlanılmamış brifə «hə» dedikdə, biznes problemini həll etməyi deyil, sadəcə müəyyən funksiyalar toplusunu hazırlamağı öhdəsinə götürür. Həmin funksiyalar gəlir gətirməsə və ya istifadəçi cəlb etməsə belə, studiya öz ödənişini alır. Maliyyə riski tamamilə müştərinin üzərində qalır.

Struktur səhvləri nə qədər gec aşkarlanarsa, bir o qədər baha başa gəlir. Layihələndirmə mərhələsində tapılan tələb səhvi kağız üzərində düzəldilir. Produkşnda aşkarlandıqda isə onu kodda, məlumatlarda və üzərində qurulmuş hər bir funksiyada düzəltmək lazım gəlir.

«Brif yanlışdır» ifadəsi əslində nə deməkdir

Müştəriyə brifinin yanlış olduğunu dedikdə, üç struktur qüsurundan birini müəyyən etmiş oluruq:

Həcm uyğunsuzluğu. Brifdə monolit tətbiq tələb olunur, halbuki yüngül veb-tətbiq bazarı daha tez yoxlamağa imkan verərdi. Yaxud əksinə, «sadə MVP» istənilir, lakin aylarla infrastruktur işi tələb edən köhnəlmiş ERP sistemləri ilə mürəkkəb inteqrasiyalar daxil edilir.

Texniki mümkünsüzlük. Brif məhsulun əsas tələbləri ilə ziddiyyət təşkil edən konkret texnologiya stekini diktə edir — məsələn, aparat təminatının doğma API-ləri ilə dərin və aşağı gecikməli inteqrasiya tələb edən tətbiq üçün kross-platforma freymvorkunun seçilməsini şərt qoyur.

Tədqiqatın olmaması. Brif nəyin qurulmalı olduğunu təfərrüatı ilə təsvir edir, lakin bunun niyə mövcud olmalı olduğunu və ya uğursuzluğun necə ölçüləcəyini müəyyən etmir. İlkin göstəricilər və hədəf nəticələr olmadıqda, mühəndislər əsaslandırılmış arxitektura kompromislərinə gedə bilmirlər.

Müzakirə: öhdəlikdən əvvəl şəffaflıq

Müştəriyə brifinin əsaslı şəkildə yenidən qurulmalı olduğunu demək xüsusi ünsiyyət çərçivəsi tələb edir. Biz brifləri birbaşa rədd etmirik; onları audit edirik.

Geniş yayılmış bir hala baxaq. Şirkət sıfırdan fərdi CRM yaradılması üçün brif gətirir, funksiyalar siyahısı isə iri kommersiya platformasını təkrarlayır. Qurma işini qiymətləndirmək əvəzinə, biz iş axınını audit edirik. Çox vaxt təhlil göstərir ki, əsas problem fərdi proqram təminatının olmaması deyil, şirkətin artıq istifadə etdiyi platformalar arasında parçalanmış məlumatlardır.

Bundan sonra müzakirə «CRM qurmaq neçəyə başa gələr?» sualından «Məlumat axınlarınızı necə birləşdirək?» sualına keçir. Sonrakı əməkdaşlıq API inteqrasiyaları və məlumat anbarlarının qurulması üzərində cəmləşir — bu həll fərdi CRM-dən daha ucuz başa gələ bilər və biznesin real dar boğazını aradan qaldırır.

Niyə etiraz etmək daha yaxşı nəticələr verir

Fərziyyələrini sual altına alan studiyalarla əməkdaşlıq edən müştərilər üç konkret üstünlük qazanır:

Kapital itkisinin azaldılması: Tərtibat başlamazdan əvvəl lazımsız funksiyaları müəyyən etməklə kapital marketinq, istifadəçi cəlbi və ya buraxılışdan sonrakı iterasiyalar üçün qorunub saxlanılır. Yanlış məhsulu səmərəli şəkildə qurmaq yenə də kapitalın tam itirilməsi deməkdir.

Dəqiq icra müddətləri: Dərindən yoxlanılmış brif möhkəm texniki spesifikasiya ilə nəticələnir. Kənar hallar, üçüncü tərəf API məhdudiyyətləri və məlumatların miqrasiyası çətinlikləri əvvəlcədən xəritələndikdə, müddət hesablamaları nikbin təxminlərdən proqnozlaşdırıla bilən təhvil qrafikinə çevrilir.

Biznes göstəriciləri üzrə uzlaşma: Studiya hər hansı funksiyaya etiraz etdikdə, bu, ROI barədə müzakirəni zəruri edir. Nəticədə mühəndis komandası müştərinin sadəcə tapşırıqlar siyahısına deyil, maliyyə hədəflərinə uyğunlaşır.

Studiyanın yanaşmasını necə qiymətləndirməli

Brif təqdim etdikdə studiyanın reaksiyası onların real layihəni necə idarə edəcəyinin ən dəqiq göstəricisidir. Əgər onlar istifadəçi cəlbi strategiyanız, məlumat strukturlarınız və ya köhnəlmiş sistem məhdudiyyətləriniz barədə dəqiqləşdirici suallar vermədən 48 saat ərzində qiymət təklifi göndərirlərsə — onlar həlli deyil, funksiyalar siyahısını qiymətləndirirlər.

Əks halda, əgər onlar məntiqinizdəki boşluqları üzə çıxaran suallarla qayıdır, alternativ arxitekturalar təklif edir və ya bazara çıxışı sürətləndirmək üçün ilkin həcmi azaltmağı tövsiyə edirlərsə — siz mühəndislik tərəfdaşı ilə danışırsınız. Həmin ilkin müzakirədəki mübahisə 12 ay sonra tam uğursuzluğun qarşısını alan əsas mexanizmdir.