Pull to refresh

Comments 41

UFO just landed and posted this here
Вы делаете новые фичи прямо на продакшене? Или всё-таки сначала отправляете свежий коммит на code review, а потом тестерам? Речь именно об этих операциях — проверьте то, что делает сотрудник до того, как оно дошло до истинного выполнения. Писать за сотрудника каждую строчку кода или аналитическую записку вы не сможете, времени не хватит. Но ловить проблемы до того, как от них пострадали клиенты — это практика более общая, находящаяся за пределами именно руководства. Уж об этом я стараюсь не писать.

В чем еще я оказался «илитарен»?
UFO just landed and posted this here
Изложили ясно, и я именно такой вариант и подразумевал. Code review и тестинг до релиза. Просто поэкономил букв. Нигде у меня не написано «Пусть его лажу видят все, пусть он страдает и пьет горькую», да и вряд ли у вас будут такие сотрудники.

Вокруг меня просто много примеров, когда начальник — это самый высокопроизводительный сотрудник, no matter what. Отдел по показателям считается в норме, потому что главный чувак молотит за четверых без сна и отдыха. Проблемы начинаются, когда он болеет или решается уйти в отпуск через 2.5 года — потому что оказалось, что он пытался руководить «личным примером», а команда по факту расслабилась, да и сам начальник сгорел. Первое, от чего хочется предостеречь — это от такого подхода.
Эффективный менеджер «видит» к чему это приведет, берет сотрудника за плечо, интересуется тем, что он делает, его видением на то, что происходит, а потом объясняет, к чему это приведет.

Это типичный микро-менеджмент, зло во плоти.
В нормальных командах так не работают, никто не стоит у человека за плечом, не мониторит его таски, не спрашивает, почему таск занял в 2 раза больше времени и не лезет делать code-review после каждого коммита. Конечно, если вы не хотите, чтобы человек ушел, но тогда его проще уволить.
Это все от лукавого. Либо вы доверяете людям, либо будете в перманентной запаре. Представьте, что подчиненных не 5, а 25, все не получится контролировать.

Надо работать над развитием у команды навыков коммуникации, с Вами и между собой — это самое главное.

Косяки же всегда были и будут, если пишется что-то сложнее hello world. Высокий code-coverage и авто-тесты в таких случаях очень спасают нервы.
А вообще это разработка софта, а не хирургия, не нужен тут этот кондовый перфекционизм.

Вы не обижайтесь, но от Вашей риторики за версту тянет плохим процессом разработки и кучей морально-психологических проблем, которые он порождает.
Сочувствую, коллега, крепитесь, в жизни много хорошего!
UFO just landed and posted this here
Если подчиненных 25, значит должна быть выстроена иерархия из опытных сотрудников, которые уже менторят и следят за менее опытными коллегами и совсем джуниорами на листьях иерархии.
Микроменеджмент очень хорош в случае небольшого количества сотрудников и на этапе сработки. Например, если чел собаку съел на определенном виде задач (сделал 100500 вьюшек для данных), то зачем мне его контролировать? Я уверен, что он все сделает правильно. А вот если челу поручается R&D задача, причем я точно знаю, что в этой области он не работал, естественно, я буду с ним очень плотно взаимодействовать.

upd. большой пардон, отвечал на комментарий выше :)
Такой подход имеет право на жизнь, но содержит существенный недостаток — если сотрудники знают что добрый босс не позволит допустит им ошибку — они потеряют чувство личной ответственности. А восстановить его невероятно сложно. По собственному опыту управления.
UFO just landed and posted this here
Не захочется, и сотрудник действительно будет переживать, если вас подвел. Поэтому он будет к вам приходить и советоваться по любому вопросу. Это ответственность перед вами(боссом) а не перед командой, общим делом и самим собой. А именно такая ответственность нужна, я считаю.
UFO just landed and posted this here
У вас, видимо, был опыт работы «нянькой-боссом», что грустно, да.
Именно. Сам до этого довел, потом долго расхлебывал.

В здоровом конкурентом мужском коллективе это слабо представляется — бегать по любому вопросу к начальнику
Мне сложно об этом судить, у меня был единственный коллектив. Были и девушки правда. Но знаете, и мужики за тридцать всеми руками-ногами упирались, когда я прямо предлагал решить вопрос без моего участия. При этом мне уже предложили варианты и даже указали оптимальный. Но все равно пришли посоветоваться.
Помнится, была очень успешная практика, когда на совещаниях вместо поименного оглашения «героев» получал в тыкву весь отдел, без конкретики, потому что мы — команда. Все знали, кто накосячил, в том числе и виновники, но никто их открыто в этом не винил
Пробовал такую практику. Вслух никто друг на друга не косил, но кулуарно, все как один мне эмоционально жаловались в духе «Я же свою часть сделал без ошибок — почему меня наказали?».
Наверное, это надо было делать регулярно, тогда через какое-то время был бы эффект?
Впрочем уже не так важно. Сделал левелап и стал предпринимателем. Совсем другой круг проблем теперь
UFO just landed and posted this here
Вообще, половину статьи можно разобрать на цитаты «как не стоит руководить людьми»


