Як на співбесіді зрозуміти, що ви маєте справу з бюрокрачним менеджером?

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

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

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
бюрокрачним

Щось гугл не чув про таке слово

Як на співбесіді зрозуміти, що ви маєте справу з бюрокрачним менеджером?
Спільното, напевно багато хто з вас мав справу з неоптимізованим та відверто жахливим менеджментом на роботі

Только я не вижу ничего общего между этими 2-ми цитатами? ))
Ужасный менеджмент — это не бюрократия. Там как раз всё просто: есть чётко прописанный процесс, по которому действовать. Он может быть кривой, горбатый, да какой угодно — но он ЕСТЬ. Иногда его даже дают оптимизировать в разумных пределах. Обычно это огромные энтерпрайзовые проекты на тысячи кодеров, тестеров, саппортеров и т.д., поэтому процесс громоздкий и неповоротливый. В большинстве случаев на таких проектах неплохо платят и можно не перенапрягаться — как бы ты лично не пыжился, от твоего вклада мало что зависит, надо просто делать задачи и не провтыкивать эстимейты.
Гораздо хуже, если процессов НЕТ. Например, когда подкидывают задачку из бэклога за день до релиза или когда тестеры получают билд с функционалом, которого нет на борде — ну вот просто заказчик в личку позвонил разрабу и сказал впилить вот эту кнопку. Вот это, как по мне, и есть ужасный менеджмент.

Как избежать такого проекта?
Задавать правильные вопросы на собесе. Вопросы по принятым процессам в проекте. Например: когда определяется скоуп итерации? Насколько часто он менялся за последние 6 спринтов? Кто контролирует бэклог? Какие есть проблемы на проекте? Что случилось с предыдущим человеком на проекте? Какие есть митинги? Есть ли DoD / DoR критерии задач? И т.д.

Я запитую ще про:
— Очікування від мене
— Яка буде моя перша таска
— На що мені звернути увагу перші 30, 60, 90 днів?
— На основі чого ви можете сказати, що цей найм був успішним?

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

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

бюрокрачним менеджером

Це скорочення за новим правописомчи просто помилка?

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

ШІ почав генерувати топіки для доу

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

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

Якщо менеджер розказує що він і РО, і БА, і демо робить, ще й з архітектурою «допомагає», то очевидно що проект дно.

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

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

А насправді це був жахливий проект без архітектури, без документації, код модуля написаний в одному файлі, таких файлів десятки тисяч, дуже сильна звʼязаність коду(10-20к строк в одному файлі).
Рефакторинга не існує.
Якщо робиш малий естімейт — менеджер не задоволений якщо ти не виконуєш в срок, якщо робиш великий естімей — менеджер сам його переписує як він вірішив.
Кодер повинен тестити фічу, потім мержити в мейн, і тільки потім це передається тестерам. На питання чому так, відповідь була: «Для економії часу тестерів».
Як тільки таска бралась в роботу, через 5 хвилин залітає питання «ну що, готово?». Овертайми активно пропонувались, але не сплачувались, тільки якщо про це сказати(після овертаймів), вони були готові щоб ти раніше пішов з роботи.
За 1.5 роки роботи там, при мені приходило та уходило десь 10 людей, це були разраби та тестери, більшість уходило за власним бажанням.
Релізи — тільки в пʼятницю, кожна пʼятниця це горяща дупа, тому що менеджер міг закинути фічу в роботу без опису, просто тікет з заголовком.
Постійний психологічний тиск з боку менеджера, та продакта, та пусті обіцянки.
В кінці вони обіцяли мене підвищити як я доведу проект до релізу, перед цим вони взяли нового разраба який нічого не розумів. Я, з 1,5 років досвіду на цьому проекті вже розумів майже весь проект, і менторив цього чувака. Коли я довів проект до релізу, я взяв 4 дні відпустки, і коли вони закінчились вони мене звільнили, і залишили того якого нещодавно взяли.

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

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

Дуже легка співбесіда
Реально велика зарплата, для невеликої компанії

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

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

