Тег #внутренняя сбросить

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

Проще было пойти в бар в пятницу с коллегами, поиграть в кикер или настольные игры. Общения хватало в различных форматах. А что говорить про те моменты, когда вы в офисе до 2 часов ночи тушите прод — это было шикарное время, которое дало мне много друзей.

Переход на удалённую работу

Сейчас, в эру удалённой работы, встроить нового человека в слаженный коллектив очень сложно. Ещё сложнее из группы людей сформировать и воспитать команду. И тут, на мой взгляд, помогает культура внутри самого IT, самой разработки.

Очень важно разделить для себя: культура компании != культура IT. Потому что культура компании — это формальность, а культура IT — это неформальные отношения, определённые грани общения, которые могут выглядеть странно со стороны, но внутри это норма.

Вы и без меня знаете, о чём речь: - Шутки на весь офис - Шутки в курилке - Когда техподдержка приходит в разработку и говорит: «Ну что, смертники, фикс выдаём сегодня или на выходных отдыхать будем?» - «Кто релизит по пятницам, тот в бар не ходит» (с) и другие примеры

Культура формируется из очень многого: процессов, людей, юмора, обычаев и неформального общения.

Роль неформальной культуры в коммуникации

Как-то в процессе работы я постоянно пытался донести свои мысли о том, как будет развиваться наша IT-команда, куда мы идём и как важен вклад каждого. Слова, слова... почему опять лозунги? Терпеть не могу лозунги. И каждый раз, когда представлял изменения в процессах, меня не покидало ощущение, что отклика мало — возможно, сотрудники видят только лозунги и не верят, что станет лучше и проще.

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

Когда ты руководитель, ты хочешь прийти и сказать: «Вот наш путь», но в глазах видишь вопрос: «Круто, а что сейчас-то делать?» И вроде бы ты рассказываешь, что делать дальше, как меняется ежедневная работа, а огня не хватает, отклик какой-то слабый.

Мы что-то обсуждали в очередной раз, какую-то проблему, и один мой коллега процитировал меня: «Получается: Красиво делай, некрасиво не делай». Вот оно! Это был внутренний девиз моего IT. Да, эта фраза родилась из шутки, невзначай брошенной для подбадривания коллектива в определённый момент, но она нашла намного больше отклика у сотрудников и стала их девизом.

Значение внутреннего девиза

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

Повествование моё на аудиторию изменилось тем, что в конце, когда я спрашивал мнение у моих коллег, друзей и единомышленников, я стал спрашивать: «Ну как, красиво будет?», а в ответ получал: «Да» или «Выглядит красиво, надо пробовать», «По сути вкусно». Маленькое изменение только для общих встреч, но насколько жизнь стала проще.

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

Практические выводы

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

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

Сейчас любой директор нашей компании может прийти в разработку и спросить: «Как у вас дела, как вы живёте в своей разработке?», ответом последует единогласное: «Живём по правилу: Красиво делай, некрасиво не делай».

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

Не становитесь начальником

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

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

Цитата: "Люби Спартак в себе - а не себя в Спартаке" (с) Н.П. Старостин. Очень давно она запала мне в душу, и я отношусь к работе в компании именно так. Начинаю очень ценить моменты, когда проникаюсь компанией, когда она (работа в компании) становиться частью жизни, а не целью заработка. Если воспринимать себя именно так, то не можешь заняв руководящую позицию считать, что ты выше других, что тебе все должны.

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

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

Руководить, а не отдавать приказы

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

Приказы в формате "Сделай это!", без обсуждения и объяснения цели, вызывают негатив и нежелание его выполнять. Следовательно, результат выполнения такой задачи будет соответствующий - для галочки.

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

Дискуссия - процесс руководства

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

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

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

Да есть задачи, под которые не подобрать ожидаемый результат, и что делать в таком случае?). И мы постепенно учились через дискуссии выходить на результат. Какой же кайф видеть, как твоя идея обретает новые контуры и превращается во что-то более осязаемое. Самое главное, чтобы дискуссия была ограничена по времени и ею надо уметь управлять, чтобы не начать обсуждать устройство вселенной в какой-то момент.

Честен перед собой и коллективом, быть примером

Эта мысль собирательная, речь о том, что нужно быть требовательным к другим настолько насколько вы требовательны к себе. Если вы не приезжаете в офис к 11, то почему вы требуете это от других? Банальный пример, но самый простой для демонстрации.

