„Момчетата не се извиняват“: 6 основни грешки на ИТ мениджър

Липса на доверие в служителите

Най-често това се проявява в нежелание за делегиране на отговорност. Разбира се, има редица задачи, които не могат да бъдат делегирани. Например тези, свързани със стратегическото развитие на компанията: поставяне на цели и задачи, прогнозиране на рискове и проблеми, определяне на приоритети, избор на начини за постигане на целите.

И за да работите по такива задачи, трябва да знаете за дейностите и целите на всички екипи, глобалните цели на компанията, финансовите показатели и пазарната ситуация. Да, екипът може да бъде източник на информация, но вземането на решения трябва да остане на управленско ниво.

Струва си да споменем още един пример, при който делегирането на задачи може да не е толкова ефективно, колкото изглежда. Говорим за преговори и изнесени срещи.

Външната комуникация не е „трудно умение“ за разработчиците или дизайнерите, така че трябва да оцените личните качества на даден човек, преди да вземете решение за неговото участие в среща. Например на една от тези срещи нашият квалифициран и емоционален дизайнер се натъкна на субективна, неконструктивна критика. Това доведе до конфликт, напрежение от страна на клиента и спад в мотивацията на служителите.

Заключение: трябва внимателно да претегляте рисковете в такива ситуации. Ако е необходим личен контакт между екипа и клиента, трябва да се извърши подготвителна работа със служителите. И едно от основните правила на поведение в такива ситуации е да не се влиза в диалог, докато мениджърът не даде думата.

За да разберат етапите на изграждане на екип, за мениджърите е полезно да проучат модела на Брус Тъкман – „Формиране, щурм, нормиране, изпълнение“.

Докато екипът развива способности, взаимоотношенията се изграждат и лидерът променя стила си на лидерство. Управлението на екипа започва с лидерство, след това става като коучинг , след това частично участие. Накрая има делегиране и излизане на мениджъра от процеса. 

За да се увеличи прозрачността в нивата на отговорност на служителите, е полезно да се създаде RACI матрица за проекти.

Методологията RACI е средство за проектиране и планиране на промени, участието на различни роли в процедурите и задачите на процеса:

Р – Отговорен – изпълнява.

A – Отчетен – носи отговорност
C – Consult before doing – консултира се преди изпълнение.
I – Информирам след извършване – уведомявам след изпълнение.

Тези два инструмента установяват модел на взаимодействие между служителите, определят реалистични очаквания и имат положително въздействие върху доверието в членовете на екипа.

Ангажимент за формат на фиксирана цена

Избирайки метода на фиксираната цена , клиентът знае общата цена на целия проект, преди да започне. Първоначално зададената цена трябва да остане същата през целия проект. 

Клиентът и изпълнителят сключват споразумение за конкретен резултат, който трябва да бъде постигнат на предварително определена дата. В този случай клиентът се съгласява, че или няма да прави промени в проекта през цялото време на сътрудничество, или ще сключи допълнителни споразумения за нови изисквания.

Този метод включва максимално документиране на продукта в началото и прогнозиране на всички рискове с цел избягване на санкции. В същото време изпълнителният екип, разбира се, се стреми по всякакъв начин да изпълни проекта навреме – понякога това се случва в ущърб на качеството.

Освен това е невъзможно да се предвиди абсолютно всичко и да се отрази в техническите спецификации. А договорите с фиксирана цена с недостатъчно подробни технически спецификации ни принуждават да възпираме клиента в желанията му. И водят до продукти, които според документацията са 100{3609db0412b2f04f4f04eb70354099a0e75da5ceeada0f055dfbd8474d63d095} направени, но реално са далеч от очакванията на потребителите.

Опитваме се да използваме продуктов подход с изчисления във формат време и материал. Това дава повече гъвкавост при създаването и приоритизирането на изоставането. 

При споразумение за време и материали (T&M) общите разходи не се определят в началото на сътрудничеството – те се основават на броя на часовете, прекарани в проекта и материалите, използвани за завършването му. По този начин, дори проектът да отнеме много повече или по-малко време от очакваното, и двете страни могат да бъдат сигурни, че ще получат договорения продукт.

Руският пазар все още няма 100{3609db0412b2f04f4f04eb70354099a0e75da5ceeada0f055dfbd8474d63d095} доверие в този формат – някои клиенти искат да платят веднъж и веднага да получат продукт с желаната функционалност. Такива клиенти обсъждат само етапите, посочени в договора: одобрение на технически спецификации, приемане на резултатите за първия етап след три месеца, приемане на резултатите за втория етап и т.н.

В такива случаи ние обясняваме на клиентите важността на продуктовото проучване, пускането на MVP и демонстрациите с ключови потребители. В крайна сметка проблемът не е в документите – винаги можете да направите допълнително споразумение с корекции в съдържанието, сроковете и бюджета. Факт е, че е късогледо да се преработва продукт след пускането му, харчейки редовни бюджети. Да не говорим колко съмнително е внедряването на услуга, която не опростява работата и не я прави по-ясна от UX гледна точка.