Всё же прошу привести примеры.
UFO just landed and posted this here
Мне кажется вы ищете между строк то, чего там нет.
Дать задание подчиненному, которое ты знаешь как выполнить, не значить ничего не объяснить подчиненному.
То, что подчиненные могут неверно понимать это проблема коммуникации, а не руководителя, которая со временем сходит на нет. Но особенно она актуальна для новых подчиненных (и новых начальников).
Разбирать ссоры не значит принимать одну сторону, а тем более постоянно одну сторону, создавая любимчиков.
Забывчивость, особенно в высоком темпе работы, нормальное явление. Это не значит что по любой мелочи нужно слать мыло, но хуже от этого точно не будет, а вероятность различных неприятных ситуаций такой подход снимает.
С семинарами вообще из контекста выдернуто. Там сказано что всем плевать что вы читали и т.д., если у вас с отделом все печально.
И да, от руководителя все ждут решений. Опять же, не написано, что менять своих решений не стоит.
UFO just landed and posted this here
Много слов из предметной области, но сути нет. Поэтому от себя напишу несколько принципов:
0) начальник, как самурай, рано или поздно должен принести себя в жертву (уволиться).
1) вокруг люди — с парнями из своего отдела надо иметь хорошие отношения. Организовать совместные мероприятия, выбить бюджет у директора. Например, боулинг. Но не как награда за релиз, а просто как общее мероприятие. Общаться с каждым отдельно хотя бы иногда. Быть в курсе их жизни. Не бывает плохих людей, бывают неподходящие работники. Об этом необходимо всегда помнить.
2) Делегировать. Это означает поручать задачи и наделять полномочиями. Начальнику все равно остается много дел, в основном, административных, которые нельзя делегировать.
3) Контролировать. Проверять все — ход процесса, проверять качество кода, хотя бы выборочно. Парни должны не на словах знать, что вам важно что и как они делают.
4) Нести отвественность — все, что делают подчиненные, это то, что делает твой отдел. Если кто-то косячит, вина на тебе. Если успех — успех общий. Тебя должны хвалить не начальники, а парни в ответном слове, тогда все идет правильно.
5) Следить за дисциплиной — правила должны быть едины для всех. Один плохой работник за месяц портит работу всей команды. Чистить команду неприятно, но нужно уметь.
Вот это очень клево. А мысль про самурая у меня всегда была именно в этих словах :)
Если Вам надо обучить человека, то такой подход хорош. Если это уже middle и выше — то это перевод ресурсов. Когда начальник приходит к опытному сотруднику с заданием «ааааа сделай мне вот это не знаю как» — это провал. Всегда необходимо направляющее ТЗ, дабы наметить ход выполнения задачи. Никто не заставляет вас разжевывать, но все люди воспринимают реальность по-разному, потрудитесь хотя бы объяснить, чего вы ждете на выходе и в примерное число этапов, это облегчит жизнь человеку и повысит эффективность выполнения задания.

Нигде не сказано «Дайте человеку задачу в виде общего направления без ТЗ». Уровень проработки при постановке задачи — да, индивидуальный. Я не могу дать один исчерпывающий 100% верный совет всем и каждому. Некоторым моим сотрудникам никогда даже не надо было говорить в каком направлении работать — они изначально настроены на один лад со мной и делают всё сами. Но главная тема всего абзаца, а не нескольких слов — прекратите попытки все рядовые операции делать самостоятельно, дайте это сделать вашим сотрудникам, научите их как сделать и не облажаться. Это не руководство в двух фразах, как наладить процесс обучения в любой компании.

Все те вещи, которые я перечислил в качестве человеческих проблем — разумеется, не каждодневный труд начальника, упаси боже. Такие ситуации могут случиться (а если руководить дольше нескольких месяцев — обязательно случатся хоть раз). Важно, во-первых, не спрятать голову в песок при их наступлении — именно о том и раздел — а во-вторых, понять, что это не что-то из ряда вон, что это неотъемлемая часть руководства как работы. Если получится предотвратить неприятные ситуации или допустить их наступление лишь однажды — ну что ж, отлично.

разбирать ссоры и претензии


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


Не вижу противоречия вообще.

Только ситхи возводят все в абсолют.


Есть разница между абсолютом и последовательностью.

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


О необходимости это делать подчиненным нигде не сказано. Это необходимо делать начальнику. Также, follow-up — это не процесс принятия решений, а их «бухгалтерия», документирование, которое будет необходимо, если отдел растет и получает больше работы и ответственности (ну, если вас только не нанимали для плавного закрытия отдела).

Но книги по менеджменту и управлению людьми — последнее что стоит делать начальнику в СНГ, серьезно.


Не вижу, как приведенный кусок моей фразы иллюстрирует обратное.

Твердое решение — не всегда верное.


Что опять-таки не оспаривается в тексте статьи. Я не раз видел у других и сам испытывал страх перед необходимостью принять решение. Важно понимать, что затягивая вопрос, руководитель осложняет своё положение. Отличное решение — отлично, хорошее решение — хорошо, плохое решение — плохо, но лучше бы исправить, но отсутствие решения — это хуже всего.
UFO just landed and posted this here
Наверное, вы не видите заголовков, они предательски серые.
UFO just landed and posted this here
Ну тогда просто напишите, как надо, в этот же хаб.
UFO just landed and posted this here
Компьютер устроен так, что когда ты даешь ему одну и ту же программу, он производит одинаковый результат


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

Ловившие непонятный плавающий баг в доставшемся от «предшественников» коде поймут меня.

P.S.:
Насчет «не держитесь за свое место» — это прямо совет с альфа-центавра какой-то.
Рекомендуемое поведение настолько неконгруэнтно и нетипично, что я просто даже не в силах комментировать. Может в каком-то прекрасном зарубежном мире так все и работает, не знаю…
Не знаю, в нашем тоже работает. Мне вообще повезло работать в компании, где большинство вещей устроены так, как я мечтал, и не так, как обычно этого ожидаешь от всех.
Я никогда не видел начальников, которые бы не держались за должность «любою ценою» аки вошь за [redacted] волос, отпуская лишь в случае «возможности повышения».

Такое поведение (_не_ держаться), вероятно, требует довольно большой уверенности в себе и того, что называется personal integrity и на русский плохо переводится.
personal integrity — целостность личности. Одно из свойств личности с точки зрения мотивационного поведения.
Термин «цельная личность» в русском существует и регулярно применялся в доинтернетные времена.
P.S.: На тему плохо переводится… Бывшие русские (проводящие много времени в нерусскоязычной среде) теряются при переводе на русский не только вредных слом типа forklead (электропогрузчик на сленге), но вот когда мне друг после девятимесячной командировки в Бостон сказал «И там это… Как его… Ну как будет бридж на русском?», я понял что от корней лучше не отрываться. :)
Я в курсе что personal integrity официально переводится как «личностная целостность», но в российском психологическом дискурсе термин обычно употребляется немного иначе.

В зарубежных кругах personal integrity часто употребляется для обозначения личностей, не склонных к подлости, лжи и «враждебным манипуляциям». В РФ этот термин употребляется как положено, для обозначения " способности личности в критических ситуациях сохранять свою жизненную стратегию, оставаться приверженной своим жизненным позициям и ценностным ориентациям" — а типичный «офисный крыс» и «воен бюрократий» отлично попадает под второе определение (его ориентиры и ценности ну никак не страдают в критической ситуации) но не под первое.

Употребление personal integrity как канцеляритного эвфемизма для некоей «общечеловеческой порядочности» конечно «не вполне формально верно», но именно в таком значении его употребляют иностранные коллеги когда говорят "[name redacted] lacks personal integrity", и именно в этом значении его сложно переводить (я обычно говорю "[name redacted] неблагонадежен")
В том то и дело что в русском личностная целостность и благонадежность, а так же лояльность — разные понятия. (Хотя последние два иногда используют как синонимы, но всё же лояльный и благонадежный — немного разные вещи.) А вот термин personal integrity — имеет множество вариантов перевода.
В данном контексте я предположил что вы предполагаете начальника достаточно цельной личностью который не самоидентифицируется через свою должность начальника и она ему не нужна для сохранения своей целостности, вы же видимо имели ввиду благонадежность и лояльность начальника интересам компании.
Если честно — оба вида редкие как мамонты в Сибири.
Да бросьте вы, нормальная статья. К чему слушать нытьё дилетантов? А уж тем более на него реагировать?
С одной стороны у узнаю себя прежнего, с другой я немного не понимаю статью.
На мой взгляд позиция, описанная в статье, близкая к невмешательству и реактивности.
Например, одной из ключевых обязанностей вас, как руководителя, является контроль и корректировка, а так же постановка целей.

Для последнего прекрасно подходил, подходит и будет подходить SMART(ER). В процессе постановки целей следует полагаться не на «они изначально настроены на один лад со мной и делают всё сами», а на планирование и управление процессом. Иначе зачем вы вообще нужны? Никакой самый толковый руководитель, в-общем не нужен, если он не разделяет уровни целей и не перетасовывает их.

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

Когда же процесс будет контролируемым, следует задуматься об измеряемости процесса. В конце концов, бюрократия, как вы правильно отметили, необходима. Как ни странно, не только заказчикам и руководству сверху, но и вам самому. Просто этим нужно научиться пользоваться и анализировать. Желательно так же автоматически, и реверсом достать «проблему» из сухих циферок и KPI.

Вообще, на самом деле вам к PMBOK и CMMI-Dev, например. Так как традиционно процессов в отрасли и понимания своей роли у вас не особенно есть. Поэтому кто-то должен тыкнуть, показать и разжевать, как вам, так и сообществу на основе структурированных, конкретных статей, что такое проекты и процессы. Потому что, увы, такие как у вас статьи, хотя и очень живые, но никогда не ответят на вопросы начинающих руководителей в сфере IT.
Господи, да кто же говорит о методологиях тут? Если есть методология (или есть где ее изучить) — это прекрасно. Я ни разу не заикаюсь о том, как и когда что делать, как строить процессы, какую взять методологию — потому что тут ничего универсального не посоветуешь, это будет все равно написать статью «Если вы решили стать программистом, то какой язык выбрать». Статья — проповедь именно для вчерашних спецов, которым сказали: с завтрашнего дня ты руководишь отделом. Я сплошь и рядом вижу, что у многих это трансформируется в вывод «Буду делать, что делал всегда, за начальничью зарплату, отлично!». Нет, не выйдет — это другая работа, с такими вызовами, которых никогда не встретишь на прежнем месте, с другим кругом задач, для неё нужно перестроить своё восприятие работы.

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

Речь-то идет о готовности вчерашнего рядового поменять набор целей и задач в голове. Эта статья отвечает на вопросы будущего начинающего руководителя. А вот когда он уже начал руководить — тут найдутся советники посодержательнее меня.
Если не ошибаюсь, на эту тему был замечательный курс от Стратоплана.

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

Не в обиду вам, конечно. Я лично поставил плюс статье. Просто моё личное имхо, что немного не с этого начинать надо в наставлении будущих руководителей.
UFO just landed and posted this here
За водителей транспортного цеха — плюс)
Добавлю от себя немного:
1. Первое время вы будете кайфовать от новой должности. Но месяца через два-три, кем бы вы не были, вы ощутите очень серьезный стресс. Будет казаться что вы ничего не понимаете и не можете сделать, а кругом одни бездельники. Не пугайтесь — все через эту «яму» проходят. Не суетитесь, больше рефлексируйте собственные мысли и решения.
2. Ответственность. Это то основное, что от вас ждут вышестоящие руководители. Никого не волнует кто у вас в отделе виноват в конкретной общей проблеме. Вы — точка входа, и вам за все отвечать. Но! это не значит что получив заслуженных взысканий от начальства вы не должны спускать их ниже по служебной лестнице. Виновные внутри отдела тоже должны хотя бы об этом знать.
2.1 Не бойтесь вышестоящим боссам честно и открыто (и без дрожи в голосе) признаться в своем косяке. Вы очень удивитесь реакции, попробуйте.
3. Дружба и руководство. Вообще это вещи почти несовместимые. Вы не можете быть закадычным корешем своему подчиненному — из этого ничего хорошего не выйдет. Но! Есть хороший lifehack. Совместить в один момент времени действительно не получится — поэтому учитесь быть на работе боссом, а за обедом, в курилке, на корпоративе — другом. Ни одного серьезного разговора и наставления. Снимайте маску босса. Да, это в какой-то степени лицемерие, но так можно сохранить дружбу.
4. Плохое решение хуже никакого. Не ошибается только тот, кто ничего не делает.
Плохое решение хуже никакого
Ошибка. Лучше. Плохое — лучше никакого
Да, забыл самое важное. Вы теперь не имеете право на эмоции, особенно негативные. Если вы даже решили на кого-то орать так чтобы стекла дрожали — это должно быть четко продуманное действие с определенной целью. Вы должны понимать, зачем вы это делаете.
А постоянно сдерживать эмоции — это тяжелая психологическая нагрузка, ищите способы спускать пар вне работы и дома.
Sign up to leave a comment.

Articles