Держать слово и нести ответственность. Руководитель "балабол" никому не нужен, не вызывает интереса, потому что не верят его словам.

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

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

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

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

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

Зачем менять такую жизнь на административное руководство?

• Встречи 1х1.

• Бесконечные собеседования для найма.

• Встречи по развитию сотрудников.

• Разрешение конфликтов.

• Проведение 360.

• Планирование и выполнение задач по развитию направления/команды.

• Подготовка документации, планов вхождения в должность, планов на испытательный срок.

Ещё не остановил вас? А чем же вас ещё напугать? И это всё нужно делать, и ещё успевать кодить задачи, и думать об архитектуре текущей и будущей.

Руководитель отвечает за себя и за всех

Руководитель направления (Back, Front, QA, Аналитики или др.) в нашей компании — это такой же участник продуктовой команды, как и остальные сотрудники. Но при этом у него ещё есть целое подразделение, которым он руководит, а ещё балласт в виде административки.

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

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

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

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

Я хочу быть руководителем (тимлидом), потому что больше платят

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

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

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

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

Я хочу быть руководителем (тимлидом), потому что я буду больше значить и у меня появится вес в моём голосе

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

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

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

Я всегда пытаюсь собирать всевозможные «хотелки» и пожелания, далее обсуждать их с сотрудниками: что-то мы берём, что-то отсеивается. А ещё круто, что я очень поддерживаю, это когда сотрудник делает какую-то демку, прототип и выносит на обсуждение с коллегами, проводит демонстрацию этого прототипа. Прототипирование и демонстрация — самый трудоёмкий, но в то же время самый понятный способ донесения информации.

Неважно, какая у вас должность: предлагайте идеи, прототипируйте, обсуждайте, продавайте свои идеи!

Я хочу быть руководителем (тимлидом), потому что руководители не перерабатывают

Ох, уж эти руководители! Мы тут овертаймим для выпуска релиза, а они там…

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

Но у меня другой подход: руководитель — это лидер, он первый среди равных, он всегда там, где проблема или сложности.

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

Думаете, я на каждом шагу рассказываю: чем и кому помог сегодня? во сколько заканчивается мой день? Естественно, нет. Это не то, чем стоит гордиться или хвастаться. Это моя работа. Когда подходит сотрудник и говорит: «я хочу быть лидом», тогда я начинаю раскрывать суть этой должности по тем же пунктам, что и в этой статье. Я не пытаюсь его отговорить, нет. Я пытаюсь ликвидировать неопределённость в его голове, победить желание «убить дракона».

Руководитель всегда контролирует ситуацию и помогает команде, сотрудникам. Но его работа — это его работа. Вы не всё знаете. Поэтому не стоит судить только по тому, что вы видите или что вам рассказывают на сиюминутных встречах.

Заключение

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

Мой подход для «выращивания» новых руководителей очень прост. В нашей компании есть все условия и полная открытость для инициатив, но всё нужно доказывать делом.

У нас нельзя стать руководителем, а потом начать делать. Сначала ты делаешь, предлагаешь, проявляешь себя, а потом тебя и награда находит. Всегда находит. Это относится не только к вертикальному росту, но и к горизонтальному росту.

Поэтому мой совет: «делайте», т.е. берите на себя больше, пробуйте какие-то обязанности руководителя, просите что-либо на вас делегировать. Так в компании вас увидят, заметят и оценят. Устройте себе «бета-тестирование» новой должности, а после поймёте, чего вы действительно желаете.

В этом году я решил попробовать нестандартные методы для обучения: интенсивы, игры и другие подходы.

Вашему вниманию представлена деловая ролевая игра «Оценка задач», которая готовит проджект-менеджеров ко всем возможным ситуациям в процессе оценки. Рефлексия после каждого «раунда» помогает закрепить материал.

Концепция игры

Что такое «оценка» — это процесс демонстрации продуктом идеи для команды с подготовленными артефактами: прототип и описание того, как идея решает проблему пользователя.

Для кого: для команд разработки и проджектов.

Роли участников: - РО — продукт-оунер, рассказывает идею команде, отвечает на вопросы, хочет получить объективную оценку. - ПМ — руководитель проекта, руководит процессом оценки. - Аналитик — проводит поверхностный анализ задачи и варианты наложения на текущую архитектуру системы. - Дизайнер — отвечает за визуальную реализацию, должен обращать внимание на прототипы, важно обсуждать с фронтендером возможные решения. - Бэкендер — проектирует решение, должен полностью понять, что хочет продукт. - Фронтендер — проектирует реализацию UI, должен ограничивать полёт фантазии дизайнера. - Тестировщик — оценивает объём тестирования, возможные риски решения и подводные камни.

