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

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

Це не зовсім вірне твердження, наприклад, в Microsoft (стосується також ін. ІТ-гігантів) Software Developer — це спеціаліст, який може вирішувати вузькі задачі, а Software Engineer — це спеціаліст, який має продвинуте розуміння бізнес-логіки та інжинірингових вимог, між ними різниця не тільки в наявному досвіді, а загалом в мотивації мати широку експертизу, і це не нова тенденція, а стала ситуція щонайменше ще із позаминулого десятиліття.

Складно знаходити людей з доменною експертизою у специфічних сегментах. Наприклад, в нас є проєкти з обладнанням, де потрібні сертифікати безпеки, ASPICE-сертифікація в automotive, набори специфічних речей в industrial-сегменті тощо. Цих людей більше не стало, а попит на них лишається стабільним.

На жаль, хоча віцепрезидент зі стратегії та технологій у GlobalLogic декларує вірні речі, але на рівні найму ситуація категорично інша, наприклад, при спілкуванні з рекрутерами чи на технічному інтерв’ю (або взагалі на стадії скринінгу резюме) на менеджерські позиції в GlobalLogic віддають перевагу фактично тільки сервісному/аутстаф досвіду, а за наявність хорошої технічної експертизи буде вердикт — overqualified, ... а коли подаватися на позиції для проектів, наприклад, від Hitachi, де декларуються вимоги певних технічних скілів, то все рівно можна отримати відмову => типу класно, що у вас є експертиза в industrial/енергетичному/автомотів доменах, але нам в першу чергу потрібен менеджер-менеджер (фактично generalist в аутсорс/аутстаф) з досвідом роботи в аутсорс/аутстаф компанії подібній нашій за розміром і специфікою, ... тому немає ніяких описаних змін, щоб в GlobalLogic цінили продуктовий майндсет чи інжинірингову експертизу, як і проблема з наявністю менеджерів відповідальних за найм щоб вони могли якісно провести технічне інтерв’ю.

Всі фреймворки фокусуються на тому як розробити софт (scrum, kanban, XP...) або як виконати проект (PMI, Prince2..). Більш пізні, як SAFE, намагаються комплексно розглядати процес, поєднуючі дві складові і основи change management. Там, нажаль, не розглядається як жити в недосконалому світі недосконалих людей.

Фреймворки містять опис процесів та практик для виконання проектів щоб отримати розроблений продукт.
SAFe-фреймворк не є тим, що ви описали, основне, що він приніс — це додаткові процеси і практики щоб можна було масштабувати Scrum для більш комплексних проектів та з великою кількістю розробникі (50+ осіб).

Щодо ITIL — це набір практик для IT Service Management (управління інцидентами, проблемами, конфігураціями і т.д.). Це окрема ніша ІТ бізнесу під специфічні задачі обслуговування софта. Наприклад, наша материнська компанія впроваджує ServiceNow і надає супутні послуги. Я не можу погодитись, що це єдиний посібник для ІТ проектів, або ми з вами по різному розглядаємо термін.

IT Service Management — це тільки одна із частин ITIL, а позиціонувати це як єдине призначення було б все рівно, що сказати типу достатньо лише розробки фронтенду для певного веб-проекту.

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

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

Щодо заголовку: я розглядаю проблеми, які виникають, по суті, через клієнта. Чи є підрядчиком сервісна, продуктова чи інфраструктурна компанія, то вже другорядне. З мого досвіду, з продуктом були ті самі проблеми

Ви допустили помилку.
Також хочу нагалати, що згідно PMBOK ви мали б уникати Conceptual ambiguity:
Conceptual ambiguity in the context of PMBOK refers to a situation where there is a lack of clarity or multiple interpretations about a specific concept or idea related to the project. This can lead to misunderstandings, miscommunications, and potential project risks.
... як мінімум подібне призводить до проблем з комунікацією, як максимум до проблем з імплементацією проекту.

Так. Але це не політика, а політики. Як набір якихось правил. І це справді має сенс. І мені здається, що автор описує саме політики.

