Телеграм канал «Не про код»

Токсичные фразы в продукте и разработке

Больше фраз тут

«Нам просто нужно больше людей»

Команда перегружена.
Задачи стоят.
Сроки сдвигаются.
Все заняты, никто ничего не успевает.

Решение?

Нанять ещё людей.

Звучит логично.

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

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

Если проблема не в количестве людей, можно нанять ещё пятерых, но:
❓Что именно изменится?
❓Приоритеты станут понятнее?
❓Решения начнут приниматься быстрее?
❓Зависимости исчезнут?

Нет.

Зато появятся новые участники коммуникации.
Новые согласования.
Новые вопросы.
Новые люди, которым нужно объяснять контекст.

Причём объяснять будут те, у кого и так нет времени.

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

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

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

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

Меня настораживает слово «просто».
Оно превращает увеличение штата в решение ещё до того, как сформулирована проблема.

Больше людей - не обязательно больше результата.

Иногда это просто больше людей внутри той же проблемы.

#toxicphrases@not_about_code

Демократия в отдельно взятой разработке

Сегодня у нас появилась новая фича.
Разработчик сделал её по собственной инициативе.
Для себя.

Чтобы удобнее было дежурить во время релизов.
Автоматизировал мониторинг, добавил интерфейс, настроил уведомления.
И очень доволен результатом.

А я открыла админку.
И обнаружила новую функциональность в разделе бизнес-аналитики.

С красными индикаторами.
Которые видят в том числе менеджеры.
И сразу представила, как ко мне начинают приходить с вопросами, что у нас сломалось.
Хотя ничего, возможно, и не сломалось.
Просто данных пока мало, а индикаторы уже красные.

Для разработчика это информация.
Для менеджера - потенциальный повод для паники.

С видимостью договорились разобраться отдельно.
Это не вопрос удобства, а вопрос того, кому вообще нужна эта информация.

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

Вот тут я немного засомневалась.
Не в инициативе.

Идея автоматизировать дежурства мне нравится.
Но между «я сделал удобно себе» и «я сделал удобно команде» есть некоторая разница.
Особенно когда результат появляется в общем интерфейсе.

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

Поэтому предложила простое решение.
Пусть команда посмотрит.
Если большинству удобно - оставим.
Если нет - переделаем или уберём.

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

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

Так что пока судьба фичи не определена.
Разработчик доволен.
Я не очень.
Осталось узнать мнение тех, кому с этим жить.

Чем закончится голосование - расскажу потом.

#devteam@not_about_code

Когда получилось - молодец.
Когда нет - кто разрешил?

Я не согласовываю с разработчиками каждый технический шаг.

И не собираюсь.

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

Допустим, разработчик выбрал способ реализации.
✅ Оценил риски.
✅ Сделал.
✅ Выпустили в прод.

Всё работает.

Отлично.
Именно такой самостоятельности я и жду.

В следующий раз он снова самостоятельно выбирает способ реализации.
Но после релиза что-то ломается.

И тут у меня, как руководителя, появляется соблазн спросить:
❓ Кто разрешил?
❓ Почему не согласовал?
❓ На каком основании вообще решил делать именно так?

Хотя правила не изменились.
Изменился результат.

Но что именно я ему делегировала?
Право принимать решения?
Или право принимать только те решения, которые впоследствии окажутся правильными?

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

Можно обоснованно оценить риски, выбрать лучший из доступных вариантов - и всё равно получить неудачу.

Поэтому после неудачного решения мне важно разобраться:
❓ Какая информация была у человека?
❓ Какие альтернативы он рассматривал?
❓ Какие риски видел?
❓ Был ли момент, когда он обязан был остановиться и поднять вопрос выше?
❓ И понимал ли он заранее, в каких случаях обязан прийти за согласованием?

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

Это не означает, что любое решение нужно считать хорошим.
Но нельзя требовать самостоятельности, а потом менять правила в зависимости от результата.

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

Иначе я разрешаю самостоятельность только задним числом.
И только тем, кому повезло.

#mypointofview@not_about_code

Герой - это не тот, кто всё вывозит

