Size: a a a

noTieinIT - Об IT без галстуков

2020 April 16
noTieinIT - Об IT без галстуков
​​👋 Новый прогноз по рынку IT в кризис для DOU!

Прошлый мой прогноз для DOU в декабре был самым пессимистичным из всех, но получил самую большую поддержку аудитории. Начал сбываться он через 2 месяца. С момента того прогноза я уже видел нападки аутсорса и аутстафа на меня, в публикации на liga\.net с элементами присущими у проплаченых постов, с коверканьем моих слов. Но было забавно наблюдать, как топ менеджеры украинских галер с пеной у рта пытались доказать обратное.

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

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

Приятного прочтения - https://dou.ua/lenta/articles/corona-and-technology/

P.S. А, ну и когда давал своему семейному эксперту, жене по совместительству, на вычитку материал, то она, как практикующий психолог, решила помочь и сделать бесплатную консультацию. Запись в ее телеге. Если на работе обострились проблемы, в семейных отношениях стало больше конфликтов и просто рвет крышу от сидения дома, то она готова помочь. Промокод для фри помощи и от меня, с указанием промокода NoTieInIT. Берегите свое психическое здоровье!
источник
2020 April 18
noTieinIT - Об IT без галстуков
🧠 Я много читаю отзывов людей, которые не понимают что делает бизнес в кризисные моменты. Давайте стирать эту грань. Сегодня тема - "демпинг зарплат".

Давайте сразу по хардкору. На linkedin был пост, привожу цитаты:

"Намеренный демпинг зарплат. И ни разу мне не отказывали из-за величины моих зарплатных ожиданий. Сейчас я ищу работу, и свою зп оставил прежнюю. Но что я вижу? В большинсте случаев мне приходят отказы как раз из-за зп.
Многоуважаемые работодатели (не hr, они только исполнители). Неужели вы думаете, что намеренно демпингуя зп гребцов, вы на этом секономите? Или вы думаете что рано или поздно найдёте полностью отчаиного бедолагу, который будет готов работать за 500уе имея при этом 8-ь лет опыта?"

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

Стоимость на рынке специалиста широкого профиля зависит только от спроса и предложения. Приведу пример из жизни. Допустим хотим купить картоху или гречу, таких как мы несколько миллионов человек. Когда продавцов единицы и картохи на всех не хватит, то продавцы начинают поднимать цены. Поднимают они до того момента, пока из-за роста цены желающих станет меньше и баланс между желающими купить по цене выше не сравняется с количеством картохи. Работает и обратное - если продавцов много и желающих меньше чем товара, то цена падает до равновесного состояния.

В случае с рынком труда ситуация похожа. Если до начала кризиса было много инвесторских денег и более расточительно относились к тратам и нанимали с теми ставками, которые диктовали кандидаты, то теперь начали экономить, наймы заморозили и вакансий стало меньше на 50%, а количество резюме выросло. Потому, когда много потенциальных кандидатов на рынке труда, то конкуренция усиливается и ставки идут вниз. Это будет продолжаться пока не восстановится рост экономик и снова не начнется активный рост. Но практика USA после 2008 года показывает, что затянуться рост может на годы. В той же USA, после 2008 года потребовалось 7 лет чтобы выйти на тот же уровень безработицы, который был до начала кризиса.

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

Как полезность считать сотрудника? Чем больше может прибыли принести сотрудник для компании, тем более он востребован. Если проект еще не запущен, то он несет только убытки, а прибыли не генерируют. Что делать предпринимателю? Сворачивать финансирование проекта.

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

Резюмируя. Да, компании расходы сокращают и ставки идут (и будут дальше идти) вниз. Демпинг это? Нет. Почему-то никто не кричал среди соискателей, когда было 5 лет подряд роста ставок, что среди соискателей картельный сговор? Я не тот, ни другой термин не считаю применимым к ситуации, но суть уловили.

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

Смотрите за ситуацией на рынке. Следите за статистикой, а я помогу в донесении информации до вас. @noTieInIT.
источник
2020 April 21
noTieinIT - Об IT без галстуков
​​😷 Как не общаться с работодателем.

