выкарыстоўвай прайграваныя элементы

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

Прыклад: чэк-лісты якасці

Чэк-ліст - гэта просты прыклад патэнцыйна паўтараюцца элементы, які многія людзі выкарыстоўваюць і ў асабістай і прафесійнай жыцці. Вазьміце, напрыклад, крытэрыі якасці прадукту:

• па-першае, вы можаце стварыць спіс усіх крытэрыяў, што ўжо з’яўляецца формай планавання.
• NUP6 рэкамендуе паспрабаваць абагульніць іх: ці ёсць іншыя падобныя прадукты ў праекце? У такім выпадку зрабіце агульны чэк-ліст якасці для гэтай катэгорыі прадуктаў. Калі магчымыя варыяцыі, захавайце агульны спіс і дадайце некалькі дадатковых элементаў для асобных прадуктаў. Зараз у вас ёсць прайграваным чэк-лісты.
• пасля таго, як вы падрыхтуеце агульныя чэк-лісты для розных тыпаў прадуктаў, вы можаце знайсці паўтараюцца пункты і зрабіць для іх віртуальную бацькоўскую катэгорыю. У гэтым выпадку замест паўтарэння элементаў для ўсіх гэтых агульных кантрольных спісаў вы можаце атрымаць іх і змясціць у бацькоўскі чэк-ліст. У канцы ў вас, верагодна, будзе адзіны агульны кантрольны спіс для ўсяго праекта. «Definition of Done» у Scrum з’яўляецца прыкладам выкарыстання чэк-лістоў на ўзроўні праекта для праверкі якасці (магчыма, сярод іншага). Такім чынам, кожны вынік будзе належаць іерархіі катэгорый і павінен задавальняць элементам, якія з’яўляюцца ў кантрольных спісах ўсіх катэгорый у іх ланцужку.

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

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

Прыклад: працэсы і працоўныя працэсы

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

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

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

Прыклад: цыклы

Карысна выкарыстоўваць прайграваным элементы для кіравання праектам. Гэта можа быць зрабіць яшчэ прасцей, калі размяшчалі іх у паўтараюцца цыклы. Гэтыя цыклы значна спрашчаюць паўсядзённае працу людзей, уцягнутых у кіраванне і кіраўніцтва праектам. Цыклы груп працэсаў у Кіраўніцтве PMBOK^® пры выкарыстанні ў праекце з некалькімі фазамі, этапамі ў PRINCE2^®, штодзённымі, штотыднёвымі і штомесячнымі цыкламі ў P3.express, ітэрацыі і часовымі рамкамі ў DSDM^® і спрынце ў Scrum з’яўляюцца прыкладамі гэтай канцэпцыі.

Больш за кароткія цыклы лягчэй зразумець і выкарыстоўваць, чым больш доўгія; напрыклад, спрынты ў Scrum ў параўнанні з фазамі з кіраўніцтва PMBOK^®. Аднак занадта кароткія цыклы падыходзяць не для ўсіх тыпаў праектаў, рашэннем можа быць выкарыстанне спалучэння некалькіх тыпаў цыклаў, напрыклад кароткія таймбоксы ў спалучэнні з больш доўгімі ітэрацыі ў DSDM^®, або выкарыстанне штодзённых, штотыднёвых і штомесячных цыклаў ў P3.express.

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

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

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

▼ PDF