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

Вот вам оффер пошел нах*й Часть 2

Как и обещал, вторая часть 🔥

Если пропустили первую, там был лист целей и разбор игроков А, B и С. Сегодня про само собеседование: как его вести и как не нанять очередного "ни бэ ни мэ".

Отбор в книге это не один-два созвона, а полноценная серия интервью.

1️⃣ Отборочное интервью
Первый фильтр. Звонок до 30 минут, чтобы потом не тратить драгоценные часы на встречи с кем попало. Всего 3 вопроса (кроме прям совсем стандартных):

⭐️К чему вы стремитесь в карьере?
⭐️Что лучше всего вы делаете как профессионал?
⭐️Что хуже всего? Какие аспекты профессии вам неинтересны?

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

Не увидели мэтч? Сразу завершаем звонок. Авторы книги пишут прямо:

«ЛУЧШЕ ПРОПУСТИТЬ ПРОФЕССИОНАЛА, ЧЕМ ТЕРЯТЬ ДРАГОЦЕННЫЕ ЧАСЫ НА СОМНИТЕЛЬНЫЕ ВАРИАНТЫ»

2️⃣Квалификационное интервью
Их должно быть достаточное количество, чтобы закрыть все вопросы к кандидату, но вам скорее всего хватит двух: техническое и нетехническое.

С техническим понятно. С нетехническим идём по опыту кандидата в хронологическом порядке, плюс можно накидать пару рабочих кейсов и проверить софт скиллы.
Если мест было очень много, можно сосредоточиться на последних 3-5.

⭐️Расскажите о проекте, чем занимались?
⭐️Какие были достижения? Чем гордитесь?
⭐️Были ли провалы? Что не нравилось?
⭐️Почему решили уйти? Пытались ли продвинуться?

Последний вопрос самый важный.
Нужно понять: человек ушёл на пике, потому что реально крутой, или его не оценили и он тихо слился. Сильных обычно не хотят отпускать. "Мы друг друга не поняли" не канает, будьте любопытны и копайте дальше.

Лайфхак: интервьюировать лучше вдвоём. Один задаёт вопросы, второй делает заметки. Так меньше шансов что-то упустить.

3️⃣Не бойтесь прерывать
Кандидат льёт воду? Прерывайте. Если этого не делать, разговор скатится в пересказ резюме и вы потеряете час.

Плохой способ: "стопэ, давай уже по делу/дальше". Человек начнет нервничать, подумает что сказал что-то не то, и начнёт оправдываться вместо ответа.

Хороший способ: "о, круто, давай остановимся на этом поподробнее" или "понял, погнали дальше". Звучит мягко, но управляете разговором всё равно вы.

4️⃣Тревожные звоночки
🚩Опускает свои ошибки
🚩Отвечает многословно и ни о чём
🚩Приписывает себе чужие заслуги
🚩Хейтит бывших начальников и коллег
🚩Не может внятно объяснить смену работы
🚩Слишком зациклен на себе
🚩Обвиняет других и оправдывает себя в любых неудачах
🚩Изо всех сил старается показать, какой он крутой

Один пункт не приговор, но если набралось несколько, стоит копнуть глубже.

5️⃣ Как выбрать
Помните игроков А, B и С из первой части? Вот тут они и пригождаются. Сверяем каждого кандидата с листом целей по пунктам. Уверены на 90%+, что справится? Это игрок А. Меньше 90%? Тогда B или C.

Игрок А один? Берём его. Несколько? Распределяем по рейтингу и выбираем лучшего.

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

IT АНАЛитика | Подписаться

Штош ты ментор сдал назад? Часть 2

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

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

Долго думал над форматом. Пришёл пока к такой схеме:

1. Выстроил темы от простого к сложному — каждая следующая логически вытекает из предыдущей.

2. С самого начала обозначил тему финального проекта: все ДЗ по ходу курса были завязаны на него, а не оторваны друг от друга.

3. Готовлю тему в формате презентации с примерами и мемами.

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

5. После каждой темы ДЗ, с последующим разбором.

Плюсы: освежил знания по некоторым темам, где-то взглянул под другим углом, удобная подготовка к собесам выходит😎.

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

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

Попросил у ребят фидбек:

Больше всего зашли темы про методы, транзакции, json, отрисовку диаграмм: там, где можно было много попрактиковаться руками.

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

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

