9,5% програмістів майже нічого не роблять — дослідження зі Стендфордського університету

Побачив цікавий пост із дослідженням продуктивності розробників на основі аналізу приватних репозиторіїв: x.com/...​LQ1RNrcq0EQvAaWbUm8g&mx=2

Результати наступні: 14% ремоут програмістів і 6% тих, хто працює в офісі майже нічого не роблять, їх автор називає 0.1х програмістами(:. Такі люди або роблять менше трьох комітів за місяць, або їх зміни тривіальні, що просто симулюють активність. В середньому частина таких розробників — 9%.

Автори роблять припущення, що ці девелопери можуть «працювати» на декількох роботах. З цікавого, що стосується ремоуту, в ньому зустрічається більше «5х» програмістів, але якщо приватні дослідження великих компаній показують схожі результати, не дивно, що вони женуть усіх в офіси. Зменшення відсотку тих, хто взагалі нічого не робить, з 14% до 6% виглядає дуже вагомим фактором.

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному1
LinkedIn

Найкращі коментарі пропустити

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

Пам’ятаю як ввели на одному ентерпрайзі статистику по комітам, і як всі індуси почали по 10 комітів в день робити. Такоє, але такі KPI вводяться не від великого розуму

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

І це все у рваному ритмі, бо типовий час чекання це 10-20 хвилин, ні зконцентруватись, ні відволіктись на іншу задачу.

В результаті продуктивність десь 1/5-1/20 від того, що могло б бути в нормальному середовищі, але в кінці дня виснажений як за дві роботи.

Мабуть, з таких і зібралась та статистика.

Такоє.
Багато нюансів та не врахування контексту проектів та посад в тій аналітиці.

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

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

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

Хоча й нема куди правди діти, є люди які приносять нульову чи навіть від’ємну цінність для компанії.
Але вираховувати таких людей треба точно не по кількості комітів.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Теж мені відкриття. Деяким кадрам платять просто за те, щоб не звільнилися, а сиділи тихо на бенчі, хоча для них роботи наразі немає. І це компанії обходиться дешевше, ніж наймати таких кадрів коли робота раптово зʼявиться.

9,5% співробітників Стендфордського університету майже нічого не роблять — дослідження програмістів з приватних репозиторіїв

Хмм, якщо б я був на місці власника, і дізнався про таке, то звільнив би (або дав прочухана) проджект менеджера.

Бо бля ну як, ти менеджиш проект і у тебе людина нічого не робить. І ти не в курсі.

Есть такая теория, что существуют люди-катализаторы, которые внешне делают минимум, но команды в которых они работают бьют все рекорды производительности.
Феномен мало изучен, но скорее всего дело в умении подавать правильные идеи или своим присутствием гасить конфликты.
Так что менеджер может быть очень даже в курсе и в доле.

Менеджери дуже часто НЕ розуміють складність задач, тому якщо людина вміє красиво «розповісти» — він/вона може тижнями розповідати на стендапі як вони героїчно поборюють якусь проблему

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

Яку перед тим самі ж і створили xD

Тю, вони так пишуть за це, начебто це щось погане :)

Пам’ятаю як ввели на одному ентерпрайзі статистику по комітам, і як всі індуси почали по 10 комітів в день робити. Такоє, але такі KPI вводяться не від великого розуму

Комитить каждые 2 строчки это ок. Ненормально потом это заливать всю историю 50 комитов на 1 фичу, которая занимает пару дней.

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

Метрика по числу комитов возможно была еще нормой лет 20 назад. Сейчас я даже не знаю как менеджер мог такое продвинуть ... В современных условиях сразу пошла бы обратная связь от лидов, мол дурачок что ты творишь, удоли пока сам не опозорился.

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

Тут возникает вопрос, а какие коммиты считаем — в мастер, или в рабочий бранч?

а у вас разрешены коммиты в мастер всем подряд?

Перефразирую. Принятый и сквошеный пул-реквест.

ну может на маленьких проектах. у нас пока до мастера новый код доберется, еще несколько веток по дороге будет, в каждой проверяться и тестироваться

Ох лол, спогади розблоковано:

Більше 12 років тому, на моїй першій роботі, частина проекту була на індусах де були ті самі індуси з анекдотів.
І періодично хтось щось комітив, а потім наступним комітом ревертав ці зміни.
І так часто по декілька разів. З одними й тими ж змінами. Оце були КРІ, оце активність!

Ще в той же час, більше 10 років тому, чув байки, що якимось індусам платили за кількість рядків коду і вони практикували написати конструкцію типу
if(false) { ...40 рядків ніколи не виконуваного лівого коду ... }

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

Як сказати...
На великих ентерпрайз проектах включаються різні менеджерські штуки.