Делюсь инфой прямо с полей. Должно было быть собеседование с кандидатом на позицию Senior Software Engineer. Кандидат уже проходил собеседование с TL и Project Manager, но решил и я поговорить + наш технический PO/PM/человек ансамбль. Фидбеки по техничке были не самые плохие, а у нас отбор хороший и берем инженеров хороших и тех кто готов оттачивать навык инженера, а не смузихлеба на гироскутере.

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

“Здравствуйте!К сожалению, вчера не смог найти чат, чтобы предупредить что я уже принял оффер от другой компании”.

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

Но я всегда пытаюсь сейвить и раз принял, ну ладно, невзирая на подход кандидата, давай хоть поговорим, раз назначено было. Может компания карапнется от кризиса и будет уже работодатель, что готов общаться. Разогретый работодатель. Плюс лучше узнать человека не лишнее, понаблюдать за ним, если толковый, то и в нужный момент появится рядом и сразить наповал, забрав на проект. Короче, предлагаю ему созвон таки провести. Обозначил, что мы не давим на его решение и не будем уламывать, просто давай поговорим. Ответ…

“Я сейчас за рулём, про компанию напишу через пару часов , как приеду домой
я понимаю, сейчас не могу общаться “

Это вообще перебор полный. Он не то что не знал как сказать, ему просто по%&ер на те слова что он давал. На минуточку, кол с топ менеджером (не, я не о том, что у меня ЧСВ раздуто), просто недальновидно так поступать, ибо у меня коллеги из индустрии спрашивают фидбеки про людей, а у него в CV достаточно инфы, чтобы читатели этого CV приняли решение вылезти ко мне.

Единственный позитив, что на раннем этапе узнали нутро и не выяснили это после прохождения испыталки.

Итого, антипример привел, давайте советы:
👌Если вы даже принимаете другой офер, либо решаете стопнуть продвижение, то предупредите рекрутера. Респект будет от ребят, если честно сказать и открыто. Лучше горькая правда, чем балабольство.
👌Уважайте время других людей.
👌Отвечайте за слова и поступки.
👌Хоть приличия ради стоит извиниться за ошибки, а не как кандидат выше, что себя Трампом возомнил.

Этика поведения крайне важна. С мудаками работать никто не хочет. В довесок обложку книги тематической приведу, может кто прочтет. А в следующей публикации контрпример хорошей коммуникации приведу, тоже сегодня случилось. Мир вам!
источник
2020 April 22
noTieinIT - Об IT без галстуков
​​👻 Как известно, Google и другие топовые компании мира, такие как: Linkedin, Twitter, Netflix, BMW, Samsung, UBER, Amazon используют метод постановки целей и достижения желаемых результатов — OKR. Сундар Пичаи, CEO Google, даже заявил, что благодаря OKR Google стал той компанией которую мы знаем (нет, это не про империю зла, как уже могли подумать).

Наблюдая за чужим опытом, я начал изучать что такое OKR и как же он помогает. Пару месяцев, читал книги, статьи, собирал чужой опыт по крупицам, общался со знакомыми кто использовал эту методологию. Ну какой я задрот к деталям и качеству вы и так знаете. В конце 2019 я инициировал переход в Aurora Technologies на OKR. После полной пропитки идеей и подходом себя самого, была стадия продажи этого решения другим участникам бордпака. После продажи идеологии, наступил черед формализации и донесения до всех команд и людей информации об этом инструменте. И мы запустились.

Пережили уже 2 этапа планирования и успели поменять некоторые подходы. Проблем с внедрением OKR оказалось немало. Они всплывают и спустя 5 месяцев, а потом от нашего HRD узнал, что ее предыдущая компания адаптировалась почти год к OKR. Кста, минутка рекламы, канал нашего HRD, вот он, на украинском, авторский. Но так как мы знакомы и с CTO этой компании, то с ним я начал обсуждать с чем же они столкнулись.

Слов за слово… и мы уже придумали записать видео с 4 компаниями, которые живут и работают по OKR и имеют разный размер, разную структуру, культуру. Но всем им, в том или ином виде, OKR помогают быть успешными. А потом начались грабли с поставкой техники для записи, затем карантин… Несерьезно пообещать и не сделать, потому мы решили сделать стрим на эту тему!

Встречайте, стрим #2.
🔥 OKR. Опыт внедрения системы целеполагания в компаниях.

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

Наш звездный состав:
— Алексей Солнцев (CTO, Kasta, ранее известная как ModnaKasta)
— Дмитрий Гринь (CTO, Jooble)
— Евгений Пилянкевич (CEO & CTO, Cossack Labs)
— Дмитрий Меньшиков (кто бы это мог быть? 😄)