Концепция игры: 1. Создание ситуации оценки задач продукта. 2. Участники должны быть в неестественных ролях, например, разработчик получает роль аналитика или тестировщика. 3. У каждой роли есть антипаттерны поведения, которые участник разыгрывает в ситуации. 4. Задача участника с ролью руководителя проекта — преодолеть все антипаттерны поведения, выдержать встречу в рамках и добиться результата.

Итоги игры: ПМ сделал всё хорошо, если: 1. Встреча прошла структурно. 2. Конфликты удалось погасить или избежать. 3. Задача была декомпозирована и оценена. 4. РП справился с антипаттернами поведения. 5. Оценка задачи имеет обоснование на своё существование. 6. Встреча прошла в заложенный тайминг.

Процесс проведения

Начинается сама игра: 1. Ведущий рассказывает правила: 3 оценки, каждый будет в роли ПМа и в роли одного из участников оценки: аналитика, разработчика, тестировщика. 2. Назначается первый ПМ, раздаются роли индивидуально остальным. Даются пояснения. 3. Когда все готовы — объявляется старт первого раунда. Засекается таймер на 15 минут. 4. Руководитель QA, он же играет роль Product Owner, запускает демонстрацию экрана с первой продуктовой задачей. 5. Модерация встречи полностью переходит к играющему ПМу. 6. Оценка проходит согласно нашему процессу разработки. 7. Оценка заканчивается. Объявляется стоп-игра. 8. Проджект-менеджер пытается угадать, с кем он только что оценивал задачи. 9. Дальше рефлексия всех участников первой итерации. 10. Повторяется для ещё 2 сценариев. 11. В конце рефлексия по всей игре: начинает приглашённый на роль Product Owner, дальше остальные участники. В конце ведущий проговаривает важные нюансы и основные ошибки, которые были допущены. Обсуждается, как их в дальнейшем не допускать и исправлять.

Как прошла игра

Игра была проведена между всеми проджект-менеджерами нашей компании, всего их трое. Был приглашён руководитель тестирования на роль Product Owner. Я был ведущим, но при этом отыгрывал одну из ролей из списка, следил за выполнением условий игры и подмечал моменты, которые нужно было вынести на обсуждение.

3 ситуации, при которых каждый проджект примерил на себя роль ПМа и провёл встречу по оценке задач, а также ещё одну из ролей: аналитик, разработчик, тестировщик.

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

Выводы после игры

1. Всем понравилось.

2. Каждый испытал на себе разные роли, что позволило подойти к заданию творчески.

3. Прошло нескучно.

4. Много кейсов было решено правильно.

5. Во время рефлексии многие вспомнили похожие ситуации, а также проанализировали во время игры, что не получилось.

6. Были подсвечены проблемные места и что нельзя ПМам делать на такой встрече.

О чём видео

В этом видео Сабина Метляева и Григорий Шутов обсуждают тему матрицы компетенций в IT-командах. Они разбирают её применение на примере гипотетической ситуации с тимлидом, менеджером и инженером в баре.

Ключевые моменты

• Матрица компетенций — это инструмент для оценки навыков сотрудников, который помогает в планировании развития команды.

• В сценарии с баром авторы иллюстрируют, как разные роли (тимлид, менеджер, инженер) могут по-разному воспринимать и использовать эту матрицу.

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

Где посмотреть

Видео доступно по ссылке: https://youtu.be/UHRt-33ilbk.

В видео Алексей Пименов (RealResult) делится своим взглядом на рабочий процесс как на процесс накопления знаний, а не просто выполнение задач.

Суть подхода

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

Практические аспекты

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

• Анализ ошибок: неудачи стоит рассматривать как ценный источник информации для будущих улучшений.

• Создание базы знаний: накопленный опыт следует структурировать в доступные материалы, которые можно использовать повторно.

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

Значение для специалистов

Для менеджеров и разработчиков это означает переход от реактивного режима "тушения пожаров" к проактивному построению систем, которые предотвращают проблемы. Видео доступно по ссылке: https://youtu.be/ux4Gl234qMk