Регулярно сталкиваюсь, с возмущением, что в каком-то онлайн сервисе очень сложно позвонить в тех. поддержку. Особенно для бесплатного пользователя. Со стороны пользователя это действительно неудобно, но со стороны сервиса это вполне разумно.
во многих интернет бизнесах расход на обслуживание одного звонка в саппорт выше годовой выручки с клиента. особенно во freemium'ах - где среднее сильно опущено бесплатными пользователями. Поэтому не только интернет сервисы, но даже телекомы стараются максимально избежать звонка в поддержку и отправить людей решать проблемы самостоятельно. Их стратегия это добиться, чтобы в поддержку не надо было звонить вообще. И если это покрывает 99.99% пользователей - то и отлично.
Потеря оставшихся 0.01% может обойтись дешевле, чем их поддержка. Ничего личного, просто economy of scale, а делать хорошо одному человеку плохо масштабируется. Известный эффект, что массовая аудитория предпочитает выбирать по цене , когда преимущество в качестве не очевидно. Так что мы сами стимулируем такое поведение сервисов
во многих интернет бизнесах расход на обслуживание одного звонка в саппорт выше годовой выручки с клиента. особенно во freemium'ах - где среднее сильно опущено бесплатными пользователями. Поэтому не только интернет сервисы, но даже телекомы стараются максимально избежать звонка в поддержку и отправить людей решать проблемы самостоятельно. Их стратегия это добиться, чтобы в поддержку не надо было звонить вообще. И если это покрывает 99.99% пользователей - то и отлично.
Потеря оставшихся 0.01% может обойтись дешевле, чем их поддержка. Ничего личного, просто economy of scale, а делать хорошо одному человеку плохо масштабируется. Известный эффект, что массовая аудитория предпочитает выбирать по цене , когда преимущество в качестве не очевидно. Так что мы сами стимулируем такое поведение сервисов
В разные годы у нас были разные принципы найма и есть три казалось бы хороших принципа, из-за которых можно остаться без хороших сотрудников.
1. Мы будем компактной организацией!
На практике контора не даёт нанимать новых людей, только замену ушедшим. В особо бюрократичных конторах это контролируется на уровне каждой отдельной позиции. На моей практике главный большой HR запрещал открывать поиск по вакансии, без предварительно уволившегося.
Что получается на практике:
- чтобы кого-то нанять - надо кого-то уволить. Менеджеры с маленькими командами боятся оставлять открытую брешь в штате на 2-4 месяца. Единственный инструмент - партизански найти более сильного человека и держать его в готовности. Команда стагнирует без новых людей
2. Мы берём самых лучших!
На практике отказываемся от рисков с обучением талантливых середнячков и новичков и ищем только супер-звезд. Во-первых, их вообще мало и без приличного бюджета их не привлечь. Щедрая контора задирает зарплаты на рынке, жадная - ждёт у моря погоды. А поскольку даже талантливый человек обычно уступает по меньшей мере опытом текущему сотруднику - поступление новых кадров прекращается по формальным признакам.
3. Мы тщательно отбираем!
На практике длинные серии тестов, собеседований, согласование с директором, вице-президентом, старшим вицей-президентом, CFO, CEO. Чего? Кандидат уже ушёл в другую компанию.
В принципе то каждый из трёх принципов имеет смысл, но в «кровавом энтерпрайзе» силами бюрократии извращается в опасный яд.
Все три ситуации были реальными в разные годы моей жизни.
1. Мы будем компактной организацией!
На практике контора не даёт нанимать новых людей, только замену ушедшим. В особо бюрократичных конторах это контролируется на уровне каждой отдельной позиции. На моей практике главный большой HR запрещал открывать поиск по вакансии, без предварительно уволившегося.
Что получается на практике:
- чтобы кого-то нанять - надо кого-то уволить. Менеджеры с маленькими командами боятся оставлять открытую брешь в штате на 2-4 месяца. Единственный инструмент - партизански найти более сильного человека и держать его в готовности. Команда стагнирует без новых людей
2. Мы берём самых лучших!
На практике отказываемся от рисков с обучением талантливых середнячков и новичков и ищем только супер-звезд. Во-первых, их вообще мало и без приличного бюджета их не привлечь. Щедрая контора задирает зарплаты на рынке, жадная - ждёт у моря погоды. А поскольку даже талантливый человек обычно уступает по меньшей мере опытом текущему сотруднику - поступление новых кадров прекращается по формальным признакам.
3. Мы тщательно отбираем!
На практике длинные серии тестов, собеседований, согласование с директором, вице-президентом, старшим вицей-президентом, CFO, CEO. Чего? Кандидат уже ушёл в другую компанию.
В принципе то каждый из трёх принципов имеет смысл, но в «кровавом энтерпрайзе» силами бюрократии извращается в опасный яд.
Все три ситуации были реальными в разные годы моей жизни.
Разовьём вопрос найма до бюджетного планирования. Ещё несколько энтерпрайзных анти-паттернов:
1) устанавливается планка в число сотрудников. Превышать нельзя.
Эффект #1: Очевидно, что в среднем численность будет всегда меньше штатной? Отлично. Теперь по итогам года надо или снизить численность до средних человеко-голов или бюджет. Простая математическая формула позволит вычислить момент, когда команда схлопнется в ноль.
Эффект #2: возникает стимул заткнуть дыру хоть кем-то, но быстро. Общий уровень команды деградирует.
Решение: добиваться временной избыточной численности. Кто-то все равно по статистике уйдёт и баланс сойдётся
2) берётся курс на ползучее снижение численности. было две вакансии в двух отделах. Подумали и оставили только одну. Кто-то второй остался без сотрудника. И так много раз
Эффект: Негарантированная возможность найма замены заставляет тимлидов держаться за имеющихся сотрудников. Разве это не хорошо? Но держаться будут даже за плохих сотрудников - был плохой, ушёл, и не осталось вообще никакого. Команды деградируют
Решение: требуется очень матёрый тимлид с навыками политической работы с верхами для сохранения вакансии и собственной сетью кандидатов для быстрого заполнения позиций
Теперь бюджетные анти-приёмы:
3) вилка (мой любимый) - запретить расходы в одном квартале, затем срезать из бюджета все, что не было израсходовано (вы же как-то обошлись?)
4) вилка на уровне годов - запрещать запланированные траты в течении года, затем потребовать бюджет следующего года как прошлый +10%
5) потребовать перенос расходов на бюджет другого отдела, а другой отдел в свою очередь не будет планировать эти расходы
У всех трёх и эффект и решение ровно одно - отрыв бюджета от реальности за счёт его перераздутия ложными статьями (что-то срежут, но что-то же останется!)
6) срезать неиспользованные в году средства из бюджета следующего года. Это популярно не только в России, но и в Европе и в США. Поэтому в конце года там бум корпоративных заказов («освоение бюджета»)
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%)
Вчера роскомнадзор продолжил «беглый огонь по окружающей действительности» и забанил ещё 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%)
www.theregister.co.uk
How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript
Code pulled from NPM – which everyone was using
Попался старый выпуск РадиоТ со спором о том, программист это инженер или нет?
Надо сказать, что уровень потихоньку опускается. Лет 10-12 назад споры шли на уровне программист это художник или нет? Сейчас опустились до инженера и это естественно.
100-150 лет назад инженер мог построить корабль, паровоз, мост или здание. В крайнем случае, пушку или пулемёт. К середине века инженеры сидели пачками за кульманами и вычерчивали адаптации шаблонных узлов. Сегодняшнему выпускнику можно доверить несложную технику чинить.
Индустрия требовала больше рук. Навык масштабировался и упрощался.
Аналогично, полвека назад программист писал язык программирования, операционку, сетевой протокол, систему управления ядерным реактором. Спустя 20-30 лет - толпы программистов кодили фрагменты больших систем. Сейчас самая частая работа - плагин или тему к вордпрессу подкрутить.
Тоже самое можно и про врачей рассказать.
Во всех случаях верхушка пирамиды никуда не делась, кто-то ещё не делает тот самый rocket science. но основание ее быстро разрослось в размерах и пошло вниз, к людям. Плюс, мощные инструменты и материалы, позволяют мастеровым делать задачи ранее доступные уровню мега-профи. Как в фантастике, где дети собирают звездолёт или телепортер. Только сегодня они собирают роботов. Или нейросети из фреймворков, а математическое образование уже не нужно.
Так что предмет спора очень иллюзорен. Все профессии проходят через масштабирование и упрощение.
Надо сказать, что уровень потихоньку опускается. Лет 10-12 назад споры шли на уровне программист это художник или нет? Сейчас опустились до инженера и это естественно.
100-150 лет назад инженер мог построить корабль, паровоз, мост или здание. В крайнем случае, пушку или пулемёт. К середине века инженеры сидели пачками за кульманами и вычерчивали адаптации шаблонных узлов. Сегодняшнему выпускнику можно доверить несложную технику чинить.
Индустрия требовала больше рук. Навык масштабировался и упрощался.
Аналогично, полвека назад программист писал язык программирования, операционку, сетевой протокол, систему управления ядерным реактором. Спустя 20-30 лет - толпы программистов кодили фрагменты больших систем. Сейчас самая частая работа - плагин или тему к вордпрессу подкрутить.
Тоже самое можно и про врачей рассказать.
Во всех случаях верхушка пирамиды никуда не делась, кто-то ещё не делает тот самый rocket science. но основание ее быстро разрослось в размерах и пошло вниз, к людям. Плюс, мощные инструменты и материалы, позволяют мастеровым делать задачи ранее доступные уровню мега-профи. Как в фантастике, где дети собирают звездолёт или телепортер. Только сегодня они собирают роботов. Или нейросети из фреймворков, а математическое образование уже не нужно.
Так что предмет спора очень иллюзорен. Все профессии проходят через масштабирование и упрощение.
Уже на примере нескольких компанию наблюдаю проблему «отстали, потому что опередили»
Вначале компания первой осознаёт необходимость каких-то инструментов или технологий или практик, когда на рынке ещё ничего нет. Затем делает сама и пользуется, опережая рынок.
Затем рынок соображает, делает сколько-то глупостей, но затем делает больше и лучше. Все переходят на мощные стандартизованные решения.
... А первый остаётся один на один со своим доморощенным легаси, с каждым часом отставая от индустрии
И что можно сделать?
1) не делать самому. В маленьких компаниях вполне разумна стратегия - не изобретать, подождать, все придёт
2) «я тебя породил, я тебя и убью». Ничто не вечно - лошадка отслужила свою службу, время фиксировать убытки и переходить на более современное решение
3) «так доставайся же ты ... всем». Чтобы не отстать от индустрии надо быть индустрией. Если подсадить всех на свой инструмент с самого начала, заопенсорсить его, то можно очень сильно продлить свою жизнь на нем. Это, конечно, вложения сил, но для больших контор оправдано.
Можно обойтись и малыми силами, но тут надо быть богом управления коммунити.
Вначале компания первой осознаёт необходимость каких-то инструментов или технологий или практик, когда на рынке ещё ничего нет. Затем делает сама и пользуется, опережая рынок.
Затем рынок соображает, делает сколько-то глупостей, но затем делает больше и лучше. Все переходят на мощные стандартизованные решения.
... А первый остаётся один на один со своим доморощенным легаси, с каждым часом отставая от индустрии
И что можно сделать?
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
Немного спойлеров:
- Фил Кулин рассказал про свой сбор статистики о блокировках и механизмах блокировок вообще. В частности, интересно узнать, что не все заблокированные решением суда сайты передаются хостерам для блокировки, что файл описания блокировок содержит некоторый объем испорченных записей (нереализуемая блокировка). Также файл все еще содержит ставшие свободными домены, так что можно продолжать их использовать для "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м проектом шла целый год
- 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м проектом шла целый год
VK
Andrey Rogozov
Мы представляем будущее интернета как безопасную площадку, где каждый может быть уверен в сохранности своих данных.
Одна из основных технологий, которая гарантирует безопасность данных — end-to-end шифрование, которое происходит на конечном устройстве пользователя.…
Одна из основных технологий, которая гарантирует безопасность данных — end-to-end шифрование, которое происходит на конечном устройстве пользователя.…
Для разнообразия обсудим другую тему. Есть устойчивый шаблон про "русские программисты - самые умные". С 2007го года я прилично поработал с программистами разных национальностей и не мог понять чем я или мои товарищи настолько сильно умнее иностранных коллег. Но понимание в итоге пришло
Дело в том, что возможно ни я, ни мои коллеги не должны были стать программистами. Многие из нас должны были стать врачами, учеными, кем угодно. Но после в 90х и после не так то много было высокооплачиваемой работы и мы все ушли в программирование. В 2001м моя наиминимальнейшая з/п в софтовой конторе уже была в два раза выше возможной альтернативы в "реальном секторе". Куча чуть более взрослых людей подалась в эмиграцию и один из самых лучших шансов устроиться для технически способного человека в эмиграции снова было IT - благо оно быстро росло и требовало все больше и больше кадров, так что войти можно было всегда и начать свой путь по лестнице вверх. Тоже самое случилось и в других бывших республиках, так что "русский программист" на практике может оказаться и украинцем, и белорусом и прибалтом.
К чему это привело? Именно в ИТ сконцентировались все те, у кого была светлая голова. В другой стране люди такого же уровня могли заниматься кучей другой возможной работы, но у нас IT было основной отдушиной. Наши коллеги из более богатых стран были куда более простыми ребятами, в массе своей университетов не заканчившие, олимпиад пачками не побеждавшие, не готовившиеся в физики/химики/математики с детства, чтобы ковать оборонный щит советской родины
Понятно, что это не делает каждого русского автоматически гением программирования. По мере знакомства с другими странами понимаешь что "ну тупые" это зубоскальство на радость толпе и не более того. Однако, статистически вероятность встретить более прокачанного программиста из числа русских и "русских" остается выше.
Вероятно, это в меньшей степени применимо к выпускникам 2010го года и позднее, когда для юного таланта было больше возможностей себя применить.
Как не обидно было бы это для кого-то, но "русские мега-хакеры" это не столько наши особенные гены, сколько эффект от сложившейся экономической ситуации.
Написано по мотивам моего ответа на Quora
https://www.quora.com/Are-Russian-software-developers-the-best-in-the-world/answer/Sergey-Lystsev
Дело в том, что возможно ни я, ни мои коллеги не должны были стать программистами. Многие из нас должны были стать врачами, учеными, кем угодно. Но после в 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) выигрыш от "взлома" метрики не оправдывает необходимых затрат на "взлом" (включая риск спалиться)
Приведу несколько примеров сверх классической копи-пасты в ответ на оценку по числу строк кода:
Начинаем оценивать разработчиков по числу фиксов - сразу возникает "спорт", кто первый заберет на себя самые простые проблемы и набьет ими наибольшее количество. Трудные проблемы брать никто не хочет.
Начинаем оценивать качество работы разработчиков по числу реопенов на фикс. Разработчики входят в сговор с тестировщиками о том, чтобы вместо реопенов заводился новый баг.
Начинаем оценивать качество работы тестировщиков по числу инвалидных и дубликатных багов. Тестировщики входят в сговор с разработчиками о том, чтобы вместо инвалидности и дубликатности разработчики ставили статус "автофикс" (проблема не повторяется, предположительно устранена одним из предшествующих исправлений)
Многим известно, что продавцы в компаниях работают за комиссию от суммы сделки и оттого часто заинтересованы подписать большую сделку с маленькой (или отрицательной) прибылью.
И так далее. Во всех случаях от простой метрики можно легко уйти.
В китае ввели социальный рейтинг по куче метрик - появилось устройство, которое симулирует, что ты много ходишь (и появилась скидка на мед.страховку). SEOшники постоянно пытаются хакнуть метрики поисковиков.
Сложность метрик можно проиллюстрировать таким примером. У вас наполнена водой ванна, но вода вытекает медленно, и чтобы она вытекала быстрее - вы стукаете рукой по воде (стимулируете метрикой). Какой итог? Только брызги. У воды есть куча вариантов куда ей пойти с меньшим трудом, чем заталкиваться в ту дырку. Как это решается в гидравлике? Ну конечно - делается цилиндр, поршень и в шприце, ваше усилие превращается строго в усиление оттока жидкости.
То есть переход к метрикам требует выстраивания подобной гидравлической системы, где все влево-вправо чем-то закрыты. Это в разы (если не в порядки) сложнее задачи просто начать что-то мерить.
В несколько более простом случае команд технической поддержки такая задача часто более-менее решается. Что им помогает? Более высокая однородность задач. Вопросы и проблемы пользователей на порядок или два однороднее, чем задачи в разработке, которые сильно различаются как между разными командами, так и внутри команд. Очень мало взаимодействий. Один человек решает одну проблему одного пользователя. Также очень помогает, что есть пользователь - он извне системы и пользователей в целом можно считать условно объективными (за счет статистики и большого объема).
Проще система - проще выстроить цепочку труб. Измеряется количество решенных обращений, скорость решения проблем и итоговая оценка пользователя. Хотя и там не все просто, требуется аппарта контроллеров качества и жесткие(!) кары за попытки обмана метрик (даже если формально человек прав). Я помню, что когда в поддержке только еще внедряли метрики - были случаи увольнения целыми командами на этой почве. А внешнюю (аутсорс) поддержку заставить нормально работать даже гора метрик до конца не могла - нужен очень большой аппарат контроля.
Таким образом, при попытках внедрения метрик важно понимать свою ситуацию, чтобы не оказаться обрызганным водой в ванной. Грубо говоря, важно отследить, что попытки оптимизации отдельных метрик в ущерб реальному результату будут минимизированы через
1) развитый детальный контролль за "взломами"
2) полноту набора метрик и их устойчивость к "взлому"
3) выигрыш от "взлома" метрики не оправдывает необходимых затрат на "взлом" (включая риск спалиться)
Очень сильно помогает согласованность метрик с реальным неманипулируемым критерием успеха - например как удовлетворенность пользователя в поддержке.
Рабочий консенсус в разработке может быть в измерении показателей команд или продуктов, но не отдельных людей. Это позволяет не уходить в выстраивание дорогого контроля за "взломом" метрик
Несогласные могут высказаться в чатике
https://t.me/joinchat/B-bfYQrvBssyBCf4D2YjhQ
Рабочий консенсус в разработке может быть в измерении показателей команд или продуктов, но не отдельных людей. Это позволяет не уходить в выстраивание дорогого контроля за "взломом" метрик
Несогласные могут высказаться в чатике
https://t.me/joinchat/B-bfYQrvBssyBCf4D2YjhQ
Возвращаясь к вопросу о метриках - на этот раз о продуктовых метриках. Можно иметь сотни графиков (и у нас есть), но они никого не сделают счастливым, если не дают простых ответов. А вопрос стоит только один - улучшило ли изменение продукт?
Что значит "улучшило"? Пойдем от обратного. Если мы сделали новую фичу и видим, что ей пользуются - стал ли продукт лучше? Вообще не факт. Мы видим только то, что фичей пользуются. Если в коридоре поставить дверь, то ее будут открывать и закрывать 100% пользователей, но стал ли коридор от этого лучше - мы не знаем.
"Лучше" определяется только через влияние на показатели продукта в целом. 1го порядка - выручка / аудитория / вовлеченность. 2го порядка - приток клиентов, текучка клиентов, средний чек, время жизни пользователя, удовлетворенность и тп. Можно строить 3й и более дальние порядки - нужно только в любой момент понимать, как дальняя метрика влияет обратно на более первичные. Чем чаще ходят в магазин - тем больше выручка, хорошо.
Соответственно, для построения метрики нужна гипотеза - что именно изменится и как. Но изменения тоже есть разных порядков. Скажем, у нас продукт и так растет на 1000 пользователей в месяц. Если мы что-то сделали и получили +1000 пользователей за месяц - то мы что-то улучшили? Нет, потому что это продолжение старой динамики. Значит надо смотреть на производную (в математическом смысле) - на ускорение прироста.
То есть, нужно выбрать метрику продукта в целом (1), понять ее текущий тренд(2) и предположить изменение следующего порядка (3). Для констант - абсолютный прирост. Для растущих показателей - ускорение роста. И т.д.
Это разумеется, касается, только задач развития продукта. Если они не могут ничего изменить, то никакого развития не происходит. Может быть это был неверный шаг, а может быть уже нет и потенциала для развития - уперлись в стену, такое тоже бывает
В отношении "долгов" решается задача удержания - то есть предотвращения риска, что какая-то метрика вдруг ухудшится. Но измерить это наверное никак нельзя, кроме булевского "проблема случилась" или "не случилась"
Что значит "улучшило"? Пойдем от обратного. Если мы сделали новую фичу и видим, что ей пользуются - стал ли продукт лучше? Вообще не факт. Мы видим только то, что фичей пользуются. Если в коридоре поставить дверь, то ее будут открывать и закрывать 100% пользователей, но стал ли коридор от этого лучше - мы не знаем.
"Лучше" определяется только через влияние на показатели продукта в целом. 1го порядка - выручка / аудитория / вовлеченность. 2го порядка - приток клиентов, текучка клиентов, средний чек, время жизни пользователя, удовлетворенность и тп. Можно строить 3й и более дальние порядки - нужно только в любой момент понимать, как дальняя метрика влияет обратно на более первичные. Чем чаще ходят в магазин - тем больше выручка, хорошо.
Соответственно, для построения метрики нужна гипотеза - что именно изменится и как. Но изменения тоже есть разных порядков. Скажем, у нас продукт и так растет на 1000 пользователей в месяц. Если мы что-то сделали и получили +1000 пользователей за месяц - то мы что-то улучшили? Нет, потому что это продолжение старой динамики. Значит надо смотреть на производную (в математическом смысле) - на ускорение прироста.
То есть, нужно выбрать метрику продукта в целом (1), понять ее текущий тренд(2) и предположить изменение следующего порядка (3). Для констант - абсолютный прирост. Для растущих показателей - ускорение роста. И т.д.
Это разумеется, касается, только задач развития продукта. Если они не могут ничего изменить, то никакого развития не происходит. Может быть это был неверный шаг, а может быть уже нет и потенциала для развития - уперлись в стену, такое тоже бывает
В отношении "долгов" решается задача удержания - то есть предотвращения риска, что какая-то метрика вдруг ухудшится. Но измерить это наверное никак нельзя, кроме булевского "проблема случилась" или "не случилась"
Рубцовая ткань. Что это такое? У нас один из партнеров написал скрипт, доводящий наш продукт “до ума” в недружелюбной для продукта среде. Видимо, в какой-то момент этот скрипт передавался от одного админа к другому и второй оставлял свои примечания, в основном в духе “WTF?!”. Там правда было очень много жутких и страшных извращенных приемов программирования. Но веселее всего то, что во многих местах продукт уже давно не требовалось допиливать скриптом, он давно уже научился сам нормально решать неприятные ситуации, а админ за админом продолжали поддерживать эту обвязку. Исправления в продукте вызывали поломку этой обвязки, и эти поломки чинились еще более жуткими обвязками, но все эти многие слои обвязок были НЕ НУЖНЫ, потому что в ее сердцевине уже давно не было проблемы. Это наиболее яркая иллюстрация того, что я называю РУБЦОВАЯ ТКАНЬ. Это код, это обходные решения, построенные из-за невозможности решить суть проблемы. Хуже всего, что со временем суть проблемы вообще забывается и эта рубцовая ткань может стать вполне самостоятельным “организмом”, высасывающим силы из команды. Рубцовая ткань это не всегда код. Это может быть процесс, или шаблоны поведения в команде. Сложившиеся когда-то давно под воздействием каких-то обстоятельств, которые уже могли давно пропасть, а рубец остался. Наилучшая иллюстрация это анекдот про “здесь так принято”
Клетка. В ней 5 обезьян. К потолку подвязана связка бананов. Под ними лестница.
Проголодавшись, одна из обезьян подошла к лестнице с явными намерениями достать банан. Как только она дотронулась до лестницы, вы открываете кран и из шланга поливаете ВСЕХ обезьян очень холодной водой. Проходит немного времени, и другая обезьяна пытается полакомитЬся бананом. Те же действия с вашей стороны. Третья обезьяна, одурев от голода, пытается достать банан, но остальные хватают ее, не желая холодного душа.
А теперь уберите одну обезьяну из клетки и замените ее новой обезьяной.
Она сразу же, заметив бананы, пытается их достать. К своему ужасу, она увидела злые морды остальных обезьян, атакующих ее.
После третьей попытки она поняла, что достать банан ей не удастся. Теперь уберите из клетки еще одну из первоначальных пяти обезьян и запустите туда новенькую. Как только она попыталась достать банан, все обезьяны дружно атаковали ее, причем та, которую заменили первой еще и с энтузиазмом.
И так, постепенно заменяя всех обезьян, вы придете к ситуации, когда в клетке окажутся 5 обезьян, которых водой вообще не поливали, но которые не позволят никому достать банан. Почему?
Потому что тут так принято... И в коде, и в поведении убирать рубцовую ткань очень сложно, потому что в первую очередь нужно понять, что она рубцовая. Ведь она живая, люди работают, шестеренки крутятся. Просто она грубая и не гибкая. Но убирать надо, для чего надо приучаться смотреть все время в корень проблем
Клетка. В ней 5 обезьян. К потолку подвязана связка бананов. Под ними лестница.
Проголодавшись, одна из обезьян подошла к лестнице с явными намерениями достать банан. Как только она дотронулась до лестницы, вы открываете кран и из шланга поливаете ВСЕХ обезьян очень холодной водой. Проходит немного времени, и другая обезьяна пытается полакомитЬся бананом. Те же действия с вашей стороны. Третья обезьяна, одурев от голода, пытается достать банан, но остальные хватают ее, не желая холодного душа.
А теперь уберите одну обезьяну из клетки и замените ее новой обезьяной.
Она сразу же, заметив бананы, пытается их достать. К своему ужасу, она увидела злые морды остальных обезьян, атакующих ее.
После третьей попытки она поняла, что достать банан ей не удастся. Теперь уберите из клетки еще одну из первоначальных пяти обезьян и запустите туда новенькую. Как только она попыталась достать банан, все обезьяны дружно атаковали ее, причем та, которую заменили первой еще и с энтузиазмом.
И так, постепенно заменяя всех обезьян, вы придете к ситуации, когда в клетке окажутся 5 обезьян, которых водой вообще не поливали, но которые не позволят никому достать банан. Почему?
Потому что тут так принято... И в коде, и в поведении убирать рубцовую ткань очень сложно, потому что в первую очередь нужно понять, что она рубцовая. Ведь она живая, люди работают, шестеренки крутятся. Просто она грубая и не гибкая. Но убирать надо, для чего надо приучаться смотреть все время в корень проблем
Сегодня напишу короткое про ПЛАНЫ. Нужни ли они и зачем?
Мало кто любит планы:
- во-первых, планы никогда не сбываются. Писал-писал, а вышло все по другому.
- во-вторых, классическая шутка про спросим у них оценку и выдадим ее за план - планы начинают восприниматься как commitment'ы и никто их делать, разумеется, не хочет
Казалось бы, план должен прибавлять ясности и уверенности, но первый пункт выше говорит, что это ложная ясность, а второй пункт говорит, что и уверенности тоже нет. Так что делать с планом?
Я думаю, надо изменить свое отношение к плану. Откройте навигатор в машине, он построит вам маршрут. Вы по нему поедете. Что дальше? А дальше - сюрприз! - маршрут меняется. Вы едете быстрее или медленнее, поворачиваете не туда, встречаете пробки или навигатор собирает данные о пробках из других источников и маршрут меняется. У вас в любую минуту есть план (маршрут) и он в любую минуту может быть новый.
Маршрут от этих изменений не стал хуже, не стал чем-то эфемерным и уж точно не стал менее нужным. Точно также надо быть с планами
Некоторые пишут "план МОЖЕТ меняться, но план ДОЛЖЕН быть" - уточним, что план и ДОЛЖЕН ПОСТОЯННО МЕНЯТЬСЯ, чтобы оставаться АКТУАЛЬНЫМ. Именно жесткий план это ложный и эфемерный план. А постоянно меняющийся план как раз очень реален (покуда мы едем в тоже самое место).
Я в таких безплановых ситуациях предлагаю начать с выписывания промежуточных целей в определенном порядке как этапов. Мы хотя бы начнем представлять, что мы будем делать после чего. Нам даже не нужны здесь сроки, хотя можно проставить желаемые сроки. А потом мы будем постоянно его менять, чтобы отражать сколько нам еще осталось до финальной цели
потребителю плана (мне в частности) надо отказаться от идеи трясти людей за соблюдение сроков каждого этапа (слишком много переменных), а только трясти
1) за соблюдение фокуса (мы едем именно туда, куда хотим, а не катаем левый груз)
2) за поддержание плана в актуальном виде (не живем в мире иллюзий)
Мало кто любит планы:
- во-первых, планы никогда не сбываются. Писал-писал, а вышло все по другому.
- во-вторых, классическая шутка про спросим у них оценку и выдадим ее за план - планы начинают восприниматься как commitment'ы и никто их делать, разумеется, не хочет
Казалось бы, план должен прибавлять ясности и уверенности, но первый пункт выше говорит, что это ложная ясность, а второй пункт говорит, что и уверенности тоже нет. Так что делать с планом?
Я думаю, надо изменить свое отношение к плану. Откройте навигатор в машине, он построит вам маршрут. Вы по нему поедете. Что дальше? А дальше - сюрприз! - маршрут меняется. Вы едете быстрее или медленнее, поворачиваете не туда, встречаете пробки или навигатор собирает данные о пробках из других источников и маршрут меняется. У вас в любую минуту есть план (маршрут) и он в любую минуту может быть новый.
Маршрут от этих изменений не стал хуже, не стал чем-то эфемерным и уж точно не стал менее нужным. Точно также надо быть с планами
Некоторые пишут "план МОЖЕТ меняться, но план ДОЛЖЕН быть" - уточним, что план и ДОЛЖЕН ПОСТОЯННО МЕНЯТЬСЯ, чтобы оставаться АКТУАЛЬНЫМ. Именно жесткий план это ложный и эфемерный план. А постоянно меняющийся план как раз очень реален (покуда мы едем в тоже самое место).
Я в таких безплановых ситуациях предлагаю начать с выписывания промежуточных целей в определенном порядке как этапов. Мы хотя бы начнем представлять, что мы будем делать после чего. Нам даже не нужны здесь сроки, хотя можно проставить желаемые сроки. А потом мы будем постоянно его менять, чтобы отражать сколько нам еще осталось до финальной цели
потребителю плана (мне в частности) надо отказаться от идеи трясти людей за соблюдение сроков каждого этапа (слишком много переменных), а только трясти
1) за соблюдение фокуса (мы едем именно туда, куда хотим, а не катаем левый груз)
2) за поддержание плана в актуальном виде (не живем в мире иллюзий)
Products | People | Process pinned «Чатик для дискуссий и несогласия https://t.me/joinchat/B-bfYQrvBssyBCf4D2YjhQ»
Новость дня. Hipchat - все. Slack выкупил его у Атлассиан и закроет.
Получается, что не всегда иметь в портфеле полный вертикальный стек решений - это путь к успеху. Через социальный фактор + открытые интеграции Слак смог объехать собственное интегрированное решение Атлассиан и сделать его бесперспективным. Походу Атлассиан дряхлеет и теряет хватку
https://techcrunch.com/2018/07/26/atlassians-hipchat-and-stride-to-be-discontinued-with-slack-buying-up-the-ip/
Получается, что не всегда иметь в портфеле полный вертикальный стек решений - это путь к успеху. Через социальный фактор + открытые интеграции Слак смог объехать собственное интегрированное решение Атлассиан и сделать его бесперспективным. Походу Атлассиан дряхлеет и теряет хватку
https://techcrunch.com/2018/07/26/atlassians-hipchat-and-stride-to-be-discontinued-with-slack-buying-up-the-ip/
TechCrunch
Atlassian’s HipChat and Stride to be discontinued, with Slack buying up the IP
HipChat, the workplace chat app that held the throne before Slack was Slack, is being discontinued. Also being discontinued is Atlassian’s own would-be HipChat replacement, Stride.
Предыдущий пост про сбер был по ошибке снесен. Если у кого-то сохранилось, то закиньте плз мне - верну в ленту
Итак, рукописи не горят, а вот сообщение в телеграм отлично удаляется по ошибке. Давно я ничего не писал, а теперь напишу два раза подряд одно и тоже.
С мест поступают множественные сообщения, что Сбербанк переводит своих сотрудников из СберТеха в непосредственно бизнес-подраздления. То есть если человек работал над автоматизацией бухгалтерии, то его начальником и будет главный бухгалтер? Хорошо это или плохо?
Очень давно стоит проблема - кто должен руководить человеком?
Тот, кому его работа больше все нужна (заказчик)?
Или тот, кто можем им правильно управлять в профессиональном плане (супервизор)?
Как эффективнее распределить людей?
Раздать по местам конкретной работы?
Или собрать в единый "кулак"?
Первыми, и больше прочих, с этой проблемой столкнулись военные. Раздать танки по отдельным частям или собрать в танковый корпус? Кому должна подчиняться авиация ПВО - ПВО как заказчику или ВВС как специалисту по авиации?
В какой-то момент корпорации пришли к консенсусу матричного управления. Каждый входит одновременно в две группы. Горизонтально - в отдел специалистов данного типа. Например - разработчики. Под командой "линейного менеджера". И вертикально - специалисты разного титпа входят в какой-то проект. Под командой "проектного менеджера". Более-менее хорошо работало для больших организаций и сейчас, как я понимаю, работает в аутсорсовых компаниях типа ЕПАМ или Люксофт.
В какой-то момент индустрия столкнулась с тем, что стало непонятно что надо делать дальше и ответила на этот вызов аджайлом. Вместо штабов, продумывающих планы на будущее, и огромных команд иерархично это исполняющих, появились множественные независимые микрокоманды, каждая отвеччающая за свое направление. Аджайл. Историй таких трансформаций и переходу к продуктовым командам очень много на конференциях. Фокус на командах привел к значительному перевесу вертикальной связи. Это компенсировали "гильдиями" - связью специалистов одного типа между командами.
Но при любой форме организации ИТ - обычно сам ИТ в организации оставался единым в силу своей особости.
Впервые про распил ИТ на части я услышал от Wildberries. У них была проблема донесения нужд бизнеса до ИТ, создать класс аналитиком/менеджеров для решения этих задач у них не вышло. Тогда они распределили инженеров по бизнес-отделам и возрадовались. Ценой этого было некоторое увеличение числа инженеров (потому что статическое распределение по задачам менее эффективно по ресурсам, чем динамическое) и некоторая утрата качества управления. Дело в том, что главный бухгалтер и остальные "обычные" бизнес-отделы слабо понимают ИТ-специфику со специфичным планированием и необходимостью как-то помнить про технический долг. Им надо здесь и сейчас. Лидер разработчиков может недолюбливать аналитиков/менеджеров за разногласия между их хотелками и своим перфекционизмом, за неточность и сумбурность передачи бизнес-трембований. Но без них легко обнаружить, что бизнес еще более безкомпромисен, чем аналитики, еще более игнорирует технический долг и прочие неосязаемые понятия, еще более противоречив и сумбурен. То есть искажения от слоя аналитиков/менеджеров пропадают, но пропадает и привносимое ими сглаживание. Вертикальная связь заказчик-исполнитель становится короткая и жесткая. А горизонтальная связь исполнителей между собой сильно размывается, может даже стать совсем неформальной.
Именно это сейчас происходит со СберБанком. Само по себе это не хорошо и не плохо - это как два типа подвески, мягкая и жесткая. Но на жесткой подвеске по неровной дороге кататься будет некомфортно.
С мест поступают множественные сообщения, что Сбербанк переводит своих сотрудников из СберТеха в непосредственно бизнес-подраздления. То есть если человек работал над автоматизацией бухгалтерии, то его начальником и будет главный бухгалтер? Хорошо это или плохо?
Очень давно стоит проблема - кто должен руководить человеком?
Тот, кому его работа больше все нужна (заказчик)?
Или тот, кто можем им правильно управлять в профессиональном плане (супервизор)?
Как эффективнее распределить людей?
Раздать по местам конкретной работы?
Или собрать в единый "кулак"?
Первыми, и больше прочих, с этой проблемой столкнулись военные. Раздать танки по отдельным частям или собрать в танковый корпус? Кому должна подчиняться авиация ПВО - ПВО как заказчику или ВВС как специалисту по авиации?
В какой-то момент корпорации пришли к консенсусу матричного управления. Каждый входит одновременно в две группы. Горизонтально - в отдел специалистов данного типа. Например - разработчики. Под командой "линейного менеджера". И вертикально - специалисты разного титпа входят в какой-то проект. Под командой "проектного менеджера". Более-менее хорошо работало для больших организаций и сейчас, как я понимаю, работает в аутсорсовых компаниях типа ЕПАМ или Люксофт.
В какой-то момент индустрия столкнулась с тем, что стало непонятно что надо делать дальше и ответила на этот вызов аджайлом. Вместо штабов, продумывающих планы на будущее, и огромных команд иерархично это исполняющих, появились множественные независимые микрокоманды, каждая отвеччающая за свое направление. Аджайл. Историй таких трансформаций и переходу к продуктовым командам очень много на конференциях. Фокус на командах привел к значительному перевесу вертикальной связи. Это компенсировали "гильдиями" - связью специалистов одного типа между командами.
Но при любой форме организации ИТ - обычно сам ИТ в организации оставался единым в силу своей особости.
Впервые про распил ИТ на части я услышал от Wildberries. У них была проблема донесения нужд бизнеса до ИТ, создать класс аналитиком/менеджеров для решения этих задач у них не вышло. Тогда они распределили инженеров по бизнес-отделам и возрадовались. Ценой этого было некоторое увеличение числа инженеров (потому что статическое распределение по задачам менее эффективно по ресурсам, чем динамическое) и некоторая утрата качества управления. Дело в том, что главный бухгалтер и остальные "обычные" бизнес-отделы слабо понимают ИТ-специфику со специфичным планированием и необходимостью как-то помнить про технический долг. Им надо здесь и сейчас. Лидер разработчиков может недолюбливать аналитиков/менеджеров за разногласия между их хотелками и своим перфекционизмом, за неточность и сумбурность передачи бизнес-трембований. Но без них легко обнаружить, что бизнес еще более безкомпромисен, чем аналитики, еще более игнорирует технический долг и прочие неосязаемые понятия, еще более противоречив и сумбурен. То есть искажения от слоя аналитиков/менеджеров пропадают, но пропадает и привносимое ими сглаживание. Вертикальная связь заказчик-исполнитель становится короткая и жесткая. А горизонтальная связь исполнителей между собой сильно размывается, может даже стать совсем неформальной.
Именно это сейчас происходит со СберБанком. Само по себе это не хорошо и не плохо - это как два типа подвески, мягкая и жесткая. Но на жесткой подвеске по неровной дороге кататься будет некомфортно.
Про инновации
Я последнее время на собеседованиях встречал много людей, который беспокоил застой в их компаниях, тогда как эти компании декларируют на публику высочайшую инновационность. У меня самого был такой период в работе, когда контора декларировала агрессивную гонку за инновациями, но при этом оказалось, что за период «гонки» мы прилично отстали в ряде областей. Как так могло получиться?
Дело в том, что есть два встречных процесса. «Изменения сверху» и «изменения снизу». Сверху видна какая-то глобальная картина и в ответ на неё запускаются какие-то действия. Снизу видные конкретные проблемы и на них тоже идёт ответ. Оба процесса нужны.
Но что если у нас классическая top down контора с агрессивными целями? Все для фронта, все для победы. Значит, вся деятельность подчинена этим целям. Значит, все, что не ради их достижения - это плохо. Отсюда последствие первого порядка - это нетерпимость к ошибкам. ошибка это потеря. А если нельзя ошибаться, то резко сокращается пространство для экспериментов. На запланированные эксперименты воля ещё остаётся. «Верхи» могут агрессивно инвестировать в какой-то запланированный сверху экспериментальный проект . А вот сумбурный эксперимент снизу, «на попробовать» пропадает. Всякая гипотеза может дать два ответа, но в этой среде ответ «не получилось» уже не приемлем. «Не получилось» будет понят как «плохо старался». Поэтому лучше не рисковать. Снижение числа таких сумбурных экспериментов неизбежно отсекает какие-то потенциально выгодные пути, поскольку не распробовав не оценишь
Из «плохо старался» происходит последствие второго порядка - неприятие возражений. Кто-то «сверху» уже подписался под будущим результатом и не готов признавать, что получилось не очень. Люди осознанно применяют заведомо неэффективный инструмент. «Низы» все понимают. «Середина» тоже. Но наверх шлются победные сводки, иначе «подстава», которую не простят. Общая эффективность операций ползёт вниз
Из принятия плохого за хорошее идёт последствие третьего порядка - двоемыслие. Все всё понимают, но говорить вслух нельзя. Между собой ещё можно, но официально - нет. Только иногда. Кому-то. В подходящем контексте. Например, подготовить практически спектакль с гипер-наглядной демонстрацией проблем на встрече, проходящей раз в год - чтобы показать непригодность одного такого проекта. Это требует таких значительных вложений, что в системе проходят только небольшое число сверхсильных сигналов. Это как голова, которая слепа и глуха ко всему извне и только живет в мире собственных идей.
Эти идеи могут быть очень инновационными, но ход их реализации уже таким не будет.
Как мы сами пытаемся вырваться из этой ловушки, когда гонка за «инновацией сверху» убивает «инновацию снизу» (что потом убьёт и «инновацию сверху» тоже)?
Не факт, что этого достаточно, но
- Выделяем время на эксперименты «просто так». Иногда технологию надо пробовать, даже если на неё нет бизнес-потребности. Потому что технология может внезапно создать бизнес-возможности, который заранее видны не были.
- Выделяем время на тех.долг. Мы чистим зубы каждое утро не дожидаясь кариеса. Так и здесь не надо ждать, когда этот долг начнёт стрелять на уровне бизнеса.
- Стараемся внимательно слушать, если люди говорят, что есть проблема
- Ещё не регулярно, но уже часто спрашиваем, есть ли проблемы, которые почему-то не решаются
Я последнее время на собеседованиях встречал много людей, который беспокоил застой в их компаниях, тогда как эти компании декларируют на публику высочайшую инновационность. У меня самого был такой период в работе, когда контора декларировала агрессивную гонку за инновациями, но при этом оказалось, что за период «гонки» мы прилично отстали в ряде областей. Как так могло получиться?
Дело в том, что есть два встречных процесса. «Изменения сверху» и «изменения снизу». Сверху видна какая-то глобальная картина и в ответ на неё запускаются какие-то действия. Снизу видные конкретные проблемы и на них тоже идёт ответ. Оба процесса нужны.
Но что если у нас классическая top down контора с агрессивными целями? Все для фронта, все для победы. Значит, вся деятельность подчинена этим целям. Значит, все, что не ради их достижения - это плохо. Отсюда последствие первого порядка - это нетерпимость к ошибкам. ошибка это потеря. А если нельзя ошибаться, то резко сокращается пространство для экспериментов. На запланированные эксперименты воля ещё остаётся. «Верхи» могут агрессивно инвестировать в какой-то запланированный сверху экспериментальный проект . А вот сумбурный эксперимент снизу, «на попробовать» пропадает. Всякая гипотеза может дать два ответа, но в этой среде ответ «не получилось» уже не приемлем. «Не получилось» будет понят как «плохо старался». Поэтому лучше не рисковать. Снижение числа таких сумбурных экспериментов неизбежно отсекает какие-то потенциально выгодные пути, поскольку не распробовав не оценишь
Из «плохо старался» происходит последствие второго порядка - неприятие возражений. Кто-то «сверху» уже подписался под будущим результатом и не готов признавать, что получилось не очень. Люди осознанно применяют заведомо неэффективный инструмент. «Низы» все понимают. «Середина» тоже. Но наверх шлются победные сводки, иначе «подстава», которую не простят. Общая эффективность операций ползёт вниз
Из принятия плохого за хорошее идёт последствие третьего порядка - двоемыслие. Все всё понимают, но говорить вслух нельзя. Между собой ещё можно, но официально - нет. Только иногда. Кому-то. В подходящем контексте. Например, подготовить практически спектакль с гипер-наглядной демонстрацией проблем на встрече, проходящей раз в год - чтобы показать непригодность одного такого проекта. Это требует таких значительных вложений, что в системе проходят только небольшое число сверхсильных сигналов. Это как голова, которая слепа и глуха ко всему извне и только живет в мире собственных идей.
Эти идеи могут быть очень инновационными, но ход их реализации уже таким не будет.
Как мы сами пытаемся вырваться из этой ловушки, когда гонка за «инновацией сверху» убивает «инновацию снизу» (что потом убьёт и «инновацию сверху» тоже)?
Не факт, что этого достаточно, но
- Выделяем время на эксперименты «просто так». Иногда технологию надо пробовать, даже если на неё нет бизнес-потребности. Потому что технология может внезапно создать бизнес-возможности, который заранее видны не были.
- Выделяем время на тех.долг. Мы чистим зубы каждое утро не дожидаясь кариеса. Так и здесь не надо ждать, когда этот долг начнёт стрелять на уровне бизнеса.
- Стараемся внимательно слушать, если люди говорят, что есть проблема
- Ещё не регулярно, но уже часто спрашиваем, есть ли проблемы, которые почему-то не решаются
Про японское “да”
В учебнике японского языка отмечено, что японское «да» («хай») отражает не столько согласие с вашими словами, сколько то, что собеседник вас слышит и признает ваше право на высказанное мнение
Но и в русском языке есть «японское да» и с ним надо быть осторожным. Вот вы увлечённый человек и что-то пытаетесь донести собеседнику, а он кивает и поддакивает. Вы выходите с убеждением, что собеседник вас понимает, поддерживает и мысль оценил положительно. А потом - сюрприз! - он делает что-то прямо поперёк.
Где с этим можно столкнуться?
Наивный продакт менеджер рассказывает идею клиенту, а тот поддакивает. «Клиентам наша фича нравится!» делается вывод, а они не покупают потом.
Руководитель команды доносит до сотрудника его оценку и перспективы, тот кивает. Руководитель полагает, что есть взаимопонимание, а потом сотрудник уходит - он себя оценивал иначе и перспективы видел и искал другие.
В продажах или bizdev у меня нет личного опыта, но со стороны наблюдателя проблема выглядит так же. Очень легко принять свою убежденность за свою убедительность.
Что можно сделать?
Самое простое упражнение на проверку понимания и взаимопонимания - это когда говорит второй собеседник.
Например, в отношениях с пользователями custdev учит спрашивать об объеме вложений в решение этой проблемы текущими средствами - это выводит вопрос из гипотетической плоскости. Если люди что-то пытаются сделать с проблемой, то этим практически подтверждают интерес.
В отношении сотрудников ситуация осложняется тем, что проблема не очевидна. Про неё ещё не так много говорят, как про пользователей. Поэтому первый шаг - это проблему показать. Мы делали специальный анонимный опрос на всех сотрудников и это показало, сколько человек на самом деле оценивают ситуацию не так, как полагал их лидер. После этого лидеры команд постепенно научатся больше слушать и прислушиваться.
У Sales есть в частности практика уточнять KPI покупателя в организации, чтобы понимать, что предлагаемое решение действительно выгодно для покупателя. Если нет выгоды, то нет и реального интереса. bizdev это почти как sales в этом смысле.
Вобщем, переспрашивайте.
В учебнике японского языка отмечено, что японское «да» («хай») отражает не столько согласие с вашими словами, сколько то, что собеседник вас слышит и признает ваше право на высказанное мнение
Но и в русском языке есть «японское да» и с ним надо быть осторожным. Вот вы увлечённый человек и что-то пытаетесь донести собеседнику, а он кивает и поддакивает. Вы выходите с убеждением, что собеседник вас понимает, поддерживает и мысль оценил положительно. А потом - сюрприз! - он делает что-то прямо поперёк.
Где с этим можно столкнуться?
Наивный продакт менеджер рассказывает идею клиенту, а тот поддакивает. «Клиентам наша фича нравится!» делается вывод, а они не покупают потом.
Руководитель команды доносит до сотрудника его оценку и перспективы, тот кивает. Руководитель полагает, что есть взаимопонимание, а потом сотрудник уходит - он себя оценивал иначе и перспективы видел и искал другие.
В продажах или bizdev у меня нет личного опыта, но со стороны наблюдателя проблема выглядит так же. Очень легко принять свою убежденность за свою убедительность.
Что можно сделать?
Самое простое упражнение на проверку понимания и взаимопонимания - это когда говорит второй собеседник.
Например, в отношениях с пользователями custdev учит спрашивать об объеме вложений в решение этой проблемы текущими средствами - это выводит вопрос из гипотетической плоскости. Если люди что-то пытаются сделать с проблемой, то этим практически подтверждают интерес.
В отношении сотрудников ситуация осложняется тем, что проблема не очевидна. Про неё ещё не так много говорят, как про пользователей. Поэтому первый шаг - это проблему показать. Мы делали специальный анонимный опрос на всех сотрудников и это показало, сколько человек на самом деле оценивают ситуацию не так, как полагал их лидер. После этого лидеры команд постепенно научатся больше слушать и прислушиваться.
У Sales есть в частности практика уточнять KPI покупателя в организации, чтобы понимать, что предлагаемое решение действительно выгодно для покупателя. Если нет выгоды, то нет и реального интереса. bizdev это почти как sales в этом смысле.
Вобщем, переспрашивайте.