В IT-индустрии сложилась парадоксальная ситуация. Курсы по Python, тестированию и аналитике плодятся как грибы после дождя. Тысячи людей получают «корочки» и выходят на рынок, уверенные, что знают своё дело. Но на практике одного знания языка программирования или инструмента оказывается катастрофически мало.
Встречаются сотрудники, которые блестяще разбираются в конкретной технологии, но понятия не имеют, как работает продуктовый цикл, зачем нужна ретроспектива и почему тимлид не утверждает их пулл-реквест. Они путаются в подобных элементарных вещах, что не дает им расти. Чтобы стать настоящим профессионалом, нужно понимать, как работает система под названием «разработка программного обеспечения» в целом.
Фреймворки, языки и методологии приходят и уходят. Но существуют базовые принципы, общий подход и, что особенно важно, российские особенности. Они работают независимо от того, создаёте ли вы мобильное приложение для миллионов или сложную enterprise-систему.
Именно эту системную картину даёт книга Александра Литвинчука «Разработка программного обеспечения. Практическое руководство для новичков в IT-команде». Это путеводитель для начинающего специалиста любого профиля — разработчика, тестировщика, аналитика, продакт-менеджера или дизайнера.
О чём эта книга (и почему она не про код)
Автор, Александр Литвинчук — руководитель разработки CSI. Эксперт с 20-летним стажем, он прошел путь от программиста до руководителя крупных подразделений. Александр обладает международной сертификацией Scrum Alliance (CSM), ICAgile и Scaled Agile (SAFe Agilist), при этом в своей практике и книге делает ставку на перевод сложных процессов на язык здравого смысла и адаптацию мировых методологий под реальные задачи российского бизнеса.
Книга построена как практическое руководство, которое проводит читателя через все этапы погружения в IT-команду:
-
Часть I. Старт в IT-команде — здесь разбирается, какие компании вообще есть на российском рынке (техгиганты, средний бизнес, стартапы), чем аутсорс отличается от аутстаффа и продуктовой разработки, какие сегменты IT в России наиболее активны (финтех, телеком, e-commerce, госсектор, игровая индустрия). Без этого контекста новичок рискует попасть не туда, где ему реально интересно.
-
Часть II. Основы процессов разработки — жизненный цикл ПО от идеи до утилизации, принципы KISS, YAGNI, DRY, Fail Fast. И, конечно, гибкие методологии: Scrum и Kanban. Автор не просто пересказывает манифест, а показывает, как эти методологии работают (или не работают) в российских командах: что такое формальные ретроспективы и размытая роль владельца продукта.
-
Часть III. Командное взаимодействие — эффективная коммуникация, стендапы, ретроспективы, уточнение бэклога, демонстрации. Отдельно разобраны аварийные режимы и эскалация проблем. Есть даже разговорник новичка: как спросить, а не промолчать, как сообщить о блокере и не прослыть паникёром.
-
Часть IV. Участие нетехнических специалистов — это золотая жила для аналитиков, тестировщиков и менеджеров. Как собирать требования (CustDev, JTBD), как писать пользовательские истории и сценарии использования, что такое критерии приемки и ограничения. Детально разобраны виды тестирования, тест-кейсы, чек-листы, системы управления тестированием. И, конечно, качество ПО глазами разных ролей и работа с обратной связью.
-
Часть V. Инструменты и профессиональное развитие — здесь и про таск-трекеры (Jira, Яндекс Трекер, Trello), и про базы знаний (Confluence, Notion), и про CI/CD простыми словами. Отдельная глава посвящена искусственному интеллекту в работе IT-команды, о чём чуть позже.
Российская специфика: то, о чём молчат западные книги
Почти все учебники по разработке написаны под американский или европейский рынок. В них не встретишь:
-
объяснения, что такое импортозамещение и почему оно создаёт возможности для новичков;
-
разбора типов компаний с учётом российских реалий (например, что «технические гиганты» вроде банков или ритейла — это не IT-компании в чистом виде, и там свои правила);
-
специфики работы с госзаказчиками, 152-ФЗ, интеграции с ЕСИА и Госуслугами;
-
особенностей географического распределения: Москва, Питер, Казань с Иннополисом, Новосибирск — где какие шансы и как быть с удалёнкой.
Александр подробно разбирает все эти моменты. Например, он прямо говорит: «Удалённая работа — это визитная карточка IT-рынка, но новичку я не советую сразу стремиться к полностью удалённой работе. Если есть выбор, лучше отдать предпочтение гибридному режиму или даже работе из офиса». И поясняет почему — из-за неформального общения, быстрой помощи и «невидимых» процессов.
Российские реалии: «срочные задачи» и формальные ретроспективы
«В российских компаниях, особенно работающих по каскадной модели или с госзаказчиками, бывает обратная ситуация: задачи разбирают и утверждают за много месяцев до начала реализации. За это время могут поменяться и требования, и реалии, но процесс пересмотра может оказаться чрезвычайно сложным».
Или ещё хлеще: авралы и «срочные задачи» убивают поток. Александр приводит пример с Kanban: «Российский бизнес любит срочность. В Kanban-командах это выливается в то, что половина доски завешана красными стикерами «СРОЧНО!», которые срывают все планы и лимиты. Поток останавливается». И даёт совет: договоритесь сразу, сколько срочных задач может быть в работе.
Особенно показательно про ретроспективы. По учебнику они нужны для улучшения процессов, но в России часто превращаются в формальность или «разбор полётов» с поиском виноватых. «Люди могут молчать или говорить только о незначительных проблемах, итоги ретроспектив ни к чему не приводят — решения записываются, но не выполняются, что демотивирует команду». Автор даёт новичку простой, но сильный совет: на ретроспективе говорите о конкретных ситуациях («В прошлый вторник я потерял два часа, потому что не мог найти актуальные настройки») — это сдвигает разговор с абстрактного нытья на реальные улучшения.
Или про корпоративную культуру: «Культура ест стратегию на завтрак». Можно нарисовать идеальные OKR, но если руководитель пишет в общий чат в полночь и ждёт ответа, то все поймут, что регламент ничего не значит.
Практические инструменты: от онбординга до Performance Review
Одна из самых ценностных частей книги — детальные чек-листы и планы действий. Например, в главе 3 «Первые дни в команде» даётся план онбординга на 30, 60 и 90 дней. Что выяснить в первый день? Как настроить окружение по чек-листу? К кому обращаться с вопросами (и как правильно формулировать)? Что такое «бадди» и чем он отличается от наставника?
Отдельно разобрана тема оценки и обратной связи. Как вести журнал достижений, как готовиться к Performance Review, как составлять индивидуальный план развития (ИПР) и главное — как договариваться с руководителем в российских реалиях, где формальные критерии часто соседствуют с неформальными правилами. Даже даны фразы-шаблоны: «Я заметил, что мы часто тратим время на настройку окружения. Предлагаю попробовать создать для этого пошаговую инструкцию. Я готов взять это на себя».
Работа с требованиями: JTBD на пальцах (история про метро и машину)
Одна из сильных глав — про работу с требованиями. Автор аргументированно пишет: «Требования в разработке — это основа для всего. Плохо проработанные требования — это, в конце концов, недовольный заказчик, которому говорят, что «этого не было в требованиях»».
Чтобы вы не создали то, что никому не нужно, в книге разбираются методики CustDev (Customer Development) и JTBD (Jobs To Be Done). Вторую автор объясняет на простом и понятном примере:
«У меня есть автомобиль, но я езжу на работу на метро. Почему? Потому что на работу и с работы нужно ехать по пробкам, да ещё искать место для парковки. Проехать пару остановок на метро — лучшая идея, чем поехать на машине. Но при этом я регулярно использую автомобиль, чтобы съездить на дачу, за город, купить продукты или отвезти семью в гости. Метро лучше выполняет работу по доставке меня на работу. Машина — по доставке за город. Я использую то, что выполняет работу лучше в конкретной ситуации».
Подход JTBD говорит: сам по себе продукт не нужен — нужен результат того, что продукт делает. И это меняет взгляд на сбор требований: вы спрашиваете не «какие кнопки сделать?», а «какую работу клиент хочет выполнить с помощью нашего продукта?».
Искусственный интеллект как помощник, а не замена
Отдельного внимания заслуживает глава 16 «ИИ в работе IT-команды». В отличие от многих книг, которые либо хайпят нейросети, либо их боятся, здесь даётся взвешенный и практический взгляд. Рассматриваются:
-
варианты использования ИИ любым сотрудником компании (генерация текста, резюмирование, тестирование, поиск решений);
-
специализированные инструменты для разработчиков: модели (LLM, диффузионные модели), IDE с плагинами, локальные и облачные вычисления;
-
промпт-инжиниринг: как правильно формулировать запросы, чтобы получить качественный результат (с примерами хороших и плохих промптов);
-
использование ИИ для анализа данных и исследований (типовые задачи и ограничения);
-
этические аспекты: где ИИ неприменим, правила работы, законодательные ограничения в РФ.
Автор предупреждает: «ИИ не обладает критическим мышлением и не несёт ответственности. Никогда не загружайте в публичные ИИ-сервисы код с проприетарной бизнес-логикой, персональные данные клиентов, паспортные данные, логины/пароли». И даёт чёткие правила работы, которые защитят и новичка, и компанию.
Для кого эта книга?
Книга в первую очередь предназначена для начинающих специалистов, которые только приступили к работате в IT или планируют это сделать. Это могут быть:
-
разработчики (junior level);
-
тестировщики (ручные и автоматизаторы);
-
бизнес- и системные аналитики;
-
продуктовые менеджеры и владельцы продуктов;
-
дизайнеры (UI/UX);
-
менеджеры проектов.
Она также будет полезна тем, кто хочет выйти за рамки своей специальности и глубже понять, как ведётся разработка ПО целиком. И даже опытным специалистам, которые хотят систематизировать знания или адаптироваться к российским особенностям после работы в западных компаниях.
Пара живых примеров из книги
Чтобы не быть голословными, приведем пару цитат, которые дают представление о стиле и полезности.
Про разницу между аутсорсом и аутстаффом (аналогия с поварами):
Аутсорс: «Вы — повар в компании, которая готовит на заказ (кейтеринг). Клиент приходит и говорит: «Мне нужен фуршет на 100 человек». Ваша компания подключает вас и ещё нескольких коллег на подготовку блюда по предоставленному гостем рецепту. Завтра у вас будет новый клиент с другим меню».
Аутстафф: «Заказчик приходит и говорит: «Мне нужен на 6 месяцев повар-универсал для работы в ресторан азиатской кухни». Ваша компания передаёт вас в ресторан заказчика, и вы работаете там на условиях компании. Процессом управляет заказчик, а ваша компания отвечает только за зарплату и налоги».
Про принцип KISS (Keep It Simple, Stupid) с кухонной аналогией:
«Я хочу сделать омлет. Мне нужны яйца, молоко, соль и масло, а также миска, венчик и сковорода. Можно использовать и многофункциональный комбайн: найти насадку, подключить, потом мыть кучу деталей. Омлет получится тот же, но мороки больше. Не значит, что комбайн не нужен — для безе из 10 белков он отлично подойдёт. Просто выбирайте инструмент под задачу».
Заключение
Книга «Разработка программного обеспечения. Практическое руководство для новичков в IT-команде» — это системный взгляд на то, как устроена разработка ПО в реальной российской компании. С акцентом на процессы, людей, коммуникацию и карьерный рост.
Особенно рекомендуем обратить внимание на главы про онбординг (план 30/60/90 дней), про работу с требованиями и тестированием (для нетехнических ролей), про ИИ в IT-команде и про подготовку к Performance Review. Эти разделы в одиночку окупят стоимость книги.
Если вы только входите в IT, чувствуете себя потерянным в корпоративных процессах или хотите перейти из «просто кодера» в системного специалиста — эта книга ваш навигатор.
При покупке книги на сайте издательства “БХВ” используйте промокод HABRBHV, который дает скидку 36%.
ссылка на оригинал статьи https://habr.com/ru/articles/1029460/