Уютный IT адочек

Софт скиллз: шаблонизация и потеря смысла

Когда вы перестаёте двигаться к новому - шаблоны мышления становятся оковами.

Есть хорошее видео chicken chicken высмеивающее "стандартную презентацию". Шаблон оной видно в каждом третьем корпоративном выступлении и на куче конференций. Если не видели - просто насладитесь немного :)

https://www.youtube.com/watch?v=yL_-1d9OSdk

Усиление режима.

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

Рассинхрон очень опасен. Приведёт к самодурству и нелепым попыткам самоутвердиться. Что в свою очередь разрушит имидж в глазах других участников, и замкнёт цикл.

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

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

На пикабушечке кто-то вспомнил про "Принцип Питера" (https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF_%D0%9F%D0%B8%D1%82%D0%B5%D1%80%D0%B0) и понеслось...
"кокококо, вот при горизонтальной структуре такого нет...", "кококо эджайл, кококо бирюзовые организации"

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

Софт скиллз: Расскажите 10-летнему ребёнку про Git.

Самый частый ответ примерно такой: "Ну смотри, ты сделал из лего домик, потом разобрал - но всегда можешь вернуться к собранному состоянию". Это ответ на три с минусом. Потому что описывает систему бэкапов, а не Git.
Особенность git, которую мы любим - это совместная работа и _мерджи_ веток.
Лучший ответ я слышал всего один раз, и он коррелировал с офигительностью тимлида по всем остальным параметрам (технические навыки, архитектура, кругозор, управленческие компетенции). Звучал же он примерно так: "Ты сделал домик из лего. И вы с другом решили сделать из него машину. Друг начал делать мотор, а ты - колёса. Вы с помощью волшебной кнопочки делаете две одинаковых копии домика и доделываете их. А потом нажимаете ещё одну волшебную кнопочку и бац - ваши две копии слились в одну, собрав все ваши доделки".

Подготовка ко встречам

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

Встреча нужна чтобы _синхронизировать_ своё видение. Но _видение надо предварительно сформировать_. То есть ответить на все вопросы, вынесенные на повестку дня встречи.

Кто очень хочет поделиться своим вариантом - может написать адочному секретарю: @tinyest_devil_secretary_bot

Софт скиллз: Расскажите 10-летнему ребёнку про Git.

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

Есть хорошее задание: расскажите 10-летнему ребёнку про гит. Постарайтесь отразить особенности именно git-а, а не svn или mercurial. Подумайте над этой задачей до завтра, а завтра я запощу лучший ответ, который слышал в своей жизни и разберу нюансы.

Вы достигнете максимума от этого упражнения, если потратите 5 минут на размышление :) Просто подумайте это для себя и запишите себе в блокнот.

Постановка групповой цели

Когда вы собираете группу для какого-то нового дела (например, новой задачи, новой продакт-команды, нового проекта или решения) - очень полезно формулировать с ними групповую цель. Не надо считать, что "сотрудники должны сами понимать, зачем они работают, а того, кто не понимает - надо увольнять и искать нового". Во-первых, новых не напасёшься, сами знаете. Во-вторых, не меньше 70% народонаселения не имеют чётких убеждений, но их можно повести за собой.

Примеры групповых целей: заработать 5 миллионов, запустив проект; повысить за год прибыль на 40%; снять котёнка с дерева.

"Цель" от "групповой цели" отличается только одним: она озвучена и с ней согласились все участники. Мне подсказали чудесную формулировку: "Мы собрались здесь чтобы XXX, кто не согласен, пожалуйста, покиньте нас прямо сейчас". Она достаточно жёсткая, но это именно ваша задача как лидера - удерживать направление движения.

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

Например, нужно сбивать в кучку специалистов одного профиля, которые не общаются друг с другом из-за работы над разными проектами/задачами. В результате чего типовые задачи переизобретаются, типовые проблемы - не решаются ("надопотерпеть!", "сейчаснедотого!", "чтоямогуизменить?..." - и другие отмазы).

Есть разные способы: общие обеды, покурить, совместные чатеги, совместные походы на картинг/пейнтбол/в бар, "демо" релизов и защиты технических решений и ретроспективы - но от того, как вы их организуете зависит какой будет эффект.

*общие обеды, покурить и совместные чатеги*. Просто "сгонять" народ бессмысленно, беседа не завяжется.
Сначала нужно наладить _личное_ общение с каждым из будущих участников. У меня хорошо получается раскручивать тему "что плохо? кто урод? что задолбало?" - у вас возможно найдётся свой подход, лишь бы это было связано с работой и люди горели желанием высказаться и поделиться своими мыслями. И лишь когда контакт налажен - людей нужно сводить вместе, указывая на общие темы, которые вы от них услышали.

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