Політика чи політики — це різниця однина чи множина (річ про конкретну політику чи про список), але я мав мав на увазі політику в управлінні (policy) uk.wikipedia.org/...​i/Політика_(в_управлінні

Хоча, як виявилося в коментарі нижче, в авторки своє розуміння цього слова, як намагання описати ним корпоративну культуру uk.wikipedia.org/...​iki/Корпоративна_культура

+Дана стаття скоріше має відношення не до озвученого заголовку «Чому провалюються ІТ-проєкти: політика в технологічних змінах», а до проблем з стейкхолдер/енгейджмент/аккаунт менеджментом в сервісних (аутсорс) компаніях.

Ви зазначили наступне =>

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

Хоча я не побачив від вас чому недостатньо практик описах для певного фреймворку, наприклад, в XP, яких достатньо було для такого гіганта як Microsoft чи взлетівшого стартапу Uber.

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

ITIL є метолологічним посібником, я не знаю як ви це надаєте як послугу, напевно, річ про те, що від клієнта є вимога сертифікації чи досвіду спеціалістів відповідно ITIL. А стосовно цифрової трансформації, то це одне із очевидних застосувань ITIL, і одна із книг присвячена саме цьому — ITIL 4 Digital and IT Strategy.
Запитання про ITIL поставив, бо це фактично єдиний крупний методологічний посібник для ведення ІТ-проектів, ... наприклад, для PMBOK, як для «Біблії проектного менеджменту», ІТ-проекти не є цільовим доменом, хоча в українських аутсорсних компаніях — це один із основних фокусів, ще й типу коли менеджерам не подобається останнє 7-ме видання PMBOK, а керуються попереднім, яке ще менше має відношення до ІТ 🙃

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

В даному випадку річ про політику в управлінні, англійською — це policy en.wikipedia.org/wiki/Policy
Ось приклади політик для компанії www.indeed.com/...​e/c/info/company-policies

Дякую за статтю!
Мав очікування, що основний фокус буде на ризик-менеджментові — приклади формування реєстрів ризиків та практики їх пом’якшення чи уникнення, але ви поділилися досвідом переважно стейхолдер менеджменту.
Маю також запитання, чи використовуються в Luxoft практики описані в ITIL при імплементації проектів з цифрової трансформації бізнесів клієнтів?

Спільното, чи погоджуєтеся з такою думкою? І наскільки добре університет підготував вас до майбутньої роботи в ІТ?

З думкою Олени Самборської не погоджуюся. Університет підготував мене дуже добре до майбутньої роботи в ІТ, хоча спеціальність в мене була не ІТшна (як, напевно, у суттєвої частини айтішників), хоча були предмети з програмуванням на С/С++, Pascal і Assembler, математичним моделюванням та скріптами в САПР, а також знання з електромеханіки були корисними в Embedded-розробці, тому велика частина набутих знань була корисною, ... і загалом університетська освіта ще й добре розвиває підхід до самонавчання.

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

Керуючись логікою пані Олени, випускники ВУЗів повинні бути зразу готові до => проектування мостів та житлових будинків; обслуговувати дуже дороге і складне обладнання задіяне в певних технологічних процесах; робити легкі-складні хірургічні операції; молодші лейтенанти з досвідом військової кафедри кращі за сержантів із 2ма роками бойових дій (бо тайтл вище); and so on ...

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

неправильно після пʼяти років у технічному виші випускати джуна. Це має бути, як мінімум, мідл

В такому випадку — це має бути Індійський мідл, де, як жартують, народжуються джунами, а з ВУЗу випускаються мідл-сініорами, ... чи як в тому бородатому анекдоті: «- Ну і ти кажи».

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

Пересічний військовий недостатньо компетентний в питаннях безпеки, тому є ризики не тільки з з telegram, а загалом =>
Хакери РФ атакують мобільні українських військових через Telegram та Signal www.epravda.com.ua/news/2024/05/15/713699

Про захищеність telegram з точки зору професіонала в криптографії => twitter.com/...​tatus/1789687898863792453

Тобто якщо беремо за основу іншу систему — то тоді маємо певні результати цієї системи

“1964–1975. More than 300,000 Black Americans served in Vietnam. Though only about 12% of the U.S. population, Black servicemembers were 16.3% of the armed forces, and up to 25% of enlisted men in the Army, but only 2% of officers across all branches.” ©

“Robert McNamara’s Project 100,000, implemented in 1966, pulled hundreds of thousands of poor men into the war—40% of them African American.” ©

“After Ali’s title defense against Zora Folley on March 22, he was stripped of his title due to his refusal to be drafted to army service. His boxing license was also suspended by the state of New York. He was convicted of draft evasion on June 20 and sentenced to five years in prison and a $10,000 fine.” © en.m.wikipedia.org/wiki/Muhammad_Ali

Взяв за основу “іншу систему”, результатом для США був програш в останній великій для них війні.

Далі можна не читати — тяжко зрозуміти що треба мати у черепі що дійти до такої геніальної ідеї.

Це схоже на варіацію популярної останній рік стратегії «Quiet cutting» en.wikipedia.org/wiki/Quiet_cutting

Може бути гірше чим описала пані Оксана

The ‘Quiet Cutting’ Trend Is A Controversial Leadership Strategy, New Study Shows www.forbes.com/...​dy-shows/?sh=2f3ea7951db9

Стаття не про soft skills, а про рівні компетенції.
Також можу порекомендувати ознайомитися з різницею між Competence vs. Competency www.indeed.com/...​/competence-vs-competency

Вітаю!

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

Нуу, перед вами був весь ринок для світчу в менеджмент, відповідно у вашої компанії також, вони могли найняти вільного кандидата з ринку чи захантити в іншої компанії, а для промоушна всередині компанії більш логічною була би кандидатура Senior Project Manager => Delivery Manager.

З приводу саме назви цієї позиції Ви, як і решта коментаторів, підмітили добре. Позиція в різних компаніях може мати різну назву, різний список обовʼязків, залежно від розміру компанії.

Згідно традиційного проектного менеджменту є «магічна» абревіатура PMO (Project management office), деякі спеціалісти навіть називають себе PMO, маючи на увазі Project Management Officer, хоча не існує такої ролі згідно PMBOK, ... тому якщо річ про стандартизований тайтл, то ваша позиція мала називатися PMO Director.

Також впливає розмір акаунту, розмір та кількість проектів в цьому акаунті. Я знаю приклад однієї компанії де найбільший акаунт — це був один проект близько 200 людей, яким керував client success manager, він мав в підпорядкуванні делівері директора, той мав 3 чи 4 делівері менеджера а вони в свою чергу скрам мастерів. В такому сетапі обовʼязки ДМа були досить вузькими і дійсно не зрозуміло чому це не ПМ, а саме ДМ.

Обов’язки DMа дійсно досить вузькі, якщо розглядати тільки фокус на делівері процесах, а не той «Full-stack PM», що ви описали в статті.
А стосовно прикладу з 200 людей, то річ може бути про N проектів в рамка розробки/розвитку певного комплексного продукту, де можна було задовольнитися традиційними ролями: типу Program Manager, Principal Project Manager і Project Manager, а роль SM могли виконувати ліди розробники. Також такі продукти вже давно досить популярно розробляти згідно фреймворку SAFe, де є прописані зовсім інші ролі і більшість яких може бути на стороні клієнта, а менеджмент на стороні аутсорсної компанії в основному сфокусований на: білінгові акаунту, атрішн та конфлікт резолюшн, ... і SAFe є майже безальтернативним, якщо є вимоги до розробки дотримуватися Quality Management System (QMS) згідно ISO 9001.

Взагалі ця позиція на сьогодні не є новою в українському ІТ як це було скажемо 10 років назад, тому дивно що етимологія саме назви і не стандартизований список обовʼязків викликає таке здивування. Хоч її і немає в ПМБОК проте вона досить сильно закріпилась на нашому ринку, клієнти розуміють що це за роль та з моїх спостережень зараз більшість позицій ДМ в компаніях мають приблизно такий самий опис обовʼязків який я описав у статті.

Напевно, за такий час ваша компанія суттєво виросла в розмірах, і якщо на момент вашого промоушна була т.з. «сімейного типу» і вам запропонували позицію DMа, то це також був суттєвий ризик для них, бо ви ж не мали необхідного досвіду, в підсумку навчалися на новій позиції і своїх помилках, ... загалом на нашому ринку шукають DMів з досвідом більше 5 років в менеджменті.
Для малих та середніх українських ІТ-компаній в процесі росту та трансформації є 2 підходи: 1) городити щось своє в менеджменті (що досить ok для продуктових), або 2) створювати PMO (Project management office).

