Ko par sevi nezināja sistēmanalītiķis?


Analītiķu vakariņās atcerējos reiz lasītu stāstu. Kāda žurnāliste bija nonākusi spēlē, kur bija jāpelna nauda, piedāvājot kādu savu prasmi. Kamēr tirgošanās jau gāja pilnā sparā – kāds piedāvāja deju, kāds pazīlēt uz rokas, kāds dziesmu, šī meitene apjukusi domāja – bet ko lai es piedāvāju… un tad izdomāja: pārdošu patiesu un atklātu stāstu par to, kā es redzu savu sarunu biedru! Un, ziniet – pie viņas izveidojās rinda.

Tā nu līdzīgi bija, kad mēs, analītiķi, aizrautīgi klausījāmies stāstu par sevi, kad runāja mūsu kliente. Mūsu – plašā nozīmē. Cilvēks, kam ir ilggadēja pieredze – gan pozitīva, gan negatīva. Tā bija saruna. Ne moralizēšana, ne didaktiska pamācīšana, bet unikāla iespēja atklāti izrunāties. Lai paliek tehniskās nianses, lai paliek lietas, kuras nav paredzētas publiskošanai. Lūk, kādas atziņas es pierakstīju un šur tur apņēmos laboties:

No sistēmanalītiķa (to gan var attiecināt uz ikvienu izstrādātāja pārstāvi) sagaidu patiesu ieinteresētību savā darbā, nevis atstrādāšanu.

Kad pirmo reizi atnāk analītiķis, sagaidu, ka viņam ir priekšstats par mūsu uzņēmumu, kā arī orientējas mūsu biznesa pamatos.

Pirmajā tikšanās reizē sagaidu, ka uzklausīs mani. Negaidu, ka sāks mani mācīt dzīvot!

Nepatīk, ja man saka: „uzdošu muļķīgu jautājumu”. Nav muļķīgu jautājumu!

Valoda, kādā runā ar mani… Neatkarīgi no iemesliem – varbūt grib manā priekšā izrādīties vai neiedomājas, ka esmu biznesa, nevis datorcilvēks, taču gribu sarunāties sev saprotamā valodā, bez IT žargona vai specifiskiem jēdzieniem.

Ja nedēļas laikā pēc tikšanās nesaņemu jautājumu vai komentāru par notikušo sarunu, rodas sajūta, ka par mūsu sarunu netiek domāts vai vēl ļaunāk – ir vienkārši…. aizmirsts. Un tā ir nepatīkama sajūta. Šādu sajūtu klientam nedrīkst radīt!

Risinājumi atkarībā no projekta situācijas:

sarunāt obligātās tikšanās reizi nedēļā pat tad, ja nav akūtu jautājumu, ko pārrunāt,

– katras komunikācijas beigās vienmēr norunāt, kad būs nākamā, par ko tā būs un kāds būs tās rezultāts.

Īpašs uzsvars – tiešām ir ļoti svarīgi neradīt klientam informācijas vakuuma sajūtu. Klients grib zināt aktuālu informāciju par termiņiem, par notiekošo.

Klienta īpašs lūgums analītiķiem: ja ir sarunāts termiņš, līdz kuram kaut kas tiek gaidīts no mums, un rezultāts svarīgs arī jums, lūdzu, atgādiniet arī jūs. Arī mēs esam tikai cilvēki. Nepaļaujieties, ka mēs atcerēsimies un ievērosim. Lūdzu, neizmantojiet mūsu aizmiršanu, lai kaut kādā veidā atspēlētos par kavēšanos.

Arī mans laiks ir dārgs. Tikšanās laikā ārkārtīgi svarīgi ir satikties pareizajiem cilvēkiem. Gan no savas puses gribu būt droša, ka sarunā nodrošināšu pareizos cilvēkus, gan sagaidu, ka izstrādātāja pārstāvji pilnībā pārklās sarunas tēmu.