Ти: «Колеги з Азії зробили херню в коді.»
Менеджер тебе питає: «Це впливає на нашу роботу?»
Ти: «Ні»
Менеджер: «забий».

.....Пройшло 12 років.

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

коли інші колеги творять якусь фігню. Невже всі бачили і мовчали?

як тобі сказать тут можна сказать трохи простіше а тім іншим колегам які бачили їм платять за те щоби вони і бачили і витрачали свій час а також час «корпорації» на те щоби усе це рапортувати і реагувати тощо?

бо маючи вже то все як свій бізнес та конктракти уже як контракти тож маю усе що прописане у контракті які працює що цікаво в обидва боки де з одного боку «я виконую рівно те що прописано у контракті» і так само з іншого «ми тебе не просили виконувати те що у контракті не прописано»

завжди було цікаво, як на це реагує основна команда

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

творять якусь фігню.

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

ЗЫ: якщо ти думаєш то типу літературна гіпербола то ніт не зовсім так однозначно бо я особисто вже стикався як особисто бачу код «... що це за ... який ... цей код взагалі писав ...» а тут оказується що то вже єсть уважаємий чєловєк сіньор віпі манагєр вагомого направлєнія вот єто всьо ))

Невже всі бачили і мовчали?

тож тут скажу з досвіду ну х.з. просто так без політри там нема рецепту як то «простих рішень Офісу Президента» (к) (тм)

просто бізнес

ЗЫ: як то буквальне «работає не трогай» (к) (тм)

... це правило работає я провіряв ))

що якимось індусам платили за кількість рядків коду

ну технічно за що платили те вони робили все чесно

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

Але це дані не зав’язані на офіс чи ремоут а зав’язані на менеджмент, і чіткість його роботи.

Зі ста людей? О_о У нас на проєкті з 4 девів один цілий рік робив або нічого, або шкоду, недавно звільнили правда. А зараз, коли в команді 8 девів, можливості нічого не робити (створювати видимість роботи) збільшились в рази xD

зі ста людей це шикарно у нас одну тіму по шинкували на половину продуктівність не впала

у нас одну тіму по шинкували на половину продуктівність не впала

Та стандартна штука. В нас якраз було річне рев’ю проекту, −30% витрат і +20% кількість релізів і фіч (хз як рахували).

принцип Парето: 20% роблять 80% роботи незалежно від масштабування

роблять 80% роботи

лишається тіко проблема kpi щоб вирахувати саме нужні 20% бо ось згідно теми люди кодять і комітять тож певно якраз і роблять роботу хіба ні? ))

проблема в тому, що після того як відняти 80%, появиться нових 80% ловперформерів

на проекті в 100 людей принаймі двоє ніфіга не роблять

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

Місцеві експерти, які все знають, вже писали що це заказуха щоб всіх в офіси загнати, бо «менеджерам треба показувати видимість роботи» і «нерухомість знецінюється»?

Ну якщо вирити Ілону Маску, а тут йому брехати сенсу нема — головна проблема видаленки — це якраз знецінення комерційної нерухомості. Ті хто тримали свої капітали в ній, люди типу Єріка Шмідта (його між іншим з Google попросили бо спіймали на не законних монопольних діях на ринку праці) які і бударажать як уряди так і наукове товариство. Реальна проблема — вони особисто програють конкуренцію, як економічну так і з рештою як бачимо політичну і вилітають зі списків Forbes.

що це заказуха щоб всіх в офіси загнати
14% ремоут програмістів і 6% тих, хто працює в офісі майже нічого не роблять,

Таку різницю можна ще пояснити різницею в ЗП, в США якщо офіс то ЗП на третину+ більша.
І це мотивує людей на ремоуті чітити.

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

Сама по собі «кількість комітів на місяць» — метрика така сама дурнувата, як і кількість рядків коду. Будете платити людям за це — ну, будете мати сотні комітів дурні на місяць.

Мені в якості метрики оцінки продуктивності подобається читати pull request description. Береш будь-якого незнайомого програміста з незнайомого проєкту, відкриваєш його останні 10 пул реквестів і читаєш не код навіть, а що він написав про цю зміну. В чому була задача чи проблема, що було зроблено для її дослідження і вирішення, в чому полягає фікс, які додані тести, що зроблено щоб такої проблеми не сталося в майбутньому. Півгодини читання — і ти розумієш про цю людину все. В принципі, можна такому, напевно, навчити якийсь AI.

на останньому проекті 2-3 пулреквеста щотижня в реліз, а це 10-20 комітів якщо без сквоша, я 5х програміст? удальонка єслі чо. Дослдіження фуфлою фуфлижне

да у всех так. не слушай дурачков.