*защиты решений, публичные демо релизов и т.п.* - классный и очень дорогой способ синхронизировать представителей разных команд. И, ввиду неумения людей выступать и выделять самое важное - зачастую трата времени оказывается пустой.
Цели подобных мероприятий может быть две:
- запустить кулуарные беседы. То есть не решить проблему, а создать её, сформулировать в головах у людей.
- сформировать новый "язык" для общения узких специалистов. Например, научить тимлидов обсуждать архитектуру решений, а не просто трепаться "какой фреймворк круче". Или продактов - общаться о метриках продуктов и подходах, а не только о пикселях в конкретных задачах.

На майских мы обычно встречаемся с теми, кого давно не видели и рассказываем им о том, что нам интересно.
Самое время потренировать soft skills!
Один из ключей ко _всему_ объему софт скиллов - это умение выводить на осознания перемены в людях. Изменения мимики, жестов, тональности голоса, позы и 100500 других параметров. Если навык осознавать эти перемены есть - наша нейронная сеточка в голове начинает выявлять паттерны в поведении людей, замечать скрытые связи и кучу всего еще.
Но научиться осознанно замечать перемены прочитав книжку - нельзя. Нужно много-много практики.
Увы, не могу пройти эту практику с вами вживую, попробуем на словах.

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

Рецепт рабочий, отвечаю.

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

Очевидное решение: оставить условных дизайнеров отделом, который обслуживает все команды, по мере необходимости. Я слышал названия "служба дизайна", "сервис дизайна", "отдел дизайна".
Внимательный читатель уже знает или догадался, чем это грозит? Конечно, сроки решения задачи "службой" становятся непредсказуемы. Особенно шикарно - это когда такой службой делают тестирование ^_^ Котятки прямо.
Адекватных решения я знаю всего два:
- Таки учиться менеджменту и растить менеджерские компетенции в "службе". Те самые, из-за нехватки которых многие бросаются в объятья "agile". Те самые "давать фидбэк заказчику", "управлять ресурсами", "планировать" и прочие. Зачем делать fullstack-команды и затем ставить мощнейший блокер в своём любимом time to market - я не понимаю, возможно вы объясните. Или учитесь в менеджмент, забивайте на диверсификацию бизнеса и не начинайте этих плясок.
- Скидывать _функцию_ дизайна, тестирования, whatever на команды, даже если у них нет специалистов. Догадываетесь, какой дизайн будет, если его начнут делать верстальщики? ;) И хрен бы с ним, на самом деле, но ведь никто об этом не предупреждает бизнес, нельзя же просто так сказать "мы проводим agile трансформацию, поэтому дизайн у нас теперь будет ГОВНО", да? :) А если таких отделов несколько - представляете как прекрасно будет?

А что делать? Думать перед тем, как действовать, чёрт возьми. Считать бюджет. Честно предупреждать бизнес о рисках.
Чего и вам желаю.

Уютный IT адочек pinned «Читая данный канал, вы соглашаетесь с тем, что он не может оскорбить ваши религиозные, политические и идеологические чувства. И что у вас вообще, скорее всего, нет чувств. Вы же технический менеджер.»

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

Поймал себя на том, что мне стало труднее писать сюда посты после сколь-нибудь значимого прихода подписчиков.
Вообще писать посты для технического менеджера, к сожалению, необходимый хлеб. Я с сожалением обнаружил, что без нормального личного бренда попасть в _интересную_ компанию не рентабельно сложно. Что бы ты ни делал, какие бы проекты, и как бы не вытаскивал. "Забрендированные" люди пройдут туда, где с тобой даже разговаривать не будут, ведь: "Ты кто такой? Давай до свидания!".

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

Почему в компаниях массово внедряют agile?
У вас наверняка есть свое мнение на этот счет. Но я убежден: потому что модно.
А зачем компаниям agile? Опять-таки, только ради двух вещей: диверсификация рисков и решение кадрового голода.
Нет, читатель, "уменьшение тайм ту маркет" достигается с помощью разрешения блокеров. И позже я объясню, почему и с чем сталкивается доморощенный эджайл в этом контексте.
Нет, "улучшение качества" тоже мимо. Чтобы не делать хуйню - надо нанимать опытных людей.

"Диверсификация рисков" же приводит к тому, что бюджет, которым раньше рулил один большой дядя "за всех", внезапно начинает рулиться кем-то из команды. Вот вам и вторичная выгода, из-за которой педалируют agile, и она стара как мир: отдельные люди из команд хотят больше власти. И не факт, что это плохо, но мало кто задумывается - как эта власть будет передаваться. Старый ответственный должен научить нового, а раз за разом я вижу, что это не делается и об этом даже не думают. Мол, "жизнь покажет".

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

Про любовь и внимание.
Не всегда нужно и можно загонять своих сотрудников в рамки правил. Когда нужно?
- когда этого требует рынок
- когда этого требует сотрудник

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

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

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

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

Конечно, это не отменяет любви к своим сотрудникам и ваша сила - это исключительно ваша ответственность.

Channel photo updated

Channel name was changed to «Уютный адочек»