Klients var pat nenojaust, ka projektā ir tādi arhitekti u.tml. speciālisti. Tāpēc būtu labi kādā no pirmajām tikšanām neuzkrītoši noskaidrot priekšzināšanu līmeni un īsumā izskaidrot projekta struktūru un raksturot to cilvēku pienākumus un atbildību, ar kuriem klientam būs tikšanās. Nevis vienkārši painformēt – nākamreiz man līdzi atnāks arhitekts (???!!!!).

Kad zināms, ka tikšanās laikā runa būs par konceptuāliem jautājumiem un lēmumus būtu labi pieņemt operatīvi, ir labi, ja līdzi ir arhitekts. No klienta skatījuma tas izskatās tā: „Arhitekts piebaksta projekta pārvaldniekam vai analītiķiem, abi parunājas savā starpā dažādos IT svešvārdos, pastrīdas, vienojas un klientam jau atbild vienotu – jā/nē”. Klients redz, ka speciālisti ir apspriedušies, un ir ticamība lēmumam.

Ja programmētājs bieži nāk līdzi uz tikšanos pie klienta, rodas sajūta, ka viņam īsti nav ko darīt. Tāpēc ir ļoti svarīgi vienoties par nākamās tikšanās tēmu, lai varētu paņemt līdzi tieši tos cilvēkus, kuri ir nepieciešami. Un: nevajag ņemt līdzi kodētāju. Labāk ņemt līdzi arhitektu.

Ja tomēr paņemts līdzi programmētājs, viņam jādomā, ko runā. Gadījums no dzīves: grāmatvede uztraucas, ka virsgrāmatā nepareizs ieraksts. Programmētājs mierinoši: neuztraucieties taču, visu izdzēsīsim! Grāmatvede vēl šobaltdien negribot redzēt nevienu programmētāju :-)

Gadu gaitā interesants novērojums – laba sadarbība izdodas ar sistēmanalītiķēm sievietēm. Augstu vērtēju prasmi ātri pārslēgt domāšanu no vienas tēmas uz otru, un sagadījies, ka tieši sievietēm tā piemīt teicamā līmenī. Savukārt labāka sadarbība izveidojusies ar projektu pārvaldniekiem vīriešiem. Tā nav dogma un tas nav uz stereotipiem balstīts pieņēmums – konkrētā projektā un manā pieredzē tā vienkārši ir sanācis.

Klients pieķeras pie visa, par ko viņam sarunā vai sarakstē ļauj cerēt, ka būs. Tāpēc aicinu nopietni pieiet jebkādiem solījumiem vai pat mājieniem. Dažreiz izveidojas pat tāda kā spēlīte: analītiķis – labais policists, projekta pārvaldnieks – sliktais policists, kurš pasaka, ka resursu nav, laika nav, nebūs. Būtu labi šādas spēlītes nespēlēt un ikvienam atbildēt par saviem vārdiem.

Klientam ļoti svarīgi ir zināt precīzus, pēc iespējas precīzākus termiņus. Organizācijā ir arī augstāka līmeņa plāni, kuri veidojas no zemāka līmeņa plāniem, tāpēc sagaidām no izstrādātājiem pēc iespējas precīzākus laika un izmaksu aprēķinus. Laiku pastiept ir salīdzinoši vieglāk. Izmaksas – krietni grūtāk. Tāpēc aicinājums – ļoti nopietni pieiet šādiem aprēķiniem un solījumiem.

Ir bijis laiks, kad par varītēm šķita svarīgi panākt, ka maksimāli daudzas lietas pie katras izdevības ir problēmu ziņojumi. Ar laiku nāca pieredze un tīri cilvēciska atklāsme, ka svarīga ir pozitīva sadarbība, tāpēc katrs gadījums tiek rūpīgāk izvērtēts, bez mērķa nogrūst to izstrādātājam.

