Софт-скиллы для начинающего в IT
В IT редко работают в одиночку. Даже джуниор ежедневно пишет в чат, уточняет задачу, показывает результат, принимает ревью кода. Слабая коммуникация на работе выглядит как "не тянет", хотя технические навыки могут быть в порядке.
Hard skills (жёсткие навыки) — что вы умеете делать: язык программирования, Git, SQL.
Soft skills (мягкие навыки) — как вы работаете с людьми и собой: ясные письма, вопросы, обратная связь, самоорганизация.
Базовый набор для старта
| Навык | Практика |
|---|---|
| Уточнять задачу | "Правильно ли я понял: нужно X к дате Y? Что не входит в задачу?" |
| Писать структурно | Контекст → проблема → что пробовали → вопрос |
| Давать статус | "Застрял на Z, нужна помощь" лучше, чем молчание три дня |
| Принимать фидбек | Ревью кода — про код, не про вашу ценность как человека |
| Признавать "не знаю" | "Не знаю, разберусь за N часов и отпишусь" — нормальная фраза |
| Документировать решение | Короткая заметка "как починил" экономит команде время |
Плохие и хорошие сообщения в чате
Запрос помощи
Плохо
не работает, помогите
Хорошо
Контекст: ветка feature/login, локально Windows 11, Node 20.
Проблема: npm run dev падает с EADDRINUSE на порту 3000.
Пробовала: закрыла старый терминал, перезапуск ПК — то же.
Вопрос: можно ли сменить порт в .env или лучше найти процесс на 3000?
Дедлайн: демо завтра в 15:00.
Статус по задаче
Плохо
всё ок
(при том что срок сорван)
Хорошо
Задача AUTH-42: API готово, фронт на 70%. Риск — нет макета для экрана сброса пароля.
План: завтра до 12:00 закрою happy path, вечером созвон 15 мин для уточнения макета.
Ревью чужого кода
Плохо
ужасный код, кто так пишет
Хорошо
Строки 45–52: при пустом `userId` будет NPE. Предлагаю guard в начале функции
или тест на пустой ввод. Могу скинуть пример из нашего `utils/validate.ts`.
Отказ от лишней работы
Плохо
это не моя работа
Хорошо
Сейчас в приоритете тикет PAY-10 к пятнице. Рефакторинг модуля отчётов могу взять
со следующего спринта, если сдвинем приоритет — давайте согласуем с @lead.
Извинение за задержку
Плохо
извините!!!!!!!!!
(без плана)
Хорошо
Извиняюсь за сдвиг срока на 1 день — недооценил интеграцию с SSO.
Сегодня до 18:00 отдам PR с тестами, утром созвон 10 мин для демо.
Больше примеров — чаты и почта, этика переписки.
Коммуникация в чате и на созвонах
- Один тред — одна тема; длинное — в документ или тикет.
- На созвоне камера по договорённости; если без видео — активнее пишите в чат.
- Не пинговать "есть кто?" без контекста — сразу суть и дедлайн.
- Реакции emoji — ок для "принял", не замена отчёта по задаче.
- @mention — только когда нужен ответ человека, не вся компания.
Этикет встреч
До встречи
- Прочитать повестку и материалы за 5–10 минут.
- Проверить микрофон и камеру заранее, не в первую минуту звонка.
- Для демо — открыть вкладки, отключить уведомления.
В начале
- Представиться, если в созвоне новые лица.
- Уточнить цель и время: "У нас 30 минут, цель — выбрать вариант API".
Во время
- Не перебивать; короткое "согласен" или поднятая рука в Zoom/Teams.
- Говорить по делу; детали в чат или follow-up документ.
- Фиксировать решения: кто, что, к когда — в конце или в протоколе.
После
- Отправить краткое резюме в тред: решения, action items, ссылки.
- Если опоздали — не требовать пересказа всего; прочитать запись или notes.
Работа с неопределённостью
IT-задачи часто сформулированы размыто. Полезные вопросы:
- Какой результат считается готовым?
- Есть пример или макет?
- Какие ограничения — время, стек, безопасность?
- К кому идти при блокере?
- Что не нужно делать в этой итерации?
Такие вопросы задают и опытные инженеры — это часть профессии.
Метод STAR на собеседовании
STAR — структура ответа на поведенческие вопросы:
- Situation — ситуация
- Task — ваша задача
- Action — что сделали
- Result — результат
Пример 1. Конфликт в команде
Вопрос: Расскажите о разногласии с коллегой.
S: На учебном проекте мы делали API; напарник хотел GraphQL, я — REST под дедлайн хакатона.
T: Нужно было согласовать подход за один день, чтобы не дублировать работу.
A: Составили таблицу: срок, опыт команды, требования жюри. Предложили REST для MVP и GraphQL как stretch goal. Записали решение в README.
R: Уложились в срок, жюри оценило документацию; напарник позже изучил GraphQL на pet-проекте.
Пример 2. Срыв срока
S: Фриланс — лендинг для клиента, оценка 3 дня.
T: Доставить вёрстку и форму обратной связи.
A: На 2-й день выяснилось, что нет брендбука. Сразу написал клиенту, предложил 2 варианта палитры и сдвиг на 1 день с приоритетом блоков.
R: Клиент выбрал вариант за вечер; сдвинули релиз на день без конфликта, получил повторный заказ.
Пример 3. Обучение новому
S: На стажировке дали задачу в незнакомом фреймворке.
T: Исправить баг в модуле отчётов за неделю.
A: Первые 2 дня — официальный tutorial, параллельно мини-репро бага. В середине недели показал ментору черновик PR с вопросами, не в последний день.
R: Баг закрыт, добавил тест; ментор включил меня в ревью похожих тикетов.
Пример 4. Ошибка в продакшене (учебный / стажировка)
S: На тестовом стенде после деплоя упала авторизация.
T: Быстро откатить и понять причину.
A: Сообщил в чат сразу, откатил релиз по инструкции DevOps, задокументировал шаги в постмортем на 1 страницу.
R: Сервис восстановлен за 20 минут; добавили чек-лист перед деплоем.
Подготовьте 3–5 своих историй. См. собеседования, вопросы работодателю.
Сценарии конфликтов
Коллега резко критикует PR
- Не отвечать в тоне сразу — пауза 10 минут.
- Отделить факты от тона: какие замечания по коду обоснованы?
- Ответить по пунктам: "Согласен с п.2, в п.4 добавлю тест".
- Если тон системный — к тимлиду один на один, без публичного суда.
Заказчик меняет требования в последний день
- Зафиксировать новое требование письменно.
- Оценить влияние на срок честно.
- Предложить варианты: сдвиг даты, урезание scope, доп. оплата (на фрилансе).
- Не молча работать ночь — цифровое благополучие.
Вы не согласны с решением тимлида
- Кратко изложить аргументы и риски в документе или комментарии.
- Попросить 15 минут обсудить.
- После решения лида — выполнять или эскалировать по процессу компании, не саботировать.
Вас перебивают на созвонах
- Использовать чат: "Допишу мысль в треде".
- Попросить модератора: "Мне 2 минуты на демо".
- На ретро предложить правило очереди выступающих.
Удалённая работа
- Рабочие часы — согласовать часовой пояс и окна доступности.
- Статус — emoji в Slack/Teams или текст "обед до 14:00".
- Документы вместо созвонов — асинхронное решение, когда нет срочности.
- Граница дом/работа — отдельное место или ритуал "конец дня".
- Не писать в личку в нерабочее время без договорённости.
- Камера уставшего человека — не обязательна каждый день; важнее голос и участие.
Подробнее — удалёнка, удалённая работа — раздел.
Типичные ошибки на удалёнке
| Ошибка | Лучше |
|---|---|
| Молчать 2 дня при блокере | Статус и вопрос в тред |
| Работать из кровати без графика | Стол, эргономика |
| Домашние шумы на созвоне без предупреждения | "Сегодня фон — дети, буду в mute" |
| Переписка только голосовыми | Текст с таймкодами или summary |
Обратная связь
Как давать
- Конкретика: не "плохо", а "нет теста на граничный случай".
- Один-два главных пункта, не 20 мелочей за раз.
- Предлагать альтернативу или ссылку на гайд.
Как принимать
- Сначала понять, не оправдываться.
- Уточнить: "Правильно ли понял, нужно вынести валидацию в middleware?"
- Благодарить за время ревью — даже если не согласны.
Чего избегать
- Молчаливая переработка вместо сообщения "не успеваю к сроку".
- Снобизм — "это для слабаков, я всё сам".
- Токсичность в чатах — сарказм без доверия разрушает команду.
- Голосовые сообщения в рабочих чатах без согласия коллег.
- Пассивная агрессия в публичных тредах.
- Обещания без оценки — "сделаю за час" на незнакомую задачу.
Как тренировать
- Учебные проекты в паре или с ментором.
- Писать README к pet-проекту — привычка объяснять решения.
- Участие в code review на курсах (или попросить друга посмотреть код).
- Английский в IT — для документации и части команд.
- Цифровое благополучие — устойчивый темп учёбы.
- Ролевые упражнения: пересказать задачу другу за 2 минуты.
Софт-скиллы и карьера
- На собеседовании оценивают и коммуникацию.
- При повышении важны менторство и влияние без должности.
- Мифы про "достаточно только кода" вводят в заблуждение.
Daily standup — примеры
Плохо
Вчера работал, сегодня буду работать, блокеров нет
Хорошо
Вчера: закрыл тикет AUTH-12, PR в ревью.
Сегодня: тесты для edge case logout, созвон с дизайном в 14:00.
Блокер: нет доступа к staging — нужен доступ от @devops.
Формат вчера / сегодня / блокеры — стандарт в Agile. Кратко, без монолога 10 минут.
Письмо на email
Плохо
Тема: срочно!!!
Текст: вы так и не ответили, это безобразие
Хорошо
Тема: [PAY-10] Уточнение по сроку интеграции Stripe — до 12.06
Добрый день, Анна.
По задаче PAY-10: API готово, ждём webhook secret для staging.
Без него не могу завершить тесты к пятнице.
Можете прислать или назначить контакт в банке?
Спасибо,
Иван
Эскалация проблемы
- Уровень 1 — тимлид в личку с фактами и дедлайном.
- Уровень 2 — письмо с копией заинтересованных, если нет ответа 24–48 ч (зависит от культуры).
- Не эскалировать публично в общий чат на 50 человек без попытки личного контакта.
Хорошая эскалация
Контекст: 3 дня нет доступа к staging, тикет INFRA-88.
Влияние: не могу сдать спринт-цель PAY-10 к пятнице.
Просьба: выдать доступ или альтернативный стенд до завтра 12:00.
Что пробовал: писал @ivan, @maria, обновлял тикет.
Ещё примеры STAR
Пример 5. Дедлайн под давлением
S: Релиз в пятницу, за день до — критический баг в оплате.
T: Найти причину без отката всего релиза.
A: Пара с коллегой разделила фронт и бэкенд, завели war room в чате на 2 часа, каждые 30 минут статус PM.
R: Баг исправлен, релиз в окне, постмортем без поиска виноватых.
Пример 6. Менторство джуниора (на стажировке)
S: Новичок в команде боялся задавать вопросы.
T: Помочь влиться за две недели.
A: Договорились о 15 минут "глупых вопросов" ежедневно, дал шаблон сообщения в чат, первый PR разобрали вместе.
R: Джуниор сам закрыл два тикета на третьей неделе.
Онбординг — что спросить в первую неделю
- Где документация и кому писать, если устарела?
- Какой чат для срочного, какой для асинхронного?
- Как оформить отпуск и больничный?
- Где тестовый стенд и как получить доступ?
- Кто ревьюит PR по умолчанию?
Записать ответы в личную заметку — это не слабость, а профессионализм.
Невербальная коммуникация на видеозвонках
- Смотреть в камеру при коротком выступлении — создаёт контакт.
- Кивок или "угу" при чужой речи — сигнал, что вы слушаете.
- Mute, если шум за спиной — уважение к группе.
- Не есть на камеру на общем созвоне без крайней необходимости.
Кросс-культурные команды
- Часовые пояса указывать в скобках: "15:00 MSK / 12:00 UTC".
- Идиомы и сленг — проще; если английский не родной — это нормально.
- Письменное резюме после устного созвона снижает недопонимание.
См. английский в IT.
Частые вопросы
Интроверт — это проблема в IT?
Нет. Важна ясная письменная коммуникация; созвоны можно минимизировать договорённостями.
Как не бояться задавать вопросы?
Формулируйте по шаблону контекст-проблема-попытки-вопрос. Вопрос после 30 минут самостоятельной работы — норма.
Ревью задело — что делать?
Отложить ответ, разобрать по фактам, обсудить с ревьюером один на один.
Нужен ли идеальный русский?
Достаточно ясности. Опечатки исправляются; путаница в требованиях — дороже.
Софт-скиллы можно измерить?
Косвенно: сроки, повторные эскалации, фидбек 360, удержание в команде.
Как просить повышение без конфликта?
Факты: закрытые цели, менторство, отзывы. Не ультиматум в общем чате.
Новый тимлид — как наладить контакт?
1:1 в первую неделю: ожидания, формат статусов, как он даёт фидбек.
Удалёнка и одиночество
Рабочий чат для быта команды; не заменяет друзей вне IT — баланс из цифрового благополучия.
Работа с тикет-системой (Jira, YouTrack, Linear)
- Заголовок тикета — глагол + объект: "Исправить валидацию email в форме регистрации".
- Описание — контекст, шаги воспроизведения, что ожидали и что получили (без паники в заголовке).
- Комментарий при блокере — сразу в тикет, не только в личку тимлида.
- Закрытие — коротко "как проверить fix" для QA.
Парное программирование
- Driver печатает, navigator смотрит и подсказывает.
- Меняться каждые 25–40 минут.
- Новичку нормально быть navigator первые сессии — учитесь читать чужой код.
- После сессии — 2 пункта "что узнал" в личную заметку.
Обратная связь руководителю (вверх)
- Факты и предложение: "За спринт 3 задачи сорвались из-за смены приоритетов в середине недели. Предлагаю freeze приоритетов до среды".
- Не публичный конфликт в ретро без попытки 1:1.
- Иерархия — уважение не равно молчание.
Активное слушание
- Перефразировать: "Правильно ли я понял, что к пятнице нужен только API без UI?"
- Не готовить ответ, пока человек говорит.
- Записать цифры и даты в тот же момент — не "запомню".
Шаблон сообщения о задержке
Тема: [TICKET-ID] Сдвиг срока на N дней
Причина (1–2 предложения):
Новая дата:
Что уже готово:
Что нужно от вас:
Отправить до дедлайна, не после.
Работа с ментором
- Готовить список вопросов до созвона, не импровизировать.
- Показывать попытки — "пробовал A и B, не сработало".
- Благодарить и отчитываться, что сделали по совету — ментор видит прогресс.
- Не ожидать ответа в 23:00 — уважать границы.
Культура blameless postmortem
После инцидента команда разбирает процесс, не "кто виноват".
- Что случилось по времени.
- Что сработало при восстановлении.
- Что изменим в чек-листе.
Джуниор может участвовать — это учит зрелости, не стыду.
Письменная культура в open source
- Issue — один баг или одна фича.
- Вежливый тон: "Would it make sense to…" вместо приказов.
- Благодарность мейнтейнерам — они часто волонтёры.
Pet-проект с хорошими issues учит тому же, что и работа в корпорации.
Чек-лист софт-скиллов на испытательный срок
- Уточняю задачу до начала кода
- Пишу статус при блокере в тот же день
- Принимаю ревью без обороны
- Документирую "как починил"
- Знаю, куда эскалировать
- Соблюдаю тихие часы коллег на удалёнке
Одна фраза на каждый день
| День | Фраза |
|---|---|
| Понедельник | "Какой результат к пятнице?" |
| Вторник | "Что блокирует — напишу сегодня" |
| Среда | "Спасибо за ревью, поправлю п.1 и п.3" |
| Четверг | "Нужна ли помощь с моей стороны?" |
| Пятница | "Краткий итог недели в тред" |
Привычка важнее длинных тренингов по коммуникации.