Оглядываясь назад, понимаю, что с SQL немного зафакапил: дал один короткий урок, скинул бесплатный курс с тренажёром — и дальше сами. Исходил из логики, что умные люди давно всё объяснили на пальцах, и смысла дублировать конкретно эту тему нет. А по факту по базовым операторам стоило поднять тестовую БД и пописать запросы вместе на созвоне, а не отправлять разбираться в одиночку.

Через 1-2 недели заканчиваем пет-проект и идём давать эйчарам по жопе пробовать выходить на собесы.

А какой формат обучения вам бы зашел больше — живой урок по каждой теме или видос с таймкодами, который можно спокойно посмотреть в своём темпе и потом задать вопросы?

IT АНАЛитика | Подписаться

Коллеги, кто?

IT АНАЛитика | Подписаться

Архитектурный паттерн "Метнись кабанчиком": разбираемся со Scatter/Gather

Сейчас на рынке от джуна ждут, что он мидл.
От мидла ждут, что он сеньор помидор.
А от сеньора ждут, что он архитектор.

Поэтому пытаюсь потихоньку читать "айтишные" книжки. Дошёл до Брендана Бёрнса, «Распределённые системы. Паттерны проектирования», и там есть один архитектурный паттерн, про который редко пишут, но он вполне простой и называется Scatter / Gather.

Допустим тебе прилетает задача: спроектировать интеграцию, в которой нужно тянуть инфу сразу с пяти источников.

Самое очевидное, что приходит в голову: дёрнем каждую ручку по очереди.
Или какой-нибудь асинхрон с кафкой замутим.

А паттерн Scatter / Gather говорит нам: метнись кабанчиком. Только не к каждому по очереди, а ко всем сразу.

Scatter: Диспетчер разбрасывает запрос по всем пяти источникам одновременно.
Gather: и собирает ответы в кучу, склеивая в один результат.

Звучит, как изи катка. Но что, если один из пяти источников сегодня тупит?

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

И вот тут у нас, как у архитектора, происходит выбор:

🐘 Ждать всех до последнего (тогда весь ответ упирается в самого медленного).

🦛 Ставить таймаут и собирать то, что успело прийти (тогда результат может быть неполным).

🐗 Решать заранее, что делать с «молчунами»: игнорировать, повторить запрос, подставить дефолтное значение.

У автора ответ один: не полагаться на единственный источник, а держать пару его копий про запас. Затупил основной, диспетчер тут же дёргает дублёра.

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

А у вас кабанчики бегают к своим источникам или к чужим? И как выкручиваетесь, когда внешняя система тупит?

IT АНАЛитика | Подписаться

Почему Авито не подключает микросервисы к Kafka напрямую?

Хороший кейс для разбора по системному дизайну:

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

Поэтому они поставили между сервисами и Kafka прослойку (шину данных). Сервисы общаются только с ней, а всю внутрянку кафки шина берет на себя. Продуктовым командам по итогу вообще не нужно знать, как там всё устроено под капотом.

На практике это дало:
1. Когда отваливался дата-центр, запись в Kafka зависала до 30 секунд и все запросы на запись просто стояли и ждали. Они переделали архитектуру: вместо одной Kafka на все дата-центры сделали несколько локальных, которые потом синхронизируются между собой. Сервисы этого перехода даже не заметили, для них ничего не поменялось.

2. Шина проверяет контракты событий при каждом деплое. Если сервис Б читает событие от сервиса А и ждёт там определённое поле - А не сможет его удалить или поменять тип, пока Б на него рассчитывает. Раньше такое всплывало багами на проде.

Читать📚

IT АНАЛитика | Подписаться

Вот вам оффер пошел нах*й 🤝🤝

Прошлый пост про книгу собрал много реакций и репостов. Хочется на регулярной основе делиться ими с вами.

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

Были ли вы свидетелем такой ситуации: взяли человека, а он оказался "ни бэ ни мэ" и по итогу и вы и компания просто потеряли время?

Прочитал книгу «КТО. Решите вашу проблему номер один» от Джеффа Смарта и Рэнди Стрита.
Авторы 13 лет занимаются наймом и делятся методикой.
Мысль простая: сначала КТО, потом ЧТО. Неважно, насколько крутой у вас проект или задачи. Важно, кто их будет делать.

Тут вводится концепция игроков А, B и С.
Игрок А это самый топовый кандидат, который с вероятностью 90% выдаст результат, доступный лишь 10% людей на этой роли.
Всё остальное B и С, и вот их-то мы обычно и нанимаем, потому что торопимся или не умеем отличать.

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