Стрим будет бесплатный и интерактивный. Вопросы уже сейчас можно и нужно задать https://app.sli.do/event/qpkn7ib3/live/questions. Вопросы во время стрима чуть ниже имеют приоритет, потому прошу задать в sli.do, а на стриме уточнения. Нам нужно подумать тоже.

Что можно вынести из ивента?
● Ознакомитесь с кейсами от 4-х разных компаний
● Поймете как работает система OKR на практике
● Сможете использовать методологию OKR для себя, команды и для достижения целей компании
● Узнаете заранее о возможных нюансах, сможете учесть все подводные камни, избежать факапов
● Получите от внедрения системе OKR только преимущества (быстрый рост, достижение результатов, синхронизация задач,мотивация команды)

Для кого будет полезно?
Для руководителей, топ-менеджеров, собственников компаний, для HR менеджеров, HR директоров, тимлидов, руководителей направлений и департаментов, для всех людей, которые стремятся увеличить свою эффективность и добиваться целей!

🎥 Ссылка на стрим (жмите кнопку “Напомнить” чтобы не пропустить): https://youtu.be/NuwPzwM5tnw
🍸Чтобы не забыть, сделали и ивент в фейсбуке, чтоб напоминал:
🚀 Если вы не знаете что такое OKR, то я выложил запись и текст. В том же виде, как давал это в Авроре. Я убрал всю воду, консолидировал чужой опыт. Теперь делюсь бесплатно во имя науки!
http://dmenshikov.com/2020-04-21-okr-goal-setting-system/

Друзья, делитесь каналом с друзьями, контент все круче и круче, а органика как-то запнулась. Ничто не мотивирует так двигаться вперед, как ваша поддержка и понимание того, что это приносит пользу.
источник
2020 May 29
noTieinIT - Об IT без галстуков
​​🍸 Продолжение трансформации в компании. От OKR к кросс-функциональности. Часть 1.

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

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

В компании была структура где присутствовали сервисные команды. Это когда есть отдельно backend, отдельно frontend, отдельно qa, аналитики… все отдельно. Когда product manager придумывал новую задачу, то она проходила технические команды и оценивался их эстимейт.  Замечу, что несколько команд проводили оценку. Вот прошло от нескольких дней до нескольких недель, оценка составлена и принимается решение какие задачи делать. Конечно, на базе эстимейта, ведь мы хотим делать те задачи, которые менее затратны и дают наибольший возможный результат.

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

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

P.S. Друзья, если вам нравится контент, то делитесь им, делитесь каналом. Это очень поддерживает и стимулирует меньше спать и больше думать и писать. Я почти год на одном и том же уровне по количеству подписчиков. Чет тут не чисто)
источник
2020 June 04
noTieinIT - Об IT без галстуков
​​🍸 Продолжение трансформации в компании. От OKR к кросс-функциональности. Часть 2.

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

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

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

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

Посчитаем на пальцах. Продакт менеджер проводит встречи с 3 командами, дабы донести свою идею. Тратит на это N часов, включая фоллоу-апы. Если он по-отдельности проводит митинги, то потратит 3*N часов своего времени и суммарно 3*N часов тимлидов. Можно оптимизировать до одного митинга, и тогда затраты всех участников составят 4*N часов. Затем тимлид тратит время на обдумывание, может поэкспериментировать, расписывает эту задачу и доносит до конечного исполнителя. Это еще затраты на коммуникацию с конечным исполнителем. Конечно же, включается испорченный телефон и исполнитель получает не цель продакт менеджера, интерпретацию этой цели из уст тимлида, может цель вообще видоизменится и тимлид свою цель озвучит. Порой возникают трудности и выполнить желаемое не получается. Маховик начинает вращаться в обратную сторону: проходят снова митинги, выяснения что делать и согласования. Если медиатором служит тимлид, то происходит тройная трата ресурса (конечный исполнитель-тимлид, тимлид-менеджер, тимлид-исполнитель). Если еще и переписать после этого задачу придется, то это снова повторные согласования и все по кругу. Ах да, все же заняты, митинги с уточнениями происходят когда у всех есть время. Это смещает срок до получения результата, как уже писал в прошлом посте.

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

