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

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

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

Очень давно стоит проблема - кто должен руководить человеком?
Тот, кому его работа больше все нужна (заказчик)?
Или тот, кто можем им правильно управлять в профессиональном плане (супервизор)?

Как эффективнее распределить людей?
Раздать по местам конкретной работы?
Или собрать в единый "кулак"?

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

В какой-то момент корпорации пришли к консенсусу матричного управления. Каждый входит одновременно в две группы. Горизонтально - в отдел специалистов данного типа. Например - разработчики. Под командой "линейного менеджера". И вертикально - специалисты разного титпа входят в какой-то проект. Под командой "проектного менеджера". Более-менее хорошо работало для больших организаций и сейчас, как я понимаю, работает в аутсорсовых компаниях типа ЕПАМ или Люксофт.

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

Но при любой форме организации ИТ - обычно сам ИТ в организации оставался единым в силу своей особости.

Впервые про распил ИТ на части я услышал от Wildberries. У них была проблема донесения нужд бизнеса до ИТ, создать класс аналитиком/менеджеров для решения этих задач у них не вышло. Тогда они распределили инженеров по бизнес-отделам и возрадовались. Ценой этого было некоторое увеличение числа инженеров (потому что статическое распределение по задачам менее эффективно по ресурсам, чем динамическое) и некоторая утрата качества управления. Дело в том, что главный бухгалтер и остальные "обычные" бизнес-отделы слабо понимают ИТ-специфику со специфичным планированием и необходимостью как-то помнить про технический долг. Им надо здесь и сейчас. Лидер разработчиков может недолюбливать аналитиков/менеджеров за разногласия между их хотелками и своим перфекционизмом, за неточность и сумбурность передачи бизнес-трембований. Но без них легко обнаружить, что бизнес еще более безкомпромисен, чем аналитики, еще более игнорирует технический долг и прочие неосязаемые понятия, еще более противоречив и сумбурен. То есть искажения от слоя аналитиков/менеджеров пропадают, но пропадает и привносимое ими сглаживание. Вертикальная связь заказчик-исполнитель становится короткая и жесткая. А горизонтальная связь исполнителей между собой сильно размывается, может даже стать совсем неформальной.

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

Про инновации

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

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

Но что если у нас классическая top down контора с агрессивными целями? Все для фронта, все для победы. Значит, вся деятельность подчинена этим целям. Значит, все, что не ради их достижения - это плохо. Отсюда последствие первого порядка - это нетерпимость к ошибкам. ошибка это потеря. А если нельзя ошибаться, то резко сокращается пространство для экспериментов. На запланированные эксперименты воля ещё остаётся. «Верхи» могут агрессивно инвестировать в какой-то запланированный сверху экспериментальный проект . А вот сумбурный эксперимент снизу, «на попробовать» пропадает. Всякая гипотеза может дать два ответа, но в этой среде ответ «не получилось» уже не приемлем. «Не получилось» будет понят как «плохо старался». Поэтому лучше не рисковать. Снижение числа таких сумбурных экспериментов неизбежно отсекает какие-то потенциально выгодные пути, поскольку не распробовав не оценишь

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

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

Эти идеи могут быть очень инновационными, но ход их реализации уже таким не будет.

Как мы сами пытаемся вырваться из этой ловушки, когда гонка за «инновацией сверху» убивает «инновацию снизу» (что потом убьёт и «инновацию сверху» тоже)?
Не факт, что этого достаточно, но
- Выделяем время на эксперименты «просто так». Иногда технологию надо пробовать, даже если на неё нет бизнес-потребности. Потому что технология может внезапно создать бизнес-возможности, который заранее видны не были.
- Выделяем время на тех.долг. Мы чистим зубы каждое утро не дожидаясь кариеса. Так и здесь не надо ждать, когда этот долг начнёт стрелять на уровне бизнеса.
- Стараемся внимательно слушать, если люди говорят, что есть проблема
- Ещё не регулярно, но уже часто спрашиваем, есть ли проблемы, которые почему-то не решаются

Про японское “да”

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

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

Где с этим можно столкнуться?

Наивный продакт менеджер рассказывает идею клиенту, а тот поддакивает. «Клиентам наша фича нравится!» делается вывод, а они не покупают потом.

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

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

Что можно сделать?

Самое простое упражнение на проверку понимания и взаимопонимания - это когда говорит второй собеседник.

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

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

У Sales есть в частности практика уточнять KPI покупателя в организации, чтобы понимать, что предлагаемое решение действительно выгодно для покупателя. Если нет выгоды, то нет и реального интереса. bizdev это почти как sales в этом смысле.

Вобщем, переспрашивайте.

Оказывается, существуют исследования о эффективности переработок, которые в разное время проводили такие титаны индустрии как Proctor&Gamble, Bureau of Labour Statistics of the U.S. Army Department o