Думаю про Кэрол Пирсон и её «Пробуждение внутреннего героя».
Я привыкла считать своей сильной стороной способность вытаскивать сложное.
Войти. Разобраться. Собрать. Дотащить.
👉🏻 Собрать цепочку, когда статусы не сходятся.
👉🏻 Пойти в логи, когда непонятно, где порвалось.
👉🏻 Выяснить, почему у провайдера одно, у нас другое, а у финансов уже третий вопрос.
👉🏻 Собрать ответ, когда у всех вокруг только куски реальности и нервное: «А что делаем?»
Я хорошо знаю эту часть себя.
Она полезная. Рабочая. Проверенная.
Но иногда мне кажется, что это не герой.
А просто хорошо натренированная реакция.
Увидела сложное - включилась.
Увидела разрыв - закрыла.
Увидела хаос - придала ему форму.
Проблема закрыта. Все выдохнули.
Только я потом сижу с ощущением, что снова сработала не система.
Сработала я.

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

У Пирсон двенадцать архетипов. Я начала узнавать их в своих действиях.
✅ Простодушный - когда верю, что взрослые люди способны выполнять договорённости без постоянного контроля.
✅ Сирота - когда понимаю, что веры недостаточно, и проверяю, что происходит на самом деле.
✅ Воин - когда защищаю команду и отстаиваю границы, даже если кому-то это не нравится.
✅ Опекун - когда человеку действительно нужна помощь, и я помогаю.
✅ Искатель - когда захожу в незнакомую область и начинаю разбираться без готовой карты.
✅ Любящий - когда за задачами, сроками и ошибками стараюсь не потерять людей.
✅ Бунтарь - когда прекращаю то, что давно перестало работать.
✅ Творец - когда из разрозненных задач и договорённостей собираю новую систему.
✅ Правитель - когда устанавливаю правила, распределяю ответственность и требую их соблюдения.
✅ Маг - когда удаётся изменить взгляд на проблему и выясняется, что решать нужно совсем не то, с чем пришли.
✅ Мудрец - когда вместо готового ответа спрашиваю, где факты, а где предположения.

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

Хорошо, что у меня есть еще и Шут.
С ним у меня отдельные отношения.
Мой Шут часто приходит в виде блондинки.
«А теперь для блондинок».
Что именно произошло?
Где факт, а где предположение?
В чём проблема?
Кто за неё отвечает?
Что мы уже сделали?
Что конкретно сейчас нужно решить?

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

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

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

Я умею вытаскивать сложное.
И долго считала это своей сильной стороной.
Наверное, так и есть.
Но теперь мне интересно другое.
А умею ли я выбирать, а не просто реагировать?

#mypointofview@not_about_code

Чему команда учится, пока ты терпишь

Примерно полгода я учила свою команду, что мои требования можно не выполнять.
Не специально, конечно.
Я вообще была уверена, что решаю проблему с одним конкретным человеком.

Однажды ко мне в команду пришёл разработчик.
Нанимала его не я.
Он пришёл по рекомендации сверху.

Сильный.
Взрослый.
Опытный.
По крайней мере, именно таким было ожидание.

Испытательный срок прошёл.
А дальше довольно быстро стало понятно, что что-то не складывается.
Задачи фейлились.
На человека нельзя было нормально положиться.
Из работы он охотнее выбирал то, что было интересно ему, а не то, что было нужно команде.

И я всё это видела.
Но не увольняла.
Давала ещё один шанс.
Потом ещё один.
И ещё один последний.

Причин было две.

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

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

Эти две причины прекрасно поддерживали друг друга.
Я могла говорить себе, что просто даю человеку шанс.
И не слишком внимательно смотреть на то, почему этот шанс уже далеко не первый.

Так прошло примерно полгода.

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

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

И этот пример создала я.
Не он.
Я.

Потому что руководитель устанавливает правила не только тем, что требует.
Он устанавливает их ещё и тем, что терпит.

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

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

Для меня это решение не было внезапным.
Я шла к нему полгода.
У меня были все эти проваленные задачи, разговоры, сомнения, последние шансы и ещё более последние шансы.
Но команда не жила у меня в голове.
Она видела только то, что я делала.
А делала я полгода одно - оставляла человека в команде.

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

Сначала своим бездействием я показывала: так можно.
А потом одним решением показала: за это могут уволить.

И обе вещи были правдой.
Потому что граница существовала у меня в голове.
Но я слишком долго не делала её видимой для остальных.

