Прослушивая одним ухом подкаст про работу в стартапах, а вторым глазом прочитывая ФБ ленту про ужас в "энтерпрайзах", сформулировал для себя, что такое "дух стартапа"

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

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

Стартап - это дух приобретения. Энтерпрайз - это дух сохранения.
Капитан очевидность апплодирует

Отсюда вопрос про себя - а мы стартап или нет? 50/50.

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

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

По-большому счету, это баланс "брони и огня"

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

Думаю, многие легковесно воспринимают эту проблему как надуманную, и я сам был таким. По большому счету, люди делятся на две категории - одни ЕЩЕ думают, что кризиса не бывает, а другие УЖЕ понимают, что он вполне реален и наблюдаем.

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

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

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

А теперь применяем к каждому пункту принцип "5 почему" и выписываем, что именно вызвало именно такую реакцию. Что именно понравилось или не понравилось в том событии. Местами причины окажутся схожими - вычеркиваем повторы. Для оставшихся делаем второй, третий и так далее проходы - пока не останутся 2-4 уникальных, непересекающихся мотива. Ну это и есть ваши оригинальные настоящие глубинные ценности.

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

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

Репутационно это нам на руку, но прежде чем злорадствовать над конкурентом надо осознать, что УЯЗВИМОСТИ ЕСТЬ У ВСЕХ. Много уязимостей. Просто у одних эти уязвимости известны, а у других еще нет. Начиная с какого-то масштаба распространения продукта/сервиса, его взлом достаточно интересен, чтобы за ним пристально наблюдали. И основной способ оставаться безопасным, это наблюдать за собой пристальнее всех и оперативно реагировать. Чисто именно там, где быстро и тщательно убирают любую грязь.

Для этого мы содержим выделенную команду по безопасности, и имеем окошко, куда сторонние эксперты заносят нам свои подозрения, а мы оперативно реагируем и благодарим их.

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

О бекапах. Взгляните на картинку выше - что в ней не так?

НЕ ТАК в ней то, что у людей есть бекап система, которой они НЕ ПОЛЬЗОВАЛИСЬ. В том смысле, что не восстанавливались. То есть они не знаю, работает ли их бекап вообще. Бекап Шрёдингера.

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

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

Мы сами не идеальны в этом смысле, но стремиться надо

Для тех, у кого и телеграмм ещё не заблокирован и прокси ещё не настроен - нажать сюда
https://t.me/socks?server=95.216.140.149&port=3128

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

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

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

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

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

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

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

Потеря оставшихся 0.01% может обойтись дешевле, чем их поддержка. Ничего личного, просто economy of scale, а делать хорошо одному человеку плохо масштабируется. Известный эффект, что массовая аудитория предпочитает выбирать по цене , когда преимущество в качестве не очевидно. Так что мы сами стимулируем такое поведение сервисов

Чатик для дискуссий и несогласия
https://t.me/joinchat/B-bfYQrvBssyBCf4D2YjhQ

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

1. Мы будем компактной организацией!

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

Что получается на практике:
- чтобы кого-то нанять - надо кого-то уволить. Менеджеры с маленькими командами боятся оставлять открытую брешь в штате на 2-4 месяца. Единственный инструмент - партизански найти более сильного человека и держать его в готовности. Команда стагнирует без новых людей

2. Мы берём самых лучших!

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

3. Мы тщательно отбираем!

На практике длинные серии тестов, собеседований, согласование с директором, вице-президентом, старшим вицей-президентом, CFO, CEO. Чего? Кандидат уже ушёл в другую компанию.

В принципе то каждый из трёх принципов имеет смысл, но в «кровавом энтерпрайзе»  силами бюрократии извращается в опасный яд.

Все три ситуации были реальными в разные годы моей жизни.

Разовьём вопрос найма до бюджетного планирования. Ещё несколько энтерпрайзных анти-паттернов:

1) устанавливается планка в число сотрудников. Превышать нельзя.