Оказывается, существуют исследования о эффективности переработок, которые в разное время проводили такие титаны индустрии как Proctor&Gamble, Bureau of Labour Statistics of the U.S. Army Department of Labor, American Association of Cost Engineers, Construction Industry Institute, The National Electrical Contractors Association. Несмотря на всю заинтересованность в выжимке соков из трудящихся, исследования показали падение эффективности работы по мере превышения стандартной 40-часовой рабочей недели.
Хотя абсолютные показатели существенно отличаются между исследованиями, а в некоторых даже были примеры, когда удлиненная неделя не приводила к падению производительности, но в большинстве случаев видно, что уже даже 50 часовая неделя существенно снижает отдачу (92% и ниже). Наиболее интересны графики, построенные на основе данных Proctor&Gamble (на картинке), где оценивается не просто падение производительности, а комплексный вклад от <все потраченные часы> * <производительность> c поправкой на длящийся эффект (сколько недель уже продолжается overtime). Здесь мы видим, что уже на 6й неделе труда по 50 часов отдача от дополнительных часов полностью исчезает и дальше уже начинается сплошной вред (то есть дополнительный час не только не дает прибавки, но и наносит вред). Там, к сожалению, не рассмотрен вопрос восстановления до 100% эффективности после отмены сверхурочной работы. По моему личному опыту, 12 недель работы по 80 часов приводят к последующим 6 неделям эффективности чуть выше нуля. В смысле, что на почту человек отвечает и простые фиксы делать может.
По этой причине я не поощряю сверхурочную работу у нас.
https://revay.com/revayreports/en/vol20no3.php

На неделе громко прогремела новость про утечку исходников Аэрофлотовских сервисов по небрежности (просто доступ не закрыли) - https://habr.com/post/424625/

Это породило довольно много тредов со стебом всего, что можно - от Аэрофлота в частности, до докера и девопса вообще. Я тем временем поучаствовал в немного более полезном практическом треде, где народ каялся в собственных подобных косяках. Реальность такова, что сколько бы "матерые админы" не стебали "любителей докера", а уязвимости есть у всех, и даже у Cisco.

Компании делятся не на "с уязвимостями" и "без", а на тех, кто узнает про свои уязвимости вперед новостей и тех, кто после.

Есть практика, которая помогает быть первым - это наладить работу с внешними "белыми хакерами". Это могут быть как выделенные пен-тестеры, так и "bug bounty". Bug Bounty это когда вы готовы платить за сообщения о своих уязвимостях. Есть довольно много народу, кто этим промышляет.

Чтобы bug bounty заработал, надо
1) завести у себя людей, которые им будут заниматься
2) объявить если не условия (мы публично условия не объявляли), то хотя бы канал, куда можно с этим обращаться - например [email protected]
3) научиться пользоваться стандартной CVSS шкалой уязвимости и прикинуть сколько вы готовы платить за взломы разного уровня
4) научиться платить людям (для россиян с нашими бухгалтерскими заморочками это вообще настолько не тривиально - что по честному наверное даже невозможно)

Сейчас мы получаем несколько подобных репортов в неделю и потому не становимся героями новостей

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

Поговорить про уязвимости можно тут https://yangx.top/joinchat/B-bfYQrvBssyBCf4D2YjhQ

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

К примеру, в США банковские карты распространены давно, но бесконтактная оплата из-за этого распространена меньше, чем у нас - много старых терминалов, которые этого еще не умеют.

Или вот свежий пример, упорядоченный по убыванию прогрессивности и возрастанию времени игры одновременно:
- в Китае рынок мобильных платежей вырос в 15 раз за 2 года (!) и достиг 15 млрд долларов
- в России при этом население в основном пользуется переводами с карты на карту и терминалами оплаты (qiwi наше национаольное достояние)
- в Германии основной инструмент это банковские переводы (direct debit)
- а в США до сих пор в ходу бумажные чеки

Кто позже всех начал, тот дальше всех ушел.

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

Хотел бы поделиться одной довольно хорошо работающей у нас практикой.

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

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

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

поспорить за пользу/бесполезность конференций можно тут https://yangx.top/joinchat/B-bfYQrvBssyBCf4D2YjhQ

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

Такие интервью интересны возможностью как-то "сверить часы" с общим трендом. Из интересных мыслей:
1) поощряйте "соревнование" между продукт менеджером и дизайнером. каждый должен пытаться сделать лучше, бросая некоторый вызов второй стороне.

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

2) в дизайне нет места догмам. все правила работают в каких-то ситуацих, и вредны в каких-то других

Думаю, это не только в дизайне так.

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

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

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

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

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

Горский приводит примеры Амазона и Букинга, которые метрически заоптимизированы до упора, но выглядят ужасно. Но работают и генерируют гору денег. Но выглядят ужасно. Трудный выбор

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

https://www.youtube.com/watch?v=kZz8dJwmH48&index=4&list=WL&t=0s

И как обычно - если кто-то хочет высказаться за Горского, то в чатике https://yangx.top/joinchat/B-bfYQrvBssyBCf4D2YjhQ

Хорошая статья про разработку CLI интерфейсов.

UX в UI уделяется очень много внимания, но в силу специфики нашего продукта (техническая вещь для инженеров) в какой-то момент мы даже ставили лозунгом, что CLI (и API) также важен, как UI. Не могу похвастаться, что мы достигли небывалых высот, но мы стараемся.

https://medium.com/@jdxcode/12-factor-cli-apps-dd3c227a0e46

​​Закрытие Google+ иллюстрирует подход к решению ситуаций типа «нести тяжело, а бросить жалко».

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

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

В итоге пришли к соломонову решению под названием «план эвакуации при пожаре». Решили ничего не предотвращать, не улучшать и даже не чинить, а просто стричь купоны до часа Х. Пока не бомбанет. Как только бомбанет, должны были распечатать заготовленный «ПЛАН ЭВАКУАЦИИ». Где заранее расписано, что делать по шагам. Но восстановления в этих шагах нет, есть отправка пользователей в новую систему.

Планом, правда, в чистом виде воспользоваться не пришлось. Не бомбануло, но в итоге всё-таки приняли «политическое» решение о сворачивании сервиса.

Как обычно, по желании обсудить, действует чятик https://yangx.top/joinchat/B-bfYQrvBssyBCf4D2YjhQ