- Зависимостите са взаимоотношения на потребности между задачи, оборудване и компоненти, които, ако не се управляват, се превръщат в рискове от забавяне и блокиране.
- Класифицирането и визуализирането на зависимости (матрици, Канбан табла, графици) позволява приоритизиране, координиране на екипи и планиране с по-голяма точност.
- Организациите с мултидисциплинарни екипи, DevOps култура и по-малко междуфункционални екипи намаляват асинхронните зависимости и подобряват времето за пускане на пазара.
- Комбинацията от подходящи инструменти, събития за преглед и добра комуникация е ключова за управление на зависимостите с проактивен подход.
Управлението на зависимостите е един от онези проблеми, с които всеки се бори ежедневно, но малко организации го решават систематично. Когато не се контролира, възникват закъснения, появяват се привидно необясними препятствия, провеждат се извънредни срещи за „гасене на пожари“ и в крайна сметка проектите или закъсняват, или изобщо не пристигат.
Обратно, когато зависимостите са идентифицирани, визуализирани и управлявани ефективно, екипите работят по-автономно , крайните срокове престават да бъдат хазарт и сътрудничеството между отделите става много по-гладко. В тази статия ще разгледаме подробно какви са зависимостите в проектите и дигиталните продукти, различните видове, които съществуват, и как да ги управляваме на практика, използвайки гъвкави подходи, рамки като Kanban и инструменти като Jira или софтуер за управление на проекти.
Какво имаме предвид под зависимост в управлението на проекти и продукти?
В контекста на проектите и разработването на продукти, зависимостта е необходимост между два елемента на работата: задача, екип, технически компонент или дори външен доставчик. За да започне, да напредва или да завърши нещо, първо трябва да се случи нещо друго.
От много практическа гледна точка, зависимостта може да бъде или функционално изискване (например, наличие на пазарска количка на уебсайт), или чисто техническо изискване (наличие на готов API, достъп до среда или внедряване на версия). Дори когато „актьорът“, консумиращ резултата, не е човек, а друга услуга, ние все пак я наричаме зависимост.
В управлението на проекти, една задача често се описва като зависима, когато нейното изпълнение е обусловено от завършването, началото или напредъка на друга задача. Ако „Задача Б“ се нуждае от „Задача А“, за да достигне определена точка, за да продължи, тогава имате зависимост.
Зависимостите не са просто неудобство: те представляват реални рискове . Те увеличават вероятността от забавяния, превишаване на разходите и дори отмяна на инициатива, преди тя дори да достигне производствени мощности. По подразбиране всяка зависимост е риск с определена вероятност и въздействие, който трябва да се управлява, а не да се игнорира.
Видове зависимости: пълен преглед
За да се управляват ефективно зависимостите, те първо трябва да бъдат класифицирани и наименувани . В литературата за управление на проекти и практиката с продукти обикновено се разграничават няколко оси: според тяхната природа (логическа, ресурсна, външна, преференциална), според връзката между задачите и според организационния обхват.
Отдели според техния характер
Логическите или причинно-следствените зависимости са тези, които следват неизбежна последователност от стъпки . Не можете да боядисате стена, ако първо не сте я построили; не можете да тествате функция, ако първо не е била разработена. Те са най-интуитивните.
Ресурсните зависимости възникват, когато множество задачи или проекти се конкурират за един и същ ограничен ресурс : ключов човек, един дизайнер, един екип за back-end, тестова машина и т.н. Напредъкът на работата се определя не толкова от логическия ред, колкото от действителната наличност на тези ресурси.
Предпочитаните зависимости са тези, които произтичат от вътрешни процедури или най-добри практики , но не са строго необходими за завършване на резултата. Например, допълнителен редакционен преглед или допълнителна стъпка за осигуряване на качеството, която екипът решава да запази, защото намалява грешките, въпреки че проектът може официално да бъде „затворен“ без нея.
Външни зависимости възникват, когато екипът е обвързан с фактори, които не контролира : доставчик, който трябва да достави материали, правен отдел, който трябва да одобри договор, метеорологични условия, които влияят на проект, или платежен портал на трета страна, който трябва да сертифицира услугата си.
Зависимости на задачите: класически времеви връзки
Когато се слиза на ниво планиране, зависимостите на задачите обикновено се моделират с четири основни взаимовръзки, които ще видите в графици или диаграми на Гант:
В релация „Завършване-към-старт“ (FS), задачата-наследник не може да започне, докато задачата-предшественик не е завършила. Това е най-често срещаната релация и се използва по подразбиране от повечето инструменти.
В релация „завършен до завършен“ (FF), следващата задача не може да завърши работата си, докато предишната задача също не е завършена . Това често се случва, когато една задача всъщност е сума от няколко взаимозависими подзадачи.
В случай на „Старт-до-старт“ (SS), двете задачи трябва да се активират паралелно . Задачата-наследник не може да започне преди предшественика си, въпреки че след това те продължават със собствено темпо.
Връзката „начало-край“ (SF), по-рядко срещана, но все още съществуваща, предполага, че задача А не може да се счита за завършена, докато не е започнала задача Б. Типичен пример е смяната на смяната в обслужването на клиенти: един човек не може да си тръгне, докато не пристигне следващият.
Вътрешни, външни и междуекипни зависимости
В допълнение към техния характер, е важно да се прави разлика между вътрешни зависимости в рамките на проекта (между задачи или ресурси, които самият екип контролира) и външни зависимости, които зависят от трети страни.
В средни и големи организации, зависимостите между екипите стават все по-важни: когато множество екипи, отдели или доставчици трябва да се координират, за да постигнат споделен резултат. Това включва зависимости между продуктови екипи, между екипи и междуфункционални екипи (HR, Снабдяване, Правен), както и между технически екипи, като например back-end, front-end, мобилни и оперативни.
Проактивно срещу реактивно управление на зависимостите
Начинът, по който една организация се справя със зависимостите, прави разликата между „пожарогасителна“ култура и много по-здравословна среда. Можем да говорим за две основни стратегии : проактивна и реактивна.
Реактивното управление включва реагиране на зависимост само когато тя се разруши : когато липсва разрешение, достъп, компонент или API и екипът е заседнал. Това е типичната ситуация на непрекъснат престой, препланиране в движение и нарушени ангажименти.
Проактивното управление, от друга страна, включва полагане на усилия от самото начало за идентифициране и планиране на зависимости . Нуждите се предвиждат, капацитетът се запазва, ангажиментите между екипите се изясняват и рисковете се идентифицират, преди да се превърнат в проблеми.
Въпреки че винаги ще има реактивен компонент (не можете да предвидите всичко), една здравословна стратегия за управление на зависимостите трябва да има силен проактивен компонент : анализ, приоритизиране, подготовка на алтернативни сценарии и установяване на повтарящи се събития за преглед на състоянието на тези зависимости.
Визуализиране на зависимости: от Канбан до матрици в Jira
Първата сериозна стъпка в управлението на зависимостите е да ги направите видими за всички . Това, което не се вижда, не се управлява; то се претърпява. Тук влизат в действие Канбан практиките, програмните табла и различните визуализации.
В Канбан системата една от основните практики е визуализирането на работата . Това включва ясно обозначаване на това кои задачи зависят от други, както и кои блокират други екипи. Ясното обозначаване на елементите, които „чакат зависимости“, помага за предотвратяване на изненади.
В инструменти като Jira, много практичен подход е да се използва полето за връзки на проблеми, за да се свържат задачи, които се блокират взаимно . Можете да използвате взаимоотношения „блокове“ или „зависимост от“, като разграничавате силни зависимости (които пречат на стартирането на зависимата задача) от по-слаби (които позволяват паралелен напредък, докато другата се решава).
Ако задачата, която трябва да разреши зависимостта, все още не съществува, можете да изберете да маркирате проблема със специфичен маркер, който показва тази нерешена нужда. Този етикет ще ви позволи да групирате и показвате тези нерешени зависимости в панели, пътни карти, изоставания или табла.
С тази информация е възможно да се изгради матрица на зависимостите, където едното измерение представлява екипите или отрядите на организацията , а другото представлява времевата линия. Това показва кой от кого зависи и кога, улеснявайки разпределението на капацитета и договарянето на приоритети.
Преди широкото разпространение на дистанционната работа, тези матрици често се рисуваха на физически дъски. Днес, плъгини и модули на Jira, като Advanced Roadmaps, BigPicture и Structure, позволяват визуално представяне на тези мрежи от зависимости в хибридни или напълно отдалечени среди.
Класове за резервация и табло за резервации в Канбан
След като имате глобален поглед върху зависимостите на продуктово или организационно ниво, можете да направите още една крачка напред и да приложите концепцията за класове за резервация от метода Канбан, за да присвоите различни нива на обслужване на разрешаването на зависимости.
Класът за резервация се използва за класифициране на работата според приоритет, спешност или необходимо време за доставка. За да се използва този подход със зависимости, се използва календар за разпределяне на капацитетни слотове, предназначени за тяхното разрешаване, независимо дали по дни, седмици или итерации (например спринтове в Scrum екипи).
Обикновено има три основни вида резерви. Първо, има гарантирани ресурси, които имат специално резервиран капацитет , за да се гарантира, че при необходимост ще бъдат налични на определена дата. Те обикновено съответстват на непредвидени, но критични задачи.
Второ, резервирани зависимости: това са задачи, които вече имат определен срок за изпълнение. Те често се използват за силни зависимости, чието разрешаване позволява на друг екип да започне работа.
Накрая, зависимостите в режим на готовност попадат в категория, където ще бъдат разгледани само ако има достатъчен капацитет . Това обикновено са зависимости, които могат да бъдат временно избегнати, отложени, докато се постигне напредък по други части от работата.
Този модел много наподобява начина, по който авиокомпаниите управляват билетите си: има много скъпи гарантирани места, стандартни резервации и билети в списъка на чакащите, които зависят от това да няма свръхрезервации. Мястото в списъка на чакащите може дори да промени статуса си с течение на времето , преминавайки от „в списъка на чакащите“ към „резервирано“ или „гарантирано“, когато наближи целевата дата и рискът се увеличи.
Събития за преглед на зависимостите и координиране на екипите
Наличието на табло за резервации или матрица на зависимостите не е достатъчно, ако не е интегрирано в редовните ритуали за преглед . От решаващо значение е в рамките на текущия работен процес да има поне едно събитие, където тези зависимости се преглеждат и се правят корекции.
Не е задължително да е нова среща; тя може да бъде интегрирана като фиксирана точка в дневния ред на съществуващи срещи: например, в среща за планиране на итерации, в планиране на PI в стил SAFe или в сесия за координация между екипите.
Наистина важното е всички страни, участващи в създаването и разрешаването на зависимости, да присъстват по време на този преглед . Без този разговор лице в лице (или екран до екран) е лесно да възникнат фалшиви очаквания, едностранни ангажименти и обещания, които не могат да бъдат спазени.
Добри и лоши зависимости: синхронни и асинхронни
Може да звучи нелогично, но не всички зависимости са лоши. Някои зависимости насърчават здравословното сътрудничество , докато други създават изолации и постоянно триене. Полезен начин да се прави разлика между тях е да се говори за синхронни и асинхронни зависимости.
Асинхронните зависимости са тези, при които екипите не работят едновременно или с различна честота. Scrum екип, който възнамерява да интегрира в текущия си спринт разработка, която друг екип ще направи в следващия спринт, или спешна заявка за достъп до ресурс, който зависи от трети, претоварен екип, са примери за проблемни асинхронни зависимости.
Синхронните зависимости, от друга страна, възникват, когато работата се извършва в рамките на един и същ период от време . Например, няколко екипа споделят среда за разработка и тестване или обща софтуерна библиотека, отворена за приноси от всеки разработчик в компанията.
Тези видове зависимости насърчават хората да си сътрудничат активно и да споделят контекст . Без тях би било по-лесно за всеки екип да се изолира в собствения си силоз. А силозите, освен че ограничават цялостната перспектива, са склонни да подкопават емпатията между отделите и да усложняват вземането на решения на организационно ниво.
Дългосрочната стратегия трябва да има за цел да минимизира асинхронните зависимости и да подобри синхронните, като предпочита екипи с по-голяма автономност от край до край и по-отворени практики за сътрудничество.
Проектиране на организации и екипи за намаляване на зависимостите
Организационната структура влияе пряко върху броя и вида на зависимостите. С разрастването на продукта и умножаването на екипите се появяват повече триене, припокривания и пречки . Обикновено проблемите започват да се появяват още с два екипа и се засилват с всеки нов създаден екип.
Във вертикално интегрираните, продуктово ориентирани организации, целта обикновено е да се създадат мултидисциплинарни екипи, които са възможно най-автономни , в съответствие с топологията на „екипи, подредени по поток“, описана в „Топологии на екипи“. Тези екипи са отговорни за бизнес домейн или поддомейн от началото до края.
Дори и с автономни екипи, все още са необходими лостове за съгласуване , за да се гарантира съгласуваност на продуктите и да се предотврати прекъсването на екипното сътрудничество: глобални арбитражни случаи на пътни карти, съвместни събития за планиране, вдъхновени от PI Planning, програмни табла, които визуализират зависимости, споделени системи за проектиране и общности от практикуващи, наред с други механизми.
На практика много компании се оказват с хибридни модели, където не всички умения могат да бъдат намерени във всеки екип . Появяват се междуфункционални екипи, обхващащи продуктов дизайн, данни, QA, мобилни устройства, бекенд или операции, които обслужват множество продуктови екипи, въвеждайки допълнителни зависимости, които трябва да бъдат управлявани ефективно.
Отдели с междуфункционални екипи: Човешки ресурси, Покупки, Правен…
В допълнение към техническите области, много екипи разчитат на междуфункционални корпоративни екипи, като например отдел „Човешки ресурси“, „Снабдяване“ или „Правен отдел“. Тези зависимости често се проявяват като ключови назначения, изграждане на капацитет чрез външни доставчици, управление на бюджета или правни прегледи.
Когато даден отбор трябва да подпише или подсили състава си и не контролира този поток , времето му за пускане на пазара е засегнато и предвидимостта страда. Могат да се задействат няколко лоста за смекчаване на тези ситуации.
Един от вариантите е да се делегират определени дейности, традиционно управлявани от отдел „Човешки ресурси“ или „Покупки“, на екипи (например част от процеса на подбор или оперативните взаимоотношения с доставчиците), с ясно управление, но по-малко бюрокрация.
Друг начин е да се договорят бюджетите за услуги, така че всеки екип да има автономна свобода на действие относно това кои профили или услуги да наеме и кога, в рамките на договорените ограничения.
Възможно е също така да се използва периодичното интегриране на експерти по човешки ресурси, покупки или правни въпроси в екипите, за да се ускори вземането на критични решения , особено по време на силен растеж или важни стратегически промени.
Типични технически зависимости: back-end, операции и мобилни устройства
На по-техническо ниво има три особено често срещани източника на зависимости: отделни бек-енд екипи , изолирани оперативни (Ops) екипи и независими мобилни екипи.
Когато централизиран back-end екип обслужва множество front-end екипи, това създава трудни за управление взаимоотношения между клиент и доставчик . Back-end екипът трябва да изгражда API за всички, да балансира външните приоритети, които не контролира, и да издържа на натиска. Междувременно продуктовите екипи изпитват закъснения и чувство на неудовлетвореност от това, че не знаят кога необходимите им възможности ще бъдат готови.
Като палиативни мерки, back-end разработчиците могат да бъдат временно интегрирани в екипи , могат да се дефинират ясни интерфейсни договори между back-end и front-end или могат да се развият микросървисни архитектури, където всеки екип е отговорен за собствените си услуги, приемайки, че ще се появят нови зависимости, но много по-управляеми.
В случая с оперативните екипи, зависимостта обикновено е концентрирана върху управлението на средата и внедряването . Екипите завършват разработката си, но се нуждаят от оперативни екипи, които да ги внедрят във всяка среда. Ако оперативният отдел е претоварен, изданията се натрупват, приоритизирането им се осъществява непрозрачно и рискът от закъсняло или прибързано доставяне се увеличава.
За да се подобри тази област, може да се внедри визуално управление на потока от доставки тип Kanban, потребителски истории, специфични за изискванията на Operations, могат да бъдат интегрирани в натрупаните задачи на екипите, и могат да се предложат „фабрики за софтуер като услуга“, които автоматизират голяма част от процесите.
Въпреки това, наистина значителният скок идва, когато се възприеме зряла DevOps култура , където разработката и операциите си сътрудничат тясно, тестването и внедряването са автоматизирани и екипите имат възможността безопасно да внедряват промените си в производство.
Нещо подобно се случва и с независимите мобилни екипи: техните силно специфични умения (iOS, Android, мобилен дизайн, насоки за платформата) карат много организации да ги групират в един екип, който в крайна сметка обслужва множество отряди. Това създава опашки, сложно приоритизиране и пречки, когато всички екипи едновременно изискват мобилни промени.
Една възможна стратегия е тези мобилни екипи да се поддържат с логика на екипа на изследователите , която да съпътства отрядите, моделите за маркиране, компонентите за многократна употреба и добрите практики, и да се разпусне тази единица, когато мобилният функционален обхват достигне този на уеб версията.
Управление на софтуерните зависимости: библиотеки, рамки и сигурност
Отвъд организацията, в разработката на софтуер думата „зависимост“ обикновено се отнася до външни библиотеки, рамки и компоненти , от които приложението ви се нуждае, за да функционира. Тук говорим за мениджъри на зависимости като Maven, Gradle, npm или Composer.
Лошото управление на тези зависимости може да доведе до конфликти на версии , проблеми с интеграцията, трудности при дългосрочна поддръжка или уязвимости в сигурността. Ето защо е толкова важно да се използват инструменти, които автоматизират изтеглянето, разрешаването на версии и контролираните актуализации.
Препоръчително е зависимостите да се поддържат сравнително актуални , като се търси баланс между сигурност и стабилност. Натрапчивите актуализации могат да доведат до неочаквани грешки, но редките актуализации правят проекта уязвим към известни уязвимости или злонамерени версии на npm.
Добра практика е също така да се минимизира броят на зависимостите: преди да добавите нова библиотека, си струва да се запитате дали тя наистина добавя стойност или е нещо, което може да се обработва по-лесно. Всяка добавена зависимост означава повече повърхност за поддръжка, потенциални конфликти и в много случаи влияние върху производителността.
Всичко това трябва да бъде придружено от ясна документация за това кои зависимости се използват, с кои версии и за каква цел, както и стриктно автоматизирано тестване, за да се провери дали дадена актуализация не нарушава съществуващата функционалност. Инструментите за анализ на сигурността също помагат за откриване на известни уязвимости в добавените зависимости.
Практически съвети за управление на зависимости в проекти
В ежедневното управление на проекти съществуват редица практики, които значително улесняват контрола върху зависимостите . Няколко инструмента (Asana, Wrike, Jira и др.) са единодушни в препоръчването на определени подходи.
Първо, от решаващо значение е да организирате задачите в надежден инструмент за управление на проекти , който ви позволява да моделирате зависимостите между задачите, да визуализирате времеви рамки и бързо да виждате какво е блокирано и защо. Това намалява риска от пропускане на важни връзки.
Ясното визуализиране на зависимостите, използвайки диаграми на Гант, пътни карти или Канбан дъски , също е много полезно . Виждането на реда на изпълнение и точките на блокиране помага на екипа да разбере по-добре защо определени задачи идват преди или след тях и как те влияят на колегите им.
Друг критичен аспект е наблюдението на потенциалните рискове, свързани със зависимости. В началните фази на плана на проекта е препоръчително да се проведе брейнсторминг на специфични рискове от зависимости : претоварване на ключов персонал, външни доставчици, висящи разрешителни или неприети бизнес решения.
И накрая, откритата комуникация между заинтересованите страни е от съществено значение. Комуникацията никога не е излишна, когато се работи със зависимости: ако някой знае, че ще се забави по задача, от която зависят други, най-добре е да го уведоми възможно най-скоро, за да могат всички останали да коригират плановете си и да избегнат тежки последици.
Влияние на зависимостите върху успеха на проекта
Овладяването на управлението на зависимостите има пряко въздействие върху успеха на проекта. От една страна, то позволява по-цялостен контрол и по-информирано стратегическо планиране , тъй като ръководителят на проекта може да види как всички части се съчетават и да определи реалистична работна поръчка.
От друга страна, това значително подобрява управлението на времето и предотвратяването на забавяния . Чрез разбирането на критичните последователности от задачи и зависимости, крайните срокове могат да бъдат коригирани по-точно, наистина критичните задачи могат да бъдат приоритизирани и последствията от преместването на задача могат да бъдат незабавно открити.
Освен това, доброто управление на зависимостите помага за намаляване на грешките и оптимизиране на ресурсите . То избягва дублирането на усилия, минимизира ненужната преработка и създава ред на изпълнение, който ограничава маржа за скъпоструващи грешки.
Всичко това води до по-голяма гъвкавост и адаптивност: когато промените са неизбежни, наличието на ясна карта на зависимостите ви позволява да реорганизирате плана с по-малко страдание , да предвиждате въздействията и да преконфигурирате приоритетите с повече преценка.
Като цяло, ефективното управление на зависимостите между задачи, екипи и технически компоненти се превръща в ключов фактор за успех както в еднократни проекти, така и в непрекъснатото разработване на сложни дигитални продукти. Организациите, които дават приоритет на автономните екипи, ясната визуализация, ритуалите за координация и силната техническа култура, намаляват пречките, подобряват времето за пускане на пазара и позволяват на екипите си да работят с по-малко триене и по-голям фокус върху предоставянето на реална стойност на крайния потребител.