Здивований, що автор маючи хороший технічний бекграунд обрав шлях в менеджменті по бізнес напрямку (вести акаунти), а не Engineering manager і далі.

Хоча в статті добре описані повноваження ролі, яка може по різному називатися в українських сервісних ІТ-компаніях (аka аутсорсних), але в класичному менеджменті не існує такої ролі.

Пояснення від Gemini, Who is the Delivery Manager according to PMBOK? =>

The Project Management Body of Knowledge (PMBOK) Guide doesn’t explicitly define a Delivery Manager role.

The PMBOK Guide focuses on the Project Manager role and its responsibilities. While delivery is a crucial aspect of project management, the specific tasks of ensuring delivery might be handled by the Project Manager or delegated to team members depending on the project structure and organization.

However, PMBOK does discuss aspects that align with delivery management responsibilities. These include:

Project Scope Management: Defining and controlling the project scope ensures deliverables meet requirements.
Project Schedule Management: Creating a project schedule helps track progress and ensure on-time delivery.
Project Cost Management: Managing the project budget is necessary for successful delivery.
Project Procurement Management: Acquiring the resources needed for project delivery.

While PMBOK doesn’t define a Delivery Manager, the concepts it outlines are relevant to successful project delivery.

Пояснення від ChatGPT =>

In PMBOK (Project Management Body of Knowledge), the term “Delivery Manager” isn’t explicitly defined or recognized as a specific role. However, there are related roles and responsibilities within project management that are crucial to successful project delivery. These roles often include:

Project Manager: This is the individual responsible for leading the project from initiation to closure. They are in charge of planning, executing, monitoring, controlling, and closing the project. The Project Manager ensures that the project meets its goals within the constraints of scope, time, cost, quality, resources, risk, and stakeholder expectations.

Program Manager: In the context of larger initiatives or organizations, a Program Manager oversees multiple related projects and initiatives that are grouped together to achieve strategic objectives. They coordinate between project managers, stakeholders, and other relevant parties to ensure alignment with the overall program goals.

Portfolio Manager: At an even higher level, a Portfolio Manager is responsible for overseeing an organization’s entire portfolio of projects, programs, and other initiatives. They prioritize projects based on strategic objectives, allocate resources, manage risks, and ensure that the portfolio aligns with the organization’s strategic goals and objectives.

While the specific title of “Delivery Manager” may not be standard in PMBOK, these related roles collectively contribute to the successful delivery of projects and organizational objectives.

Не можу охарактеризувати ваші манери з позитивної сторони і не знаю, що трапилося з вашою логікою, коли адресували мені даний коментар 🤷🏻‍♂️🤯

А стосовно «страшні історії з інтернетів», якщо ви на Техасщині з життя не знаєте, то ось вам з інтернету пара:

Why U.S. vacation policies are so much worse than Europe’s www.cnbc.com/...​h-worse-than-europes.html

8.7 Million Americans Now Work Two Jobs To Make Ends Meet Despite Inflation Continuing To Cool finance.yahoo.com/...​3011733.html?guccounter=1

Інша екстенсивна крайність — це США, де ok мати 10 днів для відпуски, але використати тільки половину, ... також для багатьох ok працювати взагалі ненормований робочий тиждень на 2-3 роботах, ... чи погодилися б ви на таке? чи все-таки в Європі краща ефективність праці і work-life баланс?

Дивно, що тема «dogfooding» не розкрита, ... бігло переглянув, що у вашої компанії є 3 продукти — це щось типу сервісів тестування email, дата скрепінгу та кращого перформансу при таск-трекінгу, от, на їх прикдаді могли описати dogfooding, або хоча би як дана техніка застосовується, коли клієнт аутсорсить ваші послуги розробки.

Також для повноцінного досвіду продакт-менеджера чи розробки комплексних продуктів потрібно обирати для роботи продуктову компанію, а не сервісну — це, напевно, ключова порада могла бути.

PHP developers drive Lambos 🙃

www.youtube.com/...​app=desktop&v=As2aivqvBpk

Для рубістів бувають жирні вакансії із ремоут культурою і без залежності від локації, ось хороший приклад нещодавно був від зановника фреймворку Ruby on Rails на 170К (там на борді jobs.rubyonrails.org є поточні не гірші відкриті вакансії) twitter.com/...​tatus/1766211428644421726

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

Знання для даної сертифікації потрібні дуже широкі, тому навіть досвідчений архітект, DevOps чи Cloud-інженер не пройде тестування без підготовки, ... і, наприклад, на курсах від Google іноді трапляється, що лектора можуть запитати досить нескладне запитання стосовно певного продукту, сервісу чи функціоналу на GCP, в якому він не є фаховим спеціалістом, але він відповідає, що не знає чи може помилятися, тому уникає відповіді, ... до речі, в 2-х пробних тестах згаданих мною вище, я зробив декілька помилок і було ще декілька запитань в яких сумнівався у виборі між 2-ма варіантами (хоча не помилився), але я не тільки для себе зробив висновки в чому потрібно зробити акцент в підготовці, а також мав роботу над помилками, коли використовуючи ChatGPT та Bard хотів побачити яка в них буде логіка аргументації, але дані чат-боти не тільки дали помилкові відповіді на ті запитання, в яких я мав помилки, а також допустили помилки в запитаннях, в яких я мав сумніви, але не помилився.

ІМХО, сертифікат Cloud Digital Leader у випадку інженера скоріше свідчить про те, що це T-shaped спеціаліст, яких цінять працедавці, бо має не тільки сильну експертизу в конкретному напрямку розробки, а також системне бачення стосовно застосованих технологій та бізнес-процесів. Для інженера дана сертифікація може бути хорошим аргументом для переходу в Engineering management, або після такого фундаментальго досвіду може бути розуміння на чому далі фокусуватися в своєму професійному розвитку та пройти вже відповідну сертифікацію Associate рівня.