Будуємо сильну команду: від 0 до 100

[Дмитро Зінов'єв — Software Engineering Manager в EPAM, 11 років в IT]

Всім привіт! У цій статті я хочу поділитися практиками побудови сильних команд, які я зібрав за 12 років роботи в цій сфері. Моя розповідь буде в контексті компаній, які успадковують сервісну модель з можливістю розширення зони відповідальності до рівня консалтингу.

Історія моєї команди

Чотири роки тому ми починали роботу командою 20 хлопців. Був тільки потенціал і нестримне бажання ростити експертизу, щоб мати можливість працювати з проектами будь-якої складності і технологічних стеків. Мета була працювати на перспективу, не потопаючи в поточній реальності. Крок за кроком, квартал за кварталом ми побудували ці процеси. Через два роки повторили цю стратегію з двома новими дисциплінами в нашій команді. Зараз у мене в команді більше 170 чудових і компетентних фахівців. 80% команди продовжує розвивати і інвестувати в практику на регулярній основі.

Які труднощі виникають

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

Поки це проект на пару місяців з універсальною командою в 1-3 людини, все йде передбачувано і поправимо. Складнощі виникають, коли це команда з 10-50 різнопрофільних фахівців на проекті з фіксованою вартістю та термінами. До того ж такий проект у вашій компанії не один. І успішне завершення поточних проектів — лише проміжна мета. Компанія повинна перманентно думати про майбутні перспективи і нові можливості.

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

В таких умовах головна інвестиція будь-якого керуючого — команда. І завдання полягає в тому, щоб набрати сильних і самостійних людей з ринку. Мета — безперервна інвестиція в лідерів (Continuous Leadership Growth). Це непростий підхід, так як окупність інвестицій місцями вимірюється роками.

Навіщо потрібна безперервна інвестиція у лідерів?

Розглянемо стандартний процес старту нового проекту, не вдаючись в деталі. Ми отримали Request for Proposal (RFP). Шляхом тривалого аналізу і спілкування з клієнтом ми підготували прагматичний варіант з нашим рішенням, закладеними ризиками, планом та іншими артефактами. Опустимо pre-sale фазу і припустимо, що шляхом складних переговорів ми виграємо тендер на умовах команди з 20 осіб і терміном на рік. Для систематичного досягнення результату нам потрібна команда ключових фахівців в розмірі 4-6 осіб (для мене «ключовий фахівець» — це спеціаліст з атрофованими слізними залозами і високою компетентністю у предметної області).

Що якщо у нас одночасно стартують кілька проектів? Що якщо у нас немає вільних фахівців такого рівня зараз? Набір молодих фахівців лише дасть ілюзію руху на старті. Як показує статистика останніх років, знайти ключових людей вкрай складно, тим більше в такій кількості і в стислі терміни.

Ми опиняємося на порозі часу, коли просто «споживати» IT-ринок фахівців вже недостатньо. Ми повинні самі інвестувати в його розвиток.

Безперервна інвестиція в лідерів

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

Особливість CIS-ринку

На просторі СНД IT-фахівці ростуть в основному емпіричним шляхом, не маючи профільних установ для підготовки production ready software engineers. Плюси — люди досить мотивовані, так як прийшли в IT більшою мірою на своєму ентузіазмі. Мінуси — у людей часто немає чітко структурованого вектора професійного зростання. В середньому при такому підході люди виходять на рівень ключових фахівців через 5-8 років. Деяким недостатньо і 10 років.

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

Я хочу поділитися практиками, які активно використовую останні 7 років. Саме вони допомогли мені збудувати сильну команду.

Профіль фахівця

Років 7 тому загальне число кандидатів з ринку говорили, що у них в компаніях немає градацій за рівнями фахівців, посилаючись на те, що це лише посилює ефективний процес розробки. Я готовий погодитися з цим твердженням лише в тому випадку, якщо компанія готова звільнити молодих фахівців і залишити на посаді Software Engineer лише ключових людей, здатних самостійно вести проекти. В іншому випадку у них є градація, нехай і неформальна.

Для чого потрібні градації рівнів і розуміння їх кореляцій щодо фахівців в компанії?

Беремо стандартний розподіл на junior, middle та senior. Кожен професійний рівень складається не тільки з набору технічних навичок. Мета кожної посади — це роль і пов'язані з цією роллю рівні відповідальності, які фахівець може на себе взяти і успішно виконати поставлене завдання. Тобто за даною шкалою спеціаліст рівня senior, крім хорошого технічного досвіду, повинен бути самостійним, мати навички вибудовування відносин з командою і клієнтом, працювати з конфліктами, ефективно інтегрувати нові тренди, брати на себе відповідальність за результат, тим більше, якщо той був побудований на базі його пропозиції, і так далі. Зауважимо, що вимоги до персональних навичок (soft skills) настільки ж високі, як і до технічних.

Об'єктивно, кожен ключовий фахівець в компанії, яким поставлять мета найняти іншого ключового фахівця, буде мати ясну картинку в голові, що останній повинен з себе представляти і з якими завданнями повинен уміти справлятися. Формалізувати першу версію профілю фахівця — справа кількох днів. Тим більше, якщо у компанії вже є експертна група.

Це дає прозору картину в першу чергу для молодих фахівців, до чого потрібно прагнути в рамках даної організації.

Прозорість зростання для фахівця і компанії

Маючи профіль рівнів та спеціалізацій, компанія легко може побудувати індивідуальний план для кожного спеціаліста. Побудувати план не становить праці — практично кожна компанія це так чи інакше робить. Наприклад: «Прочитай книгу з управління командами і будеш Team Lead». Але труднощі не пов'язані з якістю цього плану. Є два підводні камені.

Якщо фахівець виконає поставлені перед ним завдання? Компанія, швидше за все, повинна буде піти на два кроки: переглянути фінансову сторону питання і перевести людину на нову роль. Припустимо, у фінансовому питанні обидві сторони прийшли до компромісу. Що стосується нової ролі, це не повинна бути лише гучна посаду: «Все, тепер ти Team Lead, продовжуй педалить». З новою посадою повинні розкриватися нові зони відповідальності і завдань. На жаль, в деяких компаніях люди можуть формально пройти шлях Software Engineer, Team Lead, Business Analyst, Product Owner, але при цьому неформально залишатися Software Engineer, не отримуючи нових знань у суміжних областях.

Компанія надала план зростання, але як вона готова його підтримувати? «Ось план, ось проекти — майбутнє в твоїх руках!», — далеко не завжди робоча схема для ефективного зростання фахівців.

Існує три помилки стосовно ефективного зростання шляхом зміни проектів.

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

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

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

Хто мав досвід роботи на freelance з моделлю оплати за годинник роботи з кодом, той знає статистику, коли на розробку в середньому йде 3 години, плюс 3 години на прочитання документації і роздуми, як цей код написати. Втрата двох годин в день веде до втрати одного тижня на місяць. Це дуже багато і, безумовно, може бути використана для професійного розвитку та отримання нових навичок.

Третє оману. Між проектами рідко змінюється складність. Зміна предметної області привносить нові тонкощі, але для Software Engineer абстрактно завдання мають загальні риси: сутності, колекції, міжмережеві взаємодії, форми, валідація, API і так далі. По суті, для молодого фахівця всі проекти можна викрити в один домен, наприклад Healthcare або CMS. Якщо роль фахівця залишається незмінною, то з часом він лише набиває руку для більш ефективного виконання однотипних завдань.

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

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

Підготовка молодих кадрів

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

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

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

Тренінги та наставництво

Навчання — процес перманентний. Сервісна або консалтингова компанія, яка орієнтується на результат, повинна інвестувати в зростання своїх співробітників на регулярній основі. Хтось скаже: «Що якщо ми навчимо співробітника, а він піде з компанії?». А варто запитати: «Що якщо ми не навчимо цього співробітника і він залишиться?». Тренінг-програми повинні мати місце як для молодих кадрів, так і для досвідчених ключових фахівців, архітекторів і менеджерів.

В чому суть тренінгів? Тренінг поряд з гарною книгою систематизує зібраний досвід спеціаліста. В умовах динамічно розвивається індустрії ми можемо зустріти ситуацію, коли молодий розробник або менеджер потрапляє в складний і якісно організований проект. Для інтеграції та адаптації в проектні практики і процеси йому, можливо, буде досить поверхнево ознайомитися з цією темою. Швидше за все, прочитати пару-трійку статей. Через тиждень-два він вже активно залучений у процес розробки. Це добре з точки зору проекту і продуктивності праці. Але подібні ситуації викликають помилкові почуття компетентності фахівця. Йому може здатися, що він в змозі побудувати подібні практики і процеси власноруч в будь-якому іншому проекті. Від цього усвідомлення, на його думку, зростає і його вартість на ринку.

Якщо ж дати такого фахівця можливість реалізувати себе в умовах нового проекту, то ситуація може вийти з-під контролю. Чомусь клієнт не готовий використовувати автоматизоване тестування, проектна команда не згодна зі стратегією роботи в системі контролю версій, команда розробників не вірить в TDD і всіляко саботує цей процес і так далі. Кожен процес має свої корені виникнення, сильні і слабкі сторони. Вміти знайти баланс і поставити процес на рейки, тим більше у вже існуючому проекті, досить складно.

Тренінг в сукупності з наставництвом систематизує знання і допомагає застосувати частину з них на практиці, долаючи можливі несприятливі обставини. У добавок до всього, подібні ініціативи найчастіше не мають прив'язки до існуючих проектів. Що знижує їх пріоритет на користь виробничих завдань. А значить і ця ініціатива потребує сильних лідерів на місцях.

R&D, інвестиції в нові тренди

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

Буде попит — знайдемо людей, у чому складнощі? Проблема в тому, що на ринку не буде компетентних фахівців з 10-річним досвідом у новій технології відразу після її релізу. Отже, компанія починає програвати в конкурентній боротьбі.

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

Розглянемо обидва кроки окремо.

Аналіз включає в себе занурення в тему, грунтуючись на бізнес-контексті, з яким ми працюємо. Наприклад:

Часом негативне рішення зрозуміло вже в перші дні аналізу, базуючись на життєво важливих вимогах. Результатом аналізу має стати звіт або презентація. Швидше за все, ці документи знадобляться не для одного клієнта.

Внутрішній проект. Тут головне не загратися. Ілюзія розв'язаних рук може довести до надто складних рішень. Таких собі універсальних конструкторів або платформ. Подібні ініціативи повинні слідувати тільки після ствердної результату аналізу, що дане рішення має право на життя і потребує більш детального заглиблення у предметну область. Результатом має стати MVP максимально релевантний бізнес-завдань, з якими стикається компанія в проектах. За статистикою подібні результати можна продемонструвати вже через один-три місяці. Остаточне рішення наочно демонструє потенційні сильні або слабкі сторони і може служити фундаментом конструктивних переговорів.

Співтовариство і глобальний досвід

У більшості компаній є переважаючі спеціалізації, які зустрічаються на кожному проекті. Кожен фахівець несе унікальний досвід. На жаль, в більшості випадків люди не перетинаються один з одним за межами своїх проектів. Тим більше якщо компанія розділена на декілька офісів, міст або країн. Це призводить до однотипних помилок, які раніше, можливо, були вчинені іншою командою і яких можна було б уникнути.

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

Оцінка

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

У моїй практиці формат формального check list і прийняття рішення на підставі думки керівника працювали малоефективно і лише породжували більше питань.

В першу чергу бажання людини зростати професійно і виходити на нові горизонти свого потенціалу повинні будуватися на вже досягнутих результатах. Підвищення як інвестиція працює погано. Я схиляюся до підвищення як констатації, що фахівець вже відповідає новій ролі.

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

І як фінальний крок — оцінка потенціалу. Церемонія оцінювання повинна відрізнятися від типових співбесід. Уявіть собі, що ви є лідером команди з п'яти чоловік. У вашому проекті три команди. Від результату роботи всіх команд залежить успішність проекту. Успішно завершимо проект — отримаємо хороші бонуси. Завалимо проект — вся проектна команда виявиться без роботи. В процесі роботи ви отримали нову зону відповідальності і повинні зібрати четверту команду. Як ви будете проводити співбесіду нового лідера четвертої команди? Вам менш важливі досконалі теоретичні знання. Куди важливіше, як буде міркувати людина в розрізі тих реальних ситуацій, які він може зустріти на проекті.

Підводячи підсумки

Всі ці процеси і мої думки не є останньою інстанцією. Кожен з процесів, ми міняли з часом, якісь зовсім виключали з практики і додавали нові. Мета: планувати наперед і нівелювати ризики обставин, які існують на ринку.

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

Опубліковано: 18/09/18 @ 10:00
Розділ Різне

Рекомендуємо:

Як провести Discovery на новому проекті: конкретні кроки і приклади
Python дайджест #17: Python reaches Tiobe index TOP 3
GPGPU via C#: короткий огляд
Raspberry Pi — іграшка для pet-проекту або мікрокомп'ютер для highload продукту
Пожежна команда і біг на випередження: як ми будуємо Java Competence Center в EPAM