Окремий «велосипед» розвитку developer-а відмінний від FAANG

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

Питання взаємодії окремого developer-а в межах проекту/компанії з позиції росту кваліфікації самого розробника все частіше питання з розряду «включити мізки», аніж питання впровадження шаблонних/перевірених підходів (must have у вигляді самоосвіти/саморозвитку по дефолту завжди).

Матеріал я виклав на основі ідеологічних принципів, які закладав у спеціалізоване програмне забезпечення, створене в листопаді 2021 р. для своїх колег-developer-ів в компанії у якій реалізовую в тому числі роль teamlead-а.

Ця стаття — бажання отримати feedback співтовариства саме у питанні нюансів розвитку developer-а в рамках конкретної продуктової (передусім, але не принципово) компанії.

Для спрощення, можете образно вважати мене граючим тренером достатньо міцної футбольної команди, яка прагне завжди стабільно претендувати не самі значимі трофеї і при цьому не вважає вірним досягати поставлених цілей необмеженим кредитом в банку «Томсон енд Френч» за Катарською схемою ФК «Парі Сен-Жермен» чи Мадридського «Реалу». Якщо Вам є, що сказати як «футбольному» (читати ІТ) спеціалісту в питанні прокачки команди, буду вдячний за фахову думку.

Основні поняття:

0.1. «План Розвитку» (альтернативна назва — «Дорожня Карта» developer-а після «ребрендингу», так Компанія собі вирішила з 07.2022) — це план/карта куди developer-у рости/рухатися у своєму розвитку і в рамках яких саме конкретних технологій/проектів Компанії.

0.2. Спеціалізоване Програмне Забезпечення «Центр Компетенцій», покликане допомогти спроектувати та реалізувати «План Розвитку».

0.3. Дерево (матриця) Компетенцій — набір компетенцій (переважно технологічні skills) деревовидної структури імплементований в ПЗ «Центр Компетенцій» для проектування «Плану Розвитку» конкретного developer-а.

0.4. «техаудитор» — обособлена або комбіновані ролі по відношенню до developer-а:

0.4.1. техлід/провідний розробник у конкретному проекті developer-а;

0.4.2. роль, що робить постановку/приймання завдань у TFS (або аналогу) виходячи з ТЗ чи його окремих task-ів (у ролі обов’язкова наявність технічного background);

0.4.3. надає технічну консультативну допомогу у процесі реалізації окремого ТЗ/task-и чи здійснює code review;

0.4.4. затверджує pull request щодо розробок developer-а;

0.4.5. виконує роль, пов’язану з викладеним вище у цьому пункті, наприклад, ментор.

0.5. Аксіоми дають відповідь на ключові питання «Плану розвитку»: як і на основі чого проектується і яким чином реалізується «Плану розвитку» developer-а.

0.6. Програмне забезпечення «Центр Компетенцій» передусім створювалося як інструмент підтримки та розвитку developer-ів Компанії.

0.7. В ПЗ «Центр Компетенцій» не зашиті якісь ідеологічно приховані цілі, це виключно проект-подарунок більш досвідчених developer-ів Компанії всім іншим і ми маємо великі сподівання, що цей інструмент буде використано саме для підтримки/розвитку наших колег, а не якимось іншим чином.

Аксіоми проектування та реалізації Плану Розвитку developer-а:

1. Прокачування знань планується на 6 місяців, але кінцеві терміни залишаються завжди за developer-ом, якщо інше окремо не обумовено teamlead-ом або кимось з техаудиторів (наприклад, знання потрібні під конкретний проект на певну дату).

2. Developer, ознайомившись з деревом компетенцій і розуміючи можливості свого розвитку в рамках великої компанії, насамперед самостійно проектує п.1 (через «Шаблони ДК» в ПЗ «Центр Компетенцій») для подальшого обговорення та фіксації кінцевої редакції «Плану розвитку» teamlead-ом або погодженим з teamlead-ом техаудитором.

3. Базовими (пріоритетними) у ЦК «.Net/SQL» є компетенції: C#, MS SQL,. Net Core.

3.1. «Пріоритетні» — це ті, які найчастіше потрібні в проектах Компанії в межах сегменту «.Net/SQL».

3.2. До значимих також належать допоміжні компетенції, тісно пов’язані з базовими, наприклад: .Net Core + RabbitMQ, MS SQL + Service Broker і т.п. комбінації.

3.3. Чим вище рівень знань developer-а в базових/значимих компетенціях і чим більше проектів, в яких він ці базові компетенції застосував, тим ціннішим співробітником він є для Компанії.

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

3.5. Невід’ємною складовою якості, а значить, цінності для Компанії практично завжди є комплексне архітектурне розуміння проекту, в якому Ви працюєте і Ваші навички алгоритмізації, тому не слід ігнорувати такі компетенції, як IO/UML-схеми процесів чи методики розробки ПЗ (Scrum, Kanban, Waterfall).

4. Оптимальна схема реалізації «Плану розвитку» — це конкретні результати Вашої роботи в Компанії та потенціал багажу знань і здатність їх якісно/оперативно застосувати в проектах з різними технологіями та масштабом.

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

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

4.2. Досить компетентно роботу/рівень developer-а можуть оцінити техаудитори, тому чим більше кваліфікованих техаудиторів в пулі developer-а, тим легше спроектувати збалансований «Плану розвитку» та пройти його реалізацію.

4.3. Часто варіантом реалізації «Плану розвитку» обирають проходження курсів по базовим/значимим компетенціям, які підтверджуються сертифікатами з подальшим використанням компетенцій в реальних проектах.

4.4. Значимим для «Плану розвитку» є менторство — технічний on-boarding нового учасника ІТ-Аутсорс рівня Junior або Middle (в окремих випадках Strong Middle).

4.5. Об’єктивним інструментом реалізації «Плану розвитку» є «шерінг знань» — структурована та зручна для використання фіксація на загально-доступних корпоративних ресурсах знань повторного практичного застосування у реальних проектах.

5. «План Розвитку» в ПЗ «Центр Компетенцій» — це наразі самобутня площадка взаємодії між Компанією та developer-ом і допоки її не замінили на якісь «потогонні» чи бездумно формалізовані системи «як у сусіда», варто скористатися можливістю отримати від цієї схеми максимальний потенціал для особистого росту та розвитку, тим паче значний пул проектів Компанії створює для цього ідеальні умови.

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

5.2. Можливе форсоване освоєння специфічної компетенції, якщо вона потрібна під конкретний проект і developer визначений як такий, що у зазначені строки має здібності та час освоїти специфічну компетенція на належному рівні якості її застосування у зазначеному проекті.

5.3. «План розвитку» може містити переймання досвіду колеги у конкретному проекті з подальшим самостійним супроводом developer-ом цього проекту або перекваліфікацією developer-а у техліда чи ведучого розробника проекту.