Это моя задача!. «Я ее хочу решить и никому не хочу отдавать. Как же я отдам эту задачу другому человеку, мне же так интересно придумывать и воплощать, а потом смотреть, как замечательно все работает.»
В чем проблема?
В том, что к моменту, когда вам нужно делегировать свои задачи, у вас, скорее всего, не одна, а 10, 20 или более важных задач. Важных и нужных, которые должны быть сделаны к определенному сроку. У вашего сотрудника, которому вы бы могли отдать эту задачу, их меньше, либо они не столь важные и их можно подвинуть. Возможно, у меня было больше опыта в решении подобных задач, и на основании этого я могла бы решить ее лучше. Если бы у меня была только эта задача. Но так как у меня куча других и они все не помещаются даже в расширенный более 8 часов рабочий день, то решение этих задач откладывается либо растягивается. Кроме того, человек, который получит задачу сможет посвятить ей все свое время. А значит, возможно, сделает ее гораздо лучше. Слишком много «возможно»? Давайте предположим, что он сделает ее хуже чем вы бы сделали сами. Но уж точно раньше.
А как сказал кто-то умный (не помню кто): «Хорошее решение в понедельник лучше, чем отличное в пятницу».
Решение:
Я начала отдавать задачи, при этом желательно прямо отдавать полностью задачу, не навязывая собственное решение. Очень помогает на ранних этапах обсуждение процесса на каждом из этапов: планирование решения задачи, разделение на этапы, обсуждение в начале и в конце каждого из этапов.
Плюсы: высвободится время на решение других задач, или возможно, рабочий день снова станет 8 часов и вы, наконец, выспитесь и побудете с семьей. Человек, которому вы отдадите задачу внесет свой вклад в проект и получит возможность «прокачать» свои навыки, да и вопросы по реализации в дальнейшем будут задавать не вам, а ему.
Я самый умный. Некоторые задачи не хочется делегировать, так как есть недоверие к коллегам. Иногда возникает мысль: «Отдашь задачу, а там все реализуют не так как нужно».
В чем проблема?
Самыми умными становятся, решая сложные задачи. Чувствуете? Проблема тут в том, что не отдавая сотрудникам все более сложные задачи их уровень не повышается. Вы не даете им шанса вырасти.
Решение:
Возможно вы и есть самый умный. Возможно и реализуют не идеально — но опять же, как то оно будет работать. Работающая система с огрехами всегда лучше, чем идеальная и не воплощенная система. Вы можете обсуждать задачу и договариваться о реализации см. выше.
Тут объяснять дольше, чем делать. «Делать — 5 минут делать, а объяснять — 30 минут, а иногда и 2 часа. Сделаю это сама!»
В чем проблема?
Обычно такие 5-минутные задачи возникают периодически. Они, вроде бы, не большие, но съедают время и отвлекают от более важных задач.
Решение:
Отдайте их! Не хотите рассказывать 2 часа — напишите документацию за 3 часа — зато она останется для других коллег.
Иногда такие задачи еще и срочные. Отдайте, покажите, расскажите как делать такие задачи по крайней мере двум сотрудникам. Так вы освободитесь от одного отвлекающего от важных задач фактора, сотрудники узнают больше, научатся делать что-то новое. По возможности, автоматизируйте эту задачу, если у вас уже есть понимание как это можно сделать. Но, сначала отдайте — так появится время на автоматизацию.
Напишу документацию потом, когда будет время. Если у вас часто меняющийся проект и команда из 5 человек, то в таком случае, возможно, документация — слишком большая роскошь.
Документацию писать долго и потом все равно надо рассказывать.
В чем проблема?
При расширении проекта вы и не заметите как окажитесь среди немногих носителей знаний,
Решение:
Надо писать документация, показывать ее, и каждый раз когда задают вопрос дополнять документацию.
Если вы занимаетесь какой-то большой задачей с большим количеством нюансов — и на горизонте появилась необходимость ее отдать — сэкономьте себе время — напишите документацию и инструкции. Да, вам все равно будут задавать вопросы — дополняйте документацию по ним. Вопросы — это ваши помощники.
В наличии актуальной документации масса плюсов! Она облегчает перевод нового человека на эту задачу, позволяет отдавать задачу большему количеству людей. Также, если вдруг вы решите завтра сменить работу или «уехать на Таити и писать картины как Гоген» — задачи будут также делаться, вам это будет сделать проще.
Все и так очень заняты, у них тоже нет времени. «Как же я отдам эту задачу? Ведь все тоже очень заняты? и она такая скучная и неинтересная, и вроде немного времени занимает. Сделаю сама.»
В чем проблема?
В том, что такие задачи занимают ваше драгоценное время. В буквальном смысле драгоценное. Для компании. Ведь ваша зарплата наверняка выше зарплаты ваших подчиненных. Вот и посчитайте, сколько компания переплачивает вам за эту рутинную, для вас, задачу.
Второй момент. Эта задача для вас — рутинная и понятная. А для вашего сотрудника это может быть новым и интересным материалом. Если она становится и для него рутиной, либо у него уже есть кому ее подарить, либо ее можно автоматизировать.
Решение:
Как вы уже догадались — задачу нужно отдать. Посмотреть правильно кому — наверняка найдется человек, у которого есть на нее время, и для него она будет новой.
Итоги
Делегирование — замечательный способ, которым вы можете повысить свой уровень — высвободив время под новые и важные задачи, для которых раньше его не хватало. И в то же время вы можете повысить уровень своих подчиненных, отдав им новые задачи.
Когда нужно делегировать? Когда вы знаете уже эту задачу как свои 5 пальцев и можете сделать ее даже пребывая в состоянии крайней усталости, после 1 суток без сна, в состоянии алкогольного опьянения и пр.
Почему? Эта задача уже никак вас не развивает. Не жадничайте — отдайте ее, она будет развивать другого человека, а у вас высвободится время для новых свершений.
Когда вы тащите на себе все — поделитесь работой с другими. В большинстве случаев вы можете отсортировать то, что вы уже делаете на автомате, и либо автоматизировать это, либо отдать. Нет! Не так! В любом случае отдать, а если уже знаете как, то и автоматизировать это.
Комментарии (34)
SpyDeX
15.03.2017 18:03+1Согласен с каждым пунктом и разъяснением.
Слегка расширил бы пункт про «Делать — 5 минут делать, а объяснять — 30 минут».
Объяснение тоже можно делегировать — попросить сначала самостоятельно зафиксировать план работы (в виде документа, который позже можно расшарить), и по этому плану пройтись, подсказать, где ошибки, это всё человек фиксирует и расшаривает.
Двойной профит — документация написана, человек потренировался составлять план, оформлять в человекопонятном виде, ваше время на написание сэкономлено.
yokotoka
15.03.2017 19:15+2«Хорошее решение в понедельник лучше, чем отличное в пятницу»
Это не всегда работает так же хорошо, как и звучит. Есть задачи, например, на которые завязывается потом очень много всего. И сделав это «хорошо в понедельник» потом можно выбросить в мусор очень много человекочасов впоследствии, чтобы переписывать с нуля то, что уже невозможно поддерживать, т.к. «больше не гнётся». А всё потому, что задачу делегировали «просто хорошему разработчику», когда ее надо было сделать лучшему, а заказчику подождать чуть больше расчётного.
Ну и самая мякотка, когда на такие «хорошие» и недописанные, но быстро пущенные в прод решения завязываются системы, от которых начинают зависеть жизни и здоровье людей. Сами эти системы могут быть сколь угодно великолепны и протестированы, но беда придет откуда не ждали.
Наша команда уже чаще баги в сторонних библиотеках и системах находит на продакшене, чем в своем вдоль и поперек протестированном коде. И ощущение, что чем дальше — тем больше этих багов будет в любой программной экосистеме из-за таких вот «хороших решений в понедельник».
KristinaMyLife
15.03.2017 19:20+3Это очень важный момент — в идеале, если задача критичная, а та которую вы описали именно такая, она должна быть одобрена отличным разработчиком. То есть хороший может ею заниматься, но под контролем отличного как спеца.
Также если это вдруг какое то изменение в архитектуре, либо в каком то критичном узле — это не означает, что делать это может только отличный, и не может хороший, может. Но решение должно быть просмотрено, обсуждено и утверждено. И так же разделение на этапы — и подтверждение что на каждом этапе происходит то, что ожидалось — важно. Опять же code review — тоже в этом случае важный момент.
Кроме того надо глянуть, чем занят отличный разработчик и посмотреть нельзя ли что-нибудь у него забрать и передать кому нибудь еще, возможно так и время для такой важной задачи появится.
Есть вещи, где качеством нельзя жертвовать в угоду скорости, но их обычно немного. Если речь не идет о здоровье\безопасности людей, ну и о деньгах наверное.
lexit
15.03.2017 22:11+1Верно, ну и не стоит забывать о том, что не делегируются задачи касаемо оплаты труда (премирования) своей службы и бюджетирования. Не очень приятно находясь в другой стране в отпуске получить звонок от ГД с вопросом… «А какого фига премия такая большая? (в 10 раз больше чем обычно) „
Fortop
15.03.2017 22:13-1Где откровение?
Читаю третью статью и все просто ни о чем.
Кто подскажет, как добавить конкретного автора а анти-избранные, чтобы в ленте и не появлялся?
NumLock
15.03.2017 22:34К сожалению это проблема повсеместна. Не только в мелких конторах но и даже в банках и на больших предприятиях есть люди, которые занимают позиции без нужного проф. образования.
Когда нет нормального управления то всё превращается в неуправляемый самодел. Как например, это делегирование. Подарите управленцу книжку о менеджменте в картинках, может хоть какая нибудь организация появится…
Jef239
15.03.2017 23:27Брукс в "мифическом человеко-месяце" прекрасно описал, к чему приводит такое делегирование. Вкратце — проектировать (и вообще приниать существенные решения) должны наиболее грамотные игроки команды. Попытка отдать сложную задачу подчиненным меньшей квалификации — лишь затягивает сроки.
Более подробное описание ценой в миллион долларов.Очень неприятно совершить ошибку стоимостью в миллион долларов, но зато она надолго запоминается. Я отчетливо помню тот день, когда мы приняли решение о том, как практически организовать составление внешних спецификаций для OS/360. Менеджер по архитектуре, менеджер по реализации управляющей программы и я прорабатывали план, график и разделение обязанностей.
У менеджера по архитектуре было 10 хороших специалистов. Он утверждал, что они в состоянии написать спецификации и сделать это надлежащим образом. Это должно было занять 10 месяцев — на три больше, чем отводилось по графику.
У менеджера по реализации управляющей программы было 150 человек. Он заявлял, что они могут подготовить спецификации, при этом группа архитекторов выполняла бы координирующие функции. Обещалось, что это будет сделано хорошо и практично, с соблюдением сроков. Более того, если оставить спецификации группе архитекторов, его 150 человек в течение десятимесяцев будут бить баклуши.
На это менеджер по архитектуре возразил, что если я сделаю ответственной за написание спецификаций группу управляющей программы, то результата в срок не будет: он все равно задержится на три месяца, но по качеству будет много хуже.
Так оно и оказалось в действительности. Он оказался прав в обоих пунктах. Кроме того, из-за отсутствия концептуальной целостности создание и внесение изменений в систему оказались значительно более дорого
KristinaMyLife
15.03.2017 23:40Вы правы, нельзя нанять джуниора и делегировать ему задачу по проектированию ядра системы например. Везде должна быть мера и здравый смысл. Идея в том, что сложность отдаваемых задач должна наращиваться постепенно.
Это как с мышцами, если есть тренер, который поднимает 100 кг и приду я, то я их не подниму как не делегируй. Но если я приду, мне тренер даст 3 кг, я с ними освоюсь и он не будет увеличивать нагрузку, то и результата будет немного, и я возможно расстроюсь и уйду к другому тренеру. Мне кажется так и с задачами и с ростом подчиненных. Должен быть определенный баланс между «как попасть в сроки», «сделать хорошо», и «прокачать людей». И последнее тоже не нужно забывать, ведь опять же никто из нас не пришел после универа супер профи, каждый человек растет благодаря обучению и решению более сложных задач.Jef239
16.03.2017 01:04Зависит от того, что вы хотите. Если у вас цель вырастить крутую команду — то вы правы. А если цель — сделать качественный проект — то нет.
Тот же тренер, если готовит команду на Олимпиаду — просто выкинет тех, кто не поднимает 150 кг.
P.S. Команда разработчиков ядра OS/360 — это далеко не юниоры были. Юниоры ядро операционной системы вообще-то не пишут.a4k
16.03.2017 10:16+1Зависит от того, что вы хотите. Если у вас цель вырастить крутую команду — то вы правы. А если цель — сделать качественный проект — то нет.
Но сроки то никто не отменял.
Как мне говорил мой начальник когда я стал руководителем группы: не хочешь/не умеешь поручать работу своим подчиненным — делай сам, оставайся после работы, выходи в выходные.
И что бы сделать качественный проект приходится меньше писать код самому, а больше распределять и объяснять таски, продумывать алгоритмы и ревьювить код своей команды.Jef239
16.03.2017 17:40В этом отличие ненастоящего программирования от настоящего. В ненастоящем сроки, «научно» подсчитанные программистом, подлежат умножению вначале на пи, потом на е. И вообще, сроки — далеко не самое важное.
Вы платье где будете шить? У портнихи, которая соблюдает сроки? Или у той, которая сошьет красиво и по вашей фигуре? Сроки горят — значит в магазине покупаете готовое, потом подгоняете по фигуре, хуяк-хуяк и в продакшн.
Вы почитайте Брукса. А потом проверьте его выводы с карандашом и бумажкой. Добавление людей в проект лишь замедляет работу при том же качестве. Или ускоряет её — за счет снижения качества.
Я понимаю, что в вашем мире важнее всего сроки. А в нашем — нет.a4k
20.03.2017 17:29Что то у вас все в одну кучу смешано…
Я понимаю, что в вашем мире важнее всего сроки. А в нашем — нет.
Инопланетяне среди нас? ))
Вы платье где будете шить? У портнихи, которая соблюдает сроки? Или у той, которая сошьет красиво и по вашей фигуре? Сроки горят — значит в магазине покупаете готовое, потом подгоняете по фигуре, хуяк-хуяк и в продакшн.
Если шьется свадебное платье то как бы красиво оно не выглядело если просран дедлайн (дата свадьбы) заказчику оно больше не нужно.
Сроки могут гореть из-за того что портниха большую часть времени потратила на вышивку всяких рюшечек а за основную работу браться не спешила.
Если перевести это на нашу область: реализовывались и постоянно переписывались мелкие фичи а за основной функционал никто и не взялся.
Вы почитайте Брукса. А потом проверьте его выводы с карандашом и бумажкой. Добавление людей в проект лишь замедляет работу при том же качестве. Или ускоряет её — за счет снижения качества.
Тогда по вашему получается — идеален проект с одним разработчиком. Так вы ничего серьезного не сделаете.
А если серьезно то Брукса я читал а вот вы сделали неправильный вывод.
Правильно так: добавление людей в проект на поздних стадиях разработки лишь отодвигает срок сдачи проекта.Jef239
20.03.2017 19:35Я уже цитировал историю, как 10 архитекторов заменили на 150 программистов и как это затянуло сроки. Вряд ли разработку спецификаций можно назвать «поздней стадией». :-)
А идеально — вместо 5 разработчиков нанять одного и платить ему в 4 раза больше.
В целом правильное число людей на проекте — 3-5, границы от 1 до 7.
И да, мне везет заниматься интересными проектами в компании очень крутых людей.
Так вы ничего серьезного не сделаете
Мы сделали систему в 135 тысяч строк. Впятером. При этом единственным «juniorом» был будущий технический директор Jet Brains — он делал экранную библиотеку. 90% кода мы написали вдвоем с Антоном. Покойного Антона Креницкого вы, может быть, знаете по Auslogic registry defrag. Ещё один человек писал SCADA + некоторые отдельные части. Плюс шеф, который осуществлял общее руководство.
Опишу проект на хабре — кину ссылку. Пока что так.
Сейчас со мной работает человек, который в одиночку написал ГАИшный фоторадар (несколько тысяч установок по стране). И он один сделал нашу компанию из чисто софверной в софтерно-хардовую.
a4k
21.03.2017 10:14Я уже цитировал историю, как 10 архитекторов заменили на 150 программистов и как это затянуло сроки. Вряд ли разработку спецификаций можно назвать «поздней стадией». :-)
Если вы цитируете кого-то надо указывать полную цитату, без своих правок, в оригинальной цитате Брукс писал именно про поздние стадии.
Понятно что задачу можно распараллеливать на подзадачи только до какого то предела.
А идеально — вместо 5 разработчиков нанять одного и платить ему в 4 раза больше.
А при постройке дома вместо бригады строителей нанять одного и платить ему как за целую бригаду…
Похоже у вас другая крайность, вы не хотите делегировать хоть что-то кому-нибудь другому.
Видел уже таких руководителей чуть не довёвших предприятие до банкротства:
При модернизации предприятия главный инженер решил все задачи решать лично, что было этому причиной не знаю, может не умел руководить, может боялся что его подсидят, но в результате, из-за огромного количества вопросов и проблем, он успевал решать только самые мелкие задачи, от крупных и более серьезных его постоянно отвлекали. Если бы его не сменили на более адекватного руководителя закончилось все бы очень плохо.Jef239
21.03.2017 18:24Я вам очень рекомендую перечитать Брукса и сравнить цитату с полным текстом. Судя по вашим словами, Брукса вы так и не прочли. Более того, даже не потрудились прочесть цитату.
И ещё раз цитата из Брукса про ошибку ценой в миллион долларовОчень неприятно совершить ошибку стоимостью в миллион долларов, но зато она надолго запоминается. Я отчетливо помню тот день, когда мы приняли решение о том, как практически организовать составление внешних спецификаций для OS/360. Менеджер по архитектуре, менеджер по реализации управляющей программы и я прорабатывали план, график и разделение обязанностей.
У менеджера по архитектуре было 10 хороших специалистов. Он утверждал, что они в состоянии написать спецификации и сделать это надлежащим образом. Это должно было занять 10 месяцев — на три больше, чем отводилось по графику.
У менеджера по реализации управляющей программы было 150 человек. Он заявлял, что они могут подготовить спецификации, при этом группа архитекторов выполняла бы координирующие функции. Обещалось, что это будет сделано хорошо и практично, с соблюдением сроков. Более того, если оставить спецификации группе архитекторов, его 150 человек в течение десятимесяцев будут бить баклуши.
На это менеджер по архитектуре возразил, что если я сделаю ответственной за написание спецификаций группу управляющей программы, то результата в срок не будет: он все равно задержится на три месяца, но по качеству будет много хуже.
Так оно и оказалось в действительности. Он оказался прав в обоих пунктах. Кроме того, из-за отсутствия концептуальной целостности создание и внесение изменений в систему оказались значительно более дорого
a4k
22.03.2017 10:07А если уж вам так нравится аналогия со строительством, то бригада таджиков сделает квартирный ремонт не быстрее пары русских. И выйдет это дороже. Просто пару русских вы будете долго искать, а бригаду таджиков найдете за день.
Я для вас аналогии подбирал, вы же их начали приводить, строительство показалась вполне удобной аналогией.
Вы почему то выбираете работы объем и сложность которых позволяет их выполнить одному человеку и распространяете этот вывод на всё.
Я надеюсь вы же не думаете что пары русских будет достаточно для постройки современного многоквартирного дома? Причем которые построят дом не медленнее нормальной бригады строителей? Да, причем постройка дома парой человек (по вашему в идеале одному) в результате выйдет дешевле?
Это все получается из ваших слов.
Шеф участвовал во всех частях. Не написал ни одной строчки кода, но все технические решения обговаривались с ним. Придумал кучу интересных идей на самых разных уровнях системы. Кроме того, на нём было документирование и менеджмент.
Вы же сами приводите пример делегирования, причем, раз вы приводите проект в пример, успешного делегирования.
Делегировать «хоть что-нибудь» это значит замедлить проект.
Ваш шеф тратил свое время участвуя в совещаниях, обсуждая технические технические решения, объясняя вам свои идеи и проверяя то ли вы сделали что он хотел. По вашему это зло и так делать неправильно и это только затягивает сроки.
Думаю это был не единственный проект на фирме и он участвовал во всех, а если бы он не делегировал разработку проекта вам про остальные можно было бы забыть, времени на них бы не было.
Делегировать нужно очень крупные части. Или по вертикали — отдельные дома или по горизонтали — вся электрика или вся сантехника.
Похоже вы просто не смогли разбить свою часть проекта на подчасти.Jef239
23.03.2017 04:12Ваш шеф тратил свое время участвуя в совещаниях, обсуждая технические технические решения, объясняя вам свои идеи и проверяя то ли вы сделали что он хотел. По вашему это зло и так делать неправильно и это только затягивает сроки.
Угу, это зло, потому было ровно наоборот. Это я подходил к шефу, рассказывал свои варианты решения и их последствия и спрашивал, а не возьмет ли он ответственность за выбор. Потому что я сам — обычно торможу, пока не продумаю последствия до конца.
Похоже вы просто не смогли разбить свою часть проекта на подчасти.
В сервере из двух десятков одновременно работающих тредов — достаточно подчастей. В том числе там был и компилятор и декомпилятор. Но… отдача части проекта другому разработчику увеличила бы и общую трудоемкость и время выполнения проекта.
Я надеюсь вы же не думаете что пары русских будет достаточно для постройки современного многоквартирного дома? Причем которые построят дом не медленнее нормальной бригады строителей? Да, причем постройка дома парой человек (по вашему в идеале одному) в результате выйдет дешевле?
За стоимость хрущевки в Питере — можно купить коттедж 250 кв. метров в Калифорнии. Строится коттедж в 325 кв.метров почти в одиночку (женщина + четверо детей, причем младшему два года) за 9 месяцев.
Так что если вам нужны квадратные метры — дешевле и быстрее построить коттеджный поселок, чем многоквартирный дом. И строить его с вертикальным разделением — бригада по 2-3 человека на дом. И с горизонтальным: 2-3 сантехника, 2-3 электрика, 2-3 кровельщика, 2-3 водителя, 1-2 логиста, 1-2 менеджера…
Многоэтажки хороши только тем, что эффективно используют землю. Во всем остальном — они дороже, строятся медленней и просто хуже по качеству. Да и строят их с 18ого века, так что о современности речь вести трудно. И высотное строительство — это тоже 18 век. Петр 1 планировал построить в Кронштадте маяк высотой в 213 метров. Причем строительство прекратилось из-за его смерти, а не по техническим причинам.
Любуйтесь. Высотное строительство 18 века
a4k
23.03.2017 09:44За стоимость хрущевки в Питере — можно купить коттедж 250 кв. метров в Калифорнии. Строится коттедж в 325 кв.метров почти в одиночку (женщина + четверо детей, причем младшему два года) за 9 месяцев.
Так что если вам нужны квадратные метры — дешевле и быстрее построить коттеджный поселок, чем многоквартирный дом. И строить его с вертикальным разделением — бригада по 2-3 человека на дом. И с горизонтальным: 2-3 сантехника, 2-3 электрика, 2-3 кровельщика, 2-3 водителя, 1-2 логиста, 1-2 менеджера…
Многоэтажки хороши только тем, что эффективно используют землю. Во всем остальном — они дороже, строятся медленней и просто хуже по качеству. Да и строят их с 18ого века, так что о современности речь вести трудно. И высотное строительство — это тоже 18 век. Петр 1 планировал построить в Кронштадте маяк высотой в 213 метров. Причем строительство прекратилось из-за его смерти, а не по техническим причинам.
Вы какой то демагогией и словоблудием занимаетесь.
Я привел пример со строительством как простую и понятную аналогию.
А вы зачем все это написали? Причем здесь что за стоимость хрущевки в Питере можно купить коттедж в Калифорнии??? Какая разница для аналогии какие плюсы и минусы в многоэтажках??
Если заказчику нужен именно многоквартирный дом вы сделаете ему коттеджный поселок и потом будете грузить его всем этим???Jef239
23.03.2017 10:40Вы о своем кошельке думаете или о заказчике? Если о своем — то вы так и будете строить многоквартирных монстров. А если вы думаете о заказчике — то ему нужно побольше метров, побыстрее и подешевле. И unix way, то есть коттеджи, позволяет отлично масштабироваться.
Что у вас за задача такая, что заказчик сам хочет многоквартирного монстра?
george_spb
16.03.2017 00:01Очень здорово, что Вы написали вступительный абзац, потому что в нем явно обозначен контекст — для применения указанных правил, нужно их уметь применять. Вы научились за несколько лет, но в статье выдаете «готовые» решения. Обратите внимание, перечисленные причины могут быть взаимоисключающими: задача интересная, задача сложная, задача простая, задача скучная и т.п. А решение предлагается одно — делегировать. На мой взгляд, Вы можете замечательно развить идею если подробнее напишите, как научиться делегировать правильно. Успешно делегировать это действительно круто. Вы интересно пишите, удачи.
KristinaMyLife
16.03.2017 00:11Спасибо!
Про раскрытие темы — поняла, подумаю, напишу.
Озарение как и что нужно делать, чтобы правильно отдать задачу, у меня было после просмотра занятия про делегирование в школе Стратоплан, к сожалению не нашла у них в блоге соответствующую статью.
Из интересного и направляющего в эту сторону также есть Михаил Ефимович Литвак «Командовать или подчиняться», у него тоже описано как правильно делегировать задачи.george_spb
24.03.2017 01:16Понимаю Вас, «озарение» — это некая точка, в которой «количество перешло в качество». Естественно это происходит после очередной порции информации (знаний, понимания). Я хочу сказать, что совсем не обязательно именно это занятие такое. Просто у Вас оно послужило спусковым крючком и заякорилось. Но если кто-то пройдет это занятие еще не будучи готовым к делегированию он подумает «что за ерунда?».
Я, кстати зашел к ним по Вашей ссылке, и то же не нашел.
Ну и там, у меня в комменте опечатка, которая не дает мне спокойно спать. Вы интересно пишете. )
KrakaZyabrik
16.03.2017 10:15+1Возможно проблема выбора делегировать или нет возникает из-за конкуренции на решениях / архитектуре / коде. Отдать код другому означает потерять над ним контроль и, вероятно, со множеством последствий.
Был случай, начали разрабатывать систему, спроектировали предварительную архитектуру БД, интерфейсы хранимок, передали разработчику на реализацию. Закончилось тем, что от предварительной архитектуры не осталось ровным счетом ничего.
Однако делегировать все же надо хотя бы потому, что надо же как-то распараллеливать работу по работникам. Вопрос только в том, как это сделать правильно. И лучше заменить термин делегирование на распределение заданий.
heleo
16.03.2017 11:01+1Кадры решают всё
Для хорошего делегирования нужны те, кому это реально можно делегировать. Все эти правила хорошо работают когда есть люди способные развиваться, вникать в проект и становиться полноправными участниками, а не ходить как болванчики с вопросами о каждой запятой и фразами «мне не понятно и это слишком сложно» работая уже не один месяц.KristinaMyLife
16.03.2017 11:13Очень важный момент, хорошо, что вы о нем написали. К сожалению есть люди, которые совсем не готовы ни с чем разбираться сами, и действительно спрашивают каждую запятую, при этом не ясно, если человек шел в проект без документации (я на собеседовании об этом старалась говорить) или с провалами в ней, то почему он не может прочитать и разобраться по коду. Фраза «Это слишком сложно» вообще убийственная, хорошо, что человек об этом говорит, это звоночек что ему нужно дать задачу попроще, но возникает вопрос, а будет ли это для него когда-нибудь понятно. В общем люди очень разные и уметь понять кому что давать и как — очень важный навык, который к сожалению нарабатывается небыстро.
lencom
16.03.2017 19:40+1Хорошая статья. Мне это очень близко. Я умирала над проектами, а мои сотрудники были в расслабленном состоянии или делали что-то неважное. Хорошо, что продлилось это не долго. Для себя определила 2 вещи:
1. Нужно просто сделать это. Просто сменить у задачи ответственного. Сказать — это твоя задача. Если трудно решиться и не хочется этого делать — нужна только секунда, чтобы сказать эту фразу, просто скажи её. После чего нужно убедиться, что задача понятна — но тут как обычно.
2. Делегировать правильному человеку. Даже если с меньшим опытом, но он умеет находить решение, пусть и сильно дольше, чем ты, пусть не так «идеально», как ты. Как проверить — дать несколько своих задач: справляется — давать больше, на усложнение. Не справляется — поручить другую работу или расстаться — здесь тоже нужна решимость. У наших молодых руководителей сейчас 2 основные проблемы: неумение делегировать и боязнь принимать кадровые решения.
Bookimed
18.03.2017 00:41+1Принцип делегирования стоит применять и как способ мотивации, но для этого нужно уделять огромное внимание отбору талантов. Осознанность — главная ценность, которую несет в себе сотрудник. Едва ли можно ее развить, если изначально она отсутствовала. Но ее задатки и очевидные проявления даже на этапе собеседования можно/нужно отследить.
Optimus_990
21.03.2017 17:10Я считаю, что каждый работник, который хочет двигаться вперед, должен осознавать в перспективе делегирование полномочий. Без этого никак.
RomanArzumanyan
А зачем было соглашаться на позицию менеджера, если нравилось инженерить?
KristinaMyLife
О, это интересный вопрос и я немного подвисла, компания была совсем маленькая, и в общем была ситуация «если не я то кто», и уходить из компании тоже не хотелось — было очень интересно и работа горела, и прямо видение было. В общем из минусов только руководство, потом я поняла, что оно тоже плюс, главное уметь его правильно готовить.
a4k
Это очень классно управлять развитием проекта, двигать его в том направлении которое считаешь правильным, когда его успех и техническое исполнение фактически зависит от тебя, от твоих знаний и принимаемых решений.