Публикувано на: 15 ноември, 2024Работното място се състои от хора, а хората са сложни по природа. И въпреки че споровете не трябва да са част от работния процес, това изобщо постижимо ли е? Номерът е да открием проблемите и да намерим структурирани решения за тях, като същевременно следваме установените процеси. Решенията трябва да са насочени към спестяване както на ресурси, така и на нерви, както и да следват общата цел.
Известният сблъсък между продуктовите хора (продуктови мениджъри, Product Owners, и т.н.) срещу програмисти често се случва поради различни гледни точки и води до конфликти по време на процеса на разработка.
Ето някои примерни спорове, с които вероятно сте запознати, и решенията, които използват в Cognyte.
„Открих бъг!“
Винаги искаме нещата да работят по-добре и често имаме мнение за това кое всъщност е „по-добре“. Но това не означава непременно, че нашият начин е правилният или че нещата са изглеждали по същия начин, когато някой е взел решението как да работят.
Product Owner: QA, моля да отвориш бъг за този feature, счупен е! Трябва да работи ето така.
QA: Работи точно както е поискан и документиран.
Product Owner: Окей, но така ще работи много по-добре за потребителите ни. Не можем ли да го оправим?
Програмист: Разбира се, че можем, но няма да е „оправяне“, тъй като не е бъг – работи както се очаква и е изискано. Можем да отворим User Story, да го обсъдим при следващия sprint и да го имплементираме в по-следващия.
Product Owner: Очаквах да стане готово следващата седмица, не следващата година…
Всички сме били там. Може да мислите, че нещо не работи както трябва, но дори и да накарате всички да се съгласят с вас, това, че не сте доволни как работи в момента, не значи, че някога не е било договорено и планирано точно така.
Какво да направим?
Всяка промяна идва с определена цена, а тя невинаги е лесна за определяне. Само хората, които имат цялостно разбиране за това как функционира системата и за тежестта и ефектите, които би имала една промяна, могат да определят усилието, което тя би коствала на екипа. И дори тогава няма гаранции.
Затова, след като се извърши тази оценка, в крайна сметка винаги е въпрос на приоритети, за които продуктовият човек трябва да вземе окончателното решение.
Loading …„Малък feature е“
Някои продукти може да бъдат сложни. Особено в случаи, при които става дума за много компоненти в микросервизна архитектура, понякога привидно малки подобрения могат да излязат доста скъпо.
Product Owner: Ето го новия feature, хайде да изчислим колко време ще отнеме.
Scrum екип: Няма как да очакваш това наистина да е едно User Story и да влезе в един sprint, нали?
Product Owner: Буквално изисква няколко промени на една страница, какво толкова?
Програмист: За да направим тези промени трябва да рефакторираме 3 различни компонента, QA-ите да си пренапишат всички тест кейсове, да направим performance тестове, тъй като данните се агрегират от няколко различни източника. А, да, и един от тези компоненти дори не е наш…
Product Owner: Ама това е една страница!!!
Всички сме чували за „малкия feature“. И може би ние наистина го виждаме като такъв, тъй като на повърхността докосва само няколко елемента, но не го подценявайте – не знаете какво се крие под водата.
Какво да направим?
Предположенията ни помагат да вземаме решения по-бързо, но в крайна сметка те са просто това – предположения. Така че, преди да стигнете до заключението, че нещо е очевидно лесно, винаги е по-добре да седнете на масата с нужните експерти и да чуете те какво имат да кажат. Информираното решение винаги е по-доброто решение.
„Моето решение е по-добро!“ – рунд първи
Случвало ли ви се е да спорите за даден feature, защото предложеното решение просто не е добро?
Програмист: По този начин ще стане много по-добре! Много по-смислено е да използваме функционалност, която вече имаме наготово, вместо да пишем всичко от нулата.
Product Owner: На теб може да ти звучи по-логично, но ти ли си крайният потребител? Въпреки че така ще е по-лесно и по-смислено за теб, ще бъде много по-сложно за потребителя да го използва или дори да го разбере.
Всеки има мнение кой-подход е по-добър, но как да определим чие решение е правилното?
Какво да направим?
Много пъти няма едно правилно решение, важно е каква е крайната цел. Трябва да запомните, че е отговорност на Product Owner-ите да донесат най-голяма стойност на клиентите.
За да се случи това, те се консултират с множество заинтересовани страни – програмисти, UX дизайнери, продажби и акаунт мениджъри, customer support и т.н. Съответно и те носят риска, ако решението се окаже грешно. Така че, когато вашето решение изглежда по-логично, замислете се дали имате пълната картина.
Explore more
„Моето решение е по-добро!“ – рунд втори
Винаги искаме нещата да са страхотни, но не може ли понякога единствено… да са простички?
Product Owner: UX-ърът е готов с новия feature, ще ви хареса, изглежда страхотно!
Програмист: Наистина изглежда страхотно, но искаше да направим MVP за този feature възможно най-бързо, а ни се сервира UI дизайн, който ще отнеме седмици! Не може ли да използваме простички компоненти, които вече имаме готови, за да го накараме да работи, а да го разкрасим така за следваща итерация на feature-a?
Product Owner: Няма време да се прави нов дизайн, опитайте се да го имплементирате така за този sprint!
Знаем, че винаги искате да бъдете похвалени за вашето IT творение, но невинаги е разумно да очаквате и изисквате само най-доброто.
Какво да направим?
Добре е да има прозрачност през всички етапи на процеса, така че хората, които всъщност ще вършат работата, имат думата да споделят кога нещо има смисъл и кога не.
В този случай нуждата да се разработи MVP, което просто трябва да върши работа на клиента, и отделянето на ресурси, за да се направи да изглежда като произведение на изкуството, просто си противоречат. Често, стига да не ви е цел да се провалите, има смисъл да се вслушате в хората, които най-добре могат да преценят дали изискванията са разумни, или не.
„Не променяме обхвата“
Когато се появи ново предложение за подобрение на feature, Product Owner-ът може да се вглъби в добре звучащата идея сякаш е задължителна част от feature-a.
Междувременно за тези, които в момента го имплементират, идва като неочаквано разширяване на обхвата. Това е като да се опитате да добавите нови парчета към пъзел, който вече се нарежда. Тази разлика в перспективата може лесно да доведе до конфликти, особено когато sprint-ът вече е в разгара си и ресурсите са обтегнати.
Product Owner: Вярно, не съм се замислял за този сценарий, сега ще го добавя към User Story-то.
Програмист: Но това ще промени драстично scope-а на User Story-то по средата на sprint-а.
Product Owner: Не променям scope-а на feature-a, това е задължителна функционалност, за която просто не се бях сетил.
Програмист: Не те обвинявам, че не си се сетил, а казвам, че User Story-то става по-голямо и няма как да го завършим в този sprint.
Това, че нещо е много важно, не го прави възможно.
Какво да направим?
Всички имаме 24 часа в денонощието и, за съжаление, не можем да ги увеличим, за да свършим повече работа. Та, това допълнение наистина ли е важно? Ако не – оставете го за друг ден (sprint). Но – ако да – може да се направят няколко неща.
Първо, опитайте се да удължите крайния срок и да го доставите в следващия sprint. Ако това не е възможно – опитайте се да преразпределите ресурсите и да добавите допълнителени разработчици, които да помогнат с тази задача.
Но не забравяйте, че първо – те трябва да зарежат първоначалната си работа, и второ – невинаги включването на допълнителни хора разрешава проблема. С други думи – опитайте се да издействате външна помощ, да предоговорите крайния срок и т.н. Никой не е казал, че crisis management-ът е лесно умение.
„Трябва да изчистим technical debt-а“ – рунд първи
Единствените софтуери, които нямат технически дълг, са тези, които още не са разработени. И може би този, който винаги се поддържа актуален, но всички знаем, че това е като да видиш еднорог…
Product Owner: Този feature ще влезе в един sprint, нали?
Програмист: Не, защото отдавна искаме да рефакторираме компонента и да изчитим legacy кода.
Product Owner: Откога е така?
Програмист: От години…
Product Owner: Значи не е важно да го правим сега.
Всеки винаги чака „правилния момент“, а той винаги идва в най-лошото време.
Какво да направим?
Бизнес хората трябва да изградят разбирането, че не е възможно винаги да се приоритизират „новите неща“, без да се отдели време първо да се оправят старите. В противен случай се стига до дългосрочно градене върху счупени основи и това обикновено води само до един изход.
„Трябва да изчистим technical debt-а“ – рунд втори
Въпреки това, приоритетите са си приоритети и не винаги можем да правим нещата по начина, по който бихме искали.
Product Owner: Този feature ще влезе в един sprint, нали?
Програмист: Не, защото отдавна искаме да рефакторираме компонента и да изчитим legacy кода.
Product Owner: Съжалявам, но е обещан на клиент за следващия месец…
Програмист: Защо хората продължават да обещават неща, без първо да ни питат?!
Искате или не, такива решения могат да бъдат вземани, без някой да го е интересувало много дали първо трябва да ни попита.
Какво да направим?
Въпреки че премахването на технически дълг и legacy кода е важен процес, понякога трябва да разберем, че сме поели ангажимент към клиент и не е в нашите ръце да го направим „по правилния начин“.
Това, което може да се направи, е да се отвори и приоритизира последващо подобрение на feature-a, така че техническият дълг да бъде премахнат при първа възможност. И въпреки че винаги е препоръчително да се консултират с нас, преди да се вземат решения, които ни засягат, ангажиментите към клиентите са също толкова важни.
В заключение
Та, какъв е отговорът? Когато се сблъсквате с такива проблеми, не забравяйте, че целта не е да спечелим спора, а да намерим правилното решение заедно.
Имаме различни роли и различни гледни точки, а това всъщност прави един екип силен. Когато уважаваме експертизата на другия и комуникираме открито, можем да се справяме с такива конфликти много по-лесно. Бъдете приятели, не позволявайте егото да надделее, доверявайте се един на друг и работете за общото благо.
