Делегирование почтового ящика - популярная функция в корпоративных почтовых системах. Она позволяет поручить просмотр и фильтрацию почты руководителя секретарю, создавать ящики, работу с которыми осуществляют сразу несколько сотрудников, и так далее. В данной статье мы расскажем о том, как делегировать почтовый ящик другому пользователю в Carbonio.
"...5 лет назад я работал в почтовом сервисе. В мои обязанности входило сопровождение разнообразных проектов по международным перевозкам. Как-то раз мой начальник пришел ко мне и поручил следующее задание: «Саша, нужно до конца месяца решить проблему с недостатком машин по маршруту Кишинев».
О проблеме я прекрасно знал, так как регулярно сам на это жаловался. Но, одно дело жаловаться, второе решать. Я не знал, как его выполнять…. Но, отказываться от задания я не планировал, и решил хоть попробовать что-то сделать. Для начала, думаю, соберу аналитические данные о предполагаемой нагрузке и количестве необходимых автомобилей, и покажу расчеты начальнику. Я начал собирать информацию о прошлых периодах, о грузах, о динамике и планируемой нагрузке на ближайший квартал. Параллельно выполнял и другие проекты, поэтому сбор аналитики занял около недели.
Когда вся информация была собрана, я пришел к начальнику и начал показывать ему мои расчеты и таблицы. Он прослушал меня минуты 2 максимум, а потом резко остановил и достаточно нервно сказал: «Саша, что ты мне принес?! Я тебя попросил вопрос с машинами решить, а ты мне математику показываешь. Прошла неделя, а ты ничего не сделал! Что тебе не понятно? Пойди к фин. директору и скажи, чтоб согласовал покупку еще двух машин класса А».
Все мы слышали о делегировании, плоских структурах и прочем прямом взаимодействии, где каждый — автономная боевая единица, все молодцы, все ответственно работают и вообще, коллектив больше похож на отряд идеологических строителей коммунизма, чем на команду разработки. В основе всех этих разговоров об автономности и «плоскости» лежит тезис, который в кратком виде можно сформулировать как «дай людям работать, не замыкай процессы на себе». То есть максимально делегируй, а что не можешь делегировать — спихивай на подчиненных с удвоенной силой! Никакого офисного рабства, только максимум самосознания! Мир! Труд! Май!
Этот миф вдвойне опасен тем, что мы не все понимаем его проблему. Считается, что делегирование проваливается в случае, если исполнитель — помидорка, которая не хочет или не может пользоваться данными ей Богом менеджером властью. Вот только чаще всего проблема провала делегирования как практики заключается в том, что менеджеры или руководители разработки просто не умеют или не хотят по-настоящему делегировать свои полномочия, а только делают вид, что позволяют подчиненным действовать самостоятельно.
Наблюдая за работой десятков разных IT-компаний из разных сегментов я с уверенностью заявляю: так называемое «делегирование полномочий» в 90% случаев — фикция и способ самоутверждения менеджера. Потому что делегирование, это двунаправленный процесс, в котором должен быть не только сильный исполнитель (что очевидно), но и умный, со стальными нервами руководитель. И сейчас объясню, почему.
Читать полностью »
Рассмотрим задачу. Дано: технический специалист на позиции синьора с широким набором технических навыков. Напишите функцию, на вход которой подается разработчик, а на выходе получается тимлид. Дополнительные условия задачи: тимлид должен быть лидером, независимо от того экстраверт он или интроверт; соответствовать трем критериям хорошего управленца; отличаться от технаря, как минимум, по четырем параметрам; не должен совершать распространенных ошибок руководителя.
«Что за странная задача, какая функция? Просто берем синьора, назначаем тимлидом и готово!» Но мы знаем, что когда хорошего технического специалиста пытаются перевести в касту менеджеров, чаще теряют хорошего технаря и приобретают плохого менеджера. Все потому, что тимлид это именно менеджер: ему нужно управлять людьми, организовывать командную работу и решать самые разные проблемы. Здесь нужен набор навыков руководителя и новые шаблоны поведения, а технические скилы часто мешают.
Чтобы разобраться в задаче трансформации технического специалиста в руководителя, нам нужен человек, который знает о тимлидах практически все — это Дмитрий Смирягин. Дмитрий 20 лет в разработке ПО, из них 15 лет руководил группами архитектуры, разработки и внедрения продуктовых решений для 20th Century Fox, Wells Fargo Bank, Zurich Insurance, BoA и подразделениями производства ПО полного цикла, от аналитики до поддержки решений. Работал разработчиком, тимлидом и руководителем тимлидов, а сейчас обучает последние две группы и консультирует по вопросам IT-управления. Это идеальный опыт, чтобы решить нашу задачу — приступим.
Читать полностью »
Одну из сессий конференции YaTalks мы посвятим росту разработчиков. Это будет разговор между представителями разных фирм — мы пригласили CTO онлайн-кинотеатра ivi Евгения eross Россинского, технического директора mos.ru Романа romas1982 Ивлиева и Германа Наркайтиса — директора по инжинирингу компании Apstra. От нас будут участвовать руководители разных команд в поисковом портале: Ольга Мегорская и (в роли модератора) Андрей yafinder Плахов.
Мы подумали, что перед дискуссией стоит «синхронизироваться» в терминах. Все хотя бы примерно представляют, что такое вертикальный рост. С горизонтальным всё сложнее: хорошие примеры выросших горизонтально людей не так видны из-за пределов компании. В чём состоит их работа? Они пишут код или только занимаются код-ревью, составлением методологий и т. д.? А возвращаясь к вертикальному росту — какие главные проблемы встают перед (будущим) тимлидом? Мы задали эти вопросы участникам дискуссии и сегодня публикуем их ответы на Хабре. Тех разработчиков, кто выбрал горизонтальную ветку развития, будем называть экспертами — имея в виду, что они управляют не людьми, а технологиями.
Небезразличные разработчики
Помимо вертикального роста, по административной линии, разработчики могут расти горизонтально — в технологических экспертов. Тогда важнее хард-скиллы. Это очень сильные, небезразличные разработчики, которые развивают концепцию архитектуры продукта. Им не требуется менеджмент — они самостоятельно находят «дырки» в продуктах и закрывают их. Если надо, они сами пишут код, собирают и разбирают команды. На таких людях у нас держится большая часть архитектурных решений. В нашей компании 26 команд, в каждой из них примерно по 10 человек, из них 2-3 эксперта. Более того, иногда мы создаём команды только из таких суперзвёзд. Рост эксперта зависит от уровня и количества проектов, которые он курирует.
Читать полностью »
В сфере управления людьми (куда многие из нас, айтишников, зачастую приходят внезапно), существует масса инструментов и подходов. Некоторые из них базовые, другие — идут следом. Но так или иначе огромное количество начинающих менеджеров открывают для себя инструментарий управления методом проб и ошибок.
Делегирование — один из базовых инструментов руководителя, о котором большинство знает. Но обращаются к нему часто слишком поздно, считая, что «ещё не пришло время делегировать — других дел полно». К сожалению, это может привести к не очень хорошим результатам.
В статье я расскажу, что такое делегирование, зачем оно нужно и когда надо начинать делегировать, как делегировать правильно и где можно наломать дров, как это всё соотносится с ситуационным менеджментом и как необходимо действовать. В конце я поделюсь собственным ноу-хау в области делегирования, надеюсь, что каждому читателю это будет полезно.
Добро пожаловать под кат!
Читать полностью »
Я работала ведущим разработчиком в компании и, когда проект стал расширяться, стали брать еще людей и меня сделали руководителем группы. Так вышло, что я долго упиралась и хотела быть хорошим разработчиком, и чтобы от меня все отстали с руководством людьми. Через много лет, моему руководителю, все-таки, удалось меня научить как руководить, но этот путь был долгим и трудным. Я недавно прочитала статью "Delegation as Art" и вспомнила грабли, по которым прошла не один раз. Вот они во всей красе:
Это моя задача!. «Я ее хочу решить и никому не хочу отдавать. Как же я отдам эту задачу другому человеку, мне же так интересно придумывать и воплощать, а потом смотреть, как замечательно все работает.»
Каждый арбитражник, хоть раз задумывался о том, чтобы создать свой бизнес. В арбитраже есть много плюсов — можно много путешествовать, ни от кого не зависеть и при этом зарабатывать хорошие деньги. Но рано или поздно наступит момент, когда ты начнешь задавать себе вопрос: «А что дальше?»
Мы хотим рассказать о Роберте Грине, основателе Zeropark и Voluum. Роберт прошел нелегкий путь от обычного арбитражника до владельца крупной компании с оборотом более $100 млн в год.
Под катом мы публикуем перевод интервью с Робом, в котором он рассказал:
Проблема менеджера, как известно, не в том, что люди смертны, а в том, что они внезапно смертны. Если бы все увольнения, мотивации и демотивации можно было бы предвидеть и заложить план, то менеджеры чувствовали бы себя весьма комфортно.
Жизнь, однако, богаче, и на эту тему есть небольшая история, которая произошла еще лет 10 назад, когда главный герой истории коллега slavapankratov еще не только не написал свою “Черную книгу менеджера”, но еще даже не подумывал о бизнес-тренерстве, а скромно трудился руководителем команды тестирования в активно растущей аутсорсинговой компании славного града Киева.
Читать полностью »
Редкий руководитель проекта не мечтает хотя бы на неделю, сбежав от диаграмм Ганта, мобильной связи, корпоративной почты, Скайпа, интернета и вообще от всех людей, улететь за тридевять земель на отдых.
Мечтает…
Мальдивы. Жемчужное ожерелье на лике Земли. Тысяча белых островов в лазурном океане. Ходят слухи, что Мальдивских островов лет так через 30 не станет, уйдут под воду, как Атлантида. Но все-таки это райские острова, с удивительной фауной, на которые стоит хоть раз в жизни посмотреть воочию.
Но не улетает.
Потому что до конца проекта еще далеко и приходится постоянно заниматься пожаротушением. Решать неотложные вопросы, уточнять цели, разрабатывать стратегию, планировать, оценивать и обеспечивать работу команды. Темп возникновения проблем превышает скорость их разрешения. Большинство поступающих задач имеют наивысший приоритет и срочность. «Это надо было сделать еще вчера!»
А хочется.
И, что делать? Так и продолжать мечтать мечты?
Руководители с опытом ответят: «Да тут все просто! Надо делегировать часть своей работы подчиненным».
Читать полностью »
