Напишу несколько простых и избитых правил общения между руководителем и подчинёнными. Вы могли их видеть так или иначе много раз, но иногда, в моменты грусти по поводу собственного коллектива (такие моменты бывают у абсолютно всех руководителей!) хочется порефлексировать, конкретизировать и положить на бумагу мысли по этому поводу.
Ниже представленные правила, наверное, должны немного корректироваться вместе с рангом: я пишу из позиции линейного руководителя (тимлида), который управляет непосредственно исполнителями (разработчиками и тестировщиками). Скорее всего, на уровне топ-менеджмента есть свои важные нюансы. Однако в общем и целом идеи останутся теми же.
Всю дорогу стараюсь донести до своих разработчиков мысль, что задача (таск в Джире) — это их зона ответственности вплоть до попадания кода в прод. Хотя деплоит в прод за редким исключением не разработчик.
Антипример.
— (на дэйлике) Разработчик Васенька, скоро уж страшный зим катит глаза, в смысле, окончание спринта, что у тебя вот с тобой задачкой на 6 человеко-часов?
— Ой, а я же тебе на позапрошлом дэйлике сказал, что Луна в Третьем доме, поэтому на неё забил…
— (немая сцена)
Что пошло не так? Исполнитель неявно спихнул ответственность за свою часть работы на руководителя: пусть Папа Римский помолится за всех нас! Не произошло явной передачи (это когда обе стороны понимают, кто теперь тащит задачу, и фиксируют договорённость где-то, хоть в той же Джире). У подчинённого возникла иллюзия, что если он проговорил вслух о своей проблеме, то добрая фея уже прилетела и всё решила за него.
Кстати, а почему я написал «вплоть до попадания кода в прод», хотя программист не деплоит сам? — По мере выполнения задачи могут возникать тонкости, которые знает только сам исполнитель, такие как:
— нужно не забыть добавить переменную в env;
— нужно выполнить команду на серваке и ещё запустить крон;
— нужно к деплою подготовить фича-ветку так, чтобы в ней были самые последние изменения из master, иначе в день деплоя по чатам будут летать сообщения на тему «Срочно исправь конфликты в своей ветке!»;
— нужно увидеть результат своей работы в проде и получить порцию дофамина.
Этот пункт развивает мысль, начатую в первом. Иногда, особенно при разборе какого-то факапа, разработчик начинает говорить о задаче отстранённо: «в коде появилось...», «в ветку влилось...», «в прод залили...». Мой руководитель иногда перебивает такое повествование вопросом: «Кто, марсиане залили?»
У любого явления внутри компании всегда есть объект и субъект. По умолчанию ожидается, что в пределах своей зоны ответственности вы являетесь субъектом. В некоторые моменты разработчику может показаться, что он на мало что может повлиять, что все шишки сыплются на него не очень справедливо, и уходит от психологически неприятной ситуации вот таким способом — обезличиванием поступков.
Гораздо продуктивнее сразу обозначать, кто на ком стоял: мол, вот я поступил так, а Вася сделал так, а потом пришёл директор по продажами всё испортил внёс своё рацпредложение. Для уверенности и продуктивности такого общения нужно лишь пользоваться двумя простыми методами:
— говорите о делах, не давайте сразу эмоциональные оценки людям, пока это не станет уместно (ну это самая банальность про общение);
— при необходимости опирайтесь на установленные правила, процедуры, письменные договорённости (и вам станут отвечать взвешенней, и вы сами ещё раз проанализируете свой поступок, больше станете понимать, что именно пошло не так).
Из этих двух пунктов логично вытекает следующий.
Конечно, эмоции важны, и совершенно естественно прийти к руководителю со словами «да конём оно...», в смысле «мсье, я обескуражен наметившейся тенденцией». Но ведь вы не только хотите спустить пар, но и, как ответственный исполнитель, решить проблему? — Тогда помогите своему руководителю (самые хитрые тут даже начинают направлять его усилия в нужную им сторону не только по поводу одной задачи, но это отдельное искусство)!
Если мы говорим про IT, то в уме держим две важные предпосылки:
1) Тимлид часто не техлид, особенно в кросс-функциональных командах. Соответственно, мгновенную техническую экспертизу вы от него не получите. Более неуверенный тимлид попытается что-то сказать с ходу, «чтобы не выглядеть дураком». Более опытный, возможно, скажет, что нужно подумать, создаст встречу, привлечёт других людей.
2) У тимлида на сегодня, завтра и в любой другой день на порядок больше задач, чем у исполнителя. Это не преувеличение, кстати. При переходе на уровень руководства командой количество ежедневных дел, причём совершенно разноплановых, возрастает раз в 10. Поэтому даже если тимлид попытается вас понять без предпосылок и собственного исследования вопроса, не факт, что хватит его ментального ресурса.
Одно дело, когда мы прохожему на улице задаём вопрос «Как пройти в библиотеку?», а он отвечает что-то грубое: может, его уволили сегодня, или любимая команда проиграла. Другое дело, когда мы все работаем в коллективе, и примерно знаем, как оно есть на самом деле. Так вот, во втором случае каждый раз подходить за решением вопроса совершенно неподготовленным — это верный способ заставить злиться на себя.
Кстати, немного отступая: этот совет универсален для любого общения на работе, не только с руководителем. Одно дело, когда человек просит коллег помочь ему, просто пуская пузыри со словами «я ничего не понимаю» (читай: сделай-ка ты, коллега, за меня мою работу!). Другое дело, когда поясняет, что сделал 1-2-3, тут прочитал, там узнал, но вот именно тут и тут (показывает пальцем) не хватает каких-то важных знаний. Значит, такой человек уважает коллег и не собирается тратить их силы и время на то, что может сделать сам.
Из третьего пункта ещё более логично вытекает четвёртый.
Частенько люди пишут, мол, я что, нанимался ещё и требования писать, и код тестировать? Я хочу, чтобы мне просто приносили ТЗ, а я просто пилил код, отстаньте от меня все!
Я уважаю такую позицию: есть много людей, которые не хотят развиваться, выходить за однажды установленные кем-то рамки. Им нужно дать возможность работать согласно договора / контракта с фирмой, и поставить нормальный рабочий процесс — прямейшая обязанность руководителя.
Однако, если вы задумываетесь над саморазвитием, ростом куда-то вверх, вбок или вглубь, вам просто интересно что-то поменять, то ваш первый и главный союзник — не курсы по прокачиванию чакр, не джобхоппинг и не личная суперхаризма, а именно ваш руководитель. Поднесите ему идею, заразите сомнением, дайте намёк на решение, наконец, сделайте так, чтобы он подумал, что это его собственная идея (задача со звёздочкой для самых хитрых подчинённых) — и всё, теперь он играет за вас, а влияния в компании у него больше!
Мало того, открою маленький секрет: как правило, руководители сами молятся, чтобы в их команды попадали инициативные, неравнодушные люди. Пытаются понять, как увидеть таких на собеседованиях. Только пожалуйста, не путайте это с поиском «молодых с горящими глазами» (и готовых работать за полцены). Нет, тут всё максимально рационально: часто готовы поднимать людям зарплату, давать премии, растить внутри компании, но лишь бы сам человек показывал, что он этого хочет.
Причина таких ожиданий простая: с одной стороны, IT слишком сложная отрасль, и руководитель просто физически не может во всём разбираться лучше всех. С другой, всё ещё открытая экспериментам. Давайте честно, эксперименты в IT стоят фантастически дёшево: ну, не тот фреймворк прикрутили, ну потратили два месяца впустую. Это совершенно не то же самое, что поиграть в модернизацию в фармацевтике или авиастроении. Отсюда, кстати, незарегулированность IT: у нас и нормальных отраслевых стандартов до сих пор нет, и мы до посинения спорим, кого считать сеньором, кого джуном.
Поэтому когда человек показывает, что в пределах своей поляны он готов развивать себя, свою часть продукта и через это всю компанию, а не просто превращать ТЗ в JSON'ы — он welcome вери мач! Да, вы можете привести кучу примеров, когда компании это нафиг было не нужно. Но всё же, сначала попробуйте сделать своего руководителя союзником в деле своего профессионального роста. Ну а если попробовали и поняли, что тут тухло — тогда уже бегите.
И наконец, пункт, который говорит о базе, на которой строится взаимодействие. Тут не про его осуществление, а про подготовку. Люди, как и все другие социальные существа, постоянно «обнюхивают» друг-друга, то есть стараются построить более-менее точную картину насчёт того человека, с кем они имеют дело.
Вы можете влиять на то, как вас воспринимают ваши коллеги, и можете отдать это на волю случая. Если второе, но вам надо, чтобы ваш руководитель был таким же гением коммуникации, как Костик Ромин из «Покровских ворот», либо рано или поздно может возникнуть недопонимание.
Может быть, вам проще на встрече 1-1 буркнуть что-то вроде «Всё нормально, я пошёл», но вам же лучше, если вы поделитесь о том, что вас волнует, с руководителем. Может быть, вам кажется, что ваше лицо по утрам не очень, и вы сидите на дэйлике с выключенной камерой, когда все остальные коллеги с открытыми лицами. Но у людей подсознательно будет возникать ощущение, что «он какой-то не такой, что-то скрывает».
Если не особо тянет общаться, и вы просто интроверт, который любит решать задачки, рассматривайте это как инвестицию в свой личный комфорт. Вы сообщаете о себе немного, но достаточно, чтобы руководитель (и другие люди) строили коммуникацию с вами так, как выгодно вам. Может быть, вы в реальности не прогульщик, который в 14 часов в пятницу уже сбежал с работы, а добрый внук, который правда ездит ухаживать за своей старенькой бабушкой. Но сделайте так, чтобы это было понятно! Привычки, личные границы, ваш стиль — гораздо лучше, чтобы обо всём этом ваш руководитель узнал непосредственно от вас, чем додумал сам. В конце концов, все руководители — тоже обычные люди со своими фильтрами восприятия. Просто на них халат накинули раньше.
В завершение. Может показаться, что это какой-то там тимлид решил поумничать и полечить разработчиков, какими им следует быть и что делать помимо перекладывания ТЗ в код. Однако все эти советы я в равной степени примеряю и на себя. Тимлиды так же должны стараться общаться со своими руководителями отделов, направлений, а те — со своими техдирами.
Коллеги, если в комментарии вы дополните мои правила своими и подкрепите их примерами, будет замечательно!
Ниже представленные правила, наверное, должны немного корректироваться вместе с рангом: я пишу из позиции линейного руководителя (тимлида), который управляет непосредственно исполнителями (разработчиками и тестировщиками). Скорее всего, на уровне топ-менеджмента есть свои важные нюансы. Однако в общем и целом идеи останутся теми же.
Первое. Не теряйте ответственности по дороге
Всю дорогу стараюсь донести до своих разработчиков мысль, что задача (таск в Джире) — это их зона ответственности вплоть до попадания кода в прод. Хотя деплоит в прод за редким исключением не разработчик.
Антипример.
— (на дэйлике) Разработчик Васенька, скоро уж страшный зим катит глаза, в смысле, окончание спринта, что у тебя вот с тобой задачкой на 6 человеко-часов?
— Ой, а я же тебе на позапрошлом дэйлике сказал, что Луна в Третьем доме, поэтому на неё забил…
— (немая сцена)
Что пошло не так? Исполнитель неявно спихнул ответственность за свою часть работы на руководителя: пусть Папа Римский помолится за всех нас! Не произошло явной передачи (это когда обе стороны понимают, кто теперь тащит задачу, и фиксируют договорённость где-то, хоть в той же Джире). У подчинённого возникла иллюзия, что если он проговорил вслух о своей проблеме, то добрая фея уже прилетела и всё решила за него.
Кстати, а почему я написал «вплоть до попадания кода в прод», хотя программист не деплоит сам? — По мере выполнения задачи могут возникать тонкости, которые знает только сам исполнитель, такие как:
— нужно не забыть добавить переменную в env;
— нужно выполнить команду на серваке и ещё запустить крон;
— нужно к деплою подготовить фича-ветку так, чтобы в ней были самые последние изменения из master, иначе в день деплоя по чатам будут летать сообщения на тему «Срочно исправь конфликты в своей ветке!»;
— нужно увидеть результат своей работы в проде и получить порцию дофамина.
Второе. Старайтесь не общаться с марсианами
Этот пункт развивает мысль, начатую в первом. Иногда, особенно при разборе какого-то факапа, разработчик начинает говорить о задаче отстранённо: «в коде появилось...», «в ветку влилось...», «в прод залили...». Мой руководитель иногда перебивает такое повествование вопросом: «Кто, марсиане залили?»
У любого явления внутри компании всегда есть объект и субъект. По умолчанию ожидается, что в пределах своей зоны ответственности вы являетесь субъектом. В некоторые моменты разработчику может показаться, что он на мало что может повлиять, что все шишки сыплются на него не очень справедливо, и уходит от психологически неприятной ситуации вот таким способом — обезличиванием поступков.
Гораздо продуктивнее сразу обозначать, кто на ком стоял: мол, вот я поступил так, а Вася сделал так, а потом пришёл директор по продажам
— говорите о делах, не давайте сразу эмоциональные оценки людям, пока это не станет уместно (ну это самая банальность про общение);
— при необходимости опирайтесь на установленные правила, процедуры, письменные договорённости (и вам станут отвечать взвешенней, и вы сами ещё раз проанализируете свой поступок, больше станете понимать, что именно пошло не так).
Маленькое отступление. У меня был один подчинённый, который при разборе неочевидных коллизий на работе вдруг переходил «на вы», то есть начинал говорить в духе «у вас тут в компании...» и «ваши сотрудники сделали...», хотя в обычной ситуации вполне себе употреблял местоимение «мы», да и вообще уже давно работал в команде.
Из этих двух пунктов логично вытекает следующий.
Третье. Вместе с жалобой приносите проект решения
Конечно, эмоции важны, и совершенно естественно прийти к руководителю со словами «да конём оно...», в смысле «мсье, я обескуражен наметившейся тенденцией». Но ведь вы не только хотите спустить пар, но и, как ответственный исполнитель, решить проблему? — Тогда помогите своему руководителю (самые хитрые тут даже начинают направлять его усилия в нужную им сторону не только по поводу одной задачи, но это отдельное искусство)!
Если мы говорим про IT, то в уме держим две важные предпосылки:
1) Тимлид часто не техлид, особенно в кросс-функциональных командах. Соответственно, мгновенную техническую экспертизу вы от него не получите. Более неуверенный тимлид попытается что-то сказать с ходу, «чтобы не выглядеть дураком». Более опытный, возможно, скажет, что нужно подумать, создаст встречу, привлечёт других людей.
2) У тимлида на сегодня, завтра и в любой другой день на порядок больше задач, чем у исполнителя. Это не преувеличение, кстати. При переходе на уровень руководства командой количество ежедневных дел, причём совершенно разноплановых, возрастает раз в 10. Поэтому даже если тимлид попытается вас понять без предпосылок и собственного исследования вопроса, не факт, что хватит его ментального ресурса.
Одно дело, когда мы прохожему на улице задаём вопрос «Как пройти в библиотеку?», а он отвечает что-то грубое: может, его уволили сегодня, или любимая команда проиграла. Другое дело, когда мы все работаем в коллективе, и примерно знаем, как оно есть на самом деле. Так вот, во втором случае каждый раз подходить за решением вопроса совершенно неподготовленным — это верный способ заставить злиться на себя.
Кстати, немного отступая: этот совет универсален для любого общения на работе, не только с руководителем. Одно дело, когда человек просит коллег помочь ему, просто пуская пузыри со словами «я ничего не понимаю» (читай: сделай-ка ты, коллега, за меня мою работу!). Другое дело, когда поясняет, что сделал 1-2-3, тут прочитал, там узнал, но вот именно тут и тут (показывает пальцем) не хватает каких-то важных знаний. Значит, такой человек уважает коллег и не собирается тратить их силы и время на то, что может сделать сам.
Из третьего пункта ещё более логично вытекает четвёртый.
Четвёртое. Руководитель — ваш рычаг, ваш бустер, ваш джинн из бутылки
Частенько люди пишут, мол, я что, нанимался ещё и требования писать, и код тестировать? Я хочу, чтобы мне просто приносили ТЗ, а я просто пилил код, отстаньте от меня все!
Я уважаю такую позицию: есть много людей, которые не хотят развиваться, выходить за однажды установленные кем-то рамки. Им нужно дать возможность работать согласно договора / контракта с фирмой, и поставить нормальный рабочий процесс — прямейшая обязанность руководителя.
Однако, если вы задумываетесь над саморазвитием, ростом куда-то вверх, вбок или вглубь, вам просто интересно что-то поменять, то ваш первый и главный союзник — не курсы по прокачиванию чакр, не джобхоппинг и не личная суперхаризма, а именно ваш руководитель. Поднесите ему идею, заразите сомнением, дайте намёк на решение, наконец, сделайте так, чтобы он подумал, что это его собственная идея (задача со звёздочкой для самых хитрых подчинённых) — и всё, теперь он играет за вас, а влияния в компании у него больше!
Мало того, открою маленький секрет: как правило, руководители сами молятся, чтобы в их команды попадали инициативные, неравнодушные люди. Пытаются понять, как увидеть таких на собеседованиях. Только пожалуйста, не путайте это с поиском «молодых с горящими глазами» (и готовых работать за полцены). Нет, тут всё максимально рационально: часто готовы поднимать людям зарплату, давать премии, растить внутри компании, но лишь бы сам человек показывал, что он этого хочет.
Причина таких ожиданий простая: с одной стороны, IT слишком сложная отрасль, и руководитель просто физически не может во всём разбираться лучше всех. С другой, всё ещё открытая экспериментам. Давайте честно, эксперименты в IT стоят фантастически дёшево: ну, не тот фреймворк прикрутили, ну потратили два месяца впустую. Это совершенно не то же самое, что поиграть в модернизацию в фармацевтике или авиастроении. Отсюда, кстати, незарегулированность IT: у нас и нормальных отраслевых стандартов до сих пор нет, и мы до посинения спорим, кого считать сеньором, кого джуном.
Поэтому когда человек показывает, что в пределах своей поляны он готов развивать себя, свою часть продукта и через это всю компанию, а не просто превращать ТЗ в JSON'ы — он welcome вери мач! Да, вы можете привести кучу примеров, когда компании это нафиг было не нужно. Но всё же, сначала попробуйте сделать своего руководителя союзником в деле своего профессионального роста. Ну а если попробовали и поняли, что тут тухло — тогда уже бегите.
Пятое. Доверие — основа общения
И наконец, пункт, который говорит о базе, на которой строится взаимодействие. Тут не про его осуществление, а про подготовку. Люди, как и все другие социальные существа, постоянно «обнюхивают» друг-друга, то есть стараются построить более-менее точную картину насчёт того человека, с кем они имеют дело.
Вы можете влиять на то, как вас воспринимают ваши коллеги, и можете отдать это на волю случая. Если второе, но вам надо, чтобы ваш руководитель был таким же гением коммуникации, как Костик Ромин из «Покровских ворот», либо рано или поздно может возникнуть недопонимание.
Может быть, вам проще на встрече 1-1 буркнуть что-то вроде «Всё нормально, я пошёл», но вам же лучше, если вы поделитесь о том, что вас волнует, с руководителем. Может быть, вам кажется, что ваше лицо по утрам не очень, и вы сидите на дэйлике с выключенной камерой, когда все остальные коллеги с открытыми лицами. Но у людей подсознательно будет возникать ощущение, что «он какой-то не такой, что-то скрывает».
Если не особо тянет общаться, и вы просто интроверт, который любит решать задачки, рассматривайте это как инвестицию в свой личный комфорт. Вы сообщаете о себе немного, но достаточно, чтобы руководитель (и другие люди) строили коммуникацию с вами так, как выгодно вам. Может быть, вы в реальности не прогульщик, который в 14 часов в пятницу уже сбежал с работы, а добрый внук, который правда ездит ухаживать за своей старенькой бабушкой. Но сделайте так, чтобы это было понятно! Привычки, личные границы, ваш стиль — гораздо лучше, чтобы обо всём этом ваш руководитель узнал непосредственно от вас, чем додумал сам. В конце концов, все руководители — тоже обычные люди со своими фильтрами восприятия. Просто на них халат накинули раньше.
В завершение. Может показаться, что это какой-то там тимлид решил поумничать и полечить разработчиков, какими им следует быть и что делать помимо перекладывания ТЗ в код. Однако все эти советы я в равной степени примеряю и на себя. Тимлиды так же должны стараться общаться со своими руководителями отделов, направлений, а те — со своими техдирами.
Коллеги, если в комментарии вы дополните мои правила своими и подкрепите их примерами, будет замечательно!
