Управлението е всичко за хората. Независимо дали са мениджъри или служители, и двамата обмислят как да постигнат своите лични и професионални цели. Комбинацията от тези цели и личните черти на участващите хора придават форма на взаимоотношения, които с времето могат да бъдат положителни, продуктивни и изпълняващи или понякога просто стресиращи, взискателни и склонни към конфликти.
Разбира се, в последния случай качеството на продуктите намалява, текучеството на персонала се увеличава и постигането на целите става все по-трудно. Следователно намирането на начин за установяване на възнаграждаващи и мотивиращи взаимоотношения между мениджъри и служители е ключово, когато става въпрос за ефективност, производителност и самореализация и за двамата.
Това е особено вярно при управлението на разработчици на софтуер, поради техническата сложност и творческия им характер, компресирани в често тесни срокове за получаване на резултати. Както във всяка връзка шеф-служител, има много фактори, като:
В тази статия ще се съсредоточим върху основните аспекти на управлението, а не върху техническите, които смятаме, че трябва да бъдат взети под внимание от всеки, който иска да успее да успее да задържи разработчиците на софтуер.
Но тук „успех“ означава не само постигане на резултати и спазване на фирмените политики, срокове и бюджети, но и наличието на мотивиран и продуктивен екип за разработка на софтуер, който дава всичко от себе си и остава в компанията за дълго време.
Това ни води до основната ни тема: Какво кара разработчиците на софтуер да отбележат? Имайки предвид това, ще представим някои начини за задържане на служители, които сме идентифицирали в успешни екипи за разработка на софтуер.
При разработването на софтуер талантът, който наемате, ще направи разликата между успеха и неуспеха, а извършването на постоянни промени в екипа винаги е скъпо по отношение на време и пари. Следователно добрият процес на подбор е от решаващо значение за успеха на вашия проект.
Техническите подборчици знаят, че когато става въпрос за наемане на разработчици на софтуер, всичко започва с внимателно балансирано обявяване на работа. Публикацията трябва да бъде мотивираща, за да могат правилните разработчици да отговорят на нея - твърде много или твърде специализирани изисквания могат да обезсърчат, но ако сте твърде неясни, вашата компания може да очаква поток от безполезни автобиографии.
Посочването на подробни пакети за заплати и обезщетения също е нож с две остриета, защото вашата конкуренция може да използва тази информация, за да използва своите компенсационни планове, а разработчиците могат да се опитат да я използват като базова линия за договаряне по време на наемането им. Разбира се, тъй като по време на процеса на набиране винаги трябва да има място за преговори, ние предлагаме обявяването на работата да бъде по-малко конкретно, когато става въпрос за компенсация, като се използват диапазони, а не фиксирани стойности.
За разлика от това, обявата за работа трябва да бъде възможно най-ясна в задълженията и изискванията на длъжността, както задължителни, така и приятни за разполагане. Започването със стабилна форма е най-добрият контекст за останалата част от нашите стратегии за задържане на служители.
На този етап от процеса е добра идея да получите съвет за оценка на кандидатите и към вижте какви клопки могат да бъдат избегнати по време на процеса на интервю . Също така бихме добавили към указанията по-горе, че предварително искането на кандидати за някои препоръки от предишните им работни места често е добро допълнение към други начини за валидиране на техните умения.
Наемането завършва с предложение за работа на кандидата, когато компанията представи официален документ, който обобщава характеристиките на длъжността (име, ранг, площ и др.), Компенсационния пакет (заплата и обезщетения като здраве, пенсия или образование и др.) , начална дата, график, място за работа и изисквания за сключване на договор за работа, ако кандидатът приеме офертата.
Въпреки че на този етап всичко е повече или по-малко изпълнено, кандидатът може да иска да договори някои условия и от компанията зависи да ги приеме или да се пазари за тях. Това зависи от практиките на компанията.
Със сигурност обаче компанията няма да иска да загуби добър кандидат поради въпрос на принципи, така че разумните компромиси няма да навредят на никого. В този случай е препоръчително да поискате от кандидата нещо в замяна на всяка направена отстъпка, като например по-ранна начална дата, минимално време на постоянство в компанията или някакви специални изисквания, които компанията може да има.
След като разработчикът на софтуер започне да работи във фирмата, техният мениджър започва да осъзнава кои са те, как работят и най-важното резултатите, които генерират. Тогава запазването на софтуерните инженери става ясен приоритет.
Тук се появява прозрението за личността на софтуерните инженери: Те - особено високоефективни - често показват някои общи черти. Ще посочваме тези модели по време на движение, но имайте предвид, че те може да не се прилагат еднакво за всеки индивид. Управлението на проекти за разработване на софтуер се отнася както до модели, така и до изключения.
Тъй като разработването на софтуер е техническа работа, то изисква много прецизно познаване на структурата на компанията, целите, процедурите, политиките (включително убеждения и бизнес практики) и стандартите (технически и нетехнически). Следователно, колкото по-добре разработчикът разбира компанията, толкова по-добър продукт ще направи и толкова по-малко време ще им отнеме да го направят.
Това основно обучение може да се администрира чрез документи, онлайн интранет курсове или презентации. Но това е необходимост, тъй като ще даде яснота на новия служител.
Ако ще бъдат въведени нови технологии, не забравяйте да осигурите необходимото обучение. Разработчиците на софтуер обичат да бъдат предизвиквани, но може да се възмутят, че са хвърлени в нова технология, без първо да я научат правилно.
Интернет е изобилстващ от ценни учебни материали и често е първият ресурс, към който разработчиците на софтуер се обръщат, когато трябва да научат или да научат повторно технически подробности. Ако искате да задържите разработчиците на софтуер, е важно да популяризирате култура на самообучение и, ако е необходимо, да отделите време за работа за това. По този начин екипът ще бъде в крак с най-съвременните технологии и методи, нещо, което разработчиците на софтуер често оценяват изключително много.
Някои смятат, че разработчиците на софтуер търсят най-високата технология, за да вършат работата си, с възможно най-добрите спецификации, налични в бранша. Вместо това смятаме, че това зависи от съответната работа. Например, ако се развива компания игри от първо лице , ще е необходимо да се предостави на разработчиците авангардна изчислителна мощ. Но ако работата е да се разработят back-end уеб услуги за транзакционна система, може да е достатъчен по-малко мощен компютър.
Това, което е наистина важно, е да предоставите на разработчика всички необходими инструменти, за да си вършат работата и да бъдат отворени за техните предложения за нови инструменти. Логично е, че всеки нов инструмент, който разработчикът предлага, ще трябва да бъде одобрен (може би дори тестван преди) и лицензиран от компанията. Въпреки това си струва цената: Наличието на адекватни ресурси е ключов фактор за мотивацията и резултатите на разработчиците. (Не можете да очаквате да задържите софтуерни инженери, ако ги настроите да се провалят!)
Разработчиците на софтуер обичат да работят на места, които насърчават и уважават техните творчески усилия, защото тяхната работа е да правят нещо от нищо, въпреки че се ръководят от дизайна, стандартите и ИТ политиките. Следователно разработчиците трябва да бъдат разумно уверени, че принадлежат към звено, при което цялата бюрокрация и ограничения са минимум, стига да спазват политиките на компанията и да са в съответствие с нейните вярвания.
Това не означава, че разработчиците на софтуер трябва да имат някакви специални привилегии в сравнение с останалата част от компанията, а по-скоро, че техният мениджър им помага да преодолеят или решат бюрокрацията, когато е необходимо. Много важен аспект при задържането на разработчиците на софтуер е, че шефът им е отворен за личните им изисквания и им помага при нужда.
Вътрешното подреждане на звеното за развитие също играе ключова роля тук. Често съществува група за тестване и задължението на мениджъра на софтуерното инженерство е да поддържа текуща работа в екип между разработчици и тестери. Това може да бъде постигнато просто чрез наличието на ясни методологии и процеси. Разработчиците са склонни да работят с тестери много добре, ако има правила, които трябва да се спазват и от двете страни, поддържайки конфликта нисък или несъществуващ.
Ако искате да задържите разработчиците на софтуер, е важно да ги държите в течение. Всички членове на екипа трябва периодично да се информират за целите, корпоративните ситуации, които ги засягат, стратегиите, промените в организацията и не на последно място постиженията на екипа.
Дори ако някои членове на екипа споделят някои акценти, това ще бъде добре за насърчаване на сплотеността и работата в екип. Обикновено тези срещи на екипа - най-много два часа - трябва да бъдат насрочени редовно (може би седмично), както и при специални случаи, като краен етап на проекта, критична ситуация и т.н.
Освен комуникацията с екипа, мениджърът трябва да установи начин да бъде в течение на ситуацията на всеки член, бил той свързан с работата, технически или личен.
Обикновено 30-минутна седмична среща с всеки член на екипа ще позволи на мениджъра да идентифицира тези ситуации и да осигури помощ, като по този начин предотврати потенциални кризи в персонала и повиши морала на члена на екипа в компанията.
За да бъде ясно, не говорим за създаване на единица за развитие, ориентирана към срещи, така че е необходима стриктна дисциплина на срещата (точност, уважение, участие, продължителност). Нещо повече, тази дисциплина показва на разработчиците, че работят за много професионална организация, нещо, което обикновено ценят.
Няма смисъл да се определят годишни общи цели или подобни насоки за оценка.
Това е ясен фактор при работа със софтуерни разработчици: Каквато и да е тяхната роля (събиране на изисквания, архитектура, дизайн, програмиране, тестване и т.н.), целите трябва да им бъдат дадени с възможно най-голяма яснота, така че няма смисъл при определяне на годишни общи цели или подобни насоки за оценка. Тъй като разработчиците трябва да работят в проекти, т.е. с определен обхват и график, най-добрият начин за определяне на целите е в началото на проекта и включва как ще се оценяват авансите и, ако е приложимо, как ще бъдат признати.
За щастие в днешно време има методологии, чиято цел е да генерират резултати възможно най-бързо, като Agile и Scrum, които опростяват последващите действия и контрола на проектите. Понякога това може дори да изиграе значителна роля за запазване на софтуерния талант: Много разработчици обичат тези методологии, защото могат бързо да осигурят резултати, като им дават чувство за постижение редовно.
Освен това разработчиците често предпочитат по-леките методологии. Те знаят, че такива от висок клас като Rational - където крайният продукт се доставя след дълъг проект на инженеринг, проектиране, разработване, тестване и внедряване на изисквания - са рискови и може да бъде болезнено да се следват.
Това важи за екипите за разработка на софтуер както за всеки друг вид: Мениджърът на софтуерното инженерство трябва да се справя бързо и ефективно с конфликти, или може да излезе извън контрол и да унищожи морала, работата в екип и ефективността на цялото звено.
Ако приемем, че разработчиците в конфликт са професионални и добре замислени, среща на мениджъра със засегнатите лица за започване на ясен диалог с бързо разрешаване след това трябва да бъде достатъчна, за да позволи на екипа да продължи напред. Също така понякога е необходимо да им се даде ясно предупреждение, че конфликт на лично ниво, ако изобщо се стигне до това, няма да бъде приет.
Във всеки случай в края на това помирение е много важно и двете страни да смятат, че решението е справедливо, дори ако една от тях не го харесва. Понякога конфликтът е част от живота, но запазването на софтуерни таланти означава отнасяйки се с достойнство към всички винаги когато възникнат такива ситуации.
Въпреки че сме засегнали много фактори, които влияят върху мотивацията на разработчика, има още един ключов аспект. Този не е емоционален, нито технически. Говорим за размера на компенсацията за тяхната работа.
Въпреки че са склонни да бъдат идеалистични по своята същност, разработчиците на софтуер често харесват добрите неща от материалния свят. Винаги е по-добре компанията да се увери, че плановете за заплати и компенсации са съобразени с пазара на труда - индустриални проучвания са лесни за намиране - и може би дори малко по-високи за техните позиции.
Освен това повечето разработчици на софтуер не са безразлични към предимствата и наградите, включително курсове и технологични събития, където могат да научат полезни техники за обогатяване на работата си.
Що се отнася до задържането на разработчици на софтуер, е важно да се подпомогне растежът им в компанията, независимо от конкретната й посока. Когато софтуерните инженери не проявяват голямо желание да преминат към ръководни позиции или мениджмънт, те вместо това оценяват напредъка на техническата сцена. Това включва повече сертификати за старши и официални академични програми като магистърска степен или дори докторска степен. Знанието е много силен двигател за тях.
Въпреки това, когато те се стремят да израснат до ръководни позиции, препоръчително е да се направи задълбочен анализ на личността и историята на кандидата в компанията. Това може да бъде с помощта на отдела за човешки ресурси или други звена на компанията, тъй като доброто управление изисква съвсем различен набор от умения, освен техническите умения.
Може да имате най-добрите намерения и да следвате всички горепосочени съвети, но все пак не успявате да задържите разработчиците на софтуер 100 процента от времето - понякога външните фактори просто имат по-голямо влияние. Но ние смятаме, че текучеството на персонал може да бъде здравословно и пълно с възможности, стига:
Стратегиите за задържане на служителите трябва да бъдат включени във фирмената политика, а не просто реакция, когато ценен човек иска да подаде оставка. Реакционното задържане е много скъпо и недостатъчно: Човекът може да се съгласи да остане, но си помислете: „Работих тук от X години, само за да ми бъде предложена двойна заплата при напускане - току-що признаха, че не ми плащат достатъчно!'
Каква ще бъде следващата стъпка на този човек? Може да си потърсят друга работа, но сега с двойна заплата като минимум. В този момент опитът да се задържат софтуерни инженери на всяка цена вероятно не си струва. Освен ако човекът не е абсолютно основен (и незаменим) за компанията, може би е по-добре да договорим срок за предизвестие и незабавно да намерим заместител.
Привличането и задържането на разработчици на софтуер е сложна и недетерминирана задача, както при всяка роля в технологичната индустрия. Има много компании, които търсят ценни софтуерни разработчици, но за щастие целта тук не е да спечелим срещу тези компании, а по-скоро да привлечем добри хора, които можем да успеем да задържим в нашата компания.
Процесите на подбор могат да отнемат много време и усилия. Ако пристъпите към това прибързано, има шанс да се окажете с грешни хора - и кой иска да задържи софтуерни инженери, които са токсични за екипа си? Вместо това отделете време, за да го направите правилно.
Награждавайте само изключителна работа и бъдете справедливи по вина. Периодично проверявайте средните заплати, изплащани в бранша, и коригирайте съответно. Не се опитвайте да задържите човек, който иска да напусне, освен ако не е строго необходимо; вместо това застъпвайте задържането като фирмена политика.
Имайте строг и справедлив процес на подбор и никога не наемайте набързо. Предложете компенсационен пакет, съобразен с пазара на труда или по-добре.
Осигурете необходимите инструменти за работата. Тренирайте екипа си всеки път, когато е необходимо, и стимулирайте самообучението.
Да бъдеш напорист и ясен. Като периодични срещи на екипа. Провеждане на периодични индивидуални срещи.
Справете се с конфликта бързо, справедливо и ефективно. Насърчете работата в екип.
Предпочитайте конкретни цели за всеки проект пред неясни годишни цели. Прилагайте надеждни методологии за разработване на софтуер. Оценка на базата на конкретни резултати.