Эффект #1: Очевидно, что в среднем численность будет всегда меньше штатной? Отлично. Теперь по итогам года надо или снизить численность до средних человеко-голов или бюджет. Простая математическая формула позволит вычислить момент, когда команда схлопнется в ноль.

Эффект #2: возникает стимул заткнуть дыру хоть кем-то, но быстро. Общий уровень команды деградирует.

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

2) берётся курс на ползучее снижение численности. было две вакансии в двух отделах. Подумали и оставили только одну. Кто-то второй остался без сотрудника. И так много раз

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

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

Теперь бюджетные анти-приёмы:

3) вилка (мой любимый) - запретить расходы в одном квартале, затем срезать из бюджета все, что не было израсходовано (вы же как-то обошлись?)

4) вилка на уровне годов - запрещать запланированные траты в течении года, затем потребовать бюджет следующего года как прошлый +10%

5) потребовать перенос расходов на бюджет другого отдела, а другой отдел в свою очередь не будет планировать эти расходы

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

6) срезать неиспользованные в году средства из бюджета следующего года. Это популярно не только в России, но и в Европе и в США. Поэтому в конце года там бум корпоративных заказов («освоение бюджета»)

пост насущный о телеграмме

Вчера роскомнадзор продолжил «беглый огонь по окружающей действительности» и забанил ещё 1 млн IP в рамках битвы за телеграмм. На этот раз попали Digital Ocean, Azure, Hetzner. Общий объём блокировок уже примерно 0.5% от всего IPv4 пространства.

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

Вариант развертывания прокси в русском ЦОД уязвим тем же рискам - русский прокси не сможет достучаться до заблокированных облачных сервисов.

Оценка рисков осложняется тем, что угроза рекурсивная и характеризуется степенью локализации. Сам сервис может быть хоститься в РФ, но использовать компоненты извне, которые отвалятся. Или эти компоненты будут использовать кого-то, кого заблокируют. Как проблема c leftpad в JavaScript, но на сетевом уровне (если не сталкивались - то прочтите
https://www.theregister.co.uk/AMP/2016/03/23/npm_left_pad_chaos/)
А если не слетит сам сервис, то может лечь любой используемый инструмент (тоже рекурсивная угроза)

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

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

Скажем, ранее в битве за Zello - Amazon и Google попросили zello прекратить прыгать по их IP. В тот раз хватило заблокировать 2000 IP адресов
https://techcrunch.com/2018/04/17/russias-telegram-ban-that-knocked-out-15m-google-amazon-ip-addresses-had-a-precedent-in-zello/amp/

Другой логический шаг РКН - заблокировать установки telegram в AppStore и google store. В случае с LinkedIn в прошлый раз это сработало. Apple выполнил предписание. А переключаться в американский App Store не очень удобно.

Есть ещё эффективная схема обхода блокировок с обновлением адресов телеграмм серверов через push уведомления. Для ее блокировки тоже нужно сотрудничество Apple/Google. Прецедентов с блокировкой push на их стороне я не помню, но принципиально не отличается от удаления из магазинов.

Была ещё схема domain fronting от Гугл, которая позволяла открывать заблокированные сайты от имени гугла и смотреть их через Гугл. Детали здесь:
https://www.labnol.org/internet/google-proxy-server/28112/
Гугл эту схему закрывает с одной стороны. Но выпускает простой и удобный Alphabet Outline (VPN) с другой. То есть дадим возможность обходить, но за ресурсы будете платить сами.

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

В целом дальнейшая ситуация определяется имхо двумя принципиальными вопросами:
- будут ли amazon/google и другие провайдеры терпеть «токсичного клиента»? Хотя прошлые прецеденты были не в пользу телеграмма, но с другой стороны в текущей политической ситуации провайдерам будет не очень уместно отказать.
- будут ли Apple и Google принимать меры? В прошлом они сотрудничали, но опять же в текущей политической ситуации им это может быть не комфортно.

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

Провайдеры на примере ФБ видят, что русская история может ударить по их капитализации куда сильнее (-10%), чем утрата русского рынка (1-5%)

Попался старый выпуск РадиоТ со спором о том, программист это инженер или нет?

Надо сказать, что уровень потихоньку опускается. Лет 10-12 назад споры шли на уровне программист это художник или нет? Сейчас опустились до инженера и это естественно.

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

Индустрия требовала больше рук. Навык масштабировался и упрощался.

Аналогично, полвека назад программист писал язык программирования, операционку, сетевой протокол, систему управления ядерным реактором. Спустя 20-30 лет - толпы программистов кодили фрагменты больших систем. Сейчас самая частая работа - плагин или тему к вордпрессу подкрутить.

Тоже самое можно и про врачей рассказать.

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

Так что предмет спора очень иллюзорен. Все профессии проходят через масштабирование и упрощение.

Уже на примере нескольких компанию наблюдаю проблему «отстали, потому что опередили»

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

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

... А первый остаётся один на один со своим доморощенным легаси, с каждым часом отставая от индустрии

И что можно сделать?
1) не делать самому. В маленьких компаниях вполне разумна стратегия - не изобретать, подождать, все придёт
2) «я тебя породил, я тебя и убью». Ничто не вечно - лошадка отслужила свою службу, время фиксировать убытки и переходить на более современное решение
3) «так доставайся же ты ... всем». Чтобы не отстать от индустрии надо быть индустрией. Если подсадить всех на свой инструмент с самого начала, заопенсорсить его, то можно очень сильно продлить свою жизнь на нем. Это, конечно, вложения сил, но для больших контор оправдано.

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

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

