Не згадано в статті 99.9XXX% availability, як реалізовано у вас моніторинг Downtime в тиждень/місяць/рік?
Якщо річ не про автоматизацію задач за допомогою АІ, а тільки => «кількість серйозних помилок у проєктах зменшилася на 25% завдяки рекомендаціям AI», то варто було би також розкрити статистику % помилок із-за галюцинацій LLM-моделі?

Судячи з розміру компанії та орієнтовній кількості поточних проектів, можна було йти традиційним шляхом — створювати PMO на чолі з PMO Director. Але описується структура типу з Project Coordinators підлеглими до Delivery Manager, якому постійно доводиться займатися мікроменеджментом. Хоча даний керівник проектного офісу мав би залучатися в критичних випадках, можливостях апсейлу та змінах пов’язаних з переглядом бюджету.

Також незрозуміло нахіба було «винаходити колесо» з метриками, як «Середній час виконання задачі», «Середня швидкість команди», якщо дані Project Coordinators могли б оперувати на своїх проектах загальноприйнятими метриками типу: Lead Time, Cycle Time, Throughput; також, згідно опису ваших процесів дані проектні координатори не є самостійні в керуванні Scope creep, що є суттєвою вразливістю створеної у вас структури та процесів.

Оскільки в статті фокус переважно на своєрідному підході до роботи з скоупом, але без фінансових факторів, здається, що річ тільки про T&M контракти, але цікаво було би почути як в рамках описаних процесів та метрик ви можете імплементувати проекти за Fixed Price контрактами.

How do you do Eugene?

Do you know why BBC *has and CNN *have published a report on ...?

🙃

Статття не тільки з клікбейтним заголовком, а також зовсім не про те, як «Традиційні підходи до розвитку PM більше не працюють» ...
Схоже, якщо в ситні роки в SoftServe покладалися на PM-ім з недостатньою кваліфікацією, але проводили внутрішні воркшопи та тренінги для підняття їхньої компетенції до більш-менш належного рівня, то тепер вирішили змінити вимоги до компетенцій типу досвідчених PM-ів, бо overhead мати в штаті велике стадо загальників стало фінансово обтяжливим і бізнесово неефективнеим, ... але нічого нового в цьому впровадженні немає, бо подібні підходи є типовими для провідних світових компаній і спеціалісти з такими компетенціями зазвичай мають тайтли: Product чи Engineering Manager (в залежності від потреб конкретної розробки); хоча перейменовувати ще тайтли для SoftServe було би занадто, бо це вимагало б відповідного перегляду компенсацій.
IMHO, описане автором => намагання позбавитися баласту, а також «з-під палки» заставити розвиватися тих, хто подібної мотивації раніше не мав і спробувати підвищити їхню ефективність, як загалом в рамках проекту, так і щоб ведення декількох проектів не було чимось особливим (але щоб даний Project Manager зберігав свій тайтл без необхідності визнавати його як Program Manager, Engineering Manager чи Product Manager).
В старі часи, хто був мотивований розвивати свої компетенції, то після певного досвіду в SoftServe переходили працювати в продуктові компанії, ... і, враховуючи, що SoftServe є сервісною компанією сфокусованою переважно на аутсорсі послуг, то це все рівно накладує обмеження в розвитку менеджерів, а також з вузькою сервісною специфікою, а не необхідністю реально мати високу компетенцію в «The 10 Project Management Knowledge Areas» згідно PMBOK.
Такі мої takeaways, ... і хочу лише побажати SoftServe вдачі в даній трансформації, бо це не тільки вимушені міри, а й на краще для компанії.

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

В наш час, поради тих, хто досяг результату з розмовною англійською 10 і більше років тому не зовсім ефективні; потрібно використовувати переваги сучасних технічних засобів, які дають можливість розмовної практики 24/7, наприклад — це може бути Tamdem app, де можна в рендомній party поговорити на спонтанну тему і також заводити нетворкінг знайомих, з ким можна мати 1:1; або як інший варіант — це «ШІ», наприклад, Sesame AI app.sesame.com коли подивився чи почитав якийсь контент, то можна обоворити з АІ ботом враження, або загалом поговорити на тему, що зараз в голові крутиться, і т.ін. ...

Немає ніякої чарівної поради, як стати a fluent speker, просто потрібно говорити, не повинно бути перекосу на пасивні навики читати/слухати, тільки через регулярну практику буде результат — розвиток такого активного навику, як вільно говорити англійською.

В статті помилкове порівняння домену DefTech з загальним поняттям ІТ, яке включає в себе зіліон доменів і є іншим типом розробки, ... і якщо хтось вважає Embedded інженерів з GlobalLogic, Intellias, Ajax Systems та ін., як представників класичного ІТ, це не є так, бо Embedded-розробка є одним із найстаріших типів розробки програмного забезпечення, ділиться на дуже багато доменів і як поняття має відношення до OT, а не до IT, тому коректно порівнювати OT з IT, або DefTech з іншим доменом.

Лінки стосовно OT:
Operational technology en.wikipedia.org/...​ki/Operational_technology
How Do OT and IT Differ? www.cisco.com/...​ngs/what-is-ot-vs-it.html

Помилкове допущення, ... ці безпекові процедури для miltech-компаній не є поліграфічними дослідженнями, а лише поліграфічними скринінгами, і є ще менш точними, коли поліграфологи відхиляються від методології, ... і може бути абсурдна ситуація, наприклад, коли у вас проблема закрити позицію Embedded-інженера кваліфікованим спеціалістом, їх загалом мало на ринку праці, але будучи чесним і «чистим» інженер може елементарно перенервувати і провалити проходження поліграфу, а у випадку працевлаштування з метою промислового шпигунства чи загалом завербованих кацапами, спецслужби можуть таких потренувати на проходження поліграфу, і вони з брехнею, але пройдуть цей примітивний поліграфічний скринінг. 🤷🏻‍♂️

Дякую за статтю, цікавий досвід!

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

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

На майбутнє додам, у всіх людей свій досуг (Це може здивувати Вас)
Ну і після «Жахлива порада.» можна додати «На мою думку» Або ж «Для мене це не працює»

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

P.S. можете продовжувати бентежитися і співчувати 🤦🏻‍♂️🙃

Переглянь, що ти дивишся на YouTube. Зменш розважальний контент, додай більше інтерв’ю та аналітики.

Жахлива порада. На роботі ви навряд чи дивитеся розважальний контент на YouTube (хоча хто знає), і звертаєтеся до даного ресурсу тільки в специфічних випадках, ... але в ті декілька годин в день, що ви маєте для себе, якщо дивитися щось на YouTube, то це повинен бути контент світчинг від роботи на щось інше, що вам цікаво, дещо розвантажити чи розважити себе після робочого дня; бо згідно поради автора статті — це виходить порушений work-life balance зі всіма також негативними наслідками; як виняток може бути, наприклад, якщо ви джун чи прейшли в інший домен, тоді більше зусиль на початку і з тимчасово порушеним work-life balance є виправдані.

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

На місці клієнта, якщо погоджувався б на запропонований BCP від Юлії Смойловської, то фінансово максимально перекладав би тягар на аутсорсну компанію, ... тобто, наприклад, беручи до уваги процитований пункт, даний додатковий DevOps-інженер був би безкоштовним для клієнта, але overhead для команди, відповідно зі всіма наслідками на менші рейти членів команди.
Дефотним навиком в проектному менеджменті сервісних компаній є => вміння продавати рішення, зміни, вирішення ризиків та ін., а не просто різати свої бюджети як запропоновано в даній статті, ... наприклад, згаданого додаткового DevOps-інженера можна було би «запакувати» і продавати клієнту як SRE, хоча це практично синоніми, розписати їм фокус на дещо різних зонах відповідальності, але щоб у випадку непередбачуваних обставин вони були взаємозамінниим, а також одного найняти в Україні, а іншого, наприклад, в Бразилії, тоді їхня робота за гнучким графіком в різних тайм-зонах гарантувала б сервіс 24/7.

P.S. дана стаття була написана з фокусом на Україні, але цікаво з врахуванням вже нашого досвіду, які міри на сьогодні в Luxoft розглядають для BCP у випадку Індії, враховуючи що ризики у випадку конфлікту Індія-Пакистан мають суттєво більші глобальні наслідки для ІТ-індустрії.

Правило: якщо не відкривав протягом тижня — видаляю.

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

Як налаштувати на iPhone

iOS — це червоний прапор для digital мінімалізму, Android надає ширші можливості налаштування, а відсутність notification channels для додатків в iOS developer.android.com/...​ws/notifications/channels — це як «digital мінімалізм» з печерного віку.

«Вибач, я пропустив це повідомлення...» — написав я стейкхолдеру під час запуску нового продукту. У цей момент я гортав десятки вкладок у браузері: дашборд із падаючими метриками активації, логи критичного багу в ранжуванні пропозицій на сайті, трекінг поламаної воронки комʼюніті. Slack розривався від термінових повідомлень, календар нагадував про мітинг, на який уже запізнююсь на п’ять хвилин, ...

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

Думаю, з усіма цими 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 ...

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

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

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