Распрацоўка праграмнага забеспячэння :: Калі вы не кантралюеце змены, вы не кантралюеце бюджэт

Бюджэт не азначае абмежавання змен

З чаго пачынаецца большасць праектаў па распрацоўцы праграмнага забеспячэння

Большасць запытаў, звязаных з праграмным забеспячэннем, пачынаецца з аднаго і таго ж месца. Арганізацыя мае існуючы працэс, нярэдка нешта, што развівалася з цягам часу, і хоча ператварыць яго ў зручны дадатак, які паляпшае эфектыўнасць, бачнасць і кантроль.

На першы погляд гэта гучыць проста. Працэс ужо існуе, таму мяркуецца, што яго можна проста перанесці ў праграмнае забеспячэнне. У многіх выпадках гэта так. Калі бізнес разумее працэс і можа дакладна яго задакументаваць, вы ўжо на стартавай лініі.

З пункту гледжання кіраўніцтва гэта павінна ўспрымацца як пазіцыя кантролю. Арганізацыя ведае, што яна робіць, як яна працуе і чаго яна чакае ад сістэмы.

Калі працэс становіцца бачным

Складанасці пачынаюцца, калі гэты працэс пачынае набываць форму ўнутры сістэмы.

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

На гэтым этапе нават простыя з выгляду змены патрабуюць разгляду з кожнага вугла і на кожным этапе працэсу. Тое, што здаецца нязначным у ізаляцыі, можа мець больш шырокія наступствы, асабліва там, дзе задзейнічаны некалькі роляў, рашэнняў і залежнасцей.

На чым засяроджваюцца зацікаўленыя бакі і чаго патрабуе арганізацыя

Пры добра структураванай пастаўцы праграмнага забеспячэння акцэнт робіцца на тым, што найважнейшае для арганізацыі, а не толькі на тым, чаго просяць зацікаўленыя бакі. У многіх выпадках гэта ўключае аўдытаздольнасць, якая мае вырашальнае значэнне для арганізацыі, але нярэдка ігнаруецца на карысць дадатковага функцыяналу.

Зацікаўленыя бакі натуральным чынам засяроджваюцца на тым, чаго яны хочуць ад сістэмы. Яны рэдка засяроджваюцца на тым, як гэтыя змены павінны быць укаранёны, зафіксаваны і кіравацца пасля ўводу сістэмы ў эксплуатацыю.

Чаму невялікія змены не з'яўляюцца невялікімі

Гэта мяняе характар нават самага простага запыту. Невялікая карэкціроўка — гэта ўжо не проста тэхнічная змена, яна становіцца часткай кантраляванага і адсочванага працэсу. У выніку тое, што здаецца нязначным, можа мець значна большы ўплыў, калі ўлічваюцца адпаведнасць патрабаванням, адказнасць і аператыўная бачнасць.

Кантроль вызначае вынік

Калі змена не кантралюецца, вынік таксама не кантралюецца.

Тое, што пачынаецца як дакладна акрэсленая ініцыятыва, можа хутка ператварыцца ў нешта зусім іншае — не з-за дрэнных намераў, а з-за адсутнасці структуры вакол прыняцця рашэнняў у ходзе развіцця сістэмы. Выдаткі не толькі фінансавыя. Яны вымяраюцца ў часе, складанасці, аперацыйных перабоях і страце яснасці.

Менавіта тут многія арганізацыі губляюць кантроль, не ўсведамляючы гэтага.

Яны лічаць, што кіруюць пастаўкай, тады як на самой справе кірунак сістэмы паступова фарміруецца неадмераванымі зменамі.

Менавіта тут і дзейнічае Libertas Software Research.

Не проста ў пабудове сістэм, а ў тым, каб гэтыя сістэмы заставаліся ўзгодненымі з арганізацыяй у ходзе іх развіцця. Гэта азначае стварэнне структуры вакол змен, забеспячэнне бачнасці іх уздзеяння і гарантыю таго, каб кожнае рашэнне разумелася ў кантэксце кошту, часу і доўгатэрміновай эксплуатацыі.

Пытанне не ў тым, адбудуцца змены ці не.

Яны адбудуцца.

Пытанне ў тым, хто іх кантралюе.

PrimeCRM