Христо Астарджиев е мениджър с над 10 години опит в управлението на екипи. На събитието Risk Management in Agile той ще говори за управлението на риска в гъвкавите методологии за разработка. Преди това обаче се срещнахме с него, за да си поговорим за това как се избира метод на разработка, какво го вдъхновява и какви са трите съвета, които би дал на хора, които сега започват да се занимават с ръководене на екипи. Отговорите може да ви изненадат!

Как започна да се занимаваш с IT Project Management?

Това стана преди повече от 10 години в Dynamo Software, тогава – Netage Solutions. Работата ми беше сътрудник по поддръжка на клиенти – тоест, отговарях на клиентски въпроси за апликациите, написани във фирмата.  Започнахме да предлагаме софтуер пробно (software trials), a инсталацията не беше лесна – имаше клиентска част, сървър и база данни. Захванах се с пробните инсталации, които всъщност бяха мини-проекти с екипи от двама-трима инженери и продължителност месец-два. Стана ми интересно, работата по проекти започна да ме увлича. Във фирмата имаше знаещи хора, от които научих много. С времето започнах да взимам по-големи проекти от различни типове – внедряване, интеграция, разработка.

Какво те вдъхновява в работата ти?

Различни неща по различно време. Във VMware, определено ме вдъхновяват особеностите на проекти, които са технически и организационно сложни. Имат огромен обхват, големи бюджети, големи екипи и си поставят трудни технически задачи. Често търсим новаторски решения, близо до горната граница на възможностите на инженерните екипи.

В Dynamo Software ме вдъхновяваше смелостта на малка българска софтуерна фирма да се конкурира с топ компании – SAP и Oracle бяха преки конкуренти за някои сделки – и да жъне успехи.

Кое е най-голямото предизвикателство, с което си се сблъсквал в работата ти?

Това е предизвикателство, което срещат повечето големи екипи – много хора, на голямо разстояние един от друг, с различно местно време. Часовата разлика ограничава възможностите за общуване в реално време. В един предишен проект имаше екипи на 6 места – или както още се наричат „географии“, в множествено число  – два в Америка, три в Азия, и София. При такова разпределение просто няма интервал от един час в денонощието, който да е удобен за всички. Който и час да бъде избран за среща или разговор, ще се окаже неудобен за част от хората. Или ще е рано сутрин, или късно вечер – все часове, които не предполагат човек да се занимава със служебни задачи.

Как го разреши?

Не правя срещи с много хора от различни часови пояси. Старая се да ги групирам според местните времена. С големият екип, за който споменах, имах една среща за Европа и Азия, през късния следобед в Шанхай и по обяд в София. За Америка и за Европа направих втора – късно следобед в София и рано сутринта в Калифорния. Така за всички беше удобно.

Какви са плюсовете на Agile методологията?

За мен всяка методология е инструмент, оръдие на труда, и нищо повече. Смятам, че няма универсални инструменти – те трябва да се избират според поставените задачи. Agile методологията е подходяща за определен тип проекти и организации. Въпросът какво му е хубавото на agile има отговор само в множеството на смислените приложения на методологията. За екип, които не се намира в един офис, тази методология не е подходяща, защото тя разчита на възможно най-широк комуникационен канал. Това означава хората да са заедно и да си говорят в реално време, без да използват много технически средства. За малки екипи и малки проекти agile е супер, особено когато разработката е организирана на кратки итерации от по 2-3 седмици, както е неписаното правило. Обаче за екип от няколко стотин инженери – примерно, в 6 държави, на 3 континента – и проект с продължителност година, година и половина – agile няма обезателно да бъде най-удачния избор.

Каква методология би препоръчал на такъв екип?

Казах че няма универсален инструмент, сега ще добавя, че не харесвам религията. Ако някой силно вярва в дадена методология и настоява, че това е единственият начин по който трябва да се случват нещата, това за мен е религиозен предразсъдък. Предпочитам да избирам методите си според ситуацията, според типа на проекта, според екипа и не вярвам в чистите методологии. Неволята ме е научила, че ръководителя на проекта и неговия екип е добре да изберат как да управляват проекта, с който са се захванали, без твърде много да се впечатляват от различните методи в литературата. Така обикновено се стига до един практичен хибриден подход – съчетание от методи, техники и инструменти – и се изключва следването „до буква“ на предписания от религиозни текстове.

Значителна част от литературата за agile твърди, че ако един екип следва методологията, той трябва точно да спазва предписанията. Не харесвам този подход. Предпочитам да упражнявам собствената си преценка, да разчитам на интелекта, опита и здравия разум на хората от екипите, с които работя, вместо да спазвам канона.


 

Събитие на фокус:

Continuous Integration on AWS

 


Какво би посъветвал всички project management ентусиасти, които сега започват своя кариерен път?

Първо, да се запознаят, по възможност практически, с колкото се може повече роли или функции, които имат представители в екипите, с които ще работят. Тук разнообразието е голямо: софтуерни инженери с различна тясна специализация, технописци (документатори), проектанти на интерфейси и взаимодействие, информационна сигурност, както и различни предметни специалисти – локализация, право, финанси, маркетинг, продажби, поддръжка и др. За ентусиастите е добре рано да научат какви задачи решават и какви трудности срещат хората в различни роли, с които ще работят.

Второ, не изобретявайте колелото. Управлението на проекти е почти класическо общо управление. Управлението е наука с история от времето на Индустриалната революция. Много умни хора в продължение на много време са писали учебници по управление. Не е нужно – а и говорейки за себе си, може да бъде болезнено – ентусиастът всичко да измисля сам. Полезно е да премине някакъв вид структурирано обучение – управленска степен в университет или изпит за някой от по-трудните за вземане сертификати. Аз бих предпочел обучение в класна стая, пред масовите сега дистанционни методи.

Трето, запознайте се с колегите си. Човек трябва да познава средата, в която работи, на първо място – хората, да знае силните и слабите им страни. Работата с хора е слабо застъпена във всички методологии за управление на проекти. Ако четете учебниците, може да останете с впечатлението, че ръководителят на проекти не работи с хора, а с роботи, които изпълняват инструкции. Не е така. Ръководителят на проекти работи с хора всеки ден. Полезно, а и по-приятно, е когато хора които са се събрали да свършат нещо, търсят и намират начини да работят добре заедно и да си помагат един на друг.


Стани част от потребителската група IT Project Management. Абонирай се и ще ти изпращаме информация за всичко, което предстои в групата.

Визия: Личен архив

„Основната работа на всеки един лидер е да стане излишен“ – Веско Колев, Director Software Engineering, Progress
Силвана Байрева: Няма рецепта за справяне с всяка ситуация, просто анализираш и след това предприемаш действия

Share This