Немного спойлеров:
- Фил Кулин рассказал про свой сбор статистики о блокировках и механизмах блокировок вообще. В частности, интересно узнать, что не все заблокированные решением суда сайты передаются  хостерам для блокировки, что файл описания блокировок содержит некоторый объем испорченных записей  (нереализуемая блокировка). Также файл все еще содержит ставшие свободными домены, так что можно продолжать их использовать для "DoS" атак
- для незнакомых с темой есть сайт https://usher2.club со статистикой блокировок. В частности известно, что 34 тысячи российских сайтов попали в "сопутствующий ущерб" от блокировок телеграмма. 2250 жалоб поступило в РКН за 15 часов работы горячей линии.
- Блокировки РКН поддерживает по доменному имени, по URL, по IP, по подсети. При этом нет блокировок по wildcard доменам, чем с радостью пользуются
- Есть сервисы предлагающие хитрые мало-палющиеся VPNы, чтобы вас не блокировали
- Есть группы материально заинтересованные в блокировках, с намерением поднять какие-то деньги в кратко- и среднесрочной перспективе. Например, продавцы DPI
- Есть сервисы по обходу DPI (Deep Packet Inspection для блокировок по  URL)
- Само будущее DPI под угрозой - разрабатываются поправки к сетеввым протоколам, затрудняющие это до невозможности
- очень интересная часть про слежение за человек через DNS запросы и грядущие коррекции, которые это значительно затруднят
- также рассматривался интересный мне вопрос фактической экстерриториальности РКН. Я тоже немного порассуждаю об этом в следуюющий раз

Рекомендую посмотреть запись:
https://www.youtube.com/watch?v=YccwFWiSryY&feature=youtu.be

