Як ва ўмовах трэшавай архітэктуры і адсутнасці навыкаў у Scrum мы стварылі крос кампанентныя каманды

Прывітанне!

Мяне клічуць Аляксандр, і я кірую ІТ распрацоўкай у УБРиР!

У 2017 годзе мы ў цэнтры развіцця сэрвісаў інфармацыйных тэхналогій УБРыР зразумелі, што прыйшоў час глабальных змен, а дакладней - agile-трансфармацыі. Ва ўмовах інтэнсіўнага развіцця бізнесу і хуткага росту канкурэнцыі на фінансавым рынку два гады - вялікі тэрмін. Таму надышоў час падвесці вынікі праекта.

Самае складанае - мяняць сваё мысленне і паступова культуру ў арганізацыі, дзе прынята разважаць: "а хто будзе начальнікам у гэтай камандзе?", "начальнік лепш ведае, што нам трэба рабіць", "мы тут працуем ужо 10 гадоў і ведаем лепш за нашых кліентаў , ведаем, што ім трэба».

Agile-трансфармацыя можа адбыцца толькі, калі ў ёй мяняюцца самі людзі.
Я б вылучыў наступныя ключавыя страхі, якія замінаюць людзям мяняцца:

  • Страх страціць уладу і "пагоны";
  • Страх стаць не патрэбным для кампаніі.

Устаўшы на шлях трансфармацыі, мы абралі першых «доследных трусоў» – супрацоўнікаў retail-кірунку. Перш за ўсё правялі рэдызайн неэфектыўна якая працуе структуры ІТ. Прыдумаўшы мэтавы канцэпт структуры, прыступілі да фармавання каманд распрацоўкі.

Як ва ўмовах трэшавай архітэктуры і адсутнасці навыкаў у Scrum мы стварылі крос кампанентныя каманды

Архітэктура ў нашым банку, як і ў многіх іншых, мякка кажучы "трэшавая". Вялікая колькасць прыкладанняў і кампанентаў, маналітна звязаных паміж сабой DB link, ёсць ESB шына, але яна не выконвае сваіх прызначэнняў. Таксама ёсць некалькі АБС.

Як ва ўмовах трэшавай архітэктуры і адсутнасці навыкаў у Scrum мы стварылі крос кампанентныя каманды

Перад тым, як фармаваць scrum-каманды, паўстала пытанне: "А вакол чаго павінна быць сабрана каманда?". Паняцце, што ў банку ёсць прадукт, вядома, лунала ў паветры, але на адлегласці недасягальнасці. Пасля доўгіх роздумаў вырашылі, што каманда павінна быць сабрана вакол кірункі або сегмента. Напрыклад, "Каманда Крэдыты", якая развівае крэдытаванне. Вызначыўшыся з гэтым, мы пачалі прыдумляць мэтавы склад роляў і набору кампетэнцый, неабходных для эфектыўнага развіцця гэтага напрамку. Як і многія іншыя кампаніі, мы ўлічылі ўсе ролі акрамя Scrum Master – на той момант растлумачыць CIO, якая ж роля гэтага цудоўнага чалавека, было практычна немагчыма.

У выніку пасля тлумачэнняў аб неабходнасці запуску каманд распрацоўкі мы запусцілі тры каманды:

  1. Крэдыты
  2. Карты
  3. Пасіўныя аперацыі

З наборам роляў:

  1. Мэнэджар распрацоўкі (Tech Lead)
  2. Распрацоўшчык
  3. Аналітык
  4. Тэсціроўшчык

Наступным этапам трэба было вызначыць, як каманда будзе працаваць. Мы правялі agile- навучанне ўсіх удзельнікаў каманды, пасадзілі ўсіх у адзін пакой. PO у камандах не было. Мусіць, усе, хто рабіў agile-трансфармацыю, разумеюць, наколькі складана растлумачыць бізнэсу роля PO, а яшчэ складаней пасадзіць яго побач з камандай і даць паўнамоцтвы. Але мы "крочылі" ў гэтыя змены з тым, што было.

Так як у працэсах крэдытавання і астатніх кірунках раздробнага бізнэсу было задзейнічана велізарная колькасць прыкладанняў, мы пачалі думаць, хто можа падысці на ролі? Распрацоўнік аднаго стэка тэхналогій, а тамака глядзіш — і патрэбен распрацоўнік іншага стэка тэхналогій! І вось ты знайшоў тых, хто патрэбен, але жаданне супрацоўніка - таксама важная рэч, і прымусіць чалавека працаваць, там, дзе яму не падабаецца, даволі складана.

Пасля аналізу працы бізнэс-працэсу крэдытавання і доўгіх размоваў з калегамі мы ўсё ж знайшлі залатую сярэдзіну! Так з'явіліся тры каманды распрацоўкі.

Як ва ўмовах трэшавай архітэктуры і адсутнасці навыкаў у Scrum мы стварылі крос кампанентныя каманды

Што далей?

Людзі пачалі дзяліцца на тых, хто хоча мяняцца, і тых, хто не хоча. Усе абвыклі працаваць ва ўмовах "мне задачку далечы, я яе зрабіў, адчапіцеся ад мяне", а камандная праца гэтага не мае на ўвазе. Але і гэтую праблему мы вырашылі. Усяго за час зменаў звольнілася 8 чалавек са 150!

Далей пачалося самае цікавае. Нашы крос-кампанентныя каманды сталі развіваць самі сябе. Напрыклад, ёсць задача, для якой трэба мець скілы ў вобласці распрацоўніка CRM. У камандзе ён ёсць, але ён адзін. Таксама ёсць Oracle-распрацоўшчык. Што рабіць, калі трэба вырашыць 2 ці 3 задачы ў CRM? Вучыць адно аднаго! Рабяты пачалі перадаваць свае кампетэнцыі адзін аднаму, і каманда пашырала свае магчымасці, мінімізуючы залежнасць ад аднаго моцнага адмыслоўца (дарэчы, у любой кампаніі ёсць супермэны, якія ведаюць усё і нікому гэтага не распавядаюць).

На сёння ў нас сабрана 13 каманд распрацоўкі на ўсе кірункі развіцця бізнэсу і сэрвісаў. Мы працягваем agile-трансфармацыю і выходзім на новы ўзровень. Гэта запатрабуе новых змен. Мы будзем рэдызайніць каманды і архітэктуру, будзем развіваць кампетэнцыі.

Наша выніковая мэта: хутка рэагаваць на змены прадукта, хутка выводзіць на рынак новыя фічы і паляпшаць сэрвісы банка!

Крыніца: habr.com

Дадаць каментар