Что еще не так и есть ли выход? Об этом далее… @noTieInIT
источник
2020 June 10
noTieinIT - Об IT без галстуков
Вчера в Linkedin постучался психотерапевт, гештальт-психолог и все такое…

Я удивился даже, ведь обычно рекрутеры мне позиции python девелоперов предлагают, реже CEO/COO/CTO, но психолог - это что-то новое. Ну и только сегодня я выяснил, что причина такого интереса - это мое небольшое интервью для друзей, что вышло на этой неделе.

Пошарю его и здесь. Краткие тезисы:
- Что я думаю про 18-и летних синиоров (о господи, были же 23-летние, куда мир катится);
- О том как надо пахать;
- Что такое лидинг и как я менеджерил детей в садике (выпилили историю про то, как менеджерил летом детей колорадских жуков на огороде собирать, жаль);
- Про непопулярные решения;
- Почему топы получают больше;
- Где учится на СТО (нигде).

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

https://www.itblabber.com/post/kak-stat-cto-v-25-let
источник
2020 June 16
noTieinIT - Об IT без галстуков
​​🎥 Новое видео. Грабеж банками с двойной конвертацией валюты полученной ФОП.

Я ранее писал на канале кусочек этой истории. Вся история в деталях в видео сегодня. Все ФОП работающие с ВЭД и получающие валюту на счёт вынуждены продавать ее банку, а полученную гривну переводить на счёт физика и покупать валюту снова.

На такой операции теряется по 35-50  копеек для доллара и евро, а банк оставляет себе 1.5-2% средств на таком двойном обмене.

Один из подписчиков спросил в комментариях про возможность прямого вывода валюты на свой счёт за рубежом... для ФОП 3 группы на единой налоге. Я связался о свифт департаментом Привата дабы проверить этот флоу и получил зелёный свет.

Но что из этого вышло? Смотрите в видео!

https://youtu.be/xc-6D3_h4Pk
источник
noTieinIT - Об IT без галстуков
Выше видео актуально для предпринимателей из Украины. Честно говоря, ошибся каналом и не туда поставил публикацию)

Так что, дорогие мои читатели не из Украины, простите за нецелевое для вас контент. Порадую вас завтра продолжением истории про трансформацию компании.

Ждите!
источник
2020 June 19
noTieinIT - Об IT без галстуков
​​🍷 Продолжение трансформации в компании. От OKR к кросс-функциональности. Часть 3.

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

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

Когда люди считают этот простой, то возникает логичное желание "оптимизировать" загрузку и не допустить простоя каждого отдельно взятого человека. Как? Сделать сервисные команды и аутсорсить к ним задачи. Можно масштабировать количество людей в сервисных командах. Если нужно в команде всего 2 человека и они справляются, то ок, пусть будет 2, а если другая команда не справляется с 10 чел, то нужно взять еще парочку.

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

Экономия может достигать 30%. Но как отмечал уже ранее, для стартапов и продуктов, которые ищут свои ниши, стоит концентрироваться не на экономии ресурсов, а на быстрой проверке гипотез и поиска того самого грааля ниши.

Еще бонусы - это bus factor ниже, т.е. взаимозаменяемость выше. TL меньше переживает, если Иннокентий в саббатикал уедет в Тайланд на год, если у него в сервисной команде еще останется 9 удальцов переднего конца frontend разработчиков.

Контролировать и развивать проще... Особенно для control freaks. Кстати, я и сам контрол фрик и прям делал над собой усилия, чтобы отпускать ситуацию. С сервисными командами появляется больше контроля, больше формализации, больше минералов.

Но пропадает одно - концентрация на общей цели...
@noTieInIT
источник
2020 September 16
noTieinIT - Об IT без галстуков
​​♿️ Итоги трех кварталов с OKR

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

