Общая цель
Не «сделать десять экранов», а помочь человеку решить задачу. Цель даёт смысл техническим решениям.
ПУТЕВОДИТЕЛЬ В IT / 01проект на Сбер-тренажере
Технологии создают
не сами себя.
Их создают люди.
Кто придумывает продукт, пишет код, исследует пользователей и делает так, чтобы всё работало. Разбираемся в IT-командах — от первой идеи до миллионов строк кода.
Найти свою профессию ↗НЕ ТОЛЬКО ПРОГРАММИСТЫ.
НЕ ПРОСТО НАБОР ДОЛЖНОСТЕЙ.
НЕ ПРОСТО НАБОР ДОЛЖНОСТЕЙ.
РАЗНЫЕ НАВЫКИ. ОДНА ЦЕЛЬ.
01 / ИССЛЕДОВАНИЕЧто нужно человеку?
«Хочу накопить на поездку,
но не понимаю, с чего начать».
Интервью → гипотезано не понимаю, с чего начать».
02 / РАЗРАБОТКА
async function createGoal() {
await api.save(goal);
return 'Первый шаг сделан';
}Тесты пройдены
03 / РЕЗУЛЬТАТ
От разговора к работающему продукту →Моя поездка24 000 ₽Из 60 000 ₽ · учебный пример
01 / УСТРОЙСТВО КОМАНДЫ
Одна команда.
Несколько способов
думать.
IT-команда — это люди, которые совместно решают задачу с помощью технологий. Их объединяет не язык программирования, а результат.
Пользователь должен получить полезный, понятный и надёжный продукт. Для этого нужно разобраться в проблеме, выбрать решение, спроектировать его, реализовать, проверить, запустить и развивать. Ни одна профессия не закрывает весь этот путь в одиночку.
Состав зависит от масштаба, отрасли и стадии продукта. В маленьком стартапе один человек совмещает несколько ролей. В большой организации часть специалистов работает в общей платформенной или экспертной команде. Ниже — модели, а не универсальный штатный список.
Разные компетенции
Исследования, дизайн, инженерия, данные и качество дополняют друг друга, а не конкурируют.
Понятная ответственность
Команда договаривается, кто принимает решение, кто делает работу и кого нужно вовлечь.
Обратная связь
Рабочий продукт, поведение пользователей и ошибки помогают пересмотреть первоначальную идею.
02 / ЖИВОЙ ПРИМЕР
Как рождается
одна функция.
Представим учебное банковское приложение.
Команда делает «Цель накопления».
Выберите этап — и проследите связи.
учебный банк
Портреты иллюстрируют роли, а не сотрудников Сбера⌂ Цели ↗
- Кто участвует
- Что получается
- Важный вопрос
Порядок условный: исследования, дизайн, код и проверка часто идут параллельно. После релиза цикл начинается заново.
03 / ФОРМАТЫ РАБОТЫ
Команды бывают
разными.
Продуктовая команда отвечает за пользовательский результат. Платформенная — помогает другим командам. Название отдела ещё не объясняет его цель.
Должность ≠ роль ≠ команда
Должность — название в штатном расписании. Роль — функция и ответственность в конкретной работе. Команда — группа с общей целью. Backend-разработчик может быть техническим лидером, а дизайнер — работать сразу с несколькими командами. Возможность совмещения не означает, что любое совмещение полезно.
04 / АТЛАС ПРОФЕССИЙ
Найдите свою
точку приложения.
Разберите каждую профессию: обязанности, навыки, рабочие результаты, взаимодействие и первые шаги. Границы ролей различаются между компаниями.
НАЖМИТЕ НА ПРОФЕССИЮ, ЧТОБЫ РАЗОБРАТЬ ЕЁ
Ничего не найдено. Попробуйте другое слово или сбросьте фильтр.
05 / ОТ ИДЕИ ДО РЕЛИЗА
Код — только
часть маршрута.
В хорошем процессе нет стены между «бизнесом» и «техникой». Решения уточняются вместе, а результат проверяется не только фактом выпуска.
Понять проблему
Интервью, обращения в поддержку, аналитика и контекст бизнеса помогают выяснить, для кого существует проблема и насколько она важна. Команда не путает просьбу о конкретной кнопке с реальной потребностью.
Результат: описание проблемы, сегмент пользователей, гипотеза ценности.Выбрать решение и границы
Продакт, дизайнер, аналитики и инженеры сравнивают варианты. Учитывают ограничения данных, интеграций, безопасности и доступности. Определяют минимальное решение, которое действительно проверит гипотезу.
Результат: прототип, требования, критерии приёмки, оценка рисков.Спроектировать и реализовать
Инженеры согласуют API и модель данных, пишут код и тесты. Дизайнер уточняет состояния интерфейса: загрузку, ошибку, пустой экран. Code review помогает найти ошибки и распространить знания внутри команды.
Результат: изменения кода, автоматические проверки, документация решений.Проверить не только «счастливый путь»
QA и разработчики проверяют пограничные случаи, интеграции и регрессии. Специалисты по безопасности оценивают угрозы, команда — доступность и производительность. Непройденные критические проверки блокируют выпуск.
Результат: проверяемые свидетельства качества, исправленные дефекты.Выпустить управляемо
CI/CD автоматизирует сборку и развёртывание. Команда готовит мониторинг, план отката и поддержку. При необходимости применяет feature flags или постепенное включение для небольшой части аудитории.
Результат: доступная функция, наблюдаемость, готовность к инцидентам.Узнать, что изменилось
Команда смотрит на пользовательский результат, обращения и надёжность. Аналитик проверяет корректность событий и трактовки метрик. Если решение не помогло, меняют гипотезу, а не объявляют успех по количеству написанного кода.
Результат: выводы, следующий эксперимент, обновлённые приоритеты.06 / КАК ДОГОВАРИВАЮТСЯ
Процесс нужен,
чтобы работать.
Не наоборот.
Agile — подход к адаптивной работе. Scrum — конкретный фреймворк. Kanban — способ управлять потоком. Это не синонимы и не обязательный комплект для любой команды.
Scrum
Работа организуется в спринты. В Scrum Guide выделены три ответственности: Product Owner, Scrum Master и Developers. Developers — не только программисты: это участники, создающие пригодный к использованию инкремент. Tech Lead и Project Manager могут существовать в организации, но не являются отдельными ответственностями Scrum.
Первоисточник: Scrum Guide ↗Kanban
Команда визуализирует поток задач, ограничивает незавершённую работу и отслеживает время прохождения. Важно не просто передвигать карточки, а замечать очередь, блокировки и перегрузку. Спринты для такого управления потоком не обязательны.
Рабочие договорённости
Как принимаются решения? Что считается готовым? Кто реагирует на инцидент? Где хранится контекст? Чем меньше скрытых ожиданий, тем меньше конфликтов. Не каждая задача требует встречи: документ или короткое сообщение иногда полезнее.
Daily
Коротко сверить движение к цели и адаптировать план. Не отчёт руководителю и не место для всех технических дискуссий.
Refinement
Уточнить будущую работу: смысл, ограничения, зависимости и вопросы. В Scrum это деятельность, а не отдельное обязательное событие.
Review / демо
Обсудить результат со стейкхолдерами и дальнейшее направление. Показ экранов сам по себе ещё не делает встречу полезной.
Ретроспектива
Разобрать совместную работу и договориться о конкретном улучшении. Не поиск виноватого и не жалобы без последующих действий.
07 / РАБОТАТЬ ВМЕСТЕ
Стыки важнее
органиграммы.
Продакт ↔ инженеры
Продакт объясняет проблему и ожидаемую ценность. Инженеры предлагают варианты, оценивают ограничения и риски. Дата не становится реалистичной от того, что её громко объявили.
Дизайнер ↔ разработчик
Передаются не только макеты, но и поведение: состояния, адаптивность, доступность, тексты ошибок. Разработчик рано сообщает о технических ограничениях, а не после финального согласования.
Аналитик ↔ QA
Требования становятся проверяемыми сценариями. QA задаёт вопросы до написания кода: что произойдёт при повторном запросе, потере сети или недоступной интеграции?
Разработка ↔ эксплуатация
Сервис должен быть не только собран, но и наблюдаем. Логи, метрики, алерты и процедуры восстановления проектируются заранее, а не когда пользователь уже сообщил о сбое.
Что такое RACI и когда она полезна?+
R — Responsible: выполняет работу. A — Accountable: отвечает за решение или итог; для одного решения полезно иметь одного явно обозначенного A. C — Consulted: даёт экспертный вклад. I — Informed: получает информацию. Это способ договориться, а не инструмент снять коллективную ответственность за качество. Для маленькой команды часто достаточно короткого списка владельцев решений.
Как отличить здоровую команду от перегруженной?+
У здоровой команды ясные приоритеты, возможность обсуждать ошибки, доступ к пользователям и время на качество. Тревожные сигналы: всё «срочно», работа начинается без контекста, решения постоянно переигрывают, знания держит один человек, инциденты повторяются без разбора причин. Скорость не равна постоянным переработкам.
Что измерять кроме количества задач?+
Пользовательский результат, время прохождения изменений, частоту и причины сбоев, восстановление, объём незавершённой работы. Метрики нужно читать в контексте. Строки кода, story points и число закрытых тикетов не подходят для сравнения личной продуктивности людей с разными задачами.
08 / ВАШ ПЕРВЫЙ ШАГ
Не выбирайте название.
Выбирайте работу.
Интерес к конкретным задачам — полезнее случайного списка «самых перспективных» профессий. Попробуйте маленький законченный проект.
ЧТО ВАМ БЛИЖЕ?
Начните с любопытства.
Выберите интерес — предложим учебный эксперимент и профессии, которые стоит изучить. Это ориентир, а не профессиональная диагностика.
Проверьте интерес
Прочитайте описания ролей и попробуйте их реальные задачи. «Люблю компьютеры» — слишком широкая отправная точка.
Соберите основу
Разберитесь, как работает веб, как хранятся данные, что такое Git и как формулировать задачу. Глубина зависит от роли.
Доведите до результата
Маленький проект с объяснением решений, ограничений и выводов полезнее десяти незаконченных учебных работ.
Работайте с другими
Попросите обратную связь, обсудите требования, попробуйте командный проект. Профессиональные навыки включают коммуникацию.
09 / СЛОВАРЬ БЕЗ ТУМАНА
Слова, которые
будут встречаться.
10 / ЧИТАТЬ ДАЛЬШЕ
Не догма.
Карта для старта.
Названия ролей, границы ответственности и способы работы меняются от компании к компании. Этот атлас объясняет типичные практики и использует вымышленный банковский продукт, а не описывает внутреннее устройство Сбера.
Scrum Guide — ответственности, события и артефакты ↗Team Topologies — взаимодействие и типы команд ↗Google SRE — надёжность и эксплуатация ↗Примеры и описания профессий — учебное обобщение. Team Topologies — отдельная модель: stream-aligned, enabling, complicated-subsystem и platform teams; шесть форматов выше не выдаются за эту классификацию. Фото: Unsplash. Шрифт: Golos Text.