Методика состоит из 4 шагов:
1️⃣Лист целей
Подробное описание, чего вы ждёте от роли. Нужно сделать осознанный документ: зачем эта роль команде и какой результат ждём.
А не копипаст одного из тех тысяч похожих описаний, что кочуют по вакансиям.

2️⃣Поиск кандидатов
Крутых спецов нужно искать заранее и систематически, а не когда вакансия уже горит. Это, наверное, самый сложный пункт.

3️⃣Отбор
Проводим серию интервью, где выясняем, кандидат крутой или г*вно. Редко, когда за 1ч удается понять, что человек подходит. В идеале выделить несколько встреч по часу или одно на 2ч.

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

4️⃣Предложение
Выбрали кандидата? Теперь грамотно убедите его стать частью команды, иначе уведут конкуренты.

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

Лист целей состоит из 4 частей:
📌Основные задачи: 5-6 предложений о сути работы и зачем вообще создана вакансия.
📌Ожидаемый результат: 3-5 конкретных результатов, специфичных для роли.
📌Профессионализм: навыки, которые ждёте от кандидата.
📌Командность и коммуникации: тут лучше свериться с коллегами.

Плохо🤡: «Ищем аналитика с опытом написания требований».
Хорошо🤩: «Через 3 месяца сократить число доработок из-за неполных требований в 2 раза».

Лайфхак: цели стоит ставить немного "дерзкие". Люди не любят проигрывать. Чуть поднятая планка отпугнёт средних кандидатов и одновременно привлечёт сильных, которым интересен вызов.

Так же в книге отдельно подчеркивают:

НЕ НАНИМАЙТЕ УНИВЕРСАЛОВ, НАНИМАЙТЕ СПЕЦИАЛИСТОВ

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

Наберём 30 🔥 и выкладываю вторую часть.

А вы часто сталкивались с "ни бэ ни мэ" наймом? Как поняли, что произошла ошибка, сразу на испытательном или уже позже?

IT АНАЛитика | Подписаться

Хороший кейс от зеленого банка, если интересна архитектура и системный дизайн 🧠

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

Показывают обе схемы с плюсами и минусами: где просаживается time-to-market, где растёт нагрузка на сеть, а где неактуальные данные. Полезно для понимания как реальные компании выбирают между простотой и гибкостью в микросервисной архитектуре.
Подобные штуки могут спрашивать на собесе в секции системного дизайна.

Читать 📚

IT АНАЛитика | Подписаться

А кому сейчас легко в финтехе.....
Вы думали канал просто так называется, да?

IT АНАЛитика | Подписаться

Если периодически путаете SOAP, REST, GraphQL и RPC — самое время разобраться 🧠

Статья раскладывает все четыре архитектурных стиля по полочкам: чем отличаются, когда какой выбрать и в чём подвох каждого. Читать 📚

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

IT АНАЛитика | Подписаться

Пришло приглашение на вакансию.

Узнали? Согласны?🤡

IT АНАЛитика | Подписаться

Мы с командой в начале каждого спринта

IT АНАЛитика | Подписаться

Штош ты ментор сдал назад?

Периодически в личку прилетает что-то в духе:

У тебя классный канал, давай запустим курсы/школу/цирк.

Я продюсер, вы можете лутать кучу деняк. Вам не хватает простого советского…

И каждый раз примерно одно и то же.

Меня в этом всегда отталкивало даже не то, что пишут ноунеймы без аватарки, кейсов и хоть какого-то внятного предложения — «я крутой, давай работать».
А сам подход: почти всегда это про "АЛО БИЗНЕС? ДА ДА ДЕНЬГИ", а не про «давай попробуем сделать что-то интересное».

Свободного времени и так почти нет: работа, спорт, собака, другие хобби, ведение канала. Распыляться ещё куда-то вообще в падлу.

Каналу почти 3 года. За это время я даже успел получить диплом маркетолога, но желания жоска что-то продавать так и не появилось. Мне вполне хватает редкой рекламы и иногда консультаций.

Я как в том меме про таксиста:
в банке я работаю так, для души — на самом деле я админ тг-канала про IT.

Но вселенная при этом как будто подкидывала знаки:
— прошёл обучение на ментора на РАБоте
— менторил коллег
— постоянно кому-то что-то объясняю вне работы

Такой долгий сетап как-будто должен вести к:

ТОЛЬКО СЕГОДНЯ ВЫ МОЖЕТЕ ЗАПИСАТЬСЯ🤡!!!!!!

Но нет.

Очередным знаком стал разговор с корешем, у которого было не очень с работой. Разгоняли варианты, и в какой-то момент я такой:
"А давай попробуем вкатить тебя в АЙТИ?"