🔻 Наличие старых долгов. Когда люди ставят перед собой цели, чего ранее не делали, то забывают про большой пласт незавершенных задач и текучки. Она никуда не девается и над ней продолжают работать дабы добить уже и переключится на цели из OKR. Теоретически было понятно, что так и будет, должно было занять квартал, но затянулось на более долгий срок.
🔻 Работа над предыдущими OKR. После Q1 невыполненные цели частично были перенесены в Q2, частично выпали вообще. Но как и в предыдущем пункте, работы не были остановлены и шлейф тянулся дальше. Не допускайте ошибку! Если цели важны и не доделаны, не ставьте новые пока не завершите старые. Потому переносите все, а если не желаете переносить, то отказывайтесь от любой дальнейшей работы в этом направлении.
🔻 Формулировка целей. Людям нужно давать учиться на ошибках. При теоретической проработке, которую я вынес в статью, было понятно, что цели должны быть конкретными. Команды экспериментировали с целями и часто включали цели вида "увеличить что-то на X%". Данные цели плохи тем, что отсутствует хоть какой-то намек на стратегию по достижению этого увеличения на X%. Цели должны быть понятны, например, сделать A и B. Задача менеджеров и состоит в формирование набора таких целей A и B, которые позволят достигать увеличения желаемого показателя.
🔻 Нарушение правила 3-5 секунд для проверки прогресса целей и ключевых результатов. Забавная была ситуация, когда для одной из целей потребовалось создавать отчет по которому нужно было трекать продвижение. Сам отчет создавался уже в квартале с этой целью, что заблокировало чуть ли не половину квартала трекинг продвижения. Трекинга нет, потому нет возможности следить за выполнением, потому эффективность падает или вовсе не делаются задачи для достижения этой цели. Не мудрите, делайте проще.

Еще была идеологическая реорганизация. Что из этого вышло скоро напишу! Stay tuned.

P.S. Если кто пропустил, то ранее были публикации про фундаментальные факторы сервисных команд, факторы кросс-функциональных команд и сравнение этих подходов между собой.
источник
2020 September 28
noTieinIT - Об IT без галстуков
​​🔰Один из важнейших советов при работе по OKR: нужно создавать рабочие стратегические группы!

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

При анализе рисков при внедрении OKR я наткнулся на публикацию Harvard Business Review и выводам из публикации посвящен данный пост. В исследовании шла речь о том, что менеджмент часто ставит стратегические цели (стратегические OKR, уровня всей компании), но не задает вектор как эти цели достигать. Цели есть, а стратегии нет. Вероятность неудачи выполнения проектов при подобном классичесмком внедерении OKR составляла более 70%.

Почему так происходило?
1️⃣ Команды не всегда понимают какие их действия приблизят к выполнению стратегических целей.
2️⃣ Командам часто нужны конкретные подсказки какой вектор выбрать.
3️⃣ Не всегда есть полномочия брать отвественность за глобальные и дорогие изменения и за стратегическое планирование.
4️⃣ Ну и люди часто боятся рисковать и считают, что на то и есть менеджментв высшего звена дабы решать куда двигаться.

Эта тема плотно касается лидерства и задействованы очень схожие механизмы.

Что делать?
В том же исследовании упоминалось, что fail rate понижался в разы в тех компаниях, которые создавали инициативные рабочие группы для определения вектора и набора шагов для реализации стратегии. Если не перекладывать отвественность на команды, а давать подсказки и лидерский вижн, что достичь результат можно сделав A, B и C, то команды примут это с высокой вероятностью и будут понимать что же им делать.

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

Значит нужно создавать подобный генеральный штаб. Так у нас появился BUSINESS & STRATEGIC RING...
источник
2020 October 06
noTieinIT - Об IT без галстуков
-=реклама=-

Приглашаем вас на онлайн-трансляцию "Практика применения аналитических инструментов Oracle в дистрибуции Schneider Electric". Представители компании Schneider Electric расскажут, как с помощью Oracle Analytics Cloud они собирают и обрабатывают 90% данных автоматически.

Когда: 7 октября 2020 г. в 11:00 Мск
Принять участие: https://vk.cc/aAwIYe
источник
2020 October 09
noTieinIT - Об IT без галстуков
​​🐒 Не хочешь программировать - стань разработчиком. Дно пробито.

Для нашего рекрутмента давно уже есть определенные маркеры по кандидатам. Да и собеседующие смотрят на предыдущий опыт и образование. Когда у человека в CV указано, что он выпускние курсов GoIT, компьютерной академии ШАГ, SkillUP, ITEA, то это индикатор того, что с высокой вероятностью будет “все плохо”. Я уже молчу про зашквары самих курсов, а сужу по опыту прошлых собеседований. Вроде по CV все хорошо и закрываем глаза на “сомнительный опыт” таких курсов… доходим по собеседования и в очередной раз убеждаемся, что это было зря потраченное время. После очередной попытки просто перестали смотреть людей с такой “черной меткой”.

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

