Публикувано на: 13 януари, 2022*Текстът е предоставен от AMPECO
AMPECO e българска компания, която разработва изцяло cloud-базирана софтуерна платформа за управление на зарядни станции за електрически автомобили. Продуктът е комплексен, тъй като съдържа освен често срещани B2B-модули, и специфични e-mobility компоненти. Използва се от лидери на глобалния пазар и е в основата на работата на над 15 000 зарядни станции на 6 континента.
AMPECО е основана преди по-малко от 3 години, а в началото на 2021 г. компанията беше отличена от Forbes като един от трите най-добри стартъпа в България. Зад този успех стои визията на шестима основатели и посветеността на 50 колеги, като 16 от тях са опитни ръководители на проекти, back-end, front-end и full-stack софтуерни инженери.
В екипа на CTO-то Александър Алексиев, който е и сред основателите на компанията, тепърва ще се откриват нови роли. Това е и причината с него да влезем в детайл какво означава да си част от AMPECО – като ежедневна работа и принос към растежа на компанията, но и като възможности за развитие в един нов сектор с огромен потенциал.
Самият Александър познава отлично стартъп културата – преди AMPECО е основал още три компании. Има над 15 години опит в управлението на големи IТ екипи и е експерт в отворените стандарти в електромобилността – OCPP и OCPI.
Александър, как преминава работният ден на един софтуерен инженер в AMPECO?
За всеки в екипа е различно, защото работим дистанционно с гъвкаво работно време, и за да е ефективен процесът имаме малко фиксирани срещи. Практикуваме pair programming, имаме свобода и за ад-хок разговори между нас. С други думи, въпреки че не сме физически в един офис, имаме възможност да „седнем” виртуално един до друг, да обменяме опит чрез Zoom или Slack. Работим кросфункционално, т.е. няколко различни роли са част от един екип и комуникацията между тях е интензивна. В спринтовете приемаме, че сме приключили една задача, едва когато клиентът е започнал да ползва продукта ни. В крайна сметка ние сме предприемаческа компания и залагаме на т.нар. Getting Тhings Done подход: нещата се случват бързо и без излишна бюрокрация, a целта ни е да си свършим задачите, а не всеки да си свърши работата.
Какви са най-интересните проблеми, които решавате в екипа?
По време на интервюта с кандидати често трябва да отговарям на този въпрос. За мен генерално задачите се делят на лесни и интересни. При нас лесни почти няма, защото пишем автоматизация за всичко, което се повтаря. Така за решаване остават интересните задачи – тези, които изискват креативност или новаторски подход.
Oще по-вълнуващото за екипа ни е, че проблемите, които решаваме са в индустрия, която тепърва се формира, и опитът, който трупаме, е безценен. Мога да дам пример с динамичното управление на натоварването. Ако в дадена сграда има много зарядни станции, често трафопостът не може да поеме натоварването, защото много електромобили са включени едновременно. Динамичното управление на натоварването улеснява системата, за да могат да се зареждат всички коли. Ние се справихме с проблема, като взаимствахме решение от начина, по който рутерите разпределят трафика.
Каква е причината в екипите ви да няма QA?
Loading …
Hybrid
БургасВ екипа разбираме ролята QA като специалист с много опит, като софтуерен инженер с критично мислене, който познава в дълбочина продукта и предвижда различни частни случаи в разработването му. Към този етап от развитието на екипа тази роля не е разпределена към конкретен колега. Процесът по качеството на кода е отговорност и приоритет на всеки от инженерите и това е причината да сме натрупали солидно количество от автоматизирани тестове.
Не се заричам обаче, че това няма да се промени с времето – при нас всичко е итеративно и сме отворени към промени, които да правят процесите по-ефективни. Едно обаче е сигурно – дори и да назначим QA специалисти, те ще се част от кросфункционалните екипи.
А защо нямате тийм лийдове?
Отговорът тук е прост – процесът е така организиран, че те не са необходими. Всичко е много прозрачно, видимо е какво има да се прави и кой за какво е отговорен. Освен това прилагаме т. нар. pull процес. Toва означава, че всеки колега решава сам кога е приключил с дадена задача и коя ще е следващата. Разбира се, всеки има приоритети, но има и голяма гъвкавост в рамките на съответния спринт, в който работим. В този процес просто няма нужда от тийм лийд, а и така или иначе в екипа всички инженери са много опитни и знаят как да организират времето си.
Kaк избрахте текущия технологичен стак и какво ви носи това?
В самото начало ние бяхме един много нетипичен стартъп, защото съоснователите сме шестима. Всички се събрахме в една стая, тогава това още беше възможно, и обсъдихме технологичния стак през призмата на опита на всеки един от нас. Накрая трябваше да решим между NodeJS и Laravel, като Laravel спечели, защото имаше по-бърз цикъл на разработка и в перспектива се доказа като качествен инструмент.
Всъщност, използваме и NodeJS, както и React Native – реално всяка технология, която ни помага да решим оптимално даден казус в работата ни. Така че е много вероятно в бъдеще да добавим и още технологии към стака ни, защото сме в период на бурен растеж и ще имаме нужда от оптимизации.
През колко итерации преминахте до постигане на текущия модел на работа?
Не броим конкретните итерации, защото моделът постоянно се променя. Когато видим, че нещо не се случва правилно, малка работна група се събира, за да предложи потенциални решения. Експериментираме с тях и така достигаме до подходящото решение.
Споменах pair programming-а – този подход, който ние използваме много интензивно, е плод точно на такъв експеримент. Все пак е важно да добавя, че въпреки че сме отворени за промени, знаем, че те предизвикват стрес в системата и внедряваме в начина ни на работа само решения, които доказано ще ни улеснят. В крайна сметка нашата работа е високоинтелектуална и стресът в нея е излишен.
Какви са възможностите за развитие в компанията?
Те са и хоризонтални и вертикални. Към момента ние сме доста равна структура и нямаме мениджъри. Това, разбира се, ще се промени с растежа, няма как да не създадем отговорни роли. Независимо от това развитие обаче, ние държим много високо ниво на знание в екипа и инвестираме усилия да подобряваме уменията на колегите.
Вече споменах, че работим в кросфункционални екипи. Това означава, че всеки един инженер всъщност работи интензивно и с продуктовите мениджъри, които са лицето на компанията пред клиентите, и с DevOps екипа, който създава нашата инфраструктура. По този начин се увеличават и възможностите за хоризонтално развитие в компанията.