Потом решил подтянуть ещё одного кореша и вот уже ПЕРВЫЙ ПОТОК, ГРУППА ОБУЧЕНИЯ, ЗАПИСЫВАЕМСЯ, ДЕВА4КИ.
На картинке пройденные темы.

Чисто из интереса захотелось проверить:
а можно ли за 2–3 месяца дать человеку базу и довести до первых попыток найти работу в условиях нестабильного рынка.
Как это обещают разные школы, менторы и прочие проходимцы.

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

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

Если тема вам интересна, буду периодически рассказывать, как идёт этот эксперимент.

Ну и напишите в комментах, как вообще относитесь к менторству и всем этим "вкатам в IT".

IT АНАЛитика | Подписаться

Это уже киберпанк или еще нет?😎

Коллеге пришло приглашение)

IT АНАЛитика | Подписаться

Кого ты забыл согласовать? 🤔

Чем больше задача — тем больше людей вокруг неё.
Бизнес, смежные команды, архитектор, безопасники, поддержка и всем в какой-то момент «ЧЕТО НАДО».

Я не раз видел на встречах, когда кто-то со стороны заказчика говорил:

А почему так решили сделать? Я это не согласовывал.

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

Зачем вообще это фиксировать?

Когда задача небольшая, то вполне ок держать это в голове. Если заинтересованное лицо одно, вряд ли вы его забудете.

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

А пропустить стейкхолдера это:
😕узнать о пропущенном требовании в самый неподходящий момент.
😐переделывать то, что уже сделано.
🥲краснеть на созвоне и объяснять почему его не позвали.

Что фиксируем?

Для каждого стейкхолдера важно понимать три вещи:
🆗 Кто это и какова его роль?
🆗 Какой у него интерес к задаче?
🆗 На каком этапе и в каком формате его нужно подключить?

Таблицу удобно держать прямо в аналитике к задаче — не надо держать всё в голове и легко онбордить новых участников.

В комментарии кину пример таблички.

А вы ведёте список стейкхолдеров или держите всё в голове? 👇

IT АНАЛитика | Подписаться

💎👆🕊🌸💎 💜🔹💮🌷🌸🧡

Пока отхожу от концерта Ye и догуливаю последние дни отпуска — ловите подборку постов за май 🌴
Были уже в отпуске или когда планируете?

Посты
Ты точно знаешь, что такое архитектура?
CQRS: что это и зачем знать аналитику?
CJM — для чего и зачем?
Как выявить х*евое требование?
Ошибки при написании документации
Kafka на примере котиков

Интересные статьи
Основы Kafka
Как Москва превратилась в дагестанское село


#итоги_месяца

IT АНАЛитика | Подписаться

Объяснение OAuth на котиках

IT АНАЛитика | Подписаться

Как Москва превратилась в дагестанское село 🗺

Довольно поучительная история от ребят из Авито.

Коротко о сюжете: команда выкатила фичу «Лёгкое резюме». Метрики растут, все радуются. Через неделю обнаруживают, что 45000 резюме создано в селе с населением 7000 человек 😬

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

Что из этого можно вынести:
1. Интеграцию надо проверять с каждым клиентом отдельно.
Android, iOS, web — разные клиенты с разной реализацией. То что работает на одном, может сломаться на другом. Особенно при горящих сроках и спешке.

2. Думай не только про happy path.
Что происходит когда данные некорректны, поле пустое или пользователь сделал что-то неожиданное? Такие сценарии важно проработать и описать ещё на этапе анализа, иначе система сама решит как себя вести.

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

Полная история: Читать 📚

А у вас были баги, которые потом превращались в полноценное расследование?

IT АНАЛитика | Подписаться

Ты точно умеешь писать документацию? 📝

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

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

Вот одни из самых частых ошибок:

1. Внутри много много мяса, мало теста.🥟
Длинные нагромождённые предложения, где много слов и смысл быстро теряется.

Плохо🤡:
Сервис проверки клиента предназначен для осуществления проверки корректности введённых пользователем данных в рамках процесса оформления кредита с учётом действующих ограничений и бизнес-правил»

Хорошо🤩:
Сервис проверяет данные клиента при оформлении заявки на кредит.

Лучше несколько коротких предложений, чем одно гигантское.

2. Жаргон в документах 🤓куку епта
Если в чате написать "пофиксить", "задизейблить", "дропнуть" и.т.д — ок.
То в документации такое уже не ок.

