Если речь про РФ, и взять статистику опросов работников от того же Хабра, то она во-первых пляшет как пьяный матрос, а во-вторых не отражает роста зп который я вижу по моему окружению.
Можно посмотреть на статистику НН, но там далеко не все работодатели публикуют зп. И по опыту, самые вкусные вакансии как раз не публикуют.
Так вот, вопрос, из каких источников вы узнаете свою рыночную цену?
А вы знаете другой способ узнать свою рыночную стоимость? Не соседа, не сферического специалиста по данным публичной статистики зарплат, а именно свою?
Помните, что главное — не требовать прибавки, а достичь взаимопонимания с руководителем о том, как получить эту прибавку в будущем. Возможно, вам нужно освоить для этого...
Вы действительно хотите, чтобы начальство натерло ноги о вашу шею? Вас сразу нагрузят новыми обязанностями. Сами же попросили! А прибавка потом... когда-нибудь...
Даже четкие критерии получения прибавки и четкие договоренности ничего никому не гарантируют.
Актуальный пример: я затеял переговоры с начальством, мол, топ-перформер (по их же оценке), за 2 года была прибавка 5%, хочу больше.
Знаете, что мне ответили? "Ты тим лид на своем проекте, давай еще возьми роль солюшен архитектора на другом проекте. Так надо." Пока за дополнительную премию (5% оклада) а через квартал, если все будет хорошо, оформим полноценный переход.
Категорически не согласен, если я - заказчик. Заказчику нужно знать ответы на вопросы "сколько" и "когда".
При этом не стоит считать, что софт - это прямо сложно и непредсказуемо, а, например, строительство - просто и прогнозируемо. Наивно недооценивать сложность реального мира.
Недавний пример: нанял рабочих выкопать канаву на даче. Это даже проще, чем класть кирпичи, не так ли? По логике, каждый следующий метр канавы - он такой же, как предыдущий? Так-то оно так, но ровно до того момента, как рабочие уткнулись в закопанную груду кирпичей.
Не надо считать разработку - чем-то особенным. Другие области ничем не легче. А зачастую - сложнее и менее толерантны к изменениям. Если вы строите 10-и этажный дом, вы не можете посередине строительства передумать и построить 20 этажей. Каким бы гением не был ваш архитектор. А если вы строите софт, и у вас толковый архитектор, то добавить в 2 раза больше функционала, или в 2 раза увеличить нагрузку на систему - можете. Это будет стоить времени и денег, но - можете.
Возвращаясь к оценке. Если считать оценку не числом, превращающимся в обязательство по факту его озвучивания, а функцией распределения вероятности - то она вполне имеет право на жизнь.
И если вы хотите прозрачности, то накопите статистики, расскажите бизнесу азы "тервера", управляйте рисками и работайте.
Ваш бизнес не хочет слушать и требует одно число? Сочувствую. У меня такое регулярно. Качайте ораторское мастерство. Закладывайтесь со сроками по 90-му или 95-му персентилю (если хватит наглости) Или меняйте бизнес. Ну или фрустрируйте и пишите статьи о невозможности оценок.
Ну вы знаете, так про любую компанию можно сказать. С разной вероятностью - но про любую. В любой компании могут потерять заказчика или закрыть проект по прихоти бизнеса. Да и вообще, можно на ровном месте поссориться с начальством. Кто прав будет уже не важно.
Вы так говорите, как будто насквозь всех видите и просчитываете будущее. Если это так - завидую.
На прошлой работе я был в шоке, когда мой белый и пушистый начальник, в котором я души не чаял, рассказал, как он будет увольнять лоу-перформера из моей команды. Я был топ-перформером, но задумался, что при необходимости и меня будут увольнять так же.
Важно, как минимизировать риски до попадания в ситуацию. И как выбраться из ситуации, когда уже угодил.
Высказывания типа "не надо было связываться со Сколково" - это очень категорично и не очень конструктивно, не находите?
Понятно, что есть компании, который налюбили государство посредством Сколкова. Понятно, что эти же компании налюбливают как сотрудников, так и клиентов.
Вы что хотели сказать постом? Может, вы дали какие-то советы, как не оказаться на месте потерпевшего? Может, советы, что делать, если все-таки оказался?
Увы, "какой-нибудь продакт оунер или там РП" как раз и придет к разрабу за фактурой. Если продакт лицом к бизнесу, а другой стороной к команде, то "почему" надо обосновать в цифрах. Либо забить. Либо "партизанить" и делать тех. задачи втихаря.
Если продакт лицом к команде, и верит мне, я ему скажу: давай 25% на тех. долг + тех. развитие, иначе будут проблемы. "trusn me, bro". Так надо. И все пучком.
Если продакт лицом к команде, но (пока) не верит мне, я выбираю наиболее критичную вещь и говорю: вот если не сделать эту фигню, риск 30% что упадет через месяц. Продакт не верит. Потом оно падает. Все рвут волосы на разных частях тела и бегают по потолку. Когда следующий раз я прихожу к продакту, что нужно следующую фигню, чтобы митигировать риски, он уже верит. Следующий шаг: "trusn me, bro, 25% - мои".
Дальше дело продакта перед бизнесом размазать эти затраты по бизнесовым задачам.
Каждый раз по каждой мелочи обосновывать- это очень тяжело морально + не все можно адекватно оценить.
Поэтому единственный выход - это ввести непрозрачность. Либо между продактом и командой (плохо), либо между продактом и бизнесом (лучше)
Мне это не нравится. Я в общем-то за честность. Просто не знаю, в какую форму ее облечь, чтобы меня не считали разводилой, как в автосервисе.
но если человек относится к своему софту так, как будто его поставят на космический корабль, летящий к марсу, тогда чем быстрее вскроешь говнокод, тем больше вероятность, что экспедиция к марсу не закончится провалом.
Позиция тимлида обязывает сидеть в технике только одним полупопием, а вторым сидеть в бизнесе.
Поэтому, фокус на том, чтобы 1) команда прогнозируемо поставляла ценности бизнесу сейчас. 2) команда поставляла бы ценности бизнесу в будущем не хуже (в идеале - луче), чем сейчас
То есть, от говнокода глазки конечно болят, но я их закрываю, если понимаю, что тронешь - будет хуже.
Особенно боялся бы трогать, если бы писал софт для марсохода.
Потому что этот говнокод - это жуткое легаси, которое +- устаканилось, которое проверено вдоль и поперек (если не тестерами, то хотя бы пользователями), и у которого, возможно, есть неочевидные хрупкие особенности.
Если с шашкой наголо набрасываться на говнокод, то результат получится обратный: дестабилизация решения, срыв сроков. А если это делать слишком рьяно, то возможен провал проекта.
Я не к тому, что говнокод надо терпеть. Как написал выше, умеренный рефакторинг вполне допустим задолго до релиза и если есть время, чтобы успеть стабилизировать решение. И допустим он только тогда, когда выгода от рефакторинга в будущем явно выше потенциального вредв в настоящем.
Не потому, что я прикрываю зад. А потому, что бизнес мне платит за то, что я решаю его проблемы. Не за красивый код или архитектуру или красивые слова.
Вот представьте, пришли вы к стоматологу с больным зубом, а он вам удаляет, ставит протез, и говорит: с вас 100500 денег. Хотите попасть в такую ситуацию? Я вот - не хочу.
Я хочу, чтобы мне как заказчику честно описали возможные варианты, с рисками, стоимостью, и я бы принял решение. Может, меня устроит сейчас залепить зуб пломбой, пусть даже без гарантии. А когда совсем рассыпится - тогда уже и протезировать.
Боюсь, одним вопросом "зачем" тут не обойтись. Под вопросом и под ответом может скрываться второй смысл, который не вызовет одобрения второй стороны.
Разраб: Давайте писать тесты, настроим ci/cd
Бизнес: Зачем (в смысле, я ничего не понял)?
Разраб: Ну, мы автоматизируем рутинную работу, убираем человеческий фактор, бла-бла-бла (блин, как бы объяснить, что это отраслевой стандарт, все так делают. А кто не делает - отсталый питекантроп)
Бизнес: Зачем (в смысле, сколько денег экономим)?
Разраб: Ну... как бы объяснить.. (в смысле, хз сколько денег и как это посчитать. Блин, надоело ручками проект собирать. Уволюсь нафиг от этих дебилов и пойду в гуглы и прочие яндексы, где не надо торговаться, чтобы настроить пайплайн)
Не хотелось бы никого обижать, но в плане оплаты услуг Германия, скажем так, не на первом месте в Мире.
Помню, был поражен до глубины души, когда оплату прав пришлось выполнить частями: наличка + плетеж с дебетовки. Потому что одна часть - плата автошколе а другая - пошлина.
А, скажем, в турецких фастфудах (в Германии), как правило, принимают только наличку. То ли там двойная бухгалтерия, то ли эквайринг трудно и дорого подключать.
И я убежден, что как только появится удобный дешевый механизм быстрых платежей, каждый Мустафа его себе подключит. Потому что ни один торговец в здравом уме не хочет терять поток денег, который уйдет к более расторопным конкурентам.
Я "мимокрокодил", но навскидку у мелкого мусора отношение площади сечения к массе больше, чем у станции. На орбите МКС вакуум не такой уж и вакуум, поэтому мусор будет тормозиться сильнее.
При торможении в атмосфере скорость увеличится (звучит как парадокс, но все норм, это происходит за счет потенциальной энергии). В общем, мусор во-первых, обгонит станцию, а во-вторых, будет снижаться быстрее в полном соответствии с формулой скорости V=sqrt(GM/R)
Не ускорения ради, а просто чтобы не мозолило глаз. Как на меня тогда напал наш группенфюрер...
Сейчас все модели сломаются! Потом скажут, что мы всё сломали! Я такие изменения не пропущу!
Ни в коем разе не оправдываю группенфюрера, который не въехал в то, что делает код...
Но сломаться может что угодно, где угодно и как угодно.
Пример из жизни: как-то я выкинул кусок легаси кода, результаты которого нигде не использовались. Ошметки многократно измененного алгоритма. Мусор. Причем, я же опытный индеец, перед этим покрыл код юнит тестами. Ну вообще ничего не должно было сломаться.
Тестирование прошло успешно.
А потом все стало сыпаться на проде в совершенно левых местах. На тестовой среде не сыпалось.
Стоило отката системы к предыдущему релизу и многих седых волос.
Разгадка оказалась следующей: в совершенно других местах было криво реализована синхронизация потоков. Этот легаси, который я почистил, добавлял задержку на несколько мс. За это время другой поток успевал доделать работу, и потом, текущий поток мог брать уже готовые данные. А без легаси другой поток не успевал доделать, и текущий поток хватал неконсистентные данные. На проде. А на тесте ядер было поменьше, степень параллелизма кое-где отличалась и все выполнялось чуть иначе.
Можно сколько угодно говорить, что код - Г, что авторов найти и надавать канделябром по пальцам, что во всем этом надо разобраться и все переписать.
Но факт остается фактом: выкинул ненужный код - все упало.
Я над тем проектом давно не работаю.
Но всегда перед релизом ввожу не только фича-фриз, но и рефакторинг-фриз. Рефакторинг - только в первую неделю спринта. Сложный рефакторинг - только при наличии ценности для бизнеса, при наличии "воздуха" в спринте, при возможности для него 1-2 спринта "отлежаться" на препроде.
И пусть меня считают глупым душнилой и тормозом прогресса.
Простите за вопрос от чайника, перевести стрелки часов чтобы что?
Ну то есть, как я понял из статьи, сейчас время расхождения между атомным и астрономическим таймерами уже 37 секунд. При этом все как-то функционирует. Почему бы не оставить все как есть, вместо того, чтобы подвергать массу важных для человечества систем риску сбоев?
Возможно, это архитектурно неверно, но чем плохо это накапливающееся расхождение? Пусть копится.
Может иметь. Но бОльшая часть руководителей, которые являются простыми линейными менеджерами - не имеет.
В офисе я же могу лицезреть линейных менеджеров? Ну так вот, для полного погружения, чтобы было "как в офисе", я хотел бы его видеть на удаленке. Раз уж он меня видит. Мы же с ним одна команда! Хотел бы глубже погружаться в офисную атмосферу. Чтобы лучше работать. Брать с него пример. (Trollface)
У меня в одном финтехе было свое следящее ПО, которое логирует клавиатуру и снимает скриншоты.
И СБ реально смотрели на эти скриншоты. Когда мой коллега поставил заставку в виде винлокера, СБ примчались очень быстро.
В то же время, оказалось, что когда прямо с рабочего компа искал новую работу (по причине выгорания), меня никто не спалил. Видимо для СБ это безразлично.
Для интереса запросил у начальства статистику по себе. Оказалось, в среднем накликивал мышкой и клавой на 6 часов. При том, что реально работал я часов по 10.
А как вы следите за рынком?
Если речь про РФ, и взять статистику опросов работников от того же Хабра, то она во-первых пляшет как пьяный матрос, а во-вторых не отражает роста зп который я вижу по моему окружению.
Можно посмотреть на статистику НН, но там далеко не все работодатели публикуют зп. И по опыту, самые вкусные вакансии как раз не публикуют.
Так вот, вопрос, из каких источников вы узнаете свою рыночную цену?
А вы знаете другой способ узнать свою рыночную стоимость? Не соседа, не сферического специалиста по данным публичной статистики зарплат, а именно свою?
Расскажите, пожалуйста.
Вы действительно хотите, чтобы начальство натерло ноги о вашу шею? Вас сразу нагрузят новыми обязанностями. Сами же попросили! А прибавка потом... когда-нибудь...
Даже четкие критерии получения прибавки и четкие договоренности ничего никому не гарантируют.
Актуальный пример: я затеял переговоры с начальством, мол, топ-перформер (по их же оценке), за 2 года была прибавка 5%, хочу больше.
Знаете, что мне ответили? "Ты тим лид на своем проекте, давай еще возьми роль солюшен архитектора на другом проекте. Так надо." Пока за дополнительную премию (5% оклада) а через квартал, если все будет хорошо, оформим полноценный переход.
Увы, кто везет - на том едут.
Штраф - да. Затраты на адвокатов в Германии - нет. Чувак уже попал на сумму в разы, если не порядок больше.
Хороший пример, но я бы не стал покупать квартиру в этом доме.
Полностью солидарен, если я - исполнитель.
Категорически не согласен, если я - заказчик. Заказчику нужно знать ответы на вопросы "сколько" и "когда".
При этом не стоит считать, что софт - это прямо сложно и непредсказуемо, а, например, строительство - просто и прогнозируемо. Наивно недооценивать сложность реального мира.
Недавний пример: нанял рабочих выкопать канаву на даче. Это даже проще, чем класть кирпичи, не так ли? По логике, каждый следующий метр канавы - он такой же, как предыдущий? Так-то оно так, но ровно до того момента, как рабочие уткнулись в закопанную груду кирпичей.
Не надо считать разработку - чем-то особенным. Другие области ничем не легче. А зачастую - сложнее и менее толерантны к изменениям. Если вы строите 10-и этажный дом, вы не можете посередине строительства передумать и построить 20 этажей. Каким бы гением не был ваш архитектор. А если вы строите софт, и у вас толковый архитектор, то добавить в 2 раза больше функционала, или в 2 раза увеличить нагрузку на систему - можете. Это будет стоить времени и денег, но - можете.
Возвращаясь к оценке. Если считать оценку не числом, превращающимся в обязательство по факту его озвучивания, а функцией распределения вероятности - то она вполне имеет право на жизнь.
И если вы хотите прозрачности, то накопите статистики, расскажите бизнесу азы "тервера", управляйте рисками и работайте.
Ваш бизнес не хочет слушать и требует одно число? Сочувствую. У меня такое регулярно. Качайте ораторское мастерство. Закладывайтесь со сроками по 90-му или 95-му персентилю (если хватит наглости) Или меняйте бизнес. Ну или фрустрируйте и пишите статьи о невозможности оценок.
"Не влезай, убьёт!" , говорите?
Ну вы знаете, так про любую компанию можно сказать. С разной вероятностью - но про любую. В любой компании могут потерять заказчика или закрыть проект по прихоти бизнеса. Да и вообще, можно на ровном месте поссориться с начальством. Кто прав будет уже не важно.
Вы так говорите, как будто насквозь всех видите и просчитываете будущее. Если это так - завидую.
На прошлой работе я был в шоке, когда мой белый и пушистый начальник, в котором я души не чаял, рассказал, как он будет увольнять лоу-перформера из моей команды. Я был топ-перформером, но задумался, что при необходимости и меня будут увольнять так же.
Важно, как минимизировать риски до попадания в ситуацию. И как выбраться из ситуации, когда уже угодил.
Высказывания типа "не надо было связываться со Сколково" - это очень категорично и не очень конструктивно, не находите?
Кликбейт.
Понятно, что есть компании, который налюбили государство посредством Сколкова. Понятно, что эти же компании налюбливают как сотрудников, так и клиентов.
Вы что хотели сказать постом? Может, вы дали какие-то советы, как не оказаться на месте потерпевшего? Может, советы, что делать, если все-таки оказался?
Увы, "какой-нибудь продакт оунер или там РП" как раз и придет к разрабу за фактурой. Если продакт лицом к бизнесу, а другой стороной к команде, то "почему" надо обосновать в цифрах. Либо забить. Либо "партизанить" и делать тех. задачи втихаря.
Если продакт лицом к команде, и верит мне, я ему скажу: давай 25% на тех. долг + тех. развитие, иначе будут проблемы. "trusn me, bro". Так надо. И все пучком.
Если продакт лицом к команде, но (пока) не верит мне, я выбираю наиболее критичную вещь и говорю: вот если не сделать эту фигню, риск 30% что упадет через месяц. Продакт не верит. Потом оно падает. Все рвут волосы на разных частях тела и бегают по потолку. Когда следующий раз я прихожу к продакту, что нужно следующую фигню, чтобы митигировать риски, он уже верит. Следующий шаг: "trusn me, bro, 25% - мои".
Дальше дело продакта перед бизнесом размазать эти затраты по бизнесовым задачам.
Каждый раз по каждой мелочи обосновывать- это очень тяжело морально + не все можно адекватно оценить.
Поэтому единственный выход - это ввести непрозрачность. Либо между продактом и командой (плохо), либо между продактом и бизнесом (лучше)
Мне это не нравится. Я в общем-то за честность. Просто не знаю, в какую форму ее облечь, чтобы меня не считали разводилой, как в автосервисе.
Может вы знаете?
А еще - не стоит бояться или лениться периодически ходить на собеседования.
Позиция тимлида обязывает сидеть в технике только одним полупопием, а вторым сидеть в бизнесе.
Поэтому, фокус на том, чтобы 1) команда прогнозируемо поставляла ценности бизнесу сейчас. 2) команда поставляла бы ценности бизнесу в будущем не хуже (в идеале - луче), чем сейчас
То есть, от говнокода глазки конечно болят, но я их закрываю, если понимаю, что тронешь - будет хуже.
Особенно боялся бы трогать, если бы писал софт для марсохода.
Потому что этот говнокод - это жуткое легаси, которое +- устаканилось, которое проверено вдоль и поперек (если не тестерами, то хотя бы пользователями), и у которого, возможно, есть неочевидные хрупкие особенности.
Если с шашкой наголо набрасываться на говнокод, то результат получится обратный: дестабилизация решения, срыв сроков. А если это делать слишком рьяно, то возможен провал проекта.
Я не к тому, что говнокод надо терпеть. Как написал выше, умеренный рефакторинг вполне допустим задолго до релиза и если есть время, чтобы успеть стабилизировать решение. И допустим он только тогда, когда выгода от рефакторинга в будущем явно выше потенциального вредв в настоящем.
Не потому, что я прикрываю зад. А потому, что бизнес мне платит за то, что я решаю его проблемы. Не за красивый код или архитектуру или красивые слова.
Вот представьте, пришли вы к стоматологу с больным зубом, а он вам удаляет, ставит протез, и говорит: с вас 100500 денег. Хотите попасть в такую ситуацию? Я вот - не хочу.
Я хочу, чтобы мне как заказчику честно описали возможные варианты, с рисками, стоимостью, и я бы принял решение. Может, меня устроит сейчас залепить зуб пломбой, пусть даже без гарантии. А когда совсем рассыпится - тогда уже и протезировать.
Боюсь, одним вопросом "зачем" тут не обойтись. Под вопросом и под ответом может скрываться второй смысл, который не вызовет одобрения второй стороны.
Разраб: Давайте писать тесты, настроим ci/cd
Бизнес: Зачем (в смысле, я ничего не понял)?
Разраб: Ну, мы автоматизируем рутинную работу, убираем человеческий фактор, бла-бла-бла (блин, как бы объяснить, что это отраслевой стандарт, все так делают. А кто не делает - отсталый питекантроп)
Бизнес: Зачем (в смысле, сколько денег экономим)?
Разраб: Ну... как бы объяснить.. (в смысле, хз сколько денег и как это посчитать. Блин, надоело ручками проект собирать. Уволюсь нафиг от этих дебилов и пойду в гуглы и прочие яндексы, где не надо торговаться, чтобы настроить пайплайн)
Не хотелось бы никого обижать, но в плане оплаты услуг Германия, скажем так, не на первом месте в Мире.
Помню, был поражен до глубины души, когда оплату прав пришлось выполнить частями: наличка + плетеж с дебетовки. Потому что одна часть - плата автошколе а другая - пошлина.
А, скажем, в турецких фастфудах (в Германии), как правило, принимают только наличку. То ли там двойная бухгалтерия, то ли эквайринг трудно и дорого подключать.
И я убежден, что как только появится удобный дешевый механизм быстрых платежей, каждый Мустафа его себе подключит. Потому что ни один торговец в здравом уме не хочет терять поток денег, который уйдет к более расторопным конкурентам.
Я "мимокрокодил", но навскидку у мелкого мусора отношение площади сечения к массе больше, чем у станции. На орбите МКС вакуум не такой уж и вакуум, поэтому мусор будет тормозиться сильнее.
При торможении в атмосфере скорость увеличится (звучит как парадокс, но все норм, это происходит за счет потенциальной энергии). В общем, мусор во-первых, обгонит станцию, а во-вторых, будет снижаться быстрее в полном соответствии с формулой скорости V=sqrt(GM/R)
Ни в коем разе не оправдываю группенфюрера, который не въехал в то, что делает код...
Но сломаться может что угодно, где угодно и как угодно.
Пример из жизни: как-то я выкинул кусок легаси кода, результаты которого нигде не использовались. Ошметки многократно измененного алгоритма. Мусор. Причем, я же опытный индеец, перед этим покрыл код юнит тестами. Ну вообще ничего не должно было сломаться.
Тестирование прошло успешно.
А потом все стало сыпаться на проде в совершенно левых местах. На тестовой среде не сыпалось.
Стоило отката системы к предыдущему релизу и многих седых волос.
Разгадка оказалась следующей: в совершенно других местах было криво реализована синхронизация потоков. Этот легаси, который я почистил, добавлял задержку на несколько мс. За это время другой поток успевал доделать работу, и потом, текущий поток мог брать уже готовые данные. А без легаси другой поток не успевал доделать, и текущий поток хватал неконсистентные данные. На проде. А на тесте ядер было поменьше, степень параллелизма кое-где отличалась и все выполнялось чуть иначе.
Можно сколько угодно говорить, что код - Г, что авторов найти и надавать канделябром по пальцам, что во всем этом надо разобраться и все переписать.
Но факт остается фактом: выкинул ненужный код - все упало.
Я над тем проектом давно не работаю.
Но всегда перед релизом ввожу не только фича-фриз, но и рефакторинг-фриз. Рефакторинг - только в первую неделю спринта. Сложный рефакторинг - только при наличии ценности для бизнеса, при наличии "воздуха" в спринте, при возможности для него 1-2 спринта "отлежаться" на препроде.
И пусть меня считают глупым душнилой и тормозом прогресса.
Простите за вопрос от чайника, перевести стрелки часов чтобы что?
Ну то есть, как я понял из статьи, сейчас время расхождения между атомным и астрономическим таймерами уже 37 секунд. При этом все как-то функционирует. Почему бы не оставить все как есть, вместо того, чтобы подвергать массу важных для человечества систем риску сбоев?
Возможно, это архитектурно неверно, но чем плохо это накапливающееся расхождение? Пусть копится.
Первое правило
бойцовского клубасцены - ...Может иметь. Но бОльшая часть руководителей, которые являются простыми линейными менеджерами - не имеет.
В офисе я же могу лицезреть линейных менеджеров? Ну так вот, для полного погружения, чтобы было "как в офисе", я хотел бы его видеть на удаленке. Раз уж он меня видит. Мы же с ним одна команда! Хотел бы глубже погружаться в офисную атмосферу. Чтобы лучше работать. Брать с него пример. (Trollface)
и капитан Джек Воробей!
У меня в одном финтехе было свое следящее ПО, которое логирует клавиатуру и снимает скриншоты.
И СБ реально смотрели на эти скриншоты. Когда мой коллега поставил заставку в виде винлокера, СБ примчались очень быстро.
В то же время, оказалось, что когда прямо с рабочего компа искал новую работу (по причине выгорания), меня никто не спалил. Видимо для СБ это безразлично.
Для интереса запросил у начальства статистику по себе. Оказалось, в среднем накликивал мышкой и клавой на 6 часов. При том, что реально работал я часов по 10.