Attiecības – draudzīgas, taču ne personiskas. Laiks ir dārgs un nedrīkst pieļaut, ka daļa sarunas ar laiku ievirzās gultnē „un kā tad tavam sunītim klājas?”

Negaidu, ka IT cilvēks nāks uzvalkā, taču sagaidu, ka pielāgosies klienta organizācijas videi. Lai gan par IT cilvēkiem ir zināmi stereotipi, sevišķi programmētājiem, ka viņi ģērbjas, teiksim tā, interesanti, tomēr no analītiķiem sagaidām respektu pret organizācijas ģērbšanās kultūru.

Uz „Tu”, ja vispār, tad piedāvā pāriet klients.

Vai komanda ir izstrādātāji, vai izstrādātāji + klienta pārstāvji? Atkarīgs no projekta un izstrādātāja, tomēr viela pārdomām – ko uzskatīt par komandu.

Klients nevienā situācijā IT jautājumos nedrīkst sajusties pārāks par izstrādātāju!

Reizēm klientam gribas satikt valdes locekli, kurš pasaka un nodrošina pārliecību, ka jūs mums rūpat, jūs mums esat interesants un mēs iesim ar jums kopā līdz uzvarošajam galam!

Pozitīva pieredze: bija praktikante, kura pusgadu strādāja, ielauzījās biznesā un aizgāja pie izstrādātāja strādāt par testētāju. Nodevumu kvalitāte ievērojami uzlabojās attiecībā uz biznesa funkcionalitātes kvalitāti.

Darbinieku maiņa: svarīgi, lai būtu kvalitatīvi nodotas lietas. Izstrādātāja pienākums ir nodrošināt, lai aizejošais darbinieks to korekti izdara. Patiesībā ideālā gadījumā uz pēdējo tikšanos vai pat vairākām varētu atnākt kopā vecais un jaunais. Tādējādi klients redzētu, ka pēctecība tiek nodrošināta, un būtu sirds mierīgāka.

Negatīva pieredze: uz tikšanos atnāca cilvēks, kuram ne tikai nebija priekšstata par klienta biznesu, bet kurš nebija pat pacenties noskaidrot, kā notiek sadarbība ar klientu. Klients bija spiests tērēt savu laiku, „apgaismojot” paša apmaksāto izstrādātāju par to, kā viņi savā starpā strādā. Ja biznesa nezināšanu vēl varētu piedot, tad šāda attieksme jau bija zem katras kritikas.

PPS gribētu, lai ir izkārtota atbilstoši savam biznesa procesam – tā, kā ir ērtāk lasīt klientam, nevis ērtāk strukturēt izstrādātājam. Būtu labi savlaicīgi saskaņot satura rādītāju. Specifikācijā patīk bildes, modeļi. Patīk, ka ir aprakstīti algoritmi.

 Ārkārtīgi svarīga ir vienprātība definīciju izpratnē. Svarīgi iedomāties un saskaņot arī it kā vispārzināmus jēdzienus. Piemēram, „gads”. Personāla pārvaldei – gads, kopš darbinieks stājies darbā. Izstrādātājam – kalendārais gads.

Projekti notiek nevis starp organizācijām, bet starp cilvēkiem. Cienīt vienam otru un – cienīt vienam otra laiku. Un – sajust gan vārdos, gan darbos, ka sistēmanalītiķis un pārējie strādā, lai atvieglotu klienta dzīvi.

Mēs dažreiz pārmetam, ka ierēdņi aizmirst, ka strādā mums, nodokļu maksātājiem. Bet vai mēs, sistēmanalītiķi, vienmēr, vienmēr atceramies, ka strādājam jums, klienti? Sirsnīgs paldies klientei par šo sarunu!

P.S. un mums paveicās, ka starp klausītājiem bija vēl viena klientu pārstāve, arī sistēmanalītiķe, kura ik pa brīdim padalījās arī savā pieredzē. Jāteic, tie organiski papildināja sarunu.

