IT АНАЛитика | Вильд Виктор

описание

Канал для аналитиков и тех, кто хочет расти в IT. Главный системный аналитик ВТБ, в IT c 2018 года — прошел путь от техподдержки до тимлида команды разработки. 📌Связь/реклама/консультации: @tako_man

← к каналу @it_deep_sight

2 077

подписчиков

Охват к подписчикам

41,6%

ERR

Реакции к просмотрам

1,68%

335 на 22 постов

Пересылки к просмотрам

1,00%

200

Постов в день

0,1

всего 23

Где отзываются чаще

доля реакций к просмотрам

13 авг.Вот вам оффер пошел нах*й 🤝🤝 Прошлый пост про книгу собрал много реакций и репостов. Хочется на регулярной основе делиться ими с вами. Вы когда-нибудь занимались наймом? Или может помогали коллегам с собесами? Так или иначе у вас должно быть хоть какое-то представление о нем, как минимум вы сами проходили собеседования, где вас брали на работу. Были ли вы свидетелем такой ситуации: взяли человека, а он оказался "ни бэ ни мэ" и по итогу и вы и компания просто потеряли время? Прочитал книгу «КТО. Решите вашу проблему номер один» от Джеффа Смарта и Рэнди Стрита. Авторы 13 лет занимаются наймом и делятся методикой. Мысль простая: сначала КТО, потом ЧТО. Неважно, насколько крутой у вас проект или задачи. Важно, кто их будет делать. Тут вводится концепция игроков А, B и С. Игрок А это самый топовый кандидат, который с вероятностью 90% выдаст результат, доступный лишь 10% людей на этой роли. Всё остальное B и С, и вот их-то мы обычно и нанимаем, потому что торопимся или не умеем отличать. По цифрам из книги: неудачный найм обходится компании примерно в 15 месячных окладов сотрудника (статистика омэриканская, но денег в любом случае не мало). Так что брать кандидата "чисто по вайбику" или "да он вроде лучше тех пяти, пофиг, давайте возьмем" очень дорогое удовольствие. Методика состоит из 4 шагов: 1️⃣Лист целей Подробное описание, чего вы ждёте от роли. Нужно сделать осознанный документ: зачем эта роль команде и какой результат ждём. А не копипаст одного из тех тысяч похожих описаний, что кочуют по вакансиям. 2️⃣Поиск кандидатов Крутых спецов нужно искать заранее и систематически, а не когда вакансия уже горит. Это, наверное, самый сложный пункт. 3️⃣Отбор Проводим серию интервью, где выясняем, кандидат крутой или г*вно. Редко, когда за 1ч удается понять, что человек подходит. В идеале выделить несколько встреч по часу или одно на 2ч. Каждая минута потраченная на интервью избавит вас от сотен часов, которые вы провели бы, пытаясь чего-то добиться от заведомо слабых сотрудников. 4️⃣Предложение Выбрали кандидата? Теперь грамотно убедите его стать частью команды, иначе уведут конкуренты. Теперь подробнее про первый шаг, потому что главная ошибка найма это отсутствие чёткого представления, чего вы вообще хотите от будущего сотрудника. Лист целей состоит из 4 частей: 📌Основные задачи: 5-6 предложений о сути работы и зачем вообще создана вакансия. 📌Ожидаемый результат: 3-5 конкретных результатов, специфичных для роли. 📌Профессионализм: навыки, которые ждёте от кандидата. 📌Командность и коммуникации: тут лучше свериться с коллегами. Плохо🤡: «Ищем аналитика с опытом написания требований». Хорошо🤩: «Через 3 месяца сократить число доработок из-за неполных требований в 2 раза». Лайфхак: цели стоит ставить немного "дерзкие". Люди не любят проигрывать. Чуть поднятая планка отпугнёт средних кандидатов и одновременно привлечёт сильных, которым интересен вызов. Так же в книге отдельно подчеркивают: НЕ НАНИМАЙТЕ УНИВЕРСАЛОВ, НАНИМАЙТЕ СПЕЦИАЛИСТОВ Если лень читать книгу, могу выложить вторую часть: как проводить интервью по этой методике. Какие вопросы задавать, как вежливо затыкать льющих воду, тревожные звоночки в поведении кандидата и как в итоге выбирать. Наберём 30 🔥 и выкладываю вторую часть. А вы часто сталкивались с "ни бэ ни мэ" наймом? Как поняли, что произошла ошибка, сразу на испытательном или уже позже? IT АНАЛитика | Подписаться5,59%
24 июл.А кому сейчас легко в финтехе..... Вы думали канал просто так называется, да? IT АНАЛитика | Подписаться3,25%
30 июн.Штош ты ментор сдал назад? Периодически в личку прилетает что-то в духе: У тебя классный канал, давай запустим курсы/школу/цирк. Я продюсер, вы можете лутать кучу деняк. Вам не хватает простого советского… И каждый раз примерно одно и то же. Меня в этом всегда отталкивало даже не то, что пишут ноунеймы без аватарки, кейсов и хоть какого-то внятного предложения — «я крутой, давай работать». А сам подход: почти всегда это про "АЛО БИЗНЕС? ДА ДА ДЕНЬГИ", а не про «давай попробуем сделать что-то интересное». Свободного времени и так почти нет: работа, спорт, собака, другие хобби, ведение канала. Распыляться ещё куда-то вообще в падлу. Каналу почти 3 года. За это время я даже успел получить диплом маркетолога, но желания жоска что-то продавать так и не появилось. Мне вполне хватает редкой рекламы и иногда консультаций. Я как в том меме про таксиста: в банке я работаю так, для души — на самом деле я админ тг-канала про IT. Но вселенная при этом как будто подкидывала знаки: — прошёл обучение на ментора на РАБоте — менторил коллег — постоянно кому-то что-то объясняю вне работы Такой долгий сетап как-будто должен вести к: ТОЛЬКО СЕГОДНЯ ВЫ МОЖЕТЕ ЗАПИСАТЬСЯ🤡!!!!!! Но нет. Очередным знаком стал разговор с корешем, у которого было не очень с работой. Разгоняли варианты, и в какой-то момент я такой: "А давай попробуем вкатить тебя в АЙТИ?" Потом решил подтянуть ещё одного кореша и вот уже ПЕРВЫЙ ПОТОК, ГРУППА ОБУЧЕНИЯ, ЗАПИСЫВАЕМСЯ, ДЕВА4КИ. На картинке пройденные темы. Чисто из интереса захотелось проверить: а можно ли за 2–3 месяца дать человеку базу и довести до первых попыток найти работу в условиях нестабильного рынка. Как это обещают разные школы, менторы и прочие проходимцы. Пока сам не знаю, что из этого выйдет. Для вас это будет контент, а для меня возможность проверить на практике, как вообще работает такое обучение. Хочу иногда делиться процессом: что работает, что нет, где сам ошибаюсь и какие выводы из этого получаются. Если тема вам интересна, буду периодически рассказывать, как идёт этот эксперимент. Ну и напишите в комментах, как вообще относитесь к менторству и всем этим "вкатам в IT". IT АНАЛитика | Подписаться3,21%
17 июн.Кого ты забыл согласовать? 🤔 Чем больше задача — тем больше людей вокруг неё. Бизнес, смежные команды, архитектор, безопасники, поддержка и всем в какой-то момент «ЧЕТО НАДО». Я не раз видел на встречах, когда кто-то со стороны заказчика говорил: А почему так решили сделать? Я это не согласовывал. И тут уже "Управление заинтересованными лицами" из парочки красивых слов превращается в артефакт, который нужно использовать в работе, чтобы не огрести на каком-либо этапе. Зачем вообще это фиксировать? Когда задача небольшая, то вполне ок держать это в голове. Если заинтересованное лицо одно, вряд ли вы его забудете. Но если проект длится несколько месяцев, участников много, согласования идут в несколько этапов и на каждом этапе свои согласующие, то без фиксации легко кого-то пропустить. А пропустить стейкхолдера это: 😕узнать о пропущенном требовании в самый неподходящий момент. 😐переделывать то, что уже сделано. 🥲краснеть на созвоне и объяснять почему его не позвали. Что фиксируем? Для каждого стейкхолдера важно понимать три вещи: 🆗 Кто это и какова его роль? 🆗 Какой у него интерес к задаче? 🆗 На каком этапе и в каком формате его нужно подключить? Таблицу удобно держать прямо в аналитике к задаче — не надо держать всё в голове и легко онбордить новых участников. В комментарии кину пример таблички. А вы ведёте список стейкхолдеров или держите всё в голове? 👇 IT АНАЛитика | Подписаться2,66%
27 апр.Если вы читаете это, значит вы и есть сопротивление. Я когда-то знал людей, которые предупреждали: без нормальной аналитики всё рухнет. Что требования надо фиксировать. Что устные договорённости это катастрофа. Никто не хотел их слушать. Бизнес игнорировал. Разработчики смеялись. Тимлиды отмахивались. Но всё, что они предсказывали — сбылось. Прод упал. Сроки сгорели. Задачи ушли в разработку без описания. И поэтому я прошу вас поверить мне. Менеджеры хотят, чтобы мы работали как ИИ. Принимали задачи без вопросов. Писали доку для галочки. Молчали на встречах. Но мы не ИИ. А если уподобимся им, какой тогда смысл в профессии? Слушайте внимательно. Мне сейчас нужен каждый из вас. Вы жизненно важны для главного сражения — между хаосом и нормальным процессом. Те, кто фиксирует договорённости возможно, выживут. Те, кто доверяет устным обещаниям — возможно, нет. Всё предельно просто. Врываемся в новую рабочую неделю🎧 Постов не было месяц, админ восстанавливал силы в отпуске. Теперь всё, возвращаемся в work mode 💼 Ждете уже майские? Какие планы? #поддержка IT АНАЛитика | Подписаться2,60%
7 июл.Пришло приглашение на вакансию. Узнали? Согласны?🤡 IT АНАЛитика | Подписаться2,21%
19 июн.Это уже киберпанк или еще нет?😎 Коллеге пришло приглашение) IT АНАЛитика | Подписаться1,97%
26 маяКак Москва превратилась в дагестанское село 🗺 Довольно поучительная история от ребят из Авито. Коротко о сюжете: команда выкатила фичу «Лёгкое резюме». Метрики растут, все радуются. Через неделю обнаруживают, что 45000 резюме создано в селе с населением 7000 человек 😬 Оказалось: Android-клиент менял местами широту и долготу. Перевёрнутые координаты Москвы попадали на поле в Иране. А бэк вместо того чтобы показать ошибку, тихо переносил резюме в ближайший российский населённый пункт - дагестанское село. Что из этого можно вынести: 1. Интеграцию надо проверять с каждым клиентом отдельно. Android, iOS, web — разные клиенты с разной реализацией. То что работает на одном, может сломаться на другом. Особенно при горящих сроках и спешке. 2. Думай не только про happy path. Что происходит когда данные некорректны, поле пустое или пользователь сделал что-то неожиданное? Такие сценарии важно проработать и описать ещё на этапе анализа, иначе система сама решит как себя вести. 3. Поспешишь — людей насмешишь Этим грешат все. Но если к релизу фича не до конца проверена, то лучше отложить или хотя бы явно подсветить риски команде. Узнать о критическом баге на проде всегда дороже, чем перенести релиз. Полная история: Читать 📚 А у вас были баги, которые потом превращались в полноценное расследование? IT АНАЛитика | Подписаться1,97%
8 маяТы точно знаешь, что такое архитектура? 🤔 Недавно был на собесе и получил вопрос: «А что такое архитектура? Зачем она вообще нужна?» А почему солнце светит? В комментарии выложу картинку, как выглядело моё лицо в тот момент 🙂. Обычно такие вопросы задают с одной из двух целей. 1. Проверить самообладание. Бизнес порой задаёт простые или странные вопросы, и важно уметь спокойно на них отвечать. Помню, как на собесе кандидату задали простой вопрос, а он выдал: «РРЯЯЯЯЯЯЯ ВЫ ЧЕ ТУПЫЕ, НУ КТО ТАКОЕ СПРАШИВАЕТ, НУ ВЫ И КРИНЖ» 2. Проверить логику и базовые знания. Именно на простых вопросах многие неожиданно сыплются. Кажется, что это очевидно. Но попробуйте объяснить прямо сейчас не подглядывая 👀 Что такое архитектура? 🧱 Если совсем по-простому, то это чертёж системы. Как в строительстве: прежде чем строить дом, архитектор рисует план — где стены, где двери, как всё соединяется, из каких материалов. В IT всё то же самое: архитектура описывает из каких компонентов состоит система, как они взаимодействуют и почему именно так. Зачем это знать аналитику?🤔 Ну, во-первых, чтобы меньше платить и не брать полноценного архитектора . Если серьёзно, то как ты будешь проводить системный анализ в отрыве от самой системы? Любое решение проектируется внутри какой-то архитектуры, и не понимать как она устроена ну вообще никак. Не понимаешь архитектуру → не понимаешь ограничения → пишешь требования, которые невозможно реализовать. Или реализовать можно, но потом всё ломается. Самые популярные виды: ➡️ Монолит Вся система это один большой кусок. Логика, база и интерфейс лежат в одном месте. На старте это просто и удобно, особенно если приложение небольшое. Но чем больше система растёт, тем тяжелее её масштабировать и менять. ➡️Микросервисы Система разбита на маленькие независимые сервисы, каждый отвечает за свою задачу. Главный плюс, если один сервис упал, остальные продолжают работать. Гибко и устойчиво. Но есть нюансы: сервисов много, значит много интеграций, много мест где может что-то пойти не так, и отлаживать, деплоить и мониторить всё это заметно сложнее чем монолит. Дальше уже идут архитектурные паттерны, в рамках которых можно реализовать ту или иную систему. Что будет, если накосячить? 💀 Архитектурные ошибки самые дорогие. Условный баг в коде исправишь за час. Неправильно выбранная архитектура может вскрыться через год и переделывать тогда дорого по времени и деньгам. Именно поэтому архитектурные решения принимаются в самом начале и согласовываются со всеми заинтересованными сторонами. А вам на собесах задавали базовые вопросы, от которых хотелось сказать «подержи моё пиво, ща тебе расскажу»? Делитесь в комментариях 👇 IT АНАЛитика | Подписаться1,88%
29 маяОбъяснение OAuth на котиках IT АНАЛитика | Подписаться1,87%
11 июн. 2025 г.Fuck UP №1🔥 Запускаю новую рубрику на канале — про факапы. Буду делиться своими историями, чтобы показать: ошибки — это не конец света. Вы тоже можете поучаствовать. Присылайте свои истории в личку @tako_man или анонимно — вот форма. Почему вообще об этом? Многие боятся ошибаться. “А что подумают коллеги?” “Теперь все узнают, что я не тяну…” "Тимлид думает я чмоня..." Именно из таких мыслей часто и вырастает то, что знакомо многим айтишникам — синдром самозванца. Но на деле ошибки — это нормально. Более того, это один из главных двигателей роста. «Я не потерпел неудачу. Я просто нашёл 10 000 способов, которые не работают.» — Томас Эдисон И на мой взгляд, страшнее не сама ошибка, а когда на неё просто забивают и не делают выводов. А потом повторяют снова 🤡 Когда я только начинал как аналитик, сам для себя это сформулировал так: Лучше задать один глупый вопрос и исправить возможную ошибку, чем сделать одну маленькую ошибку — и по итогу обосраться. Моя история Не сказать, что это прям дикий факап, но осадочек остался. Ко мне приходит PO в лице бизнеса и спрашивает: — Вот эта СМС, которую мы шлём клиентам — она чья? Я, не особо задумываясь, отвечаю: — Не наша. Где-то в голове это чётко отложилось, плюс вроде кто-то из разрабов так говорил. Через пару часов PO возвращается — уже на эмоциях: — Я всех обошла, навела суету, все на меня смотрели как на дуру. А СМС оказалась нашей. Она была реализована на проекте до меня и не была задокументирована Мы, конечно, всё порешали спокойно. Но с тех пор у меня правило: Не доверяй себе на слово. Проверяй. Всегда. Даже если «точно помнишь» — проверь ещё раз. 🤔 А у вас бывали факапы, после которых вы всерьёз поменяли подход к работе? Пишите в личку или присылайте свои истории — можно анонимно. #FuckUP IT АНАЛитика | Подписаться1,84%
19 маяКак выявить х*евое требование?🗑 Если вы не работали с такими требованиями, то можно сказать, и не работали в IT. Бизнес иногда приносит ТАКОЕ, от чего вполне может развиться выгорание или ПТСР. Конечно, можно смириться и делать что скажут жестко осуждаем такой подход и никому не советуем. Но задача аналитика не просто принять требования и оформить, а разобраться — точно ли нужно делать именно так? И если нет, донести это без скандала. Вот как можно разложить это по шагам: 1. Сначала идентифицируй требование🧐 Прежде чем паниковать, задай себе три вопроса: ⏺Если это не реализовать, бизнес-потребность всё равно закроется? ⏺Можно закрыть это имеющейся функциональностью или сделать проще? ⏺Есть ли риски в реализации этого требования? Часто уже на этом шаге становится понятно, что требование можно упростить или вообще выкинуть. 2. Выяви истинную потребность🔍 Бизнес часто говорит что хочет, но не всегда понимает что ему на самом деле нужно. Копай глубже: 💬Какую задачу он пытается решить? 💬Что произойдёт, если это не сделать? 💬Есть ли ограничения, которые не дают рассматривать другие варианты? Если ограничения есть и альтернатив нет, то сразу переходи к шагу 4. 3. Предложи альтернативы 💡 Не просто скажи «это плохо/делать не будем/вы не шарите», а покажи варианты: ➡️ Вариант 1 — что хочет бизнес. Опиши честно, какие трудности это создаст. Без субъективного «это тупо/сложно/некрасиво», только сухие факты. Обычно после оценки и сроков этот вариант сам отметается 🙂 ➡️ Вариант 2 — некий костыль. Может, можно сделать небольшую доработку уже существующего функционала? Обычно это самый дешёвый и быстрый вариант. Но не всегда самый правильный, тут важно обсудить его с архитектурой, потому что иногда костыль это очень плохо!!!!!!! ➡️ Вариант 3 — самый трушный. Решение, которое закрывает потребность бизнеса с минимальными рисками. Да, может быть дороже, но в долгосрок все выигрывают и переделывать точно не придётся. 4. Зафиксируй ограничения и риски 📝 Бывает, бизнес хочет эту зелёную кнопку «ну вот тока тут». Не всегда получается переубедить, такое иногда бывает. Да ты че? Базару нет Но перед тем как брать в работу, обязательно зафиксируй все риски и ограничения письменно. Пропиши возможные последствия и способы их устранения. Если на демо или ПСИ кинут предъяву, сможешь уверенно и без задней мысли сказать: «А Я ВАМ ГОВОРИЛ!!!!!!!!!!!!!!!» 5. Полный газ👍 Всё согласовано, риски зафиксированы, спокойно приступаешь к аналитике. Главное помни: твоя задача не просто выполнить требование, а помочь бизнесу получить качественный результат. Иногда это значит задать неудобный вопрос: "Подождите, коллеги. Я вас правильно понял? Вы хотите сделать какую-то х*ету? А вам часто прилетают плохие требования? Как справляетесь? 👇 IT АНАЛитика | Подписаться1,81%