Ниже картинка с рекламы GoIT. Отлично характеризует их контингент и целевую аудиторию… Спасибо, не нужны такие.
источник
2020 October 13
noTieinIT - Об IT без галстуков
🥋Навеяло... а как учился я сам? Часть 1.

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

Тут на меня нахлынули воспоминания и я начал вспоминать. Естественно, я читал книги. В самом начале это были библии языков программирования, которые обучали синтаксису и базовым вещам в разработке. В лицее где я учился, привет ЛНЗ, мы занимались анализом алгоритмов и структур данных, учились думать алгоритмически и решать задачи. Они не касались задачи реального мира и ни одна из решаемых задач мне не пригодилась в дальнейшем в энтерпрайзе. Бесполезно? Нет, это один из трех важнейших векторов, который позволили мне развиться как инженеру. Нас учили думать и понимать ограничения. Именно такие задачи, от собственных игрушек на Pascal до задачек с ACM и классики по Кормену, которые я дебажил дома на x386 с 40 МГц и 8 Мб памяти, научили понимать оптимальность структур данных и сложности алгоритмов. Это не то что сейчас вместо HashMap используют поиск по массиву и не видят разницу. Конечно, не увидишь, когда у тебя минимум 8 ядер по 2.5 Ггц+. Я же довольно рано осознал в чем проблема жадных алгоритмов, NP полных задач и т.п. Как это помогает, спросите? Это помогает искать оптимальное технического решение задачи, а в довесок жизненно необходимо для построения архитектуры в хайлоаде. Как это прокачать?  Об этом еще будет отдельный пост, ибо я в рамках плана развития для коллеги подготовил флоу в этом направлении.

Пока же я оставлю интригу, ведь два оставшихся вектора не влезли в один пост, потому продолжение будет завтра, не пропустите!
источник
2020 October 14
noTieinIT - Об IT без галстуков
🥋Навеяло... а как учился я сам? Часть 2.

Внимание, продолжение первой части.

Какой же второй вектор? Это исследование чужого кода, поиск ошибок и уязвимостей. В те времена были самописные форумы, биллинги, сайтики с динамическим контентом, что-то налеплено на первые версии CMS... не так давно появился phpbb и wordpress. Было по фану ковырять публично доступные исходники и думать где может сломаться код, как вызвать переполнение памяти или где программисты нафакапили с фильтрацией данных. Вокруг еще были такие же единомышленники и происходил активный обмен опытом. Времени уходило огромное количество, зато я учился думать с другой стороны, не со стороны только true positive сценария выполнения кода, а с другой стороны, находя кучу мест где код может упасть. Я задаю такие вопросы и на собеседованиях, ведь инженер должен уметь думать как его код может поломаться и предугадывать это. Всех инженеров, по мере возможности, пытаюсь обучить, что это полезный скил, как сбор кубика Рубика в голове.

Третий вектор - бизнес задачи. Они подтянулись уже после. К тому моменту я видел как писали код другие люди и умел анализировать самостоятельно их решения. Было забавно играть в мысленные шахматы и размышлять почему именно такое решение, а не другое, чем руководствовался автор? На этой фазе было важно критическое мышление. По-сути, я строил оптимальный путь решения бизнес задачи с помощью технического языка (привет вектор 1), а потом искал в нем проблемы и улучшал в голове, еще до кодирования (привет вектор 2). Я занялся фрилансом и впрягся в проект, с которого сбежали все разработчики, бросили эту кашу из говнокода на заказчика, глючную и падающую. Проект был еще и нагруженный, ей нужна была отдельная VPS, а ни админов, ни QA не было. Работа для человека-оркестра. Это был чистый кайф! У меня была возможность использовать скилы по анализу производительности и поиска багов, тестировать свои гипотезы и проводить замеры производительности, научиться собирать и анализировать метрики, та даже деплоить без даунтайма я научился еще тогда. За каждой из задач что я решал стояли бизнес задачи: не лежать и не терять деньги пока идет миграция, увеличить пропускную способность, работать с неструктурированными данными, делать отказоустойчивость и т.п. Некому было меня учить, потому оставалось учиться самому, используя статьи от гуру топовых компаний, общаясь онлайн с теми же единомышленниками. Когда же появился Хабра, то это стало откровением, новым толчком для инженерии в СНГ.

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