Дуже легка співбесіда
Реально велика зарплата, для невеликої компанії
За 1.5 роки роботи там, при мені приходило та уходило десь 10 людей,
Коли я довів проект до релізу, вони мене звільнили,

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

я радше б прив’язав причину-наслідок до проєкту «з 10млн юзерами» ніж до легкості собесу(налагоджені процеси в курсі, зокрема, що більшість людей цінують те що важко здобуто от і крєпчають цінителів по мірі можливостей): чуєте що «оуве до*** юзерів» — буде тухле спагетті

upd оуве до*** девелоперів на проєкті — також ознака тухлого спагетті

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

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

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

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

ЗЫ: а нє мабуть не забув просто там скрізь да буквально за батьком нашим шевченком тарасом «а всі несчасні несчасні по своєму» (к) (тм0

от кляті москалі навіть батька нашого шевченка тараса вкрали! ((

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

Дивлячись якій рівень — що занадто то не добре. Та обираючи між бюрократією і тоталітарним анархізмом, ляп-ляп і продакшн особисто я виберу бюрократію. Хоч за Адізісом це прямий шлях до розвалу організації, який відбудеться просто через певний час. Так чиста можливість погрітись разом з імперією, зазвичай імперія не погано годує крім того в ній часто бувають Сули, Помпеї та Цезарі які можуть багато чого змінити.
Часто причинами розвалу СРСР називають саме бюрократію введену як державну політику, починаючи з 1964 року яка поступово розвалила імперію, до того повністю ініціативну систему, що зуміла від аграрної держави де 80% народу читати не вміло дійти до запуску людини в космос, меньше ніж за 40 років. Систему намагались рятувати комсомольськими будівництвам типу КАМАЗ та БАМ, та було вже запізно.

а яки були гарні ініціативи! індустріалізація за рахунок голодоморів та світової війни! рабський труд у гулагах! і тд і тп

А що Опіумні Війни наприклад, чи війна у В’єтнамі або Іраці краще ? Тут же Ганді наприклад, чи Мартіна Лютора Кінга ніхто не пригадує.Так само і тій імперії москвичив, тобто метрополію — голодомор не стосувався. Москвич були «трудовим елементом» тоді як українці та поволжжя — виявились «не трудовим».
Імперія зовсім не обов’язково керується імператором, та от, що точно, не буває добрих імперій, вони будуються саме на основі можливості вирішувати питання силою.
Мають чітку структуру — є метрополія як то наприклад Рим або Пекін — які є центром концентрації влади та ресурсів. Відповідно маючи великі надлишки стають центрами суспільного життя : науки, мистецтва тощо. І є колонії — сенс яких забезпечувати ресурсами метрополію. Мають сословний устрій суспільства, часто прописаний законодавчо. Нижчі класи як то раби — мають зазвичай виключно обов’язки прав та привілеїв не мають. Вищі класи як то патриції — сенатори члени імператорської родини мають дуже багато прав та привілеїв.

Що є бюрократія — придушення ініціативи. Спитайте як наймаючий менеджер відноситься до ініціативи, тільки не пряму, а провакаційно. Наприклад, що ви зазвичай робите коли хтось занадто р’яний та його треба приструнити?
Певний рівень бюрократії є необхідним інакше нічого і ніколи не буде завершено в необхідний строк та достатню якість. І перше і друге мають бути зазделегідь відомі, і так на цьому потрібно наполягати, та краще м’якою силою, інакше вас чекають постійні овертайми та переробки. Усілякі методології, процеси, PMI, звання в армії та таблиці субординації з відповідностями адміралів до генералів і тому подібне люди створили далеко не на пустому місці.
З іншого боку бюрократія може доходити до такого рівня, де щоби скопіювати текстового файла з розширеної папки якою завідує сусідня команда, до вашого GCP Claud Storage тобто простою операцією яку можна би було вирішити робочий день, виявляється потрібно два місяці, тяжкі переговори із менеджером та клієнтами, щ рештою мітингом на 10 людей. На цьому мітингу Lead QA сусідньої команди буде рішуче проти, бо в них реліз через тиждень і «ви нам тут усе зламаєте», а адміна яка цим займається і єдина хто потрібна на цьому двох часовому мітингу, взагалі нема і не покликали, бо вона в цілому відноситься до третьої команди має власного начальника та фронт робіт, просто закріплена за сусідньою командою (тобто єдиноначальність порушено). Тобто усі дві години було витрачено просто в нікуди, необхідно і достаньо було банально переговорити із менеджером сусідньої команди 5 хвилин і зв’язати програміста із адміном.
Це той самий випадок коли двоє пашуть, семеро руками машуть, на численних мітингах, в прямому сенсі, при чому місяцями. Зато в чотири рази більше народу ніж насправді треба вдалось застафити і відповідно непогано заробити (що насправді доволі важливо). Так в такій системі той «хто сидить в окопі» зазвичай крайній нічого не встигає і у всьому винуватий, тому його треба кікнути.

P.S. Забув ще додати, що менеджерів було двое на одну команду і тімлідів з рештою двое.

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

Тому питання щодо того, що таке:

— неоптимізованим та відверто жахливим менеджментом
— поганого менеджера
— бюрокрачним менеджером

і в чому власне була проблема.

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

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

Ні

Треба обережно
Вони неправильно можуть зрозуміти якщо є свіжі рани від попереднього такого менеджера

попросити описати який вигляд має процес розробки.

І що це дасть? Ну опишуть вам скрам-методологію та SDLC, а далі що? Про Definition of Done спитаєте?

неоптимізованим та відверто жахливим менеджментом

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

Як тобі ситуація коли пів року в команди нема реквайментів, вона почала з того, що хтось з попереднього вендора якого вирішили кікнути їм на телевізорі з далику показував як працює софт для якого робиться реплатформінг. Розробка робиться методом реверс інженерінгу, буквально. Тімліда, в якого це перший проект і личка сініор — прибирають та зробили крайнім. Хлопець який насправді хороший програміст — зашивається і працює цілодобово. Клієнт постійно погрожує закрити контракта і зрізає строки, клієнт вводить свою команду на тестування, вже третього вендора. Менеджер дзвонить по ночах та вихідних, та святкові і на яких примушує працювати і не платить — потім робить морду цеглою і каже, що він це просто забув . Менеджер колишній С# і лізе особисто програмувати на Java, тобто періодично вставляє якість криві костилі які взагалі невідомо для чого і тільки показують що людина не розуміє як працює фреймверк. Ці костилі доводиться прибирати і витрачати на це час.
Команда майже повним складом звільняється, або подає прохання на звільнення. Менеджер програми особисто просить декого залишитись і доробити проекта. Продукт після численних скандалів та поставлення процесів — збір та описання вимог, оцінка трудомісткості, розподілення обов’язків тощо якимось дивом вдається ввести експлуатацію. Там починають спливати баги. Менеджер намагається заставити залити хотфікс який не перевіряли навіть ще QA на продакшн і при чому хоче щоб це зробив ти в понаднормовий час, при чому після того як ти навідріз відмовляєшся від такої підстави, виявляється що директор прямо це заборонив, подзвонив та сказав, що знімає цього менеджера і починає менеджити проект особисто в кінці тижня. В цей час менеджер дзвонить тобі і влаштовує істерику, в явно нетверезому стані і із червоними очима, це він робить на протязі усього залишка тижня. В той самий час lead QA яку дістало і вона звільнилась, казала — що до неї він до цього дзвонив постійно, позаяк вони однієї національності явно в нетверезому стані, та казав, що цих гоїв треба ганяти і дурити, що якраз по Торі є ганебною поведінкою. На неї з усіх сторін постійно психологічно тиснули да довели до нервового зриву, з рештою вона звільнилась з компанії повністю як і solution architect та lead frontend.

Весело, я навіть в держ. установі такого не бачив.

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

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

Ще можна запитати, як власне він став менеджером :)

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

Чуєш «ми не просто компанія, ми сім’я» — біжи)

’Молодая, амбициозная компания единомышленников, стартап ’ - це постійно зустрічається )

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

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