Чи потрібні менеджери в IT?

  image
 
 Ларрі Пейдж і Сергій Брін всерйоз вважали, що їхні компанії управлінці нема чого. У 2002 році вони спробували вибудувати горизонтальну оргструктуру — без менеджерів, керівних програмістами. Так, вважали вони, ніщо не заважатиме швидкому обміну і появі ідей. Крім того, їм хотілося відтворити ту атмосферу студентського життя, яка так подобалася їм в університеті. Експеримент тривав недовго: через кілька місяців його довелося припинити. Брін і Пейдж змінили свою думку про внутрішній устрій компанії, коли співробітники валом повалили до Пейджу з питаннями, далекими від творчості: з фінансовими звітами, скаргами один на одного і т.п. А вже коли компанія стала рости, її засновники переконалися, що управлінці корисні і в інших відношеннях: пояснюють стратегію, значимість проектів та їх черговість, налагоджують співпрацю в колективі, стежать за кар'єрним зростанням людей і за тим, щоб всі робочі процеси і системи відповідали завданням бізнесу.
 
Тим не менш, багато розробники досі вважають, що менеджери їм не потрібні. Чи так це? Давайте розбиратися разом.
 
 
 
 Коли менеджер — це погано
 
Дуже часто розробники незадоволені менеджерами. Замість того, щоб писати код і думати про ідеальну архітектурі, їх змушують заповнювати якісь звіти і займатися іншою нудною і незрозумілою роботою. Менеджери часто отсуствуют на робочому місці, беруть участь у величезній кількості мітингів, а результат їх роботи дуже складно вимірювати в рядках коду, а це якраз те мірило, за яке в результаті платить замовник.
 
Частка правди (причому, дуже істотна) у цієї точки зору є. Дуже часто менеджери, щоб виправдати відсутність будь-яких результатів своєї роботи, змушують своїх підлеглих малювати щоденні звіти, фіксувати кожен крок, наприклад, витрачений час на відвідування курилки, з метою імітації бурхливої ​​менеджерської діяльності. Деякі менеджери тільки тим і займаються, що "впроваджують процес", проводять скрамовскіе п'ятихвилинки й організовують мітинги з кожного приводу.
 
 Перше правило поганого менеджера: не знаєш, що робити — організуй мітинг.
 
Причина того, що багато ІТ-менеджери не дуже компетентні, полягає в тому, що у нас немає повноцінного освітнього інституту, який готував би менеджерів з ІТ-ухилом. Тому в менеджери часто йдуть або дуже погані, або дуже хороші розробники, або ті, хто в ІТ ніколи не працювали, але добре говорять англійською. У всіх цих випадках наявність менеджера на проекті, швидше, шкодить проекту, ніж допомагає.
 
 В одній компанії, де у відділі працювало близько десяти проджект-менеджерів, було проведено невелике опитування на тему: чи читали вони книгу "Deadline: роман про управління проектами". Результат був приголомшливий: книгу не читав ніхто. Питати про Бруксі і його міфічному людино-місяці ніхто не став.
 
Чому ніхто не готує менеджерів? Давайте займемося арифметикою. Щоб із айтішника зробити менеджера потрібно від 0.5 року (практично ідеальний і рідко зустрічається в дикій ІТ-природі випадок) до чотирьох років. Середня тривалість роботи айтішника в компанії — рік / півтора. Таким чином, якщо компанія почне вкладати гроші у процес трансформації "айтишник-менеджер", то з великою часткою ймовірності працями цього навчання скористаються конкуренти. Тому компанії із задоволенням навчають айтішників на курсах підвищення кваліфікації, але не готові вкладати в навчання менеджерів.
 
Що ж робити айтішників в такому випадку? По-перше, вирішити, чи хоче він в майбутньому бути менеджером. Якщо відповідь позитивна, то, починаючи десь з рівня мідл, потрібно паралельно з книгами за технологіями починати читати книги з психології, ризик-менеджменту і проджект-менеджменту.
 
 Коли менеджер — це добре
 
І все ж, для чого потрібні менеджери? Спочатку статті Пейдж і Грін вже трохи відповіли на це питання: пояснюють стратегію, значимість проектів та їх черговість, налагоджують співпрацю в колективі, стежать за кар'єрним зростанням людей і за тим, щоб всі робочі процеси і системи відповідали завданням бізнесу.
 
Хочемо додати в скарбничку ще кілька важливих завдань менеджера.
 Завдання № 1: бути стіною між замовниками та виконавцями
 
