Комментарии 20
Я буду эпизодически спрашивать: ты, Вася, делаешь, эту задачу или нет? Потому что она мне важна, и мне надо отчитаться руководству, что мы не сфакапим ее, но я не буду разбираться, как ты ее делаешь, что ты там с ней делаешь – твои проблемы, может не делать ничего, потом в последнюю ночью все заколбасить, я не возражаю, если это будет работать.
Тут есть нюанс. У Васи может быть проблема, которую он на своем уровне решить не может. Каким образом и когда уважаемый докладчик об этом узнает?
Отвечу за докладчика. У тимлидов и руководителей разработки формируется постепенно чутьё — ты чуешь, что что-то не так. Так вот при малейшем подозрении надо докопаться до реальности — может быть даже непрямыми вопросами, но получить чёткое понимание, вся ли информация есть, всё ли Вася понимает, он понимает, что делать?
Обычно это быстро всплывает, ты видишь, что разработчик плавает, не уверен, начинаешь копать и выясняется, что уже три часа Вася пытается решить проблему, не эскалируя её до коллег и наверх. Делаешь эскалацию за него.
Обычно это быстро всплывает, ты видишь, что разработчик плавает, не уверен, начинаешь копать и выясняется, что уже три часа Вася пытается решить проблему, не эскалируя её до коллег и наверх. Делаешь эскалацию за него.
Это возможный вариант. Только противоречит словам докладчика "может не делать ничего, потом в последнюю ночью все заколбасить, я не возражаю, если это будет работать". Большой шанс наутро узнать, что ночью была проблема на сервере сборки, потому что сборщики не знали, что Вася собирается ночью работать. Вася самоотверженно лег на амбразуру и всю ночь пытался собрать пакет самостоятельно, никого не беспокоя. Но у него не вышло. А сегодня Вася работать не в состоянии, потому что у него с утра запланирован визит к врачу / сдача экзаменов в ГИБДД / ремонт в квартире / отпуск в жаркие страны (нужное подчеркнуть) — ведь он рассчитывал сдать работу утром и весь день свободен.
Я бы крайне возражал, чтобы кто-то из команды что-либо делал в последнюю ночь. Потому что (а) в ретроспективе это ни разу не было оправданным на моей памяти, и (б) характеризовало бы меня как фигового тим-лидера.
Я бы крайне возражал, чтобы кто-то из команды что-либо делал в последнюю ночь. Потому что (а) в ретроспективе это ни разу не было оправданным на моей памяти, и (б) характеризовало бы меня как фигового тим-лидера.
Если отношения выстроены верно, то руководитель узнает, когда к нему приходит Вася и рассказывает сам о проблеме.
Работать должно в обе стороны, мы можете спросить «как дела» и вам сами говорят «как дела».
Работать должно в обе стороны, мы можете спросить «как дела» и вам сами говорят «как дела».
В какой-то период времени я стал жаворонком и думаю: «Сейчас я приду к восьми утра на работу и поработаю спокойно один». Куда там! Я теперь прихожу на работу в восемь утра, а там уже сидят четыре человека. Я иногда прихожу на работу в восемь вечера – забыл что-нибудь – они там сидят. У меня рабочий день по сути расширился на четыре часа. То есть охват рабочего времени подразделением увеличился на четыре часа. Вместо того, чтобы работать хуже, они стали работать лучше. Сволочи (смайлик).
Последнее слово на мой взгляд лучше написать в единственном числе. И возможно без смайлика. Если рабочее время в мирное время увеличивается в полтора раза, гробится здоровье как начальника, так и подчиненных. У усталости есть свойство накапливаться. Плюс падение производительности труда. Интенсивность заменена на экстенсивность, а это тупиковый путь развития.
В целом соглашаясь с большинством тезисов, хотелось бы отметить ряд принципиальных вещей, которые в статье изложены недостаточно полно либо совсем пропущены.
1. Самое главное, чтобы руководитель был умным. Не образованным, не опытным, а именно умным от природы. Умным настолько, чтобы осознать, что люди в его подчинении – это ресурс, от которого можно либо извлечь выгоду, либо получить дополнительные головняки из-за собственной тупости или лени. А знания и опыт для умного человека — дело наживное.
2. Если технарь является действительно технарем, а не гуманитарием с техническим образованием, то он должен понимать, что в любой технической, а значит кибернетической, системе ключевым фактором эффективного управления является наличие двух составляющих – четкой цели с количественным описанием и системы обратной связи.
А чем, как не кибернетической системой, является проект создания компьютерной программы любой степени сложности (риторический вопрос)?
3. Даже самому умному руководителю в одиночку невозможно сформулировать даже основные количественные критерии конечной цели. На практике для формализации конечных целей необходимо тратить не менее 10-20% рабочего времени для разъяснения сотрудникам собственных целей и задач. Этим убиваются сразу два зайца: проговаривая вслух, вынужденно приходится преобразовывать образы в своей голове к понятным людям формулировкам, а отвечая на вопросы, получаешь качественную обратную связь.
4. Очень хорошо показала на практике управленческая концепция «долго запрягать, но потом быстро ехать». Технически это означает, что любые технические либо управленческие решения, которые затрагивают двух и более сотрудников, предварительно оформляются в письменном виде и уточняются до тех пор, пока не станут понятны всем заинтересованным сторонам (например, в любом трекере). Это позволяет максимально снизить потери времени и ресурсов на различные переделки и исправление ошибок, возникающих в результате «глухих телефончиков», когда на словах все поняли друг друга, но каждый понял по-своему. От руководителя нужны только правила и инструкции по оформлению задач.
5. И напоследок хотелось бы сказать, что какие бы современные и модные методики управления не разрабатывались, по жизни наиболее эффективным является индивидуальный подход к каждому сотруднику с его уникальным набором тараканов в голове. Как говорится — «будь проще, и к тебе потянутся люди».
1. Самое главное, чтобы руководитель был умным. Не образованным, не опытным, а именно умным от природы. Умным настолько, чтобы осознать, что люди в его подчинении – это ресурс, от которого можно либо извлечь выгоду, либо получить дополнительные головняки из-за собственной тупости или лени. А знания и опыт для умного человека — дело наживное.
2. Если технарь является действительно технарем, а не гуманитарием с техническим образованием, то он должен понимать, что в любой технической, а значит кибернетической, системе ключевым фактором эффективного управления является наличие двух составляющих – четкой цели с количественным описанием и системы обратной связи.
А чем, как не кибернетической системой, является проект создания компьютерной программы любой степени сложности (риторический вопрос)?
3. Даже самому умному руководителю в одиночку невозможно сформулировать даже основные количественные критерии конечной цели. На практике для формализации конечных целей необходимо тратить не менее 10-20% рабочего времени для разъяснения сотрудникам собственных целей и задач. Этим убиваются сразу два зайца: проговаривая вслух, вынужденно приходится преобразовывать образы в своей голове к понятным людям формулировкам, а отвечая на вопросы, получаешь качественную обратную связь.
4. Очень хорошо показала на практике управленческая концепция «долго запрягать, но потом быстро ехать». Технически это означает, что любые технические либо управленческие решения, которые затрагивают двух и более сотрудников, предварительно оформляются в письменном виде и уточняются до тех пор, пока не станут понятны всем заинтересованным сторонам (например, в любом трекере). Это позволяет максимально снизить потери времени и ресурсов на различные переделки и исправление ошибок, возникающих в результате «глухих телефончиков», когда на словах все поняли друг друга, но каждый понял по-своему. От руководителя нужны только правила и инструкции по оформлению задач.
5. И напоследок хотелось бы сказать, что какие бы современные и модные методики управления не разрабатывались, по жизни наиболее эффективным является индивидуальный подход к каждому сотруднику с его уникальным набором тараканов в голове. Как говорится — «будь проще, и к тебе потянутся люди».
Прекрасный доклад, узнаю себя на 100%, только не согласен с фразой «Никого не увольнял и не собираюсь».
И он это заявил на всю аудиторию?!
Т.е. теперь его подчиненные и вправду могут больше ничего не делать )) их же не уволят.
На мой взгляд это ошибочная позиция. Ко всему, что изложил автор, хочет добавить, что в случае, если результаты вашей работы не достигнут моих ожиданий, в можете быть уволены в любой момент, хоть в конце недели, хоть в начале.
И он это заявил на всю аудиторию?!
Т.е. теперь его подчиненные и вправду могут больше ничего не делать )) их же не уволят.
На мой взгляд это ошибочная позиция. Ко всему, что изложил автор, хочет добавить, что в случае, если результаты вашей работы не достигнут моих ожиданий, в можете быть уволены в любой момент, хоть в конце недели, хоть в начале.
На этот счёт существуют разные мнения. Существуют вполне успешные коммерческие структуры, в которых прямо зафиксированы гарантии от увольнения. Уйти можно, но прямо говорится, что увольнение не входит в список возможных санкций. При этом, там конечно устанавливаются иные требования. Такие, как неограниченный спектр решаемых задач, ненормированный рабочий график и так далее. При этом, проблемы там решаются не менее эффективно. В каком-то смысле, даже более.
А если сотрудник-исполнитель не приходит на работу раньше 14.00, если регулярно не укладывается в сроки, если плетет интриги или сливает что-то конкурентам, как можно не увольнять?
А при желании прицепиться, как говориться, был-бы человек, а статья найдется.
А при желании прицепиться, как говориться, был-бы человек, а статья найдется.
В таких коллективах отношения строятся несколько иначе. Там редко можно встретить такую фразу как «сотрудник-исполнитель». Обычно, внутренние отношения там строятся не по принципу пирамиды начальников и подчинённых. Это не очень просто описать словесно. Увольнение в таких коллективах больше похоже на развод в большой семье, чем на рядовой управленческий акт. Тот подход и те проблемы о которых говорите вы, обычно встречаются в коллективах, которые складываются на короткий срок. На время реализации проекта или что-то в таком духе. А есть коллективы, которые существуют десятилетиями с низкой текучкой. Там отношения между людьми другие и проблемы другие и способы их решения тоже. Что-то похожее можно наверное встретить в небольших деревнях или в криминальной среде, в каких-нибудь израильских кибуцах. Но это и в коммерческих структурах встречается. И это часто бывает эффективно, хотя строить такие коллективы гораздо сложнее
Никогда не понимал проблемы с делегированием и попытками делать все самому. Это же такой кайф — выдал задач подчиненным, и пускай они сами головы ломают как их делать и ковыряются в унылых мелочах, избавив от этого меня. Лучший способ убрать всю рутину и все то что раздражает в разработке — найти кого-то на кого это можно спихнуть.
Конечно тут надо быть справедливым. Если грести все интересные задачи под себя, а другим оставлять только рутину, то можно быстро остаться без команды.
Конечно тут надо быть справедливым. Если грести все интересные задачи под себя, а другим оставлять только рутину, то можно быстро остаться без команды.
Умение делегировать приходит с умением выполнять задачи (я про нормальных менеджеров).
Джуниор, не умеющий отличить рутину, не видящий четких критериев завершенности, не имеющий за собой успешно выполненных задач — не сможет грамотно делегировать, и все его устремления будут заканчиваться централизацией на себе. Как повзрослеет — научится.
Джуниор, не умеющий отличить рутину, не видящий четких критериев завершенности, не имеющий за собой успешно выполненных задач — не сможет грамотно делегировать, и все его устремления будут заканчиваться централизацией на себе. Как повзрослеет — научится.
Мне, к примеру, очень интересно поковырятся к коде, реализовать алгоритм, придумать архитектуру и т.п. Думаю многим технарям это интересно, творить своими руками, потому и делаешь сам… И получается выбор: кайф от программирования или «блин, опять план писать, задачи ставить»… Но, так как задача тимлида — это слаженно работающая команда, а это 90% управления и 10% разработки, то либо надо научиться кайфовать от управления, либо увольняться с должности…
Т.е. это вопрос интереса и умения его находить в новой сфере…
Т.е. это вопрос интереса и умения его находить в новой сфере…
Интересно мнение людей руководящих проектами представляющими что то большее чем (95 % операций чтение из базы, и 5 % инсерт в базу )
«Твои планерки народ, скажем так, демотивируют, расстраиваются люди»
Очень интересно, какие аргументы есть против планерок?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как убить технаря в тимлиде