Кто-то может не знать ваших слов или неправильно их интерпретировать. Лучше исключить разночтение заранее.

3. Масло маслянное🤩
Тавтология и бессмысленные повторы только ухудшают восприятие. Если можно написать короче — пишите короче.

«Система должна обеспечивать возможность предоставления доступа пользователям» → достаточно «Система предоставляет доступ пользователям».

«Происходит процесс авторизации пользователя» → «Пользователь авторизуется».

«Выполнить осуществление проверки данных» → «Проверить данные».

«Производится выполнение логирования ошибок» → «Ошибки логируются».

«Происходит процесс сохранения данных в базу данных» → «Данные сохраняются в базу».

4. Противоречия между разделами⚡️
В начале написал одно, в другом разделе уже другое. Лучше не торопиться и лишний раз перечитать документ/задачу/письмо, перед тем как отдавать.
Криво напишите -> Разраб криво сделает -> Тестер криво проверит -> Баг

5. Термины без расшифровки 😏
У вас могут быть специфичные термины внутри продукта, которые знают не все. Через полгода новый человек откроет вашу документацию и вообще не въедет что и как вы тогда реализовывали.

Используете локальный термин — лучше расшифруйте.

P.S. Всё никак не могу дойти до книги «Пиши, сокращай», так и просится.

Часто ловите такое за собой или за коллегами? Я лично постоянно встречаю первый и третий пункт👇

IT АНАЛитика | Подписаться

Как выявить х*евое требование?🗑

Если вы не работали с такими требованиями, то можно сказать, и не работали в IT.

Бизнес иногда приносит ТАКОЕ, от чего вполне может развиться выгорание или ПТСР.
Конечно, можно смириться и делать что скажут жестко осуждаем такой подход и никому не советуем.

Но задача аналитика не просто принять требования и оформить, а разобраться — точно ли нужно делать именно так? И если нет, донести это без скандала.

Вот как можно разложить это по шагам:

1. Сначала идентифицируй требование🧐
Прежде чем паниковать, задай себе три вопроса:
⏺Если это не реализовать, бизнес-потребность всё равно закроется?
⏺Можно закрыть это имеющейся функциональностью или сделать проще?
⏺Есть ли риски в реализации этого требования?

Часто уже на этом шаге становится понятно, что требование можно упростить или вообще выкинуть.

2. Выяви истинную потребность🔍
Бизнес часто говорит что хочет, но не всегда понимает что ему на самом деле нужно.
Копай глубже:
💬Какую задачу он пытается решить?
💬Что произойдёт, если это не сделать?
💬Есть ли ограничения, которые не дают рассматривать другие варианты?

Если ограничения есть и альтернатив нет, то сразу переходи к шагу 4.

3. Предложи альтернативы 💡
Не просто скажи «это плохо/делать не будем/вы не шарите», а покажи варианты:

➡️ Вариант 1 — что хочет бизнес.
Опиши честно, какие трудности это создаст. Без субъективного «это тупо/сложно/некрасиво», только сухие факты. Обычно после оценки и сроков этот вариант сам отметается 🙂

➡️ Вариант 2 — некий костыль.
Может, можно сделать небольшую доработку уже существующего функционала? Обычно это самый дешёвый и быстрый вариант. Но не всегда самый правильный, тут важно обсудить его с архитектурой, потому что иногда костыль это очень плохо!!!!!!!

➡️ Вариант 3 — самый трушный.
Решение, которое закрывает потребность бизнеса с минимальными рисками. Да, может быть дороже, но в долгосрок все выигрывают и переделывать точно не придётся.

4. Зафиксируй ограничения и риски 📝
Бывает, бизнес хочет эту зелёную кнопку «ну вот тока тут». Не всегда получается переубедить, такое иногда бывает.

Да ты че? Базару нет

Но перед тем как брать в работу, обязательно зафиксируй все риски и ограничения письменно. Пропиши возможные последствия и способы их устранения.
Если на демо или ПСИ кинут предъяву, сможешь уверенно и без задней мысли сказать: «А Я ВАМ ГОВОРИЛ!!!!!!!!!!!!!!!»

5. Полный газ👍
Всё согласовано, риски зафиксированы, спокойно приступаешь к аналитике.

Главное помни: твоя задача не просто выполнить требование, а помочь бизнесу получить качественный результат. Иногда это значит задать неудобный вопрос:

"Подождите, коллеги. Я вас правильно понял? Вы хотите сделать какую-то х*ету?

А вам часто прилетают плохие требования? Как справляетесь? 👇

IT АНАЛитика | Подписаться