P.S. Если кто знает, как вернуть моего любимого 🦀 в голосовалке и при этом оставить камменты - напишите плз, я не нашел, жалко краба =(
источник
2020 November 17
noTieinIT - Об IT без галстуков
​​🧨 Apple M1. Если Intel ничего не предпримет, то мы можем увидеть его закат.

Я не фанат Apple, хоть и пользуюсь Apple MacBook Pro 13 еще 2015 года, а недавно выбирал супруге ноутбук и остановился на Apple MaCbook Pro 16, хотя и перебрал множество других недешевых ноутбуков.

То что сейчас происходит - это выбивание стула из под Intel и AMD, никак иначе. Почему? Об этом ниже, в моем факт-чеке.

Сегодня появились в продаже новые MacBook Air, MacBook Pro 13 и Mac mini. Есть первые тесты производительности.

🔥По тесту Geekbench 5 в тесте на 1 ядре Apple M1 3.2 GHz уделывает MacBook Pro 16 на топовом Intel Core i9-9880H 2.6 Ghz и даже iMac 2020 года на топовом Intel Core i9-10910 3.6 GHz. Результаты синтетических тестов 1689 vs 1251 vs 1095.
🔥В multi-core тесте результаты 7288 vs 9021 vs 6869. При этом, у iMac 10 ядер, а у остальных по 8 ядер.
🔥Но! Эти тесты без эмуляции x86, а у M1 архитектура ARM, потому тот же Premier Pro для x86 систем будет медленнее работать. Ранее на Geekbench были замеры в режиме эмуляции и там результаты single core/multi-core были куда скромнее: 1313 и 5888. Но потом с Geekbench данные этих тестов удалили и оставили нативные тесты. Но интернеты помнят все. Даже с эмуляцией это быстрее чем Core i7 и Core i9. А что будет когда Premier Pro и прочие сделают поддержку нативную ARM?
🔥Эти тесты - это синтетика, стоит помнить. У MacBook Air нет вентилятора, а у MacBook Pro есть, потому я предполагал возможность перегрева при длительной нагрузке и будет происходить снижение производительности. Но я уже видел экспорт H264 4K видео и HEVC длиной в 10 минут, которые не привели к снижению производительности. Производительность тупо не падает!
🔥Еще под полной нагрузкой M1 нагрелся до 33 градусов по цельсию на корпусе на Air без вентилятора! Что повергло прямо в шок, ибо MacBook Pro 16 греется до 46-50 градусов, жужа как пылесос.
🔥Работа в Davinci, Final Cut и Premiere Pro с 4K видео работает как нативно (Final Cut), так и с Premiere Pro в режиме эмуляции x86 (Rosetta 2).
🔥Тесты Cinebench показали преимущество над Core i9-9880, 1498 vs 1183 в single core тесте. Правда Ryzen лидирует в multi-core тесте.
🔥Affinity тест: M1 уделывает iMac с AMD 580X

Числа выше говорят за себя. Но вот что еще… Apple подняла цены на официальном сайте на версии с Intel процессорами. Для примера, MacBook Pro 16 с Core i9-9880H, 16Gb RAM и 512Gb SSD стоит $2699. В то время как Apple MacBook Air с M1, 16Gb RAM и 512Gb SSD стоит $1499. При почти одинаковой производительности… Базовый Air против топового Pro… Давление ценой и качеством. Шах и мат Intel, ты зажрался!

@noTieInIT
источник
2020 November 18
noTieinIT - Об IT без галстуков
​​Еще бенчмарк M1 подьехал. Компиляция WebKit.
источник
2020 November 30
noTieinIT - Об IT без галстуков
Околотехнический вопрос.

У меня лента взрывается огромным количеством булшита про Covid-19 (который SARS-Cov2). Я факт-чекаю как сведения про препараты, рассказывая что это булшит, либо делюсь исследоаниями последними. Дорогие подписчики, вам такое интересно? Ниже опрос, потому маякните.
источник
noTieinIT - Об IT без галстуков
Псс, %USERNAME%, исследования и факт-чеки о короне интересны?
Анонимный опрос
20%
Да, пиши в отдельный мини-канал
45%
Да, пиши прямо сюда
35%
Нет, не пиши
Проголосовало: 574
источник