Я смотрела на одного человека и думала:
«Сколько ещё шансов ему дать?»
А нужно было смотреть ещё и на тех, кто всё это время смотрел.
На него.
На меня.
На то, что я разрешаю.
И на то, что однажды перестану разрешать.

#systemmodel@not_about_code

Олеся всегда права

У моих ребят уже почти правило:
«Олеся всегда права».

Появилось оно не совсем на пустом месте.
Иногда мы спорим.
Мне объясняют, почему что-то не получится, почему лучше сделать иначе или почему мой вариант не самый удачный.

Я слушаю.
А потом говорю:
«Нет. Делаем так, как я прошу».

Звучит, конечно, как образцовая корпоративная культура.
Особенно если вырвать из контекста.

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

А иногда у меня просто есть то самое:
«Мне кажется, что здесь что-то не так».
Объяснить пока сложно.
Но кажется достаточно сильно, чтобы сказать:
«Сделайте пока так».

А потом я обычно нахожу, что именно меня царапнуло, и уже могу объяснить это нормально.

И довольно часто происходит именно то, чего я ждала.
И я слышу:
«Ну да. Ты снова была права».

Хотя, если совсем честно, здесь есть небольшая статистическая проблема.
Когда я говорю «делаем так», другой вариант мы обычно не реализуем.
Поэтому я знаю, что мой сработал.
А был ли другой лучше - уже нет.
Но эту деталь наша корпоративная легенда предпочитает не учитывать.

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

И никакого противоречия я здесь не вижу.
Потому что ошибка и несогласие - не одно и то же.

Если я что-то пропустила - покажите.
Если не учла - скажите.
Если у вас есть информация, которой у меня нет, - принесите.
Я это признаю и поменяю то, что нужно поменять.

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

Я услышала.
Я поняла.
Я всё ещё не согласна.

И если решение находится в моей зоне ответственности, в какой-то момент обсуждение заканчивается и мы делаем так.

Я не считаю себя непогрешимой.
Я просто не считаю каждое несогласие поводом пересматривать решение.

А если потом выяснится, что я опять была права…

Ну.

Ребята уже привыкли.

#systemmodel@not_about_code

Система дает сбой

Начало тут

Сбой 8. Бритва Хэнлона

Иногда система ошибается не потому, что не видит проблему.
А потому что слишком быстро решает, что за проблемой стоит злой умысел.

✖️ Что-то не сделано.
✖️ Риск не поднят.
✖️ Ответа нет.
✖️ Формулировка кривая.
✖️ Срок сорван.

Есть действие.
Есть последствия.
Есть раздражение.

Остаётся объяснить, почему человек так сделал.
И система выбирает самое тяжёлое объяснение:
Он сделал это специально.

Вот здесь и начинается сбой.

Злой умысел часто выглядит убедительнее обычной ошибки.
Он проще.
Яснее.
Эмоционально удобнее.

Можно злиться уже на конкретного человека.
И больше ничего не выяснять.

Но одно и то же действие может иметь разные причины.

Человек мог не понять задачу.
Не получить контекст.
Не увидеть границу ответственности.
Быть перегруженным.

А мог всё понимать, иметь достаточно времени и просто отнестись к работе небрежно.

Снаружи результат может выглядеть одинаково.
Но причины разные.
И решения тоже.

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

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

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

«Он не подумал».
Что именно он должен был проверить?

«Он не спросил».
Видел ли он, что данных недостаточно?

«Он сделал плохо».
Было ли понятно, какой результат считается хорошим?

Ответы могут оказаться неудобными для всех.

Задача могла быть поставлена плохо.
А исполнитель мог это видеть и всё равно пойти дальше.

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

В одном сбое вполне помещается ответственность нескольких сторон.
У каждой - за свои решения.

Поэтому разбор не заканчивается на имени виноватого.
Нужно понять, что исправить в процессе и чего потребовать от человека.

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

Бритва Хэнлона не требует считать всех добросовестными.
Она требует проверить причины, прежде чем приписывать намерения.

Злой умысел тоже возможен.
Но его нужно установить.

Системе нельзя врать о причине сбоя.
Даже когда удобное объяснение уже найдено.

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

Продолжение следует

#systemfailure@not_about_code