Как понимать разработчиков
Личный опыт перехода из госучреждения в айти и готовый алгоритм, как выучить язык технарей без программирования
Шесть лет в госучреждении научили меня двум вещам: безупречной работе с документами и тому, что слово «регламент» не терпит импровизации. Мой мир был предсказуем. До того дня, когда я оказался в open-space IT-компании.
Первый же митинг стал шоком. Коллеги сыпали фразами, будто заклинаниями: «Нужно закоммитить фичу в прод, а то легаси не пройдет код-ревью». Я кивал с умным видом, а потом судорожно гуглил каждое второе слово. Я чувствовал себя актером, забывшим текст на премьере.
Оказалось, я не один. С этой проблемой сталкивается каждый второй нетехнический специалист в IT. Мы платим высокую цену за непонимание: неэффективные совещания, ошибки в постановке задач, замедление проектов и, в конечном счете, — финансовые потери для бизнеса.
Я потратил много времени на то, чтобы не просто выучить термины, а понять логику, которая за ними стоит. Я обнаружил, что любой, даже самый сложный концепт, можно объяснить через простые аналогии из жизни. Этот опыт я систематизировал в книге, но главные инсайты готов сформулировать прямо здесь.
Вот карта, по которой вы сможете сориентироваться в IT-джунглях:
1. Фронтенд и бэкенд — это ресторан.Забудьте о сложных определениях.
- Фронтенд — это зал для гостей: интерьер, меню, официанты. Всё, что видит и с чем взаимодействует пользователь.
- Бэкенд — это кухня: печи, холодильники, повара. То, что скрыто от глаз, но где готовится главный продукт.
- API — это официант, который передает заказы с зала на кухню и приносит готовые блюда обратно.
Практический вывод: Когда кнопка в приложении не работает, вопрос к фронтенду: «Официант вообще подходит к столу?». Вопрос к бэкенду: «А на кухне есть продукты для этого блюда?».
2. Микросервисы и монолит — это транспорт.
- Монолит — это грузовой поезд. Огромный, надежный, но чтобы заменить одно колесо, нужно остановить весь состав.
- Микросервисы — это колонна грузовиков. Если один сломался, остальные продолжают ехать. Но теперь нужна диспетчерская, чтобы управлять всем движением.
Практический вывод: Стартапы часто начинают с поезда (монолит), потому что это проще. Когда бизнес растет и требует гибкости, переходят на грузовики (микросервисы).
3. Спринт, бэклог и дейлики — это стройка.
- Бэклог — это полный список того, что нужно построить, от фундамента до покраски забора.
- Спринт — это конкретный этап работ на этой неделе: «залить фундамент и положить кирпич для первого этажа».
- Дейлик — это пятиминутный разговорлетучка прораба с бригадой: «Что сделали вчера? Что будем делать сегодня? Какие проблемы?».
Практический вывод: Не требуйте от команды «построить весь дом» за один спринт. Просите то, что запланировано на текущий этап.
Эти аналогии — лишь первый шаг. Чтобы говорить с разработчиками на одном языке, нужно понять их философию, а не просто заучить слова. Нужно видеть разницу между Java и Python, знать, когда выбирают нативную разработку, а когда — кроссплатформенную, и как устроена клиент-серверная архитектура изнутри.
Я написал книгу «Птичий язык: Как говорить на языке разработчиков, не написав ни строчки кода» именно для этого. Это не словарь, а система, которая выстраивает в голове целостную картину IT-мира.
Для кого это будет максимально полезно:
- Менеджерам и продактам — для точечной коммуникации с командой.
- HR и рекрутерам — для понимания, кого они ищут и о чем говорят кандидаты.
- Предпринимателям — для грамотной оценки сроков, рисков и постановки ТЗ.
- Специалистам из других сфер — для уверенного старта в IT.
Книга уже доступна на Литрес. Написать ее мне помог опыт работы с командой настоящих энтузиастов своего дела, где я проверил все эти гипотезы на практике.