Тем­ные сто­ро­ны Agile

При всей сво­ей на­це­лен­но­сти на вза­и­мо­дей­ствие и уско­ре­ние вы­во­да на ры­нок гиб­кое про­ек­ти­ро­ва­ние ори­ен­ти­ро­ва­но преж­де все­го на до­став­ку про­дук­та, а не на улуч­ше­ние биз­не­са, не го­во­ря уже о его транс­фор­ма­ции

Direktor informatsionnoj sluzhby - - СОДЕРЖАНИЕ «ДИРЕКТОР ИНФОРМАЦИОННОЙ СЛУЖБЫ» (CIO.R - БОБ лью­ИС

По­хо­же, гиб­кое про­ек­ти­ро­ва­ние ста­но­вит­ся уже вче­раш­ним днем. А как же пе­ре­до­вые ком­па­нии? они уже пе­ре­шли на DevOps. Бо­лее то­го, мно­гие раз­ра­бот­чи­ки при­ло­же­ний не толь­ко не взя­ли на во­ору­же­ние agile­тех­но­ло­гии, но да­же не име­ли та­ких на­ме­ре­ний.

Все пе­ре­чис­лен­ное мо­жет ка­зать­ся стран­ным, по­ка вы не по­зна­ко­ми­тесь по­бли­же с ре­аль­ны­ми по­треб­но­стя­ми ко­манд раз­ра­бот­чи­ков.

И то­гда ока­жет­ся, что ме­то­до­ло­гии гиб­ко­го про­ек­ти­ро­ва­ния очень ма­ло от­ве­ча­ют их це­лям.

Agile-ме­то­до­ло­гии (в осо­бен­но­сти Scrum, ко­то­рую мно­гие ИТ-ме­не­дже­ры счи­та­ют си­но­ни­мом гиб­ко­го про­ек­ти­ро­ва­ния) луч­ше все­го под­хо­дят для раз­ра­бот­ки но­вых при­ло­же­ний.

один из глав­ных прин­ци­пов ИТ фор­му­ли­ру­ет­ся так: по­ку­пай, ко­гда мо­жешь, со­зда­вай, ко­гда нужно. ИТ-служ­бы ли­цен­зи­ру­ют око­ло 90% все­го но­во­го функ­ци­о­на­ла в ви­де го­то­во­го ком­мер­че­ско­го про­грамм­но­го обес­пе­че­ния или про­грамм­но­го обес­пе­че­ния, предо­став­ля­е­мо­го в ви­де сер­ви­са (software as a service, SaaS), остав­ляя на раз­ра­бот­ку его соб­ствен­ны­ми си­ла­ми все­го 10%.

Scrum, Kanban, Lean Software Development и дру­гие agile-ме­то­до­ло­гии пред­на­зна­че­ны для со­зда­ния все­го 10% про­грамм­но­го обес­пе­че­ния. При этом 70% сво­е­го вре­ме­ни ти­пич­ный раз­ра­бот­чик тра­тит на под­держ­ку и рас­ши­ре­ние функ­ци­о­на­ла уже экс­плу­а­ти­ру­е­мых при­ло­же­ний и толь­ко 30% оста­ет­ся у него для со­зда­ния но­вых.

Про­ве­дем неслож­ные под­сче­ты. Agile­про­ек­ти­ро­ва­ние оказывается по­лез­ным лишь для 10% из 30% – то есть для 3% при­ло­же­ний, ко­то­ры­ми за­ни­ма­ют­ся ко­ман­ды раз­ра­бот­чи­ков.

Ко­неч­но, в раз­ных си­ту­а­ци­ях до­ля эта мо­жет ва­рьи­ро­вать­ся. Но в лю­бом слу­чае про­цент весь­ма не­боль­шой.

AGILE-ПУТь ПОД­ДеРж­КИ И УлУЧ­шеНИй

Да­вай­те нач­нем с про­сто­го: за­про­сов на об­слу­жи­ва­ние и улуч­ше­ния, ко­то­рые со­став­ля­ют зна­чи­тель­ную часть по­все­днев­ной ра­бо­ты ИТ-служ­бы.

Не нужно силь­но всмат­ри­вать­ся в оче­редь, что­бы за­ме­тить, на­сколь­ко все здесь на­по­ми­на­ет agile-ме­то­до­ло­гию. До­бав­ля­ем вла­дель­ца про­дук­та (че­ло­ве­ка, от­ве­ча­ю­ще­го за его раз­ра­бот­ку) и на­чи­на­ем фор­му­ли­ро­вать за­про­сы, пред­став­лен­ные в ви­де поль­зо­ва­тель­ских ис­то­рий (из­ло­жен­ных на биз­нес-язы­ке тре­бо­ва­ний к раз­ра­ба­ты­ва­е­мой си­сте­ме). Мы про­де­ла­ли это за ми­ну­ту. При­ме­ня­ем Kanban: вла­де­лец про­дук­та опре­де­ля­ет при­о­ри­те­ты, а раз­ра­бот­чик, вы­пол­нив очередное за­да­ние с поль­зо­ва­тель­ской ис­то­ри­ей, пе­ре­хо­дит к сле­ду­ю­ще­му. На­клад­ные рас­хо­ды ми­ни­маль­ны, а ра­бо­та вы­пол­не­на.

AGILE-РАз­РА­бОТ­КА COTS

При­ме­нять agile-ме­то­до­ло­гии при внед­ре­нии «ко­ро­боч­ных» про­дук­тов (Commercial OffThe-Shelf, COTS) уже не так про­сто, как в хо­де под­держ­ки и улуч­шений. Впро­чем, ни­кто это­го и не ждет: по­стро­е­ние круп­ных си­стем – не та­кой про­стой про­цесс, как управ­ле­ние поддержкой и улуч­ше­ни­я­ми.

од­на­ко agile-технологии мож­но при­ме­нять и к COTS. Нужно толь­ко учи­ты­вать два важ­ных мо­мен­та. Пер­вый: внед­ре­ние COTS, как на сво­ей тер­ри­то­рии, так и в ви­де SaaS, не пред­по­ла­га­ет раз­ра­бот­ку про­грамм­но­го обес­пе­че­ния с ну­ля, а огра­ни­чи­ва­ет­ся од­ной-дву­мя на­строй­ка­ми. А по­то­му Scrum и Kanban фак­ти­че­ски непри­год­ны для ре­ше­ния та­ких за­дач. Вто­рой мо­мент: по­ми­мо Scrum и Kanban, су­ще­ству­ют и дру­гие agile­ме­то­до­ло­гии.

РАз­РА­бОТ­КА ПРИ­лО­же­НИй ПРО­ТИВ ВНеД­Ре­НИя COTS: ВСе НА­ЧИ­НА­еТ­Ся С ДАН­Ных

При­сту­пая к раз­ра­бот­ке про­грамм­но­го обес­пе­че­ния, ИТ-ко­ман­да долж­на по­нять, ка­кие тре­бо­ва­ния предъ­яв­ля­ют­ся к нему со сто­ро­ны биз­не­са. Уяс­нив эти тре­бо­ва­ния, не нужно сра­зу при­сту­пать к раз­ра­бот­ке По. На­чать сле­ду­ет с про­ек­ти­ро­ва­ния струк­тур дан­ных.

Про­ек­ти­ро­вать струк­ту­ры дан­ных не нужно лишь в тех слу­ча­ях, ко­гда ба­за дан­ных уже су­ще­ству­ет и от­ве­ча­ет всем по­треб­но­стям но­во­го при­ло­же­ния.

При внед­ре­нии сра­зу несколь­ких па­ке­тов COTS/SaaS су­ще­ству­ю­щие ба­зы дан­ных толь­ко ослож­ня­ют, а не упро­ща­ют ра­бо­ту. Каж­дый па­кет по­став­ля­ет­ся со сво­ей соб­ствен­ной ба­зой дан­ных, а при про­ек­ти­ро­ва­нии сво­их баз дан­ных по­став­щи­ки со­вер­шен­но не учи­ты­ва­ют те, что у вас уже име­ют­ся. У них про­сто нет со­от­вет­ству­ю­щей ин­фор­ма­ции. они не об­ра­ща­ют ни­ка­ко­го вни­ма­ния и на ба­зы дан­ных дру­гих по­став­щи­ков.

Внед­ряя па­кет COTS, ИТ-служ­ба долж­на от­сле­жи­вать все су­ще­ству­ю­щие ба­зы дан­ных, в ко­то­рых на­хо­дит­ся та же ин­фор­ма­ция, что нуж­на но­во­му при­ло­же­нию. И де­ла­ет­ся это не ра­ди из­вле­че­ния до­пол­ни­тель­ных вы­год из уже су­ще­ству­ю­щих баз дан­ных, а для син­хро­ни­за­ции пе­ре­се­ка­ю­щих­ся дан­ных.

Ес­ли ве­сти речь об управ­ле­нии дан­ны­ми, внут­рен­няя раз­ра­бот­ка очень силь­но от­ли­ча­ет­ся от внед­ре­ния го­то­вых па­ке­тов.

ЧТО ДОлж­НО Де­лАТь ПРО­ГРАММ­НОе ОбеС­Пе­Че­НИе

Имея на ру­ках данные, раз­ра­бот­чи­ки долж­ны опи­сать, че­го хо­чет от про­грамм­но­го обес­пе­че­ния биз­нес. Боль­шин­ство гиб­ких ва­ри­ан­тов пред­по­ла­га­ют ис­поль­зо­ва­ние для этих це­лей «поль­зо­ва­тель­ских ис­то­рий» – утвер­жде­ний сле­ду­ю­ще­го ви­да: «Бу­дучи <тип поль­зо­ва­те­ля>, я хо­чу <цель> в си­лу <ра­зум­ная при­чи­на>». На­при­мер, «Бу­дучи спе­ци­а­ли­стом по те­ле­фон­но­му мар­ке­тин­гу, я хо­чу на­кап­ли­вать и хра­нить ин­фор­ма­цию о кли­ент­ских до­мо­хо­зяй­ствах, с тем что­бы зво­нить толь­ко тем лю­дям, ко­то­рые, воз­мож­но, за­хо­тят при­об­ре­сти про­да­ва­е­мый мной про­дукт».

Имей­те в ви­ду: внед­ряя си­сте­му CRM, вы от­ни­ма­е­те у всех вре­мя и раз­дра­жа­е­те биз­нес-ме­не­дже­ров, на­ста­и­вая на по­лу­че­нии от них со­от­вет­ству­ю­щей ин­фор­ма­ции. Ес­ли же во внед­ря­е­мой си­сте­ме CRM ин­фор­ма­ция обо всех ти­пах кли­ен­тов не хра­нит­ся, ни­ка­кой поль­зы от та­кой си­сте­мы не бу­дет.

При внед­ре­нии По COTS или SaaS обыч­но воз­ни­ка­ет спор о том, сле­ду­ет ли внед­рять его

«в том ви­де, в ка­ком оно есть», или же пол­но­стью адап­ти­ро­вать к биз­нес-про­цес­сам ком­па­нии. Но спо­рить тут со­вер­шен­но не о чем.

Про­грамм­ное обес­пе­че­ние по­став­ля­ет­ся с яв­ны­ми или под­ра­зу­ме­ва­е­мы­ми вер­си­я­ми биз­нес-про­цес­сов, ко­то­рые в од­них слу­ча­ях су­ще­ствен­но пре­вос­хо­дят те, что ис­поль­зу­ют­ся в на­сто­я­щее вре­мя на пред­при­я­тии. А в дру­гих слу­ча­ях – нет.

Те, кто ра­ту­ет за адап­та­цию (по­то­му что ИТ долж­ны сде­лать всех «внут­рен­них кли­ен­тов» счаст­ли­вы­ми), лоб­би­ру­ют, по су­ти, боль­шие де­неж­ные за­тра­ты на По, в ко­то­ром будут ре­а­ли­зо­ва­ны уже име­ю­щи­е­ся биз­нес-про­цес­сы.

огром­ные рас­хо­ды и ни­ка­ких улуч­шений с точ­ки зре­ния биз­не­са. За­чем?

При внед­ре­нии си­сте­мы без из­ме­не­ний биз­нес-про­цес­сы, есте­ствен­но, будут от­ли­чать­ся, но не по­то­му, что так сло­жи­лось у раз­ра­бот­чи­ков, а по­то­му, что так долж­но быть.

од­на­ко ес­ли ва­ша ком­па­ния яв­ля­ет­ся луч­шей в сво­ем биз­не­се, то, внед­ряя про­ект без из­ме­не­ний, вы вы­би­ра­е­те в ка­че­стве стра­те­гии пред­на­ме­рен­ное ухуд­ше­ние биз­не­са.

Ко­гда ИТ-служ­ба и биз­нес-под­раз­де­ле­ния на­чи­на­ют спо­рить о том, сле­ду­ет ли внед­рять про­ект без из­ме­не­ний или же пол­но­стью адап­ти­ро­вать его, ни­че­го хо­ро­ше­го в этом нет. И та­кой спор сле­ду­ет сра­зу пре­кра­тить.

ДВУх­эТАПНый ПРО­еКТ COTS

Ко­гда биз­нес, а не ИТ-под­раз­де­ле­ние, внед­ряя

COTS, вно­сит в свою де­я­тель­ность на­ме­рен­ные кор­рек­ти­вы, уси­лия раз­би­ва­ют­ся на два эта­па: сде­лать про­грамм­ное обес­пе­че­ние при­ем­ле­мым для се­бя и оп­ти­ми­зи­ро­вать биз­нес.

Пер­вым эта­пом мож­но управ­лять с по­мо­щью ма­ло­из­вест­ной agile-ме­то­до­ло­гии Conference Room Pilot (CRP). Вот как это ра­бо­та­ет.

Сна­ча­ла ос­нов­ные данные (кли­ент­ские данные, данные о про­дук­тах и пр.) за­гру­жа­ют­ся в ба­зу дан­ных но­во­го па­ке­та. За­тем ру­ко­во­ди­тель про­ек­та в боль­шом за­ле раз­ме­ща­ет мно­же­ство де­мон­стра­ци­он­ных до­сок, боль­ших мо­ни­то­ров и дру­гих ин­те­рес­ных ве­щей. Да­лее в но­вый па­кет за­но­сит­ся мас­са де­ло­вых тран­зак­ций, с тем что­бы обес­пе­чить его со­от­вет­ствие по­треб­но­стям биз­не­са.

Тран­зак­ции эти могут быть ре­зуль­та­том тща­тель­но раз­ра­бо­тан­но­го пла­на те­сти­ро­ва­ния. Или ре­аль­ны­ми тран­зак­ци­я­ми за про­шлый ме­сяц и бо­лее ран­ние периоды. Лю­бой ва­ри­ант ра­бо­та­ет хо­ро­шо.

За­тем в за­ле раз­ме­ща­ем несколь­ко биз­нес­поль­зо­ва­те­лей и ряд гу­ру в области при­ло­же­ний.

Вот что про­ис­хо­дит даль­ше. Биз­нес­поль­зо­ва­тель бе­рет тран­зак­цию, пы­та­ет­ся про­ве­сти ее с по­мо­щью про­грамм­но­го обес­пе­че­ния и объ­яс­ня­ет зна­то­ку при­ло­же­ний, что не мо­жет об­ра­бо­тать ее, по­то­му что… Раз­ра­бот­чик устра­ня­ет на­зван­ную при­чи­ну и пе­ре­хо­дит к сле­ду­ю­щей. Со вре­ме­нем на­хо­дить при­чи­ны ста­но­вит­ся все труд­нее. Про­ис­хо­дит по­сте­пен­ный пе­ре­ход от пер­во­го эта­па ко вто­ро­му.

В про­цес­се пе­ре­хо­да тон раз­го­во­ра ме­ня­ет­ся. Ес­ли на пер­вом эта­пе биз­нес-поль­зо­ва­тель объ­яс­нял, по­че­му не мо­жет вы­пол­нить тран­зак­цию, то на вто­ром го­во­рит, что ее мож­но бы­ло бы вы­пол­нить про­ще, ес­ли бы про­грамм­ное обес­пе­че­ние уме­ло…

Ву­а­ля! Раз­го­вор идет уже не о том, что­бы про­грамм­ное обес­пе­че­ние мог­ло вы­пол­нять воз­ло­жен­ные на него задачи, а о по­вы­ше­нии эф­фек­тив­но­сти про­цес­сов – об оп­ти­ми­за­ции биз­не­са.

И кста­ти, ва­ши раз­ра­бот­чи­ки в хо­де это­го про­цес­са уже не пас­сив­ные ис­пол­ни­те­ли за­ка­за. В лю­бое вре­мя они могут воз­ра­зить, что ме­нять про­грамм­ное обес­пе­че­ние пред­ла­га­е­мым спо­со­бом слиш­ком неудоб­но и до­ро­го. А что, ес­ли пой­ти вот та­ким пу­тем?

НАИТеМНей­шИе СТО­РО­Ны AGILE

У Agile есть недо­стат­ки и по­ху­же, чем бес­по­лез­ность для ре­ше­ния боль­шин­ства

ИТ-за­дач. Гиб­кое про­ек­ти­ро­ва­ние на­прав­ле­но на до­став­ку про­дук­та. Неза­ви­си­мо от то­го, идет ли речь о Scrum, Kanban, Lean или о чем-то еще, про­ект счи­та­ет­ся за­вер­шен­ным по­сле по­став­ки про­грамм­но­го про­дук­та.

Но и при ис­поль­зо­ва­нии Scrum для раз­ра­бот­ки По с ну­ля, и при при­ме­не­нии CRP к го­то­во­му па­ке­ту ко­неч­ная цель со­сто­ит не в до­став­ке про­дук­та, а во внут­рен­них из­ме­не­ни­ях биз­не­са. При­ло­же­ние – это все­го лишь ин­стру­мент, с по­мо­щью ко­то­ро­го биз­нес мо­жет осу­ществ­лять же­ла­е­мые пре­об­ра­зо­ва­ния.

Весь вто­рой этап CRP на­прав­лен на то, что­бы за­ста­вить биз­нес работать луч­ше. Внут­рен­ние из­ме­не­ния биз­не­са за­ло­же­ны в нем из­на­чаль­но.

С дру­гой сто­ро­ны, при­ме­не­ние тех­но­ло­гий agile-раз­ра­бот­ки при­ло­же­ний со­пря­же­но с риском то­го, что из­ме­не­ния биз­не­са оста­нут­ся про­бле­мой ко­го-то дру­го­го, по­сколь­ку це­ли Scrum, Kanban и про­че­го огра­ни­чи­ва­ют­ся до­став­кой про­дук­та.

Нуж­ны технологии, да­ю­щие воз­мож­ность опи­сы­вать, как сде­лать про­цесс луч­ше, пре­вра­щать это опи­са­ние в поль­зо­ва­тель­ские ис­то­рии и до­бав­лять в спи­сок но­вые задачи, поз­во­ля­ю­щие ме­нять биз­нес.

А еще луч­ше, что­бы эти технологии по­мо­га­ли по­сле­до­ва­тель­но и по­сте­пен­но опи­сы­вать улуч­ше­ния биз­не­са в раз­лич­ных областях, ите­ра­ци­он­но вно­сить со­от­вет­ству­ю­щие из­ме­не­ния в при­ло­же­ния и во­пло­щать тем са­мым в жизнь идеи со­вер­шен­ство­ва­ния биз­не­са.

***

Воз­мож­но, «тем­ные сто­ро­ны» Agile по­ка не слиш­ком ак­ту­аль­ны. Но пол­но­стью иг­но­ри­ро­вать их – зна­чит рас­тра­чи­вать ре­сур­сы, за­ни­мать­ся бес­смыс­лен­ны­ми спо­ра­ми и объ­яв­лять успеш­ны­ми про­ек­ты, ко­то­рые на са­мом де­ле обо­ра­чи­ва­ют­ся про­ва­ла­ми, как толь­ко кто­ни­будь по­ин­те­ре­су­ет­ся, стала ли ком­па­ния луч­ше в ре­зуль­та­те их внед­ре­ния.

Newspapers in Russian

Newspapers from Russia

© PressReader. All rights reserved.