Теодора Тодорова е част от софтуерната индустрия вече 15 години, но през 2012 г. решава да промени пътя си, за да изгражда успешни екипи и да управлява проекти. Преквалифицира се като ръководител на проекти. По-късно получава възможност да участва в Agile проекти, в които поема ролята на Scrum Master и Agile инструктор. От 2017 г. Теодора, съосновател на bTalks Agile, помага на организации, екипи и отделни личности да постигат по-добри резултати в своите Agile практики чрез предоставяне на „coaching” услуги, консултации и обучения (снимка: личен архив)
Няма процес, инструменти, методология, които могат да свършат необходимата работа по даден проект вместо човека. Неслучайно това е първата ценност в Agile Manifesto – „Хората и взаимоотношенията повече от процесите и инструментите”. Хората са тези, които правят така, че нещата да се случат, разказа в интервю за TechNews.bg Теодора Тодорова – съосновател, Agile инструктор и консултант в bTalks Agile. Най-важното е мениджмънтът и конкретният екип да са ангажирани и да осъзнават, че успехът зависи предимно от тях, допълва тя.
Г-жо Тодорова, все по-често слушаме от специалистите за Agile, Scrum, Lean и други загадъчни за обикновения човек понятия, когато става въпрос за управление на процеси и проекти. Защо тези вълшебни думички са толкова важни за съвременния бизнес?
Сега, като се връщам назад, осъзнавам, че от първия ми работен ден в ИТ фирма сме използвали Agile практики, въпреки че тогава Agile като термин не се споменаваше толкова често. Първата компания, за която работех, беше голяма корпорация и разработваше ипотечен софтуер в пика точно преди финансовата криза през 2008 година. Всичко беше толкова динамично, че те трудно можеха да планират за дълъг период от време. Бизнес климатът им налагаше да бъдат гъвкави.
В днешно време технологиите се развиват с все по-бързи темпове и дори големите гиганти трябва да намерят начин да отговорят на това темпо. Agile, и съответно различните Agile рамки като Scrum, им дават инструментите, от които се нуждаят, за да отговорят максимално адекватно на променящата се среда и нуждите на потребителите.
Много е изписано за Agile и Scrum, но нека да чуем Вашето определение за тези две понятия и смисъла им за компаниите, на базата на 15-годишния Ви опит, включително в управлението на проекти за корпоративни клиенти.
Ползите, които организациите успяват да акумулират, внедрявайки Agile процеси, са наистина много – съкращават времето за достигане до крайните потребители, печелят конкурентно предимство, разработвайки иновации, повишават качеството, съкращават разходите, като инвестират средства само във функционалности, които най-вероятно ще донесат приходи, намалява се рискът от неблагоприятен изход на проекта… Независимо дали си малка организация, или голяма корпорация това са все ползи, които бизнесът търси непрекъснато.
Аз съм част от софтуерната индустрия от доста време, но в един момент реших да изграждам успешни екипи и да управлявам проекти. Малко по-късно, през 2017 година, започнах и свое начинание. Създадохме bTalks Agile и днес предоставяме coaching услуги, консултации, безплатни и платени обучения, като опитваме да представяме Agile процесите по най-лесния и полезен начин.
Много често обаче Agile, и в частност Scrum като най-разпространената Agile рамка, са грешно разбрани и приложени на практика. Това в не малко случаи води до обратен ефект и демотивация в екипите. Факторът тук са хората, а не конкретният процес, който ще се внедри. Agile е преди всичко нагласа и начин на мислене. Отговорност на всички в една организация е да приемат тази нагласа, ако искат да се възползват от предимствата, които могат да се постигнат с Agile.
Съвършената методология или човекът с неговите недостатъци и гениалност имат по-голямо влияние при реализацията на даден проект? Кой от двата фактора трябва да се „нагоди” към другия и как се случва това на практика? Дава ли методологията право на импровизации и творчество от страна на екипите?
Кратко и ясно – ЧОВЕКЪТ. Няма процес, инструменти, методология, които могат да свършат необходимата работа по даден проект. Неслучайно това е първата ценност в Agile Manifesto – „Хората и взаимоотношенията повече от процесите и инструментите”. Хората са тези, които правят така, че нещата да се случат.
При тези условия е логично и би било странно да мислим, че въвеждайки дадена методология, без да се съобразим с хората като ниво на знания и умения, среда, в която работят, характери и интереси, мотивиращи фактори, проектът ни ще бъде успешен. Един истински лидер би взел тези особености, които са строго специфични за дадения проект, под внимание и би се съобразил с тях.
Когато се заемате с подобряване на процесите на даден клиент, какво предпочитате да наследите – архаична организация, която да промените из основи, или такава, която се нуждае от надграждане до модерните практики? Кога залогът за успех е по-голям?
Хм, труден въпрос и не мога да дам еднозначен отговор. Ние работим и с малки, и с големи организации, както и с отделни служители. Винаги анализираме и смятаме за основен фактор за успех нагласата и желанието на клиента да се впусне в приключението и да подобри своите процеси. Най-важното е мениджмънтът и конкретният екип да са ангажирани и да осъзнават, че успехът зависи предимно от тях.
Имали ли сте в практиката си случаи, когато даден проект зацикля, с риск да се провали? В по-глобален план – защо в крайна сметка някои проекти не се реализират въпреки вложените усилия? Какви са предпоставките за това и могат ли да се избегнат грешките на по-ранен етап?
Моите наблюдения и опит показват, че най-малките проблеми са процесът и начинът, по който се имплементира проектът. Причината за неуспех е почти винаги в бизнеса – доколко бизнесът има визия и се придържа към нея, доколко е проактивен на много ранен етап да валидира идеята, да я приложи на практика и да не отлага. Agile ти предоставя възможност да започнеш да използваш продукта/резултата на проекта на много ранен етап. Това дава както увереност на бизнеса, така и мотивация на хората, ангажирани с имплементацията. Тук е силата на гъвкавите процеси и на начина, по който намаляваме риска.
От друга страна, ако ще се проваляме, ще се провалим на достатъчно ранен етап, за да спестим напразно изразходени ресурси. В Agile има термин „fast failing”, което означава, че няма нищо лошо да се провалим, стига да е достатъчно рано и да можем да вложим усилия и ресурси в нещо друго, което може да се окаже по-успешно.
Вашата компания bTalks Agile планира редица образователни инициативи тази есен, включително безплатни. Към каква аудитория са насочени курсовете и какви цели преследвате с тях?
Нашата мисия е да съберем хората, практикуващи Agile, на едно място. Това е причината да организираме всеки месец безплатни събития. Първото от тях ще е за Scrum и ще е съвсем скоро, на 3 септември, като информация за него и за останалите предстоящи обучения има в уебсайта ни и социалните мрежи.
Всеки гост-лектор е добре дошъл на срещите, за да сподели своите научени уроци. Ще се радваме да посрещнем и всеки, който е част от Agile екип или просто иска да научи повече по темата. Най-голям интерес засега има от хората в ИТ бранша, понеже гъвкавите процеси в тази сфера вече са се наложили като стандарт.
—
Цялата тая работа е да строиш всички пред една дъска, за да накараш малко по-мързеливите да бачкат, за да не ги е срам, че вчера нищо не са направили.
—
Да, това е един от големите плюсове по мои наблюдения. Според мен проблема е меко казано малко по-сериозен отколко “вчера не са направили нищо”. Имам усещането, че не малко пъти твърде много хора, работят твърде много време по нещо, което 1 човек ще направи за 2-3 часа. Егати и фийчъра. При скръм доста добре е оптимизирано това нещо – разбира се, ако се изпълнява в пълнотата си, както е по буквар.
—
Хората му викат оперативка, а не скръм!
—
Ааа, не, оперативките стават твърде дълги, включват твърде много хора, които само пречат и т.н. В тази си част скръм ми се струва много на място.
Остава си обаче проблема с цялостното планиране и твърде многото ситуации, в които не е разумно да работиш по определена функционалност, докато не съставиш здрави основи. Само и само щото тази функционалност е наредена най-отгоре като нужна и добра от собственика, едва ли не трябва да кърпим лош код, за да я пуснем и така една след друга докато в един момент софтуера не почне да се чупи яко отвсякъде и има нужда да се изхвърли и да се почне от 0.
Често и просто, твърде често се налага да се работи по няколко функциоталности наведнъж или да се връщаш към основите и да прекарваш там 1-2 седмици. Това е с оглед, най-добра ефективност и стабилност, и в последствие най-много гъвкавост на софтуера. Но, това е абсолютно невъзможно да го обясниш на какъвто и да е мениджър, който не е бил програмист. В смисъл да го обясниш и той да го разбере ясно. Не, защото някои мениджъри нямат опит и не са умни, а просто защото материята е специфична и не може да го схванат от обща култура, общ управленски опит, познаване на продуктите, на клиентите, на изискванията и т.н.
Абе не знам … Раобтещ скръм още не съм видял. Ако работи пък, е ‘нещо като скръм, ама не баш’. Един приятел нямам, който да каже ‘въведохме скръм и всичко стана 6, проекта кърти, клиентите доволни’.
Цялата тая работа е да строиш всички пред една дъска, за да накараш малко по-мързеливите да бачкат, за да не ги е срам, че вчера нищо не са направили. Хората му викат оперативка, а не скръм!
Много добър коментар на Tanton. И аз се замислях в тази посока.
Но, реално всичко зависи от конкретния проект, конкретните задачи и цели. Колкото глупост е да гледаш само към краткосрочните цели и да правиш кръпка върху кръпка, без цялостен дизайн, без архитектура, без обмисляве на проекта и визия, толково е глупаво да правиш всички тези неща и да изразходваш огромен ресурс от време и средства, за нещо, което може да работи достатъчно добре, набързо (прототипно) направено. В крайна сметка често не се знае, как би се възприела една идея и не е нужно да хвърлиш всичко там.
Друг плюс, който аз виждам на Agile / Scrum методологията е, че наистина кара хората да работят, да преследват целите и постоянно да са мотивирани и съсредоточени, а не да се размотават и да се оправдават. Често имам усещането, че нещата по стандартните методи много се разводняват, много излишни приказки, чакане на одобрения и т.н.
Като тегля чертата, за мен всичко зависи от лидера, който управлява проекта. Ако той е достатъчно добър и има достатъчно добри технически подготвени кадри, може да се плъзне и по едната и по-другата методология и да завърши с успех. Въпрос на избор, кога за кой milestone или пък за кой проект да ползва едното и кога другото.
Основният проблем на всички Agile методологии, е, че са тактически-адаптивни, те нямат стратегически глед. “Провали се бързо”, “достави нещо малко на клиента бързо” и пр. И тази бързост се извинява с гъвкавост, като се (само)счита за великата методология.
Тези подходи по своята философия са greedy алгоритми, донякъде изразяват и визията на съвременния бизнес. А тези алгоритми работят по един принцип: на всяка стъпка избират винаги най-доброто решение. Това обаче може да не е най-доброто решение по принцип. (Ако искаш да отидеш на Луната, не се качваш на най-близкото дърво. Напротив, гледаш да слезеш от него.)
Подобни гъвкави подходи никога не могат да компенсират голямото виждане. Те винаги се съобразяват с близката цел, с конюнктурата, със ситуацията. Може да са приложими за определен тип софтуер, но когато някой се опитва да ги представя като велика панацея, човек може само да се усмихне. Най-голямата грешка би била точно Agile да бъде начин на мислене!
Да не говорим за конкретната глупост, наречена Scrum. Нямаш лидер на екип, имаш самоорганизиращ се екип. И това е нещо велико. Защо не вземат да го приложат и в ръководството на компаниите? Да махнат CEO-то – няма да има CEO, ще самоорганизиращ се борд. И ще видят резултатите на тримесечието. Самият принцип на липсата на водач, на липсата ръководител (както и да го наречем), е историческа глупост. Личността е, която прави история, не екипът. Тя не може без екип, но тя е, която води и прави история, фигуративно и реално. И можем да го видим на всички нива в социологията на човечеството.
Така че нищо против девойчето с 15-годишния опит. Но всички тези натруфени англо-фрази и подходи може да си ги прибере някъде.
Гъвкавостта е следствие от мъдрост, не от скорост, представена като динамика.
Имам следния въпрос – ако “бързаш” и не изпипаш проекта добре, тогава той има по-голяма вероятност да се провали. В днешно време качеството е много важно, клиентите (включително и крайните клиенти) са много взискателни и даже дреболии може да ги накарат да избягат при конкуренцията.
На базата на това нещо като прототип, нещо сглобено, за да тества бизнес идеята – хич не е добре! Да чакаш клиентите да “работят за теб” и да ти казват своите изисквания може да се приложи, но само в определени сфери. Поне, така си мисля аз.