4 komentāri

  1. Jā, tiešām paldies abām klientu puses analītiķēm! Lekcijām no šīs tikšanās ieguvu atziņu, ka vairāk jākcente šādās 2 tēmas:
    1) sistēmu analīzes process,
    2) sistēmu analīzes ētika.

    Gribas vēl mazliet piebilst Kaspara teiktajam par to, ka sistēmanalītiķa uzdevums ir šķelt. Domāju, ka precīzāk būtu formulēt šādi: Spēt saskatīt un parādīt sistēmas sastāvdaļas līdz tādai detalizācijas pakāpei, kas atbilst analīzes mērķim; kā arī saprast un prast ilustrēt, kā un kādu veselo no detaļām var izveidot.

    Patīk

    Atbildēt

    • Mārītei – jā, protams, bet es komentēju Mikus citēto Vonnegūtu “Если ученый не может объяснить восьмилетнему мальчику, чем он занимается, то он шарлатан.”, jo man liekas, ka tas tā nav.
      Protams, ir jau taisnība, ka pareiza komunikācija atkarībā no informācijas saņēmēja izpratnes līmeņa ir svarīga :)

      Patīk

      Atbildēt

  2. Paldies par apkopojumu, Tu esi pacentusies!
    Vispār, man šīs vakariņas tiešām patika, žēl ka nebija laika palikt pēc ofic daļas beigām.

    Mik, par tiem zinātniekiem – nu neticu es, ka tik vienkārši ir. Tu jau pats zini, ka velns slēpjas detaļās, bet vienkāršos vārdos detaļām nepietiek vietas. Bet analītiķa uzdevums ir šķelt!

    Patīk

    Atbildēt

  3. Posted by Miks on 28/07/2011 at 11:13

    Man šķiet, ka vairākas no minētajām lietā ir vispārcilvēciskas un attiecas uz jebkuru darba darītāju:

    Piemēram patiesa ieinteresētība — vai tas nebūtu jauki, ja visi cilvēki mums visapkārt būtu patiesi ieinteresēti tajā ko viņi dara? Un ne tikai tajā KO viņi dara, bet arī REZULTĀTĀ t.i. gribētu izdarīt darbu labi. Padomājiet no cik daudzām dažādām procedūrām, pārbaudēm utml. varētu atteikties, ja katrs cilvēks darītu savu darbu ar interesi….
    Bet iespējams, ka tā ir utopija. Iespējams, ka tas nav cilvēka dabā. Lai gan ej nu tu sazini, kas ir cilvēka daba. Tas ir filozofijas jautājums, kas ir jāskata kopā ar to, kurp mēs ejam un kāds ir mūsu dzīves mērķis (gan katra atsevišķa indivīda, gan sabiedrības kopumā) un, kā jau visi filozofijas jautājumiem, tiem nav viena pareizā atbilde….

    Tad vēl par runāšanu bez IT žargona — pilnīgi piekrītu, ka vajadzētu no tā izvairīties. Bet tas ir koks ar diviem galiem — arī klientam vajadzētu censties izvairīties no sava žargona. Un es runāju nevis par to, ka izstrādātāji nepārzin attiecīgo biznesa jomu. Es vairāk domāju kaut kādus attiecīgā uzņēmuma/iestādes iekšienā izveidojušos apzīmējumus, saīsinājums utml.
    Šajā sakarā es atcerējos jauku stāstu, ko kādreiz lasīju iekš anekdot.ru http://www.anekdot.ru/an/an1010/o101002.html. Gan pats stāsts ir labs, gan arī ievada Vonnegūta citāts ir labs:
    “… Если ученый не может объяснить восьмилетнему мальчику, чем он
    занимается, то он шарлатан.”
    (Курт Воннегут)

    P.S. Un vēl palika žēl, ka netiku uz šīm vakariņām

    Patīk

    Atbildēt

Mans viedoklis: