Делегировать задачи

Искусство управления — это достижение результатов силами других людей. А делегирование полномочий — один из главных навыков эффективного руководителя.

Брайан Трейси — известный специалист по вопросам эффективности и психологии успеха — вывел золотую формулу, которая поможет правильно передавать полномочия подчиненным. Она включает в себя 7 принципов.

Уровень задачи должен соответствовать уровню исполнителя

Запомните простое правило: если человек может выполнить 70% задачи, ему можно поручить ее целиком.

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

Делегируйте постепенно

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

Делегируйте задачу целиком

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

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

Если он не выполнит эту работу, этого за него не сделает никто другой.

Ожидайте конкретного результата

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

Стимулируйте участие и обсуждение

Существует прямая зависимость между обсуждением и заинтересованностью в выполнении работы. Когда у людей есть возможность напрямую общаться с руководством — повышается стремление выполнить работу хорошо.

Делегируйте полномочия и ответственность

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

Оставьте исполнителя в покое

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

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

По материалам «Делегирование и управление».


Ирина Балманжи

Делегирование необходимо. Посредством него управленец развивает команду, оно — неотъемлемая часть прямой работы руководителя. Публикуем несколько советов, которые помогут вам быстрее овладеть этим искусством.

Убедитесь, что вы можете делегировать задание

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

Как стать отличным руководителем

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


Источник

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

Помните:

1. Если задание содержит конфиденциальную информацию, его нельзя делегировать.

2. Делегирование — это инструмент развития. Если вас не вдохновляет разбор шкафчика с инвентарем, вряд ли он вдохновит человека, который может стать вашим преемником… в то время как «управление запасами инвентаря» вполне может быть интересным делом.

3. Необходимо учитывать, есть ли у вас сотрудники, способные выполнить это задание.

4. Вы не всегда будете вынуждены делегировать задания своей непосредственной команде. Может быть, другие отделы лучше подготовлены для того, чтобы вам помочь?

5. Делегирование развивает навыки сотрудников и помогает вам снять с себя часть рабочей нагрузки — но оно никогда не должно превращаться в перекладывание ответственности на другого человека.

Выберите правильного человека

Как только вы решили, можно (или нужно) ли делегировать задание, вам надо выбрать правильного сотрудника для его выполнения.

Делегирование — это способ развивать вашу команду, давая людям возможность «примерить» на себя управленческую роль. Для вас это способ продемонстрировать доверие, а также снизить загруженность, чтобы сосредоточиться на других вопросах.

Человек, которого вы выберете, должен быть способен выполнить задание (или научиться этому) и обладать соответствующими полномочиями.

Итак, вы можете:

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

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

2. Передать задание человеку без опыта, чтобы способствовать развитию у него новых навыков. Это может потребовать больше времени и дополнительной поддержки, чтобы неопытному сотруднику не показалось, что его «подставили».

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


Источник

Вот еще три совета

— Делегируя «банальное» задание, признайте его банальность и постарайтесь избежать повторения в будущем, попросив выполняющего его сотрудника усовершенствовать систему. Такое дополнение сделает задание более интересным.

— Учитывайте желания вашей команды. Если желания сотрудника и ваши потребности примерно совпадают, точкой их пересечения станет делегирование.

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

Четко объясните задание

Делегировать не значит просто сказать: «Вот проект, за дело!» Не потому что ваша команда не понимает задания, а потому что сотрудники могут не знать, чего именно вы хотите и каковы ваши стандарты, — так же, как два человека совершенно по-разному смотрят на одну и ту же ситуацию.

Даже если вы не уверены, чего хотите, но по крайней мере знаете, чего не хотите, четко это обговорите. Немного времени и усилий, затраченных на объяснение ваших ожиданий, существенно помогут делу в долгосрочной перспективе.


Источник

1. Четко представляйте себе, какой результат вы хотите увидеть. «Выполненное» — слишком расплывчатое понятие.

2. Если у вас нет времени объяснять (и даже если есть), составьте список своих ожиданий, чтобы ваш сотрудник мог с ним сверяться.

3. При возможности приведите пример законченного изделия или результата.

4. Обязательно установите четкие границы. Если вы приветствуете инициативу со стороны сотрудника, скажите ему об этом. Если вы против, тоже скажите.

5. Объясните, какие материалы доступны для использования и необходимы ли какие-либо инновации.

6. Убедитесь, что ваш график (в том числе этапы контролирования прогресса) понятен.

7. Всегда внимательно проверяйте информацию, если у сотрудника возникают вопросы до или во время выполнения задания. Определите средства связи, которые вы станете использовать, и будьте доступны для ответа на любые вопросы, какие могут возникнуть.

Выделите соответствующее количество времени

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

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

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

Имейте в виду: предоставляя кому-то слишком много или слишком мало времени на выполнение задания, вы можете испортить результат. Слишком много времени — и исполнитель может поддаться искушению оставить работу на последний момент и выполнить ее наспех, слишком мало — и он будет перегружен.

Предложите помощь

Фраза «Мои двери всегда открыты…» не только расплывчатая, но и часто не соответствует действительности. Очень сложно предложить поддержку «как надо».

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

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


Источник

Делегируя задачу, сделайте следующее.

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

При необходимости можно скорректировать график. Например, если изначально сотрудник рассчитывал на большой объем помощи, но на первой же встрече вы убедились, что ему нужно меньше, похвалите за уже проделанную работу и предложите перенести следующую встречу на более поздний срок.

2. Спросите у сотрудника, какая помощь ему необходима, и предоставьте ее.

3. Удостоверьтесь, что у вас есть доступное (и контролируемое) средство связи на случай, если понадобится дополнительная помощь.

Избегайте микроменеджмента

Одна из наиболее распространенных жалоб подчиненных — что они не чувствуют доверия при выполнении заданий, которые им поручили.

Для людей нет ничего более досадного — а для вас более времязатратного, — чем микроменеджмент.

Если вы удачно выбрали сотрудника, выделили ему достаточно времени и предложили соответствующую помощь, почему вы продолжаете его контролировать? Почему не используете свое (теперь освободившееся) время на выполнение других дел или развитие отдела?

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

Всегда помните, что ваша задача — «координировать процесс», а не «осуществлять» его. Ваши способности оцениваются в зависимости от того, насколько удачно вы делегировали работу.

Хвалите и оценивайте

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

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


Источник

Найдите время обсудить с сотрудниками задание — спросите, понравился ли им полученный опыт и в каких областях они хотели бы развиваться. Этим вы не только повышаете квалификацию своих подчиненных, но и вдохновляете их более активно подойти к своему профессиональному развитию. Такой подход положительно скажется на будущей производительности.

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

Обложка поста отсюда

Наталья ЛЕБЕДЕВА,
кандидат физико-математических наук,
преподаватель специализации «Управление персоналом»
программы MBA (МИРБИС), старший партнер компании KPG

Мы продолжаем разговор о базовых компетенциях успешного руководителя. В предыдущей статье мы рассмотрели инструменты, позволяющие эффективно ставить цели и задачи сотрудникам. Однако это только часть успеха. Далее эти задачи нужно передать, «поручить» конкретному исполнителю. Здесь-то и могут возникнуть сложности.

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

📌 Реклама Отключить

Зачем делегировать задачи

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

Делегирует руководитель или нет — по большому счету его личное дело. Однако руководители, которые боятся делегировать, обречены большую часть работы выполнять «ЗА» своих подчиненных, постоянно сетуя на то, что поручить-то сложную задачу «некому». Этот барьер делегирования со стороны руководителя очень характерен для нашей страны, ведь у нас становится руководителем тот, кто лучше всех «продавал продукт», «исследовал рынок» и пр., а не лучше всех управлял людьми. Став руководителем, человек продолжает «продавать» и «исследовать» лучше всех, забывая о том, что теперь его задача в другом: не продавать «за» своих сотрудников, а сделать так, чтобы они это делали лучше него.

📌 Реклама Отключить

Решить такую задачу без делегирования невозможно. Делегирование требует времени и сил. Но результат того стоит! Вспомним анекдот: «Идет человек по лесу, видит: дровосек пилит огромное бревно. Старательно пилит, весь в поту, но получается что-то плохо, медленно и криво. Присмотрелся человек, а пила-то затупилась. Подходит он к дровосеку и советует: «Пилу заточи, легче пойдет!» А тот в ответ: «Некогда точить, пилить надо!» Так и для руководителя: делегирование — это его инструмент, его оружие, его «заточенная пила».
Принцип успешного делегирования

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

📌 Реклама Отключить

Что любит больше передавать руководитель? Ответственность! А что любит больше принимать подчиненный? Полномочия! Перед нами конфликт интересов. Наша задача при делегировании — снизить риск возникновения конфликта, управлять конфликтом, разрешить его с позитивным результатом, то есть передать полномочия и ответственность, получив сотрудника, мотивированного на решение поставленной задачи.
Этапы процесса

Процесс делегирования делится на четыре основные фазы: до управленческого общения, собственно управленческое общение (коммуникация), выполнение работы и контроль, оценка результатов и мотивация. Рассмотрим две первые фазы делегирования, так как именно они закладывают основу для успешного выполнения задачи.

Фаза I. Эта фаза начинается с работы над постановкой цели. Руководителю нужно «прогнать цель по SMART» и убедиться, что он готов однозначно ответить на вопрос что нужно получить или достичь в результате выполнения задачи.
Далее стоит выбрать объект делегирования и обосновать для себя (пока для себя), почему именно этому сотруднику поручается данная задача. После выбора исполнителя нужно проанализировать, какие возражения могут возникнуть у него в ответ и как преодолеть их. Ведь мало кто из «загруженных» сотрудников сразу обрадуется новому поручению.
Затем руководителю стоит решить, какой стиль ситуационного лидерства он предполагает использовать. В процессе общения с сотрудником выбранный стиль руководства может меняться в соответствии с ситуацией и ожиданиями сотрудника. Ведь для одних сотрудников мотивирующим может являться один стиль управления, а для других — другой. Кто-то захочет наставничества, кому-то потребуется поддержка, кто-то хочет, чтобы ему не навязывали способы достижения цели и дали проявить творчество, а кто-то хочет получить четкие инструкции.

📌 Реклама Отключить

Руководитель должен решить, может ли он пойти навстречу ожиданиям исполнителя или ситуация требует строго определенного стиля. Например, есть ситуации, в которых даже от амбициозной «звезды», которая не приемлет никакого стиля, кроме «ориентированного на достижения», необходимо добиться следования точной инструкции. Здесь нужно использовать различные инструменты влияния (например, обосновать необходимость следования инструкции или доказать ее преимущество) и быть мастером коммуникации.
Теперь мы готовы приступать непосредственно к процессу делегирования в ходе управленческого общения.

Фаза II. При общении с сотрудником самое главное — помнить, что идут переговоры. Да, со всеми характерными этапами и спецификой — это переговоры по «продаже задачи». И как в любых переговорах, первый этап — это установление контакта, от которого зависит половина успеха.

📌 Реклама Отключить

Пример
— Ну, здравствуй! Как дела? (Выслушать ответ, может быть, уже этого будет вполне достаточно.) Знаю, что сдача объекта (ситуация должна быть конкретной) прошла успешно. Молодцы. Как ощущения? (И снова выслушать ответ.) Над чем работаешь, что важного? (Может быть, он уже занят на все 100 процентов на ближайшую неделю, причем задачами, которые вы ему и поставили!)

В последнем случае руководителю необходимо подумать о другом исполнителе или об изменении приоритетов или сроков. В любом случае, узнав о состоянии дел, вы уже не попадете в ситуацию, когда, прослушав ваш рассказ о новой задаче (минут на 20), подчиненный успеет вставить (в короткой паузе): «А на Чукотку открывать новый филиал завтра мне не ехать? Мы же с Вами в понедельник решили, что еду именно я».
Если на Чукотку выбранный объект делегирования не собирается, то можно приступить к формулировке задачи. Первый шаг — раскрыть задачу, объяснить, что нужно получить в результате ее выполнения и в чем ее значимость (SMART-критерии — конкретность и значимость). Вспомните, что 60 процентов ваших сотрудников мотивируют чувство своей необходимости, важности для компании, в которой они работают! Кроме того, знание ответа на вопрос, зачем нужна данная задача, позволяет выбрать оптимальный способ ее достижения.
Пример
Руководитель производства вызывает мастера цеха и, ставя ему задачу, объясняет, почему именно он должен курировать работу строителей-подрядчиков: «Ты знаешь, я вчера весь вечер изучал личные дела тех, кому мог бы доверить эту задачу. Обнаружил, что из всех нас только у тебя, Егор, есть строительное образование. Только ты сможешь понять, что там происходит на стройплощадке. Ну как, возьмешься?» Мастер цеха (который собирался сопротивляться до последнего) развел руками и… согласился.

📌 Реклама Отключить

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

Далее, как и в классических переговорах, идет двустороннее обсуждение, диалог. Начать его можно, получив обратную связь от сотрудника, например, вопросом «Как ты к этому относишься?». И слушать! Руководитель слушает ответы, возражения, аргументы, но кроме этого у него есть три дополнительные задачи: понять, насколько сотрудник понял, что от него ждут, насколько он мотивирован и насколько он готов обсуждать ресурсы.
Не стоит начинать обсуждение ресурсов, необходимых для выполнения задачи, до того, как все сопротивления и возражения сотрудника, связанные с другими причинами, сняты. Идеально, если в разговоре сам сотрудник начинает обсуждать, что ему необходимо для решения задачи (это могут быть сроки, дополнительная информация, поддержка других подразделений и пр.) — это уже половина успеха. Это сигнал, что исполнитель принял задачу и выясняет свою сферу ответственности за результат.

📌 Реклама Отключить

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

Вариант «уступка»: «Возьми все, что хочешь, — только сделай!» также опасен. В следующий раз просить будет больше (риск «шантажа»).

Третий вариант оптимальный, но долгий — обсуждение, обоснование и согласование. Если вы как руководитель знаете, что с существующими ресурсами задача может быть выполнена, обсудите свою точку зрения и получите согласие исполнителя. Но если исполнитель прав и ресурсов действительно не хватает, тогда стоит дать требуемое, «с трудом, с болью», но дать. Например, сотруднику удалось доказать вам, что ему одному без помощника не справиться в указанные сроки. У вас есть альтернатива: либо дать помощника, либо изменить сроки («поторговавшись», конечно).

📌 Реклама Отключить

После обсуждения ресурсов останется согласовать выбранный вид контроля и способы оценки результатов. И только теперь, если такая необходимость есть, речь пойдет о личной мотивации сотрудника. Часто, когда все описанное выше выполнено корректно, вопроса «Что мне за это будет?» у исполнителя не возникает. Действительно, если вспомнить, что SMART-цели являются инструментом нематериальной мотивации, если стиль управления оказался мотивирующим для сотрудника, если ресурсов достаточно, цели достижимы и вид контроля совпадает с ожиданиями сотрудника, то мотивация достигается автоматически.

Но если все это сделано неудачно и скорее демотивирует, то исполнитель вправе задать вопрос: «Ну, хорошо, я все понял, но этого нет в моих должностных инструкциях, как с этим быть?» Подтекст понятен — «А деньги?». И будет прав, так как именно деньги в коммерческой организации являются универсальным заменителем многих мотиваторов.
Когда подчиненный слушает руководителя, у него могут возникнуть, например, такие мысли: «Вы поставили мне задачу так: поди туда, не знаю куда, принеси то, не знаю что… Хорошо, я сам догадаюсь, что нужно сделать, пойду и принесу, но денег дайте тогда больше!» Или: «Вы поставили мне новую и сложную задачу. При этом не похвалили за прошлые успехи, я не обижусь, ладно, но… денег тогда дайте больше!» Или: «Ставя такую простую задачу, вы решили меня контролировать каждые пять минут, хотя я сто раз доказывал свой профессионализм и ответственность! Хорошо, я потерплю, но за это денег дайте!»
Немного упрощенно, но зато понятно. Не стоит забывать о том, что материальный фактор мотивации очень быстро из «дара» превращается в «право» — право получать компенсацию за свой труд, а нематериальный фактор укрепляет доверие и формирует лояльность сотрудника.

📌 Реклама Отключить

Если все-таки у руководителя осталось ощущение того, что мотивация сотрудника требует «поддержки», можно использовать знание его мотивационных ожиданий (которые рекомендуется узнать заранее, например, используя проективные методики).
Пример
Для выполнения поставленной задачи исполнителю придется сегодня задержаться на два часа. Руководитель, зная о том, что данного сотрудника демотивируют переработки, в конце разговора добавляет: «Сегодня вам придется задержаться. Как будет удобнее — прийти завтра на два часа позже либо вечером уйти на два часа раньше?»

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

📌 Реклама Отключить

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

В прошлой статье От инженера до руководителя. Часть 1: Чувство справедливости я рассказывал о чувстве справедливости. Возвращаясь к ней, хочу повториться, что чувство справедливости является основополагающим моментом. И если мне вздумалось о чём-то рассказать, то каждая моя неточность, а тем более ложь, неподкреплённое фактами мнение, орфографическая ошибка и агитация нашли бы своих недовольных. Что, собственно, можно наблюдать и тут и в жизни ежедневно. Одно дело придерживаться конкретной стороны в холиваре (парадигме, стандарте, процессе), получая тумаки от одних и поддержку от других; и совсем другое дело — описывать и следовать своей собственной точке зрения, опыту и выдерживая свою стилистику. Это — сродне минному полю, где известны правила игры, но за всё, что делаешь, несёшь сам ответственность. Такая же разница существует между исполнителем и руководителем, где последний при своей ошибке получит пинок из-за проявленой «несправедливости” и набьёт немало шишек сам, если будет ошибаться, хотя и спасая этим идущих за ним. Поэтому в моём понимании лучше набивать шишки загодя, с уровня сотрудника, ощупывая путь мягкими частями тела, не получая дополнительных пинков сзади — главное не отставать и не идти против руководителя, впрочем, если он не до конца неправ и не ведёт всех на обрыв. В противном случае, попридержите коней, ведь вы — рабочая лошадка — в одной упряжке. О том, как как поставить правильную цель и как исполнять работу совместно с другими и пойдёт речь в этой статье.

Friendship is magic!

Однажды, непогожим осенним деньком, меня вызвали в другую страну решать чужие проблемы с чужим проектом. Помимо языкового барьера необходимо было разрешить и барьер технологический. Я особо не представлял, что же за проект мне достался, как всё в нём работает и что надо делать. Мне сказали только одно — тебя пригласили сдать набор модулей в срок с должным качеством и по установленным стандартам. Поставленная задача для меня была совершенно обычной и понятной, мой опыт и знания позволяли это легко сделать, а чего нехватало можно было подтянуть, прочитав мануалы и даташиты, не сильно теряя по времени — пара дней, не более. Но вот что же собственно надо писать в коде, как понять и как читать спецификацию и какую же на основе её архитектуру строить, и как она связана с тем каркасом, что я увидел в UML-модели, я не имел понятия.
К счастью для разрешения этой неувязки меня познакомили с Senior Developer’ом, которого звали Майнул. Майнул происходил, по-видимому из рода брахманов, и был очень приветливым и натасканным, просветлённым человеком из Индии. Мне впервые пришлось встретиться в работе рука об руку с индусом. Не где-то удалённо, где Бангалоре за кусок лепёшки клепался код и тесты, и откуда приходили невнятные результаты с магическими числами 3, 9 и 24 от очередного Раманамамы Шакати, а с элитным представителем своей профессии здесь и сейчас вживую.
— Привет, как дела?
— Нормально, разбираюсь. Как мне писать? Есть наработки? Могу ли я добавлять что-то в модель?
На что он мне ответил, что, мол, надо писать, вот так… И принёс мне свой код, где для ознакомления он предложил мне реализовать ещё пару десятков функций. Что ж, сказать, что его код был индийским — ничего не сказать. В нём хотя и имелся некий налёт от текущих требований, но конструкции следующего вида ужасали:
sint16_t Temperature = nInTemp; bool_t Sign = TRUE; Sign = Temperature >> 15; if (Sign = TRUE) // do something // and do a little bit more else if (Sign == FALSE) { // do something }
Некоторые вещи вообще не компилировались. Я написал, что недоставало, подправил небольшие его косяки, чтобы это хотя бы не нарушало стандартов и компилировалось. Затем были разночтения спецификации у меня и у него, и он так же предлагал индусские подходы. Я увидел индусский код в действии! Он всё делал, чтобы я уверовал в предрассудки об индийских кодерах, разве что не танцевал при этом у меня под носом. Но вопросы-то возникали и накапливались, а индийские решения меня не устраивали. Поэтому в один из дней я сказал ему: «У нас проблема, надо решать”. И тут произошло следующее — Майнул стал приводить ко мне специалистов, словно они были взяты руками Шивы: тех, кто писал и трактовал спецификацию, тех, кто паял микроконтроллеры, тех, кто прогонял математические модели. И они давали мне ответы. Он умел находить людей, которые знали, как это должно работать. Людей из одной упряжки. Я же попросту не знал тысячной армии из всего штата, и подойти к кому бы то ни было, в-общем, было сложно и объяснения заняли бы немало времени. И тут я понял. Я передавал ему свои проблемы и обязанности — найти устройство механизма людей, а он покрывал свои — написание правильного кода. У нас всё заработало и проект мы закрыли за 3 недели с интеграцией из 4-ех выделенных.
В отношении руководителя есть правило — делегируйте. Но, на самом деле, даже попав не в отлаженный коллектив, где у каждого своё место, как в часах, вы можете так же делегировать свои обязанности тем, кто с этим хорошо справится. Даже с позиции рядового сотрудника. Это работает эффективно, но не значит, что бесплатно. Отдавая поручения, вы берёте на себя и определённые затраты и обязанности, иногда даже дополнительные на этапе планирования. Проявляйте инициативу и прислушивайтесь к людям, вне зависимости от той парадигмы, взглядов, что у вас есть.
Со стороны руководителя — доверяйте своим сотрудникам, они обычно лучше проинформированы, лучше знают кому дать задачу, знают кто проявит большее рвение. Делегируйте выбор, делегируйте ответственность. Не бойтесь работать на сотрудников, пускай они скажут, что же важно в данный момент и как это исправить, пусть они дают вам советы не на собраниях в овальном кабинете, а в рабочем процессе на рабочих же местах. Не делайте чужую работу, а распределяйте её так, как всем будет выгодно. Если вдруг компетентности у сотрудника не хватает, спросите его мнение, как он бы решил эту проблему, что нужно по его мнению для разрешения проблем. Слушайте больше, чем говорите. И лишь потом предлагайте своё, жёсткое, единственное решение. Единожды делегировав, оценивайте важность вклада в работу, мотивацию, дайте возможность развернуться и показать себя. Ищите людей и методы, способы замотивировать исполнение задач, поощряйте самостоятельность — хоть леденцом «театральным» или переходящим плюшевым талисманом успеха — и помогайте, не оставляйте подопечных один на один с проблемой, если им нужна помощь, используйте свои связи, чтобы привлечь нужные ресурсы. Посоветуйте книгу, посоветуйте сходить проветриться, но не лезьте никогда ни при каких условиях в код и в работу сотрудника, не тормозите «достаточно хорошими” критериями, позвольте ему самому быть мерилом хорошего кода в поставленные временные рамки.

Постановка цели

Чтобы правильно дать совет, ориентировку и выделить решение как руководителю, так и сформулировать задание разработчику, надо правильно ставить задачи. Но как правильно поставить задачу? Во-первых, есть методология SMART. Во-вторых, чтобы задание было понятным, его должен понять и оппонент. Это означает, что тот, кто ставит задачу, должен так же и проконтролировать правильность понимания, в простейшем случае — повтор постановки задачи от исполнителя. Чтобы задание было наиболее простым для понимания и его возможно было воспроизвести без ошибок, оно должно быть максимально простым, т.е. разбитым при необходимости на элементарные части и шаги, и наглядным, чтобы, если структура задания комплексная, его можно было легко изобразить на клочке бумаги.
В моей практике был случай, когда мне поставили очень важную и критичную задачу для всего проекта следующим образом: «Нам нужен набор критичных мониторов. Попробуй разобраться с этим”. Окей, пришлось уточнить, правда, что за список мониторов нужен. На всё остальное было исключительно моё design decision. Что ж, за неделю с небольшим я продумал всю структуру классов, сделал быстрые методы и систему оповещения. У меня был готовый модуль, который был связан с готовыми интерфейсами. Однако за день до сдачи мне пришлось всё переделывать. Так как после код ревью, грозная начальница, которая своим авторитетом была втрое шире и выше меня, сообщила мне, что ошибки и мониторы должны быть реализованы в разных классах (даже если в ошибках одно поле), да и не надо использовать спид-хаки, вообще не нужны битовые операции и упаковка ошибок в биты одного слова, а надо использовать кучу наглядных switch\if c отдельным int под каждую ошибку. И вообще, было сообщено мне, что в концерне давно решена проблема с мониторингом, и моё дело повторить (sic!) готовый код. Интерфейс, правда, отличается, но удалить ненужные методы, а интерфейс поглушить нулями, где это можно. Я в принципе не против рефакторинга, когда он уместен, но когда задача преобразуется из «yours design decision” в «use old damn code” от несопоставимого проекта — это как-то смущает на этапе исполнения за 1 оставшийся день. И самое интересное, что в этом был не прав и я. Надо было определить правила игры.

Техническая спецификация

Самая лучшая идея — это составить спецификацию из следующих соображений:

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

Хорошая спецификация:
11. RAM Functionality The functionality of the RAM devices shall be tested by a write / read test of at least all used memory locations. In case of detecting a RAM fault, the unit shall be halted.

Т.е. мы можем понять место своей спецификации в архитектуре и мы имеем набор действий, которые можно покрыть двумя тестами для двух действий (выполнить сценарий):

  1. случай без ошибки
  2. случай с ошибкой

Почему мы не расписываем как должен проходить read\write тест и как должен останавливаться CPU? Во-первых, позвольте решить разработчику, как это сделать. Во-вторых, подумайте о тестировщиках — как это протестировать, да ещё по желанию одним тестом? Или, что хуже, как протестировать особенность выключения CPU? Не всегда углубляться в детали — хорошо. Даже при низкоуровневых требованиях сохраняйте уровень абстракции, который сделает возможным создание тестов, а не будет ограничиваться код ревью с пометкой none-testable*. (*Впрочем, зачастую принцип чёрного ящика для тех же Unit test’ов не всегда выполним, поэтому имеет смысл давать ссылку на даташиты или описывать нефункциональные требования из разряда layout или необходимости применения ассемблерных инструкций, например остановки ISR на время записи EEPROM, чтобы перестраховаться. По возможности следует избегать уточнений, какая же из десяти функций аппроксимации должна использоваться в этой реализации — это должно логично следовать из спецификации).
Плохая спецификация:
Fault machine System shall catch and store all errors in None-Volatile Memory. Errors shall be stored as follows: 1. Set IE to OFF; 2. Write Date; 3. Write Time; 4. Write Error ID; 5. Write ‘\0’; 6. Set IE to ON;
Обратный пример. Какие ошибки? Вот overflow — это ошибка? Превышения порога датчика — ошибка? У нас есть лист ошибок в конце концов? Отлавливать как? Когда? Есть сообщения, приходящие раз в секунду — нужно ли проверять каждое из них? А во время ожидания получения? Потом детализация сохранения. Оно должно описывать формат — это хорошо, но вы составляете уже алгоритм, превращая разработчика в кодера — оно вам надо — делать двойную работу? Кроме того, как тестировщик протестирует последовательность действий? Особенно установки регистров. Дебаггером? А как же black-box? Да вы шутите!
Спецификация — не такая уж и однобокая штука, которой должны заниматься архитекторы. Со стороны разработчиков — это описание функционала и поведения кода для тех же тестировщиков. Со стороны тестировщиков — сценарий, во время исполнения которого произошёл сбой, или нарушение стандарта, отсылка к которому будет понятна разработчику, в конце-концов это — описание тест-кейса и окружения. Со стороны руководителя — чёткая постановка технической задачи и\или описания тех. процесса. Стремитесь изъяснять мысли правильно: структурировано, чтобы их можно было разделить при необходимости на подэтапы, и стилистически, для описания сценария и вашего отношения. Если это crap, то следует и писать прямо: «rework this pile of crap», конечно, с условием, если вы правы и ваша позиция весомо аргументирована. Для написания хорошей спецификации потренируйтесь в письме. Пишите тексты, хотя бы по полстраницы в день. В блог, в сообщества, в стол. Пишите и старайтесь излагать свои мысли так, чтобы они были услышаны и восприняты с исходным посылом. Хоть о сложности изготовления змеевика в домашних условиях, хоть о мягкой гриве пони. Проверяйте и зачитывайте тесты своей кошке, развешивайте план субботника в подъезде или в интернет — и не того он успел натерпеться. Ваша задача — научиться доносить мысли максимально просто и правильно. Раз. Два. Три. В моём случае посыл — это не готовый набор «наилучшей практики», а призыв поразмышлять со мной и посмотреть на обычные процессы, на примеры из собственного опыта глазами разработчика, попавшего в новые условия.

Постановка задач

Ладно, если техническая спецификация близка к коду, то что касается постановки задач?
Плохое задание:
Create input monitoring functionality urgently.
Хороший пример должен содержать последовательность действий или вовсе описываться дорожной картой:
Try to integrate last application release (from SVN) till Friday 13 in the following way: 1) Build new framework 2) Build new application with the new framework 3) Run tests 4) Run all benchmarks 5) Report to Jira If one of the steps breaks, try to re-check its default settings, and if all is correct, then report status.
Хорошее задание должно быть:
S) конкретным (что именно мы делаем)
M) детальным, а следовательно измеримым (в данном примере можно посмотреть, на каком этапе находится задание)
A) понятным и достаточным (в данном примере мы используем последние исходники с SVN, сборку в конкретной среде)
R) Каждое действие актуально, если предыдущий этап был успешно завершён. Нет смысла тестировать производительность, если неожиданно упали тесты. И уж тем более нечего тестировать, если не прошла сборка.
T) ограниченным во времени (для соблюдения сроков и синхронизации проекта).
Т.е. для моего случая поручение Майнулу было таким: «Надо узнать сегодня (T), как обрабатывать буфер ARINC сообщений (S) для интерфейса A429 уровня приложения (A), когда приходят два сообщения с одинаковым идентификатором (M1) и в случае когда буфер переполнен (M2). Это может быть связано с ошибками тайминга, пожалуйста, узнай поведение железки ®.»
Всё это, в конечном итоге, структурирует и логирует диалог между исполнителем и руководителем (или заказчиком). Если вам непонятно задание, спрашивайте до тех пор, пока его не перефразируете на атомарные фразы. Если вы хотите быть понятым, спрашивайте, насколько понятно это задание. Какие решения и предложения разработчик хочет использовать и какое место он видит заданию в архитектуре\проекте. Согласуйте до того, как приняться за дело, планируйте. Это во-первых, позволит избежать недовольства в конечном итоге, так как обе стороны приняли правила игры. Это избавит от бесконечных переделок и обид, что код уже «достаточно хорош”. Это избавит от вопросов, т.к. все правила и ответы есть в мануалах, вики, и всём, что описано в задании или в тех процессе. Это, в конце концов, приведёт к понятным отчётам, которые будут как защитой исполнителя, так и аргументом руководителя.
О пользе отчётов и вообще зачем они нужны речь пойдёт в следующий раз.

Делегирование как инструмент управления руководителя

Делегирование – это одно из важнейших качеств эффективно работающего руководителя.
Делегирование означает передачу какого-то задания или проекта от одного лица другому лицу, и согласие этого лица его выполнить.
Делегирование позволяет решить следующие задачи:
* Сокращение рабочей нагрузки, если передадите задания сотруднику, который достаточно квалифицирован, чтобы его выполнить.
* Использование освободившегося времени для решения стратегических задач и концентрации менеджмента на важнейших аспектах работы
* Развитие и оптимальное использование потенциала сотрудников, включая творческий и инновационный
* Расширение опыта подчиненных. Помогает развить существующие и новые навыки подчиненных
* Повышение мотивации подчинённых к трудовой активности
* Повышение уровня доверия и коммуникации между вами и вашим персоналом.
* Экономия средств организации, благодаря правильному распределению задания. Повышение продуктивности благодаря экономному расходу ресурсов. В каких случаях необходимо делегировать
* Когда подчиненный может сделать работу лучше.
* Когда чрезмерная занятость не позволяет руководителю заняться проблемой самому.
* Когда делегирование позволит руководителю высвободить силы и время для важных дел, имеющих первостепенное значение.
Необходимо делегировать:

всегда никогда
* Мелкие, рутинные дела
* Специализированную деятельность,
которую ваши сотрудники могут выполнить лучше, чем вы
* Подготовительную работу, сбор информации
* Постоянные поручения (регулярные отчеты, анализы)
* Решение частных вопросов
* Замещения вас (конференции, совещания)
* Стратегическое планирование и целеполагание
* Постановка целей, окончательное решение по стратегическим вопросам, контроль результатов.
* Мотивация сотрудников
* Задачи особой важности, личные поручения
* Задачи высокой степени риска, необычные, исключительные дела
* Актуальные, срочные дела, не оставляющие времени для объяснений или перепроверки
* Конфиденциальные задачи или щекотливые обстоятельства (коммерческая тайна)
• Политически окрашенные ситуации
• Оценка деятельности, дисциплину и взыскания
• Организация работ персонала

Проверяйте каждое дело на возможность делегировать. «Все что могут делать сотрудники, должны делать сотрудники».
Делегирование – это такое поручение задачи, которое соотнесено с возможностями и способностями (а также загруженностью) подчиненных. Делегировать задачу надо не тому, кто хочет, а тому, кто может и способен ее решить.
В рамках делегирования руководитель выполняет роли советчика, консультанта, арбитра и наблюдателя.
Типичные ошибки делегирования
1. Неумение инструктировать /объяснять.
2. Ошибка в выборе делегата.
3. Ориентация не на дело, а на личность. Ворчливость, несдержанность, излишняя эмоциональность.
4. Фиктивное делегирование (делегирование функций, которые подчиненные имеют в силу их должностных обязанностей).
5. Делегирование задания группе сотрудников без определения индивидуальной ответственности.
6. Делегирование одной и той же задачи двум сотрудникам, не знающим об этом.
7. Боязнь уронить авторитет.
8. Перепоручение функции руководства.
9. Делегирование отдельными распоряжениями (Необходимо делегировать задачу целиком).
Правила и принципы успешного делегирования
1. Делегирование происходит на этапе планирования (делегируйте заблаговременно).
2. Делегирование учитывает особенности и возможности сотрудника.
3. Делегирование сопровождается мотивацией и стимулированием.
4. Делегирование предполагает желание сотрудника взяться за задачу.
5. Однородные задачи делегируются преимущественно одному и тому же сотруднику.
6. При делегировании вместе с задачей передается компетенция, ответственность и полномочия.
7. При делегировании необходимо объяснить смысл и цель задачи.
8. Делегирование не предполагает поручение одной задачи двум сотрудникам одновременно.
9. Делегирование задачи или работы целиком, а не в виде частичных изолированных заданий.
10. Делегирование предполагает перепроверку понимания сотрудником задачи и инструкций.
11. Делегирование сопровождается предоставлением всей необходимой информации.
12. Делегирование не сопоставимо с постоянным вмешательством в процесс выполнения задачи.
13. Делегирование сопровождается предоставлением поддержки и совета
14. Делегирование предполагает промежуточный контроль исполнения через установленные отрезки времени.
15. Делегирование заканчивается контролем конечных результатов и моментальным информированием сотрудника о результатах контроля.
16. Конструктивно хвалите успехи и критикуйте недостатки в выполняемой работе
Делегируйте задание по следующему алгоритму:

1. Назначьте личную встречу с подчиненным, которому собираетесь делегировать задание

Сотрудничество – это важный момент в делегировании. Поэтому вы должны встретиться лично.

Хорошо подготовить

2. Четко опишите, задание, проект или функцию.

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

3. Оговорите стандарты выполнения, мерки успеха и уровень ответственности.

  • Установите контрольные точки для качества времени и цены.
  • Объясните сотруднику, что выполнение задания должно соответствовать установленным стандартам.

4. Определите ресурсы, и какие из них доступны.

  • Определите материалы и физические ресурсы, необходимые для задания и убедитесь в их доступности.
  • Если необходимо, подберите дополнительный персонал.
  • Узнайте у сотрудника, какая помощь ему понадобится в выполнении задания.

5. Определите, есть ли необходимость в тренинге или наставничестве и как их лучше провести.

  • Если сотрудникам необходимо развить какие-то новые навыки, согласуйте план тренинга.
  • Обсудите необходимость наставничества и составьте расписание, приемлемое для обеих сторон.

6. Определите уровень полномочий, который вы будете делегировать.

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

7. Согласуйте параметры окончательного исполнения и обратной связи.

  • Установите систему регулярных отчетов (например, встречи раз в неделю или раз в месяц, отчеты раз в месяц).
  • Согласуйте параметры обратной связи, заранее обговорите, когда и как она будет осуществляться.
  • Согласуйте, каким образом вы должны быть вовлечены в выполнение задания, если она окажется под угрозой или возникнут непредвиденные проблемы.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *