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


@it_underside

#будниИТ

Как часто у вас на проекте съезжают сроки?

Скажу честно, не помню практически не одного большого проекта, когда сроки были 1 в 1 с запланированными, т.к. бизнес всегда накидывает требования, даже тогда когда продебы всё понятно, какая-нибудь пара функций превращается не в стори, а в настояих монстров… Просто верхнеуровневое планирование и сроки чае всего ставятся до реальной и детальной прорабтки БТ и это чаще всего бьёт по планам, так что старайтесь проводить бизнес анализ как можно раньше, чтобы требования звучали не просто, как реализовать что-то, а максимально четкие с понятным началом и концом и был понятен спектр работ.

Вобщем, чтобы избежать типичных ошибок и задержек в проекте из-за недостаточно проработанных бизнес-требований, старайтесть следовать этому чек-листу при начале работы (моё видение, с небольшим упором на статейки):

1️⃣Определение целей проекта
Четко сформулируйте, какие бизнес-цели должен достигнуть проект. Это должно включать как общие, так и специфические цели.

2️⃣Понимание потребностей пользователя
Определите, кто является вашими пользователями и какие их потребности должен удовлетворять ваш продукт или услуга.

3️⃣Формализация требований
Все требования должны быть задокументированы в понятной форме. Это включает функциональные и нефункциональные требования.

4️⃣Приоритизация требований
Определите, какие требования являются критически важными для запуска проекта, а какие можно реализовать позже.

5️⃣Определение метрик успеха
Установите четкие критерии, по которым можно будет оценить, успешно ли были реализованы требования и достигнуты ли цели проекта.

6️⃣Планирование ресурсов
Убедитесь, что у вас есть все необходимые ресурсы для выполнения проекта, включая время, бюджет и команду.

7️⃣Согласование с заинтересованными сторонами
Проведите встречи со всеми заинтересованными сторонами, чтобы обсудить требования и получить их одобрение перед началом проекта.

8️⃣Гибкость в требованиях
Будьте готовы к изменениям требований в процессе работы над проектом, но старайтесь контролировать их объем и влияние на общие сроки и бюджет.

9️⃣Прототипирование
Разработайте прототипы или MVP (минимально жизнеспособные продукты) для тестирования и уточнения требований с реальной обратной связью пользователей.

1️⃣0️⃣Регулярный пересмотр и анализ
Регулярно пересматривайте требования и ход выполнения проекта, чтобы своевременно выявлять и решать возникающие проблемы.

@it_underside

#будниИТ #КоманднаяРабота #Планирование #УправлениеПроектом

🧠Многозадачность и память и почему мы чувствуем себя самозванцами?

Вы когда-нибудь чувствовали, что не на своем месте на работе или в учебе, несмотря на все ваши достижения? Это может быть не просто неуверенность, а так называемый синдром самозванца, который часто усиливается из-за нашего стремления выполнять множество задач одновременно. Сколько раз это было)))

💡Многозадачность — это когда мы переключаемся между задачами, часто не давая себе времени полностью сосредоточиться на чем-то одном. Это может привести к тому, что наша память становится перегруженной. Мы начинаем забывать детали, делать ошибки и чувствовать, что работаем неэффективно. Пример из жизни, когда делаешь сразу несколько задач, то забываешь их статусы, технические параметры и так далее, я вот по несколько раз могу спросить аналитиков или разработчиков об одном и том же)))

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

🔍 Так что же делать?
1. Практикуйте однозадачность. Постарайтесь сосредоточиться на одной задаче за раз. Это поможет улучшить качество вашей работы и уменьшить стресс. Правда, так не всегда))) Тут баланс, но жизнь и работа всегда сопровождает множество ad-hoc))
2. Записывайте свои достижения. Ведите дневник успехов, где вы будете отмечать свои маленькие и большие победы. Это поможет вам вспомнить, как много вы уже достигли. Я стал их писать, иначе есть ощущение, что все не очень, но когда смотришь, что удалось сделать, становится приятно.
3. Общайтесь с окружающими. Разговоры с коллегами и друзьями могут помочь вам осознать, что многие из них переживают те же самые чувства.

✨ Важно помнить, что быть человеком — значит не быть идеальным. Мы все можем чувствовать себя перегруженными или сомневаться в себе, но это не делает нас самозванцами. Это делает нас человечными.

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

@it_underside

Почему пора отказаться от REST API в пользу GraphQL?


🔍Сегодня разбирается в технологических трендах! (понятно, что это не что-то новое, но GraphQL не так часто используем, как хотелось бы). Сегодня поговорим о том, почему REST API уступает место более современному и удобному GraphQL.

REST API

🟢Преимущества
1. Простота использования. REST легко понять и имплементировать, что делает его отличным выбором для начинающих.
2. Широкая поддержка. REST поддерживается практически всеми веб-сервисами и библиотеками.

🔴Недостатки
1. Жёсткая структура. REST требует строгого соблюдения правил и методов (GET, POST, DELETE и т.д.), что ограничивает гибкость.
2. Избыточность данных. Клиенты часто получают больше данных, чем им нужно, что увеличивает нагрузку на сеть.
3. Много запросов. Для сбора разнородных данных необходимо делать множество запросов, что замедляет работу приложения.

GraphQL

🟢 Преимущества
1. Гибкость запросов. Клиенты могут запрашивать именно те данные, которые им нужны, не больше и не меньше.
2. Оптимизация сетевого трафика. GraphQL позволяет получить всю необходимую информацию в одном запросе, уменьшая количество обращений к серверу.
3. Сильная типизация. Наличие строгой типизации упрощает разработку и уменьшает количество ошибок на этапе выполнения.

🔴 Недостатки
1. Сложность. Из-за своей гибкости GraphQL может быть сложнее в освоении и требует более сложной реализации на сервере.
2. Проблемы с производительностью. Сложные запросы могут негативно сказаться на производительности сервера, если не уделить достаточно внимания оптимизации.

🔄 Заключение
Переход на GraphQL представляет собой шаг вперёд к более гибкой, масштабируемой и эффективной разработке веб-приложений. Хотя он требует некоторого времени для изучения и адаптации, преимущества перевешивают начальные трудности. Рассматривайте GraphQL как инвестицию в будущее вашего проекта! Ещё подмечу, крайне релевантно для корпоративной архитектуры.

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


@it_underside

🟢 Летний ИТ-лагерь Т1.Дебют: мы начинаем! ❤️

💃 Ты студент и мечтаешь попасть в мир больших идей и технологий? Присоединяйся к ИТ-лагерю Т1.Дебют!

⚡️ Это шанс прокачать свои навыки и начать звездную карьеру: финалисты лагеря смогут попасть на оплачиваемую стажировку, а более опытные — получат оффер от Холдинга Т1!

🐈 Зачем участвовать?

✅ развитие навыков при поддержке менторов, работа над реальными кейсами
✅ крутое комьюнити единомышленников со всей страны и техновайб
✅ карьерные консультации и лекции от ведущих ИТ-экспертов
✅ защита исследовательского проекта, хакатоны и квизы

🖥 Как проходит обучение?

ИТ-лагерь проходит в два этапа: 1 месяц онлайн-обучения и неделя летнего офлайн-буткемпа. Проезд, питание, проживание - за наш счёт!

Выбирай направление: 💻 разработка Java, разработка JS+React, 🪲 тестирование, 💻системный анализ.

👍 ИТ-лагерь Т1.Дебют — место для старта звездной карьеры в ИТ!

➡️ Отправляй заявку на сайте до 31 мая вот здесь! ⏰

Быстрый набор команды в IT. Риски и плюсы!

Привет! Думал не смогу даже голову из своего проекта вытащить, но всё же немного времени появлось и пока накатывается хотфикс расскажу про быстрый набор ИТ команды. Костяк команды мне удалось собрать за месяц, а за два закрыл полностью набор. Но так ли всё радужно? Мммм, не совсем, с двумя специалистами я всё-таки ошибся), наша команда состоит из 10 человек если что. И да, уж очень нужны были спецы и по всем факторам они полностью подходили от хардов до софтов, но по факту, некоторые проблемы со специалистами, которых ты нанимаешь, можно увидеть только на практике и при выполнении реальных задач, а именно дав индивидуальные задачи и затем посмотрев результат.

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

🛑 Риски быстрого набора

1️⃣ Неподходящие кандидаты.
Спешка может привести к выбору сотрудников, которые не соответствуют требованиям проекта или культуре компании, возможно культуре команды.

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

3️⃣ Нарушение культуры. При срочном найме может быть недостаточно времени для адекватной оценки соответствия культурных ценностей кандидата компании, что может привести к конфликтам и дисбалансу в команде.

4️⃣Переплата за скорый найм
Если хочешь взять кого-то быстро, то нужно и предложения делать соответствующие, иначе спец будет долго думать, а времени нет, а возможно ему и так комфортно в другой компании. И обратная ситуация, работник может быть финансово переоценен.


🎯 Плюсы быстрого набора

1️⃣ Сокращение времени до запуска проекта.
Быстрый набор команды позволяет сократить время до начала работы над проектом и оперативно реагировать на изменения в рыночной ситуации.

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

3️⃣ Увлечение новых талантов.
Быстрый набор может привлечь к вашей команде талантливых специалистов, которые ценят быстрый темп работы и готовы к вызовам.

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

@it_underside

#ITLife #Рекрутмент #Команда #найм #hr

P.S. вчерашний пост, вот только забыл его отправить

💀Более 40 дефектов на младших контурах;
⚰️первая команда в банке, которая дошла до продакшена на полностью импортозамещенном пайпе;
🧛‍♂️более 40 артефактов за 3 месяца;
💩12 микросервисов на scala, java и Lua;
💪4 поднятых контура;
😇 собственные кластера flink, tarantool....

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

@it_underside

Flink кластер, а как лучше?

Что такое флинк и более подробное описание тут - ХАБР

💎Баре метал

Производительность. В среднем, баре метал может обеспечить высокую производительность, а также прямой доступ до железа без посредников и динаминческого распределения ресурсов.
Масштабируемость. Ограничена физическими ресурсами серверного оборудования. Для масштабирования требуется добавление новых серверов. Если ты в большой корпорации, то подумай 10, нет 100 раз перед тем как брать, а то нового обородувания может долго не быть.
Надежность. Традиционно более надежная, поскольку нет дополнительного уровня виртуализации, но так как компаниях не особо любят прям на железо ставить, то сюда меньше ресурсов дают из-за чего резервирования часто нет полноценного, если ты не важнейшая информационная система для компании.

❓Виртуальная машина

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

🔘Кубернетес кластер

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

Доброго утра, понедельника!
Всем кто будет на конференции «Анализ и управление проектами» заходите на доклады:

Первый доклад - «Как собрать команду экспертов в сжатые сроки»
О чем буду говорить:
1️⃣Боли и проблемы классического подхода по набору команды экспертов на проект
2️⃣Почему «Хантеры» вам не помогут, и что делать, когда проект уже начался?
3️⃣Сила профессиональных связей и рекомендаций
4️⃣Блоги и сообщества - задействуем по максимуму
5️⃣Что делать, если у вас маленькая, средняя или огромная компания?
6️⃣Чек-лист для быстрого набора
7️⃣Мой кейс, проблемы, и то, к какой ситуации мы пришли
Трек по Soft skills, управление командой проекта

Второй доклад - «Ускоряем разработку на 30-60% с помощью ИИ»
Тезисы:
1️⃣Классическая разработка
2️⃣Боли классической разработки для менеджмента и сотрудников
3️⃣Как мы начали разработку
4️⃣Возможности автоматизации
5️⃣Сравнение Copilot, Chatgpt, Gigachat, YandexChat
6️⃣Где можно повысить производительность
7️⃣Рекомендации
Трек по ИИ


@it_underside

Слово дня идемпотентность👁

Утро доброе! Как часто вы встречаетесь с данной терминологией? Думаю, не часто, а возможно только в универе) но когда мы нашли баг в БД Tarantool их базового модуля CRUD, то нам пришлось не раз вспомнить данный термин и погрузиться в него, а главное обосновывать идемпотентные ли были совершенны операции или нет. Давайте сделаем краткий ликбез, надеюсь вам будет полезна эта краткая статейка. (на полноту картины не замахиваюсь)

🆔Ссылка на статейку🆔

ВСЕМ ПРОДУКТИВНОЙ ПЯТНИЦЫ!!!!

➿➿➿➿➿➿➿
✈️ @it_underside