Якось одному нашому знайомому, будучи ще досить молодого віку, довелося виступити в ролі "23-річного сеньйора" (а ще й у ролі тім-ліда) для одного дуже серйозного замовника (Fortune 100). Проект був нескладний технічно, але непростий з точки зору інтеграції та вимог до апаратної середовищі. Для інтеграції була виділена окрема машина (на стороні замовника), де все благополучно запустилося. Але інженерам замовника цього здалося мало і вони вирішили розгорнути систему на персональному ноутбуці, а також на робочому комп'ютері. І в якийсь момент система не завелася. Довелося довго розбиратися чому, причому проблеми виникали одна за одною.
 
Це могло тривати досить таки довго, якби в ситуацію не втрутився менеджер. Він заборонив інженерам замовника давати виконавцю завдання без його відома і розгортати систему на неперевіреної залозі. Після цього втручання ситуація устаканилася, розробника перестали смикати, а проект був благополучно зданий через кілька днів.
 
 Завдання № 2: брати на себе відповідальність за весь проект
 
— У нас проблеми з проектом, — сказав якось топ-менеджер компанії, для якої робився проект. У розробника похололо всередині. — Але ти не переживай, це не твоя область відповідальності, — додав він.
 
Варто запам'ятати одну просту думку: програміст кодіт, менеджер відповідає. Якщо програміст погано накодо — в будь-якому випадку винен менеджер, адже він не простежив за ходом виполененія проекту та / або найняв НЕ відповідного співробітника.
 
Так, менеджер отримує більше булочок, але й відповідальність у нього на порядок вище.
 
 Завдання № 3: гарантувати досягнення мети в умовах обмеженого доступу до ресурсів
 
Причому йому потрібно гарантувати досягнення цілей як замовника, так і виконавців. Це вдається рідко. Адже менеджер стикається з мільйоном різних проблем: відсутністю та недостатньою кількістю кадрів, часу і бюджету, злим або компетентним замовником, відсутністю експертизи і т.д.
 
Але якщо менеджер може гарантувати результат, то не важливо, де, скільки і як він працює. Більш того, менеджер, який працюватиме по 7-8 годин на день — гарантовано завалить проект. Менеджеру повинні платити за його рішення і кінцевий результат. В ідеалі менеджер повинен отримувати основний дохід у вигляді бонусів за вчасно виконані проекти, а не за кількість продавлені в linkedin або skype годинах.
 
 Завдання № 4: бути мотиватором і стежити за розвитком підлеглих
 
Якби розробники нас запитали, в якій компанії найкраще працювати, ми б без роздумів відповіли: у тій, де у них буде адекватний менеджер (навіть якщо грошей там платитимуть удвічі менше).
 
В одній з компаній, ми програміст отримав великий кредит довіри від свого менеджера. Довіра полягало в повному схвалення прийнятих ним (програмістом) рішень, автономність роботи, допомоги при організації зустрічей розробників, навчальних курсів і поїздок на різноманітні конференції. Результат не змусив себе довго чекати: було відкрито новий відділ на 5-6 чоловік; знання, отримані на заходах, були впроваджені в робочий процес, на проектах почали використовувати сучасні технології та іструменти. Підсумок? Всі пропозиції інших компаній (включаючи пропозиції з більш високою зарплатою), протягом року-півтора були відхилені програмістом без краплі жалю.
 
Який він, ідеальний менеджер?
 
У Google виділяють 8 якостей хороших менеджерів:
 
1. Чуйний наставник.
2. Надає колективу свободу і не контролює кожен крок.
3. Стежить за успіхами підлеглих і намагається допомогти.
4. Компетентний і націлений на результат.
5. Вміє розмовляти з людьми — вислуховує і ділиться інформацією.
6. Допомагає підлеглим робити кар'єру.
7. Має чітке уявлення про майбутнє своєї групи і розуміє стратегію її роботи.
8. Володіє основними професійними навичками, тому може давати поради групі.
 
Ми б додали до цього портрета наступне: ідеальний менеджер повинен бути компетентним у питаннях авторського права, ризик-менеджменті, в таких областях, як психологія, мотивація, управління ресурсами, юриспруденція, а також повинен володіти рядом додаткових якостей: комунікабельність, твердість, справедливість, адекватність.
 
Ідеальних менеджерів мало, але якщо людина з такими якостями і навичками вам випадково попадеться, відмінні результати не змусять себе довго чекати.
  
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.