Имахме няколко случая – услуга за подобряване на качеството на живот, платформа за международен пазар, услуга за отдаване под наем на недвижими имоти – когато след договор с фиксирана цена беше възможно да запознаем клиента със стойностите на продуктовият подход – вече бяха сключени последващи договори за T&M.

Винаги казвай да

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

Имахме клиент, който винаги се пазареше много (буквално за всяка рубла) и постоянно променяше изискванията си. И се срещнахме по средата, естествено, в ущърб на маржовете. Това продължи около година и до края на нашето сътрудничество всички членове на екипа бяха толкова съсипани, че не можеха да произвеждат същия качествен продукт както преди. И само благодарение на това, че се събрахме и натиснахме, не отидохме на червено. Вече не работим с този клиент.

Всъщност тук всичко е просто. Следвайте тези критерии, когато избирате проект:

• не работете по проекти, които могат да повлияят негативно на вашата репутация;
• не работете с неадекватен, агресивен или твърде пасивен клиент;
• не работете с едностранни търгове, ако трябва да намалите разходите, намалете обема на изискванията;
• не поемайте проекти с нереалистични срокове;
• не поемайте проекти с технологии, които компанията не може да разложи, оцени или да избере подходящи специалисти;
• не поемайте проекти, ако служителите са претоварени.

 

Липса на изградени взаимоотношения със служителите

За ангажиран ръководител на екип признаването на грешки е тревожно. Това често се дължи на желанието да се поддържа външния вид на „сериозен“ човек, който определено ще доведе отбора до целите му.

Новият опит води до растеж и грешки. И това е добре. Мениджърът, на първо място, трябва да покаже на екипа как да работи с грешка: как да неутрализира последствията и да запази репутацията си. Например, ако е станала грешка от наша страна, той трябва да покаже със собствения си пример как да преговаря, да намали степента на напрежение и негативизъм и в същото време да настрои клиента за удобно партньорство.

Също така помагаме за точно установяване на взаимоотношения, ако някъде сме сгрешили.

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

В резултат на това моят подчинен и аз се срещнахме с клиента и като начало се извинихме за факта, че не сме му предали достатъчно ясно необходимостта от рефакторинг. След това те обясниха ситуацията и значението на отделянето на време и ресурси за технически дълг. Ние защитихме позицията си и казахме, че извършената работа по техническия дълг в спринта ще позволи последващите подобрения да бъдат направени по-бързо и по-евтино.

Затова се съгласихме да включим часове за рефакторинг във всеки спринт; получихме повече време да завършим работата от предишния спринт. И с един подчинен обсъдихме важността на осигуряването на прозрачност в комуникацията.

Такива взаимоотношения са пътят към доверително и прозрачно сътрудничество.

Авторитарните лидери виждат признаването на вина и извинението като слабост и унижение. Те имат две възможности: да игнорират ситуацията или да обсъдят и намерят виновен. Но стратегията „момчетата не се извиняват“ води само до увеличаване на недоволството в екипа, ерозия на доверието в лидера и в резултат на това бизнес стагнация.

За да предотвратите това, можете да се придържате към следните правила:

1. Искрени извинения с ясно посочване на грешката и последствията от нея. 
2. Не забравяйте да подчертаете за какво е прав служителят – това е стимул за изграждане на взаимоотношения.
3. Поемете отговорност само за своята част от грешката, а не за глобален провал, при който грешки са направени от различни участници.
4. Не забравяйте да предложите начини за разрешаване на проблема.

Най-често грешките се намират в зоната на класическия проектен триъгълник, който се формира от тройно ограничение: обем на работа, срокове, цена. Балансът на тези аспекти определя качеството. С други думи, ако обемът на планираната работа е равномерно изграден във времето и е достатъчно покрит от бюджета (разходи плюс марж), основната част от рисковете е покрита.

Доста подробен и прозрачен инструмент за прогнозиране на възможни трудности е матрицата на риска. Има много решения с отворен код, които ще ви помогнат да го компилирате и актуализирате. В краен случай може да се създаде матрица на риска в Excel.

Какво трябва да направите, за да направите този документ възможно най-полезен:

• периодично актуализирайте матрицата с екипа, например провеждайте сесии за мозъчна атака;
• проследявайте зависимостите, обръщайте специално внимание на рисковете, изпълнението на които ще задейства изпълнението на последващи;
• описват рисковите тригери и план за реакция;
• направете справка с документа, за да проверите дали липсва един от тригерите за риск;
• Документирайте опита, който да използвате като шаблон за следващи проекти. Снимка на корицата:Freepik

Важно е да запомните, че грешките в управлението не са необичайни. И дори опитните топ мениджъри не винаги се измъкват лесно и просто от трудни ситуации. Но това не е краят на пътя, а възможност за растеж. И за да управлявате ефективно ИТ проекти, трябва да приемете грешките като част от процеса на разработка. Работете със сложностите, подкрепяйте екипа, насърчавайте откритостта и се фокусирайте върху намирането на решения.