Pull to refresh

Comments 27

Понравилась мысль о черном ящике: " Задача для такого начальника остаётся чёрным ящиком. Сделали – и хорошо." Это очень точное наблюдение, сам много раз это замечал.

Кстати, это modus operandi т.н. "эффективных менеджеров". Им вбивают несколько шаманских приемов, которые вроде бы помогают решать типовые проблемы. И вот они этим инструменарием пытаются пользоваться в любой ситуации. А суть проблемы для них всегда именно черный ящик.

Как следствие, они очень боятся "засветить свою некомпетентность". Хотя исполнители все отлично "снизу" видят. Но ведь главное перед начальниками хорошо выглядеть. Хуже то, что они при этом еще и пытаются "компенсировать" некомпетентность ужесточением условий труда (тут об этом много публикаций, вроде того, как работник с утра составляет всякие планы) и "строгим" отношением к подчиненным.

Главное "делать грозное лицо" и не допускать нормального общения. Отрывистые команды или "разборки" с маской бесконечно занятого важное начальника.

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

Это я к тому, что у каждого своя работа и свои скилы. Быть везде - невозможно. Точнее можно, но это как утка - умеет плавать,нырять, летать, ходить, но все делает хреново.

UFO just landed and posted this here

Как мне кажется "руководитель" - это состояние души, а "тех.спец" - профессия. Т.е. то, про что говорится в посте - это (на мой взгляд) про начальников (как профессия), которые не руководители.

К чему я вам ответил? К тому, что если бы этот тех.спец был руководителем, то он, МОЖЕТ БЫТЬ, не смог бы ответить на вопросы про планы, бюджеты и т.д., но он смог бы быстро найти на кого перенаправить вопрос, с кем проконсультироваться и т.д. и в конечном счёте дал бы ответ достаточно оперативно.

Т.е. тех. спец неспособный, а не просто не погружен во все планы, бюджеты и т.д.

У вас акцент, что именно начальник, а другой тех. специалист, значит начальник не технический специалист, а менеджер? И проблема технического специалиста, что он не компетентен в менеджерских вопросах? Он в принципе неспособен или просто не занимался этими вопросами? Лучше бы конечно заверил все планы и бюджеты да.

Нескромный вопрос: сколько у вас подчиненных, что вы успеваете вникнуть в их проблемы, потом сходить на совещания, потом помочь продавцам и руководителям проектов, потом погрузиться в смежные области да еще и попрограммировать ?

И второй -сколько часов в день вы работаете ?

Это же nmivan , 250+ статей на Хабре. Может показаться, что его работа - это писать статьи на хабре. Большинство статей вызывают много противоречивых мнений о выводах в статье. Впрочем, он и сам признается, что использует это для влияния на людей, а большая часть статей - выдумка, что впрочем автор и не скрывает.

Статьи интересные, спорные и кликбейтные. За это его и любят и ненавидят :)

Не только на Хабре. Инфостарт, Проза.ру и ещё вроде что-то.

Может не стоит переходить на личности? Между прочим очень правильная статья написана. Ну а то что человек продуктивен - честь ему и хвала.

По поводу противоречивых мнений - а всем никогда не угодишь, всегда будут противники.

Когда человек - звезда Хабра, то он уже личность и его обсуждают, как @alizar в каждой его статье :). Ну и я очень уважительно отношусь к @nmivan , это можно было заметить в моем комментарии. Все суждения - только по его статьям, ни больше ни меньше. Хоть его рассказы и перекручены, но в них есть доля истины в человеческих взаимоотношениях.

а всем никогда не угодишь, всегда будут противники

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

Я вас понял, но неважно кто человек - звезда. или нет, чисто по человечески некрасиво переходить на личности - это не делает вам чести.

PS: Смотрю местные хомячки уже начали фигачить мне минусы за мнение отличное от их собственного

15 подчинённых, работаю по 9 часов в день.

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

хождение в народ издревле считалось занятием рискованным (а риск - дело благородное). тут главное не путать спорт с физкультурой (ну или когда для души по праздникам - с алкоголизмом) - ведь эти крайности требуют принципиально разной физ подготовки и подхода к делу.