до того тема небінарності стереотипного гендера нерозкрита

Ок, поставлю собі нагадування на телефоні пушнути якесь сміття в свою бренчу, щоб побільше лінійок.
А наступного дня перетру коміт.

Тебе все рівно примусять зробити одним коммітом на 5000 рядків (через squash) все за один тікет у джирі.
І статистика побачить один комміт.

Ні, статистика бачить всі коміти. Але не бачить вже конкретно коду. Там статистика не по main бренчі а по комітах у всіх бренчах.

Цю, чого?
2,862 contributions in the last year

Може там менегер який по 10 разів на день змінює думку щодо кольору кнопки

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

щодо кнопок, я майже не займаюсь фронтендом останні часи.

Подивився свої комміти — я більше видаляю коду, ніж додаю.
ЩЗМНТ

Даже не знаю, как тебя назвать. Какой антоним у слова «программист»?

)) до речи — непогано. Може в git* додадуть досягнення, що якщо кожен коміт додаєш менш ніж видаляєш тоді ти менеджер!

Пишеш більш лаконічний код. Це якраз показник кваліфікації.

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

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

Побачив цікавий пост із дослідженням продуктивності розробників на основі аналізу приватних репозиторіїв: x.com/...​LQ1RNrcq0EQvAaWbUm8g&mx=2

Автор:
www.linkedin.com/in/ydenisov

— Stanford University (2022 — Present): Researcher in software engineering productivity and post-COVID work models.
— Stanford HAI (2022 — 2023): Researcher at Human-Centered AI Institute.
— DHL (2017 — 2022): Chief of Staff to EMEA CEO, strategic and digital transformation.
— USA Weightlifting (2012 — 2016): Senior athlete in Olympic weightlifting.

Спортзал + пошта = 10 років
IT (в інституті) = меньш 2 років?

Ок, припустимо. Далі:

We have data on the performance of >50k engineers from 100s of companies.
на основі аналізу приватних репозиторіїв

Звідки данні? Зібрали самостійно? Як?
А що стосовно видалення гілок після мержу?

Под любое неприятное для персонала корпоративное решение надо подвести мнение британского ученого.

Бо головою працюють
Не руками

Менеджери взагалі нічого не роблять

Менеджери взагалі нічого не роблять

Ні ну як, вони статуси у тасків перевіряють і пишуть всім, хто статус не обновив :)

9,5% програмістів майже нічого не роблять

Well, Of Course I Know Him. He’s Me.

В наші часи краще обережнішим бути з такими жартами(:.

Бо роботодавець прочитає, як його робітник на доу хизується як в робочий час серіали дивиться, і звільнить?

Итак, человек ищет трудно воспроизводимый баг в большом проекте.
Собирает журналы, всякие данные, отладка и прочее. Потратил неделю
коммит — 1 (фиск, чаще всего пару строк и тесты на такой случай)

по версии этого ...., который считает коммиты и их количество — это было 0.1 программист
но бизнесу он принес большую пользу, решив серьезный вопрос

В целом наступление на удаленку с помощью откровенно манипулятивных исследований заказного характера продолжается

Ну і що, він ці мєга-баги шукає кожен тиждень, з місяця в місяць? Ось я теж, на цьому тижні, тільки два баги вирішив, і все. Але в минулі тижні було і по 10 багів.

какая неделя на коммит ? вначале 2 недели на то что бы поднять ифраструктуру и воспроизвеси баг. потом 2 недели написать дизайн док про то как будем фиксить, заапрупить у прайваси и сикюрить, две недели на написание фикса — каунтеры, статистика, эксперименты и т.д. Месяц ожидания пока коммиты попадут в продакшин, Пол года на роллаут экспериментов. Могу и побыстрее, но потом не жалуйтесь что у вас виндовс вдруг обновился прямо в время презентации и после обновления не грузится.

Ну особенно после последней отмазки понятно, почему в большинстве больших продуктов коммитится только дерьмо и накапливается долг, а все попытки исправления упираются в вот такие вот фантастические рассказы про якобы ответственность.
Далеко пойдёте, пора лычки CTO заранее приклеивать.

Сорри забыли собрать фидбек от тебя лично как выкатаывать изменения ) Ты бы конечно все ускорил и пофиксил все долги )

Ты бы конечно все ускорил и пофиксил все долги )

Я просто не делаю фальшивые отмазки, этого достаточно для честной работы от себя лично.

Сорри забыли собрать фидбек от тебя лично как выкатаывать изменения )

Зачем от меня? Вокруг достаточно много честных. Если у вас их нет, это очень показательно.

Далеко пойдёте, пора лычки CTO заранее приклеивать.

