Як стати хорошим менеджером

Думаю, багато хто погодиться з тим, що у нас дуже багато хороших IT фахівців. І навіть наша освіта, а також політичні, економічні та інші фактори не сильно можуть завадити стати хорошим IT фахівцем при наявності бажання. Але ось з менеджерами в сфері IT не все так добре ...

Під IT менеджерами я маю на увазі тімліда, керівників проектів, начальників відділів, скрам майстрів, лайн менеджерів і т.д. З топ менеджментом справи виглядають краще, так як їх або надсилають через бугра, або це представники рідкісного виду управлінців-технарів, які іноді водяться в дикій IT середовищі.

Освіта

Якими властивостями повинна володіти хороший менеджер? По-перше, він повинен вміти комунікувати з різними людьми, а також ними керувати. По-друге, бути добре підкованим в суміжних областях - психології, економіці, юриспруденції, розбиратися в таких питаннях, як мотивація, моральний ризик, оцінка ризиків, попит-пропозиція, трудове законодавство, міжнародне право, інтелектуальна власність.

Ці предмети номінально викладають в технічних університетах, але їх кількість і якість прагнуть до нуля. Таким чином, університетська освіта ніяк не вирішує питання виховання IT менеджерів.

Так де ж брати IT менеджерів? З суміжних областей менеджерів не візьмеш - у них банально не вистачить кваліфікації.

Залишається єдиний варіант - вирощувати менеджерів з розробників. А це має кілька проблем, одна з яких - потрібно міняти мислення.

Проблема в тому, що змінити мислення за день або тиждень неможливо. За експертними оцінками, процес транформации мислення займає від півроку до чотирьох років.

І ось тут криється одна з головних проблем. Середня тривалість роботи IT фахівця в одній компанії - 1.5-2 року. Тому компанії можуть бути практично на 100% впевнені, що розробник не буде працювати в їх компанії, коли закінчиться процес його навчання. Таким чином, немає сенсу і починати його вчити ...

Друга проблема в тому, що рідкісний розробник буде дивитися наперед на 3-4 роки і стане планувати своє менеджерське майбутнє ... без зовнішнього втручання. На жаль, HR більше стурбовані, як захантіть чергового джавіста і закупити нову партію печенек, щоб хоча б ці не розбіглися.

Також потрібно пам'ятати, що хорошим менеджером може стати далеко не кожен технар. Схема «сьогодні - кращий розробник, завтра - хороший менеджер» не працює. Можна втратити хорошого розробника і отримати поганого менеджера. Економічний ефект від цього навіть не варто починати рахувати.

Робота менеджера будується на управлінні людьми. Проблема в наступному: щоб стати хорошим IT фахівцем, потрібен лише комп'ютер, інтернет і бажання; хорошим менеджером без практики стати навряд чи вийде.

відповідальність

Ще один момент, які багато втрачають. У будь-яких ситуаціях за все, що відбувається в команді розробників, відповідальність повинен нести менеджер (керівник).

Ще раз повторюся: за все косяки в команді повинен відповідати менеджер.

У століття скрам і гнучких методологій відповідальність розмазується серед членів команди, керівників і замовником, тобто відсутня персональна відповідальність. Не потрібно говорити, що це дуже вигідно компаніям і самим розробникам.

Приклад з життя: як-то поставив запитання своєму менеджеру, хто візьме на себе відповідальність за нереальну оцінку, відсутність кваліфікованих кадрів і впроваджену методологію управління під назвою scrumно. На що отримав здивований відповідь: все. При персональної відповідальності за свою роботу нічого подібного б не було. Думаю, не потрібно говорити, що проект з тріском провалився, і ніхто при цьому не поніс персональне покарання.

Розуміти і нести персональну відповідальність за себе і своїх підлеглих - це одне і найважливіших властивостей хорошого менеджера.

До речі, є ще один побічний ефект: через, не побоюся цього слова, тупих менеджерів деякі нормальні фахівці змінюють місце роботи, а деякі починають схилятися до думки, що краще взагалі працювати без менеджерів (статті на подібну тематику легко можна відшукати в інтернеті) .

Далеко ходити не треба: в одній компанії я і мої колеги протягом кількох місяців приховували реальний стан справ від менеджера, щоб він не дай бог не втрутився в процес розробки і не похєрив все те, що без його участі відмінно працювало.

Також кілька разів спостерігав ситуацію, коли менеджери через деякий час відмовлялися від своїх посад і назад перетворювалися в розробників. Причин кілька: зростання зарплати, як правило, незначний (якщо взагалі є), а обов'язків і головного болю - на порядок більше.

До того ж ситуація, коли розробник заробляє більше свого менеджера, - не рідкість в IT компаніях, хоча в інших сферах таке трапляється вкрай рідко. Цим також можна пояснити небажання багатьох технарів перетворюватися в менеджерів.

замість висновку

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