Некоторые новости за прошедший период
- https://vk.com/wall6492_6115 Вконтакт объявил о работе над end-to-end шифрованием. Закинутую в тексте палку в сторону РКН и иллюстрацию  "прогресс не остановить" (Сегалович)  можно рассматривать как легкое фрондерство
- за подобным же фрондированием были ранее замечены Себрант и Бакунов из Яндекса
- Mail.Ru заявили что заблокировали машину, которая искала Telegram proxy и сдавала их в РКН https://tjournal.ru/69686-mail-ru-group-otkrestilas-ot-obvineniy-v-pomoshchi-roskomnadzoru-po-obnaruzheniyu-proksi-telegram
- Яндекс попал под блокировки изза Телеграмма, разблокировался и потребовал объяснений от РКН https://eadaily.com/ru/news/2018/04/27/yandeks-trebuet-obyasneniy-ot-roskomnadzora-zablokirovavshego-ego-adresa
- Одноклассники не стали упоминать РКН, но высказались о блокировках критически https://www.igromania.ru/news/74851/RKN_vremenno_zablokiroval_IP-adresa_Yandeksa_VKontakte_i_Odnoklassnikov.html
- разработчики DPI софта (инспекция траффика) сделали опцию "Разблокировать популярные сайты в обход требований РКН" https://www.carbonsoft.ru/google-youtube-telegram/
- Мария Захарова (официальный представитель МИД) выразила протест и непонимание происходящих блокировок

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

Из не-РКН новостей интересно, что Яндекс успел
- анонсировать превращение Яндекс.Маркета в чистый агрегатор (покупка только с сайта продавца) https://retailer.ru/jandeks-market-uberjot-vozmozhnost-kupit-tovar-bez-perehoda-na-sajt-prodavca/
- спустя едва две недели анонсировать движение в обратную сторону через развертывание торговой площадки наподобие Amazon или AliExpress (перезапуск Яндекс.Маркета как магазина?)
https://www.rbc.ru/finances/27/04/2018/5ae332279a79477da3f810a1

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

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

Дело в том, что возможно ни я, ни мои коллеги не должны были стать программистами. Многие из нас должны были стать врачами, учеными, кем угодно. Но после в 90х и после не так то много было высокооплачиваемой работы и мы все ушли в программирование. В 2001м моя наиминимальнейшая з/п в софтовой конторе уже была в два раза выше возможной альтернативы в "реальном секторе". Куча чуть более взрослых людей подалась в эмиграцию и один из самых лучших шансов устроиться для технически способного человека в эмиграции снова было IT - благо оно быстро росло и требовало все больше и больше кадров, так что войти можно было всегда и начать свой путь по лестнице вверх. Тоже самое случилось и в других бывших республиках, так что "русский программист" на практике может оказаться и украинцем, и белорусом и прибалтом.

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

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

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

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

Написано по мотивам моего ответа на  Quora
https://www.quora.com/Are-Russian-software-developers-the-best-in-the-world/answer/Sergey-Lystsev

Часто подымается вопрос, как померить программистов или инженеров, ввести метрики или KPI для объективности. Мы экспериментировали с ними с середины 2000х и в целом опыт негативный. Дело в том, что при появлении "метрики" люди склонны оптимизировать "метрику" вместо реального результата, который всегда сложнее. Проблема здесь не в метриках как таковых, а в их неполносте - очень сложно подобрать в разработке такой комплект метрик, который будет действительно полно характеризовать чей-то труд.

Приведу несколько примеров сверх классической копи-пасты в ответ на оценку по числу строк кода:

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

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

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

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

И так далее. Во всех случаях от простой метрики можно легко уйти.
В китае ввели социальный рейтинг по куче метрик - появилось устройство, которое симулирует, что ты много ходишь (и появилась скидка на мед.страховку). SEOшники постоянно пытаются хакнуть метрики поисковиков.

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

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

В несколько более простом случае команд технической поддержки такая задача часто более-менее решается. Что им помогает? Более высокая однородность задач. Вопросы и проблемы пользователей на порядок или два однороднее, чем задачи в разработке, которые сильно различаются как между разными командами, так и внутри команд. Очень мало взаимодействий. Один человек решает одну проблему одного пользователя. Также очень помогает, что есть пользователь - он извне системы и пользователей в целом можно считать условно объективными (за счет статистики и большого объема).

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

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

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

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

Несогласные могут высказаться в чатике
https://t.me/joinchat/B-bfYQrvBssyBCf4D2YjhQ