не рабі нічога без выразнай мэты

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

Калі ў вас няма яснай мэты і вы робіце нешта толькі таму, што гэта робяць усе астатнія, ці ўсё кажуць, што гэта важна, то:

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

Прыклад: партфоліо і праграмы

Калі вы ўдзельнічаеце ў адборы і запуску праектаў, пераканайцеся, што вы сканцэнтраваны на развязальных праблемах і ствараемых перавагах, а не на тэхнічных рашэннях. Класічным прыкладам з’яўляецца вытворца ліфтаў, які атрымліваючы скаргі на хуткасць сваіх ліфтаў, запусціў некалькі праектаў па павелічэнні хуткасці без асаблівага поспеху. Гэта працягвалася да таго часу, пакуль яны не вырашылі засяродзіцца на праблеме (нуда або дыскамфорт людзей) замест «натуральнага» рашэння (больш хуткія ліфты). У выніку яны дадалі люстэрка ў ліфты, і гэта вырашыла праблему проста і танна.

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

Прыклад: праект у цэлым

Гнуткасць прадукту вар’іруецца паміж праектамі. У некаторых праектах па развіццю ІТ прадукт з’яўляецца цалкам гнуткім, і яго канчатковая форма залежыць ад зваротнай сувязі, якая будзе генеравацца па инкрементам прадукту ў ходзе праекта, што патрабуе прымянення адаптыўнага (гнуткага) падыходу. На практыцы гэта камбінацыя узроўняў партфеля, праграмы і праекта і патрабуе максімальнай увагі да канчатковай мэты. Рэкамендуецца задакументаваць мэта і зрабіць яе даступнай; гэта адна з мэтаў «бачання прадукта», якое выкарыстоўваецца ў некаторых праектах Scrum. Увага да кошту бізнесу ў Agile праектах - гэта іх спосаб забяспечыць адпаведнасць мэты.

У іншых тыпах праектаў, дзе прадукт з’яўляецца адносна фіксаваным і існуюць іншыя механізмы, якія гарантуюць, што канчатковы прадукт будзе задавальняць мэты, члены праектнай каманды могуць перанесці большую частку сваёй увагі з мэты на прадукт (такім чынам, прынцып «засяродзіць увагу на прадуктах» (PRINCE2^®)), але ўсё ж патрабуецца па меншай меры мінімальнае увагу мэты, каб гарантаваць, што тое, што будуецца, будзе адпавядаць мэты, што можна зрабіць шляхам параўнання прагназуемых выгад з чаканымі (прынцып «пастаянная ацэнка мэтазгоднасці» і тэма «эканамічнае абгрунтаванне» у PRINCE2^®).

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

Прыклад: маніторынг праекта

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

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

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

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

Прыклад: дакументы

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

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

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

Пошук «шаблону» - гэта супрацьлегласць таму, каб рабіць нешта на аснове мэты.

Прыклад: статус-справаздачы

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

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

Аднак, калі вы рыхтуеце аднастаронкія справаздачы, некаторыя людзі могуць пярэчыць і думаць, што ў вас няма «належнай» сістэмы маніторынгу. На практыцы гэта стварае для вас другую мэту (акрамя першай мэты - дапамагчы зацікаўленым бакам зразумець статус праекта), і каб задаволіць яе, вы можаце проста стварыць другі тып справаздачы, які будзе вельмі доўгім. Пры гэтым вы не будзеце змешваць яго з першым справаздачай, таму што гэтыя дзве мэты не супадаюць.

Прыклад: бізнес-кейс і статут праекта

Падрыхтоўка дакументаў, такіх як бізнес-кейс і статут праекта, звычайна з’яўляецца сумнай, бясплоднай, бюракратычнай неабходнасцю, у той час як усе гэтыя дакументы маюць абгрунтаванне і дастасавальныя да большасці праектаў. Калі вы паспрабуеце знайсці «шаблон» і запоўніць яго, праца будзе проста зроблена марна; тым часам як вы можаце замест гэтага праверыць рэальнае прызначэнне гэтых дакументаў, паглядзець, ці могуць яны дапамагчы ў вашым праекце і якім чынам яны могуць дапамагчы, а затым падрыхтаваць дакумент так, як вам падабаецца, проста для дасягнення гэтых мэтаў: гэта будзе правільны дакумент.

Пакуль вы думаеце пра тое, як падрыхтаваць дакументы для дасягнення іх мэтаў, вы забыцца разгледзець усе варыянты. Каб пазбегнуць гэтага, вы можаце праверыць, што прапануюць PRINCE2^®, PMBOK^® Guide, P3.express і DSDM^®, а затым ацаніць гэтыя варыянты ў залежнасці ад мэтаў.

Прыклад: пост-праект

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

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

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

Прыклад: прастата

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

Прыклад: адаптацыя

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

▼ PDF