руководитель должен наносить пользу с тех сторон где он хорош: администрирование, координация, переговоры.·не очень представляю где начальник "включая программиста" приносит хоть какую-то пользу. простые задачи команда и так решает. забирать у нее такие сладкие плюшки это прямой путь к демотивации. если же задача кажется команде супер-сложной, тогда нужно решать проблему с постановкой или стафингом (а пока просто подбодрить, произнеся красивую пламенную речь). решение опять же не в плоскости программирования.

Звучит это хорошо, а если посмотреть со стороны сотрудника? Вот я фронтенд разработчик объясняю своему реководителю который начинал на С++ и из фронтенда знает только PHP почему я вынес логику в кастомные хуки на ReactJS, а вариацию кнопок через БЕМ модификатор обновил в npm пакете самописной библиотеки компонентов. И я благодарен ему, что он не старается делать вид что понимает о том что я ему говорю, а спрашивает нужно ли мне ещё время чтобы подстраховать если я об.делаюсь по срокам или помощь со стороны параллельной команды, если я сам не буду понимать как у них работают карты с которыми мне нужно интегрироватся

Это и есть понимание. Ведь можно было просто в озвученный срок спросить за результат и без отговорок.

Курица - не птица

1с - не программист

Конечно, 1C - платформа)

Опыт вникания нужно экстраполировать на отношения между любыми коллегами. Каждый должен понимать, чем живут другие. Иначе получается не команда, а пачка премудрых пескарей по норам. Имел несчастье оказаться в такой. Ну и продукт будет так себе.

А результат-то, результат-то какой? Кто более эффективен, как начальник? Тема не раскрыта

Если погружение в задачи не включает в себя "приставания" к программистам в виде обязаловки рассказывать всё, что сделал и почему, а лишь чтение итоговой документации по задаче, тогда норм.

В противном случае, программист устанет от такого внимания к себе.

На счет "черных ящиков" - хорошо сказано. У техлида не должно оставаться черных ящиков на проекте.

Так кто он все таки: Техлид, Тимлид или начальник более высокого ранга ? ))))

Как за несколько минут ускорить работу 1С на сервере в 2.5 раза, если там был плохой админ.

Интригует, поделитесь

если там был плохой админ

это ключевое. Элементарная реиндексация SQL даёт вау-эффект.

Я думал, автор напишет по-человечески, как находить время на самообучение, тренинги или про коллективное мышление. В итоге, я так понимаю, надо делегировать по минимуму, а лучше вообще писать код за подчиненных. И тогда они точно тупее тебя будут)))

Короче, статейка полный бред. Написал в стиле "я узнал вот это, и теперь я крут, а если бы я делегировал, то не узнал бы ничего".

Делегирование - работа на разных уровнях абстракции. Руководитель видит общую картину, программист же занимается деталями. По сути, принцип инкапсуляции налицо.

Вообще документирование как бы must have. Нет документирования, нет видения бизнес процессов. В итоге наш автор тонет в рутине, попутно бегая на все совещания, пытаясь успеть везде. Хотя, если руководить двумя подчиненными, то может еще не все так плохо? Но я сомневаюсь.

Палка о двух концах тут. С одной стороны, прекрасно, когда начальник понимает, может подсказать и направить, но иногда ситуация несколько другая: начальник думает, что понимает, нахватавшись по верхам, а потом начинает продавливать своё неэкспертное мнение, как рабочее решение. В лучшем случае просто не сработает, в худшем - как-то сработает, но его будет сложно поменять на хорошее.

Иван, это и называется в нормальных компаниях "code review". Оно преследует в том числе и эту цель - расширить знание продукта у человека, который не писал эту функциональность.

А еще возможно подсказать написавшему другой способ решения проблемы (например использование существующей в конфе библиотеки вместо своего велосипеда) или указать на явные ошибки. т.е. чтобы написавший тоже рос. В конечном счете оно про то чтобы люди становились компетентнее и лучше.

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

Sign up to leave a comment.

Articles