Как не надо объяснять людям задачи и изменения

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

Быть руководителем в ИТ сегодня = быть переговорщиком.

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

Сейчас расскажу несколько случаев эпических провалов, когда руководитель хотел сделать что-то хорошее, а получалось только стечь под стол и облажаться.

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

Готовые к развитию

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

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

Динозавры

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

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

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

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

Вообще, запомните этот приём, возможно, он вам пригодится много где в жизни. «Мы показываем вам 5 дней, если нет правок по вот этой форме, то считается принятым» — довольно радикально, но может оказаться действенным.

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

Хитрые

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

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

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

Юристы и безопасники

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

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

Тусовщики

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

В итоге они проталкивают новые идеи там, где они имеют контакты. Лучшие тусовщики — сотрудники техподдержки, потому что эти люди знают вообще всю компанию. Что ещё ценно — они очень быстро приносят объективную обратную связь (а не ту, что для анонимных форм «что мне не нравится»). Эти же люди очень активно задают вопросы, и если вы плохо подготовились — иногда это неудобные вопросы на общих созвонах. Так вот, эти люди становятся основой комьюнити, и если вы сможете такое комьюнити создать, то дальше они сами будут наводить движуху. Узнать таких людей просто: те самые товарищи, которые первыми постят мемы про новую технологию в корпоративных чатах.

1. Объясняет цель

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

Бывают задачи, где цель — устать. Это, например, подметание плаца ломом, перекрашивание травы из зелёного цвета в уставной зелёный и так далее. У нас в банке, например, была задача подготовить документацию по регуляторным требованиям ЦБ. Реализация системы такова, что эта документация в принципе не будет применена и сразу ляжет на полку. Но она должна быть, и мы планировали использовать на это несколько человеко-месяцев. Это стандарт. Да, он не учитывает каждый точный случай, но таковы правила игры.

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

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

Когда человек не видит смысла своей работы, это демотивирует.

2. Расставляет шаги и уточняет задачу

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

Очень легко просадить лишнюю неделю просто на том, что вы сказали что-то вроде «ну сделайте там это».

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

3. Собирает обратную связь

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

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

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

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

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

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

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

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

Уже затем дополнили это регулярными опросами.

Важно, что тот, кто отправил запрос в любом виде, должен понимать, что его запрос не ушёл в пустоту. Ему важно понимать, что его запрос получили, его запрос рассмотрели. То есть дальше либо взвешенный ответ, либо запрос принят в работу, положен в бэклог. Плюс ещё могут люди вернуться и что-то уточнить. Те, кто даёт вам информацию, должны чувствовать себя участниками. Запросы должны быть приняты и обработаны. Только тогда это начинает работать.

Каждый новый тестировщик приходит с вопросом — ребята, а у вас тут Xray, а мы вот на прошлом месте Редмайн использовали. А давайте его. Мы устаём каждому новому джуну объяснять, что нет, не всё так просто. Мы не можем взять и завтра перейти на новую систему. У нас есть внедрённая система с интеграциями, 1000 человек, которая используется, выбрана по таким параметрам, есть стандарты. Приходится объяснять — есть FAQ с типовыми вопросами.

У нас открытый бэклог. Любой сотрудник, участник процесса может посмотреть его. Собственно, мы развиваем процессы и инструменты, и все 2 тысячи айтишников, для которых мы это делаем, знают, что мы делаем, где их задача. Это тоже очень полезно: люди понимают, что процесс идёт и что у других команд тоже есть потребности.

Как устанавливается культура обратной связи? С трудом. Нужны инструменты (поначалу очень простые), плюс мы на каждой встрече говорили, как это важно. Причём отдельно команде, отдельно на личной встрече — лиду.

Важны демонстрации: приходит некий «динозавр» и говорит, что какой-то кусок нерабочий. Мы говорим: «Жаль, но вот два месяца назад мы просили прийти с обратной связью по этому участку. Вы смолчали. Теперь поезд ушёл, поздно». Через пару таких примеров, когда «жертва» очень громко кричит и всем жалуется на несправедливость, этот пиар начинает работать. Инструмент внедрён, но вам не подходит? «Дорогой, где ты был раньше?» — вот так через грабли и шли.

4. Документирует процессы

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

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

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

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

Что может пойти не так

Если не объяснить цель — ваша задача просто не будет выполняться. Никто не будет знать, зачем её делать. То есть не будет никакой мотивации в принципе. Прилетевшие потом проблемы покажутся сюрпризами, совпадениями, явлениями природы. В общем, чем угодно, но только не следствиями того, что надо было подумать про это заранее. Увы, большая часть проектов на моей памяти испытывала сложности именно с объяснением целей большим командам. Точнее, декомпозицией целей до каждого участника.

Увы, я знаю слишком много стендапов, презентаций и постановок задач, которые сводятся до «копайте туда, потому что я так сказал».

Если не расставить шаги и контрольные точки и не описать конечный результат — вы просто не договоритесь и каждый участник будет делать что-то своё. В итоге проект просто не соберётся. Либо команды перегрызутся.

Если не собирать обратную связь с потребителей — вы получите недовольство при внедрении. В идеальном мире инструмент помогает кому-то улучшить процесс. Да, на него надо переходить, да, этот процесс не самый приятный, но люди должны понимать, зачем это и что будет, если не перейти (это первый пункт). Люди должны понимать чётко, как всё пройдёт (это второй). И, наконец, они должны иметь возможность влиять на процесс так, чтобы снять реальные проблемы, которые будут мешать использовать этот инструмент. Это обратная связь. Фактически вы заключаете соглашение «мы делаем вам вот это, а вы помогаете нам сделать это так, чтобы вы же этим потом могли удобно пользоваться».

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

И всё?

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

Читай эту и другие статьи об IT в Газпромбанке  в нашем блоге на Хабре.