Блуканне ў лабірынце некалькіх дошак JIRA: дапаможнік для каманд распрацоўкі праграмнага забеспячэння

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

Каб працаваць эфектыўна, вы вырашаеце наладзіць у JIRA некалькі дошак — па адной для кожнай ролі: уладальнікаў прадукту (PO), кіраўнікоў праектаў (PM), дызайнераў і распрацоўшчыкаў. На паперы гэта выглядае ідэальным рашэннем. Але па меры развіцця праекта вы пачынаеце заўважаць і складанасці, і магчымасці, якія нясе такая схема.

Навошта некалькі дошак?

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

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

Плюсы: яснасць і засяроджанасць

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

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

Мінусы: складанасць і ізаляцыя

Але ў такога падыходу ёсць і недахопы. Першая праблема — каардынацыя. Калі дошак шмат, каб усе былі на адной хвалі, даводзіцца працаваць на поўную стаўку. Што рабіць, калі затрымка на дошцы дызайну зрывае тэрміны распрацоўкі? Як пераканацца, што PO і PM ведаюць пра змены прыярытэтаў у розных камандах?

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

Як знайсці баланс

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

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

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

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

Галоўны вынік

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

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