карочі як бізнес то є просто бізнес я пристрілявся на лінкедіні дивитися хто єсть in charge як не дивно стало реально цікавоє і схоже реально профіт як виходячи з чистого kpi як не потрапляв доки у реальну ж. типу класики «безнадійного проекту» (к) (тм)

... тож ти правий там сто такі буквально карьєрноє ))

Ви там в своїх америках зовсім розучились думки українською мовою виражати. Скільки не пишите — ніфіга не зрозуміло.

І так на протязі кількох років? Такий інженер невдаха робота якого складається виключно із подібних багів? Не думаю що виборку брали за один тиждень чи місяць.

Куди ймовірніше, що просто пинав х*ї, щи створював видимість роботи, чи програмував в слаку/тімсі

створював видимість роботи, чи програмував в слаку/тімсі

Це досить таки відволікаючий фактор

Такоє.
Багато нюансів та не врахування контексту проектів та посад в тій аналітиці.

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

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

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

Хоча й нема куди правди діти, є люди які приносять нульову чи навіть від’ємну цінність для компанії.
Але вираховувати таких людей треба точно не по кількості комітів.

Людина може мало комітити по 1001 причині.

Може і багато комітити, і після мержу у master гілку видаляти. Через 3-4 роки виявиться, що

на основі аналізу приватних репозиторіїв

коміти раз на 2-3 місяці.

метрика «кількість комітів» виглядає «трохи по-дебільному». найскладніші проблеми — це, зазвичай, ті, де спочатку тижні debug-у, а потім невеликий фікс який раптом все ремонтує. мій власний рекорд — два тижні роботи і коміт із 1 (одного) символа.

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

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

Зустрічав таких.

Як це виглядало: керівництво призначає завдання доробити функціонал, а там виконано лише 1/10 з того, що було описано в завданні, яке позначене як виконане.

Німець, англієць та українець — можливо, когось я вже й забув.

Описана вище історія про німця.

Німець, англієць та українець

Схоже на початок якогось анекдоту

почему же ничего — играются с chatgpt что позволяет сказать что компаня использует ИИ для разработки

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

І це все у рваному ритмі, бо типовий час чекання це 10-20 хвилин, ні зконцентруватись, ні відволіктись на іншу задачу.

В результаті продуктивність десь 1/5-1/20 від того, що могло б бути в нормальному середовищі, але в кінці дня виснажений як за дві роботи.

Мабуть, з таких і зібралась та статистика.

Навіть в такому режимі виглядає так, що все одно хоча б раз на пару днів ви щось помітне комітили і віддавали на перевірку. Тут в ці 9,5% вносять тих, у кого менше трьох комітів за цілий місяць.

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

Ха:((

Таки ніт. Іноді 2-3 тижні уходило на те, щоб продратись через все.

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

А потім я створив собі робочу інструкцію (на щастя, там в wiki були приватні сховища), і весь одділ користувався нею. А ту що містила менше половини вірних пунктів не можна було міняти, бо один з технічних шефів все відкатував — «ви неправі».

Тут в ці 9,5% вносять тих, у кого менше трьох комітів за цілий місяць.

Ось у мене саме так і було.

Щоденна дерганина на повний день, не можна відволіктись, рідкі результати... і, на диво, керівницство це все влаштовувало.

Але я витримав трішки менше року.

Ось у мене саме так і було.

Щоденна дерганина на повний день, не можна відволіктись, рідкі результати... і, на диво, керівницство це все влаштовувало.

Але я витримав трішки менше року.

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

Ти ентерпрайзних проектів не зустрічав де мій рекорд 5-ти годинний мітинг за фітчу на яку від сили витратили 2 години разом з тестуванням

Тим більше ;(

Цікаві висновки насправді. Просто дехто номінально числиться в розробниках. Скажімо на минулому проекті техлід зі сторони замовника в перше поставив робочий енв по інструкції, що я її зробив, щоб перевірити наскільки вона робоча — десь тиждень тому, програмі два роки. При цьому особисто я, три проекти тому — не написав за півроку для проекту жодного рядка коду, при цьому чим займатись блін було (моя особиста думка це не правильний процесс, та не я його ставив та і в цілому це визнали «найкращім проектом компанії»).
6% різних лідів та менеджерів, девопсів і т.д. хто номінально має акаунт — ну десь так воно напевно і є.
В цілому же — дійсно ситуації неіснуючий ролей, це коли двоє пашуть — семеро руками машуть. Справді часто структура може бути так влаштована, коли задача когось — тупо ходити на мітинги, тому що за технологією розробки такої ролі не існує, чи взагалі ідіотизм коли людину заставляють сидіти на стандапах 5 команд по черзі.

Просто дехто номінально числиться в розробниках

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

Підписатись на коментарі