1.0 Введение к части 1: Люди
Программное обеспечение создают люди, а люди организованы культурой, структурой и процессами. Поэтому, прежде чем говорить о коде, архитектуре или инструментах, эта часть рассматривает человеческую систему, которая всё это производит: общие ценности, которыми живёт команда, способ деления на команды, рост карьеры, повседневную координацию, а также то, как принимаются и запоминаются решения. Всё остальное в книге опирается на этот фундамент. Блестящая архитектура, созданная боязливой, раздробленной или забывчивой организацией, не переживёт столкновения с реальностью.
Для больших команд этот фундамент перестаёт быть интуитивным и становится структурным. Практики, которые распространяются сами собой среди восьми человек в одной комнате, разваливаются среди восьмисот человек по всему миру. Поэтому культуру нужно делать явной, границы команд проектировать намеренно, ожидания роста фиксировать письменно, координацию переносить из разговоров в коридоре в долговечные документы, а решения записывать так, чтобы их обоснование пережило тех, кто их принял.
Корпоративные и государственные организации ощущают каждое из этих давлений в полную силу. Они работают в масштабе, под аудитом и надзором, на длинных горизонтах и со смешанным составом: штатные сотрудники, подрядчики и поставщики. Система, которую вы создаёте сегодня, может проработать десять лет, а сопровождать её будут люди, никогда вас не встречавшие. В таких условиях основы, описанные в этой части, не мягкие навыки и не приятное дополнение. Это механизм институциональной памяти, подотчётности и управления рисками.
Главы этой части
1.1 Ценности программной инженерии: Общие убеждения и повседневное поведение, которые на самом деле определяют, как создаётся программное обеспечение: психологическая безопасность, обучение без поиска виноватых, ясная ответственность, культура письменной речи и устойчивый темп.
1.2 Топологии команд и организационное проектирование: Как деление людей на команды формирует программы, которые они способны создавать (закон Конвея: организации производят системы, повторяющие структуру их собственных коммуникаций). Потоковые, платформенные, поддерживающие команды и команды сложных подсистем помогают снизить когнитивную нагрузку и сократить зависимости между командами.
1.3 Роли, карьерные лестницы и рост: Построение явных, откалиброванных карьерных систем с параллельными треками индивидуального вклада и управления, чтобы уровни, повышения, найм и оплата были справедливыми, согласованными и обоснованными в масштабе.
1.4 Способы работы: Как команды координируются, планируют и поставляют результат изо дня в день: принципы важнее ритуалов, по умолчанию выбираются асинхронные практики, ориентированные на документы и результат, которые масштабируются через часовые пояса и смешанные коллективы.
1.5 Принятие решений и управление: Баланс между автономией команд и согласованностью организации: проторённые дороги, ревью нужного размера, мышление в категориях обратимых и необратимых решений и управление техническим долгом как портфелем.
1.6 Записи о решениях: Как писать, хранить и поддерживать записи о решениях, чаще всего записи об архитектурных решениях (ADR), чтобы обоснование выбора пережило смену персонала и выдержало аудит, и как сделать решения находимыми и даже проверяемыми.
1.7 Инженерные стандарты и исключения: Как организация составляет, публикует, обеспечивает и развивает свои инженерные стандарты и как она обрабатывает отклонения через управляемый, документированный процесс исключений (освобождений), чтобы стандарты оставались убедительными и не становились жёсткими.
1.8 Найм, собеседования и адаптация: Осознанное построение команды: инклюзивный поиск кандидатов, структурированные и откалиброванные собеседования, снижающие предвзятость, и настоящий план адаптации, который быстро делает новых инженеров продуктивными и причастными, а не бросает их на произвол судьбы.
1.9 Распределённая и удалённая работа: Работа в разных местах и часовых поясах: по умолчанию асинхронное, письменное сотрудничество с опорой на документацию, продуманные пересечения рабочего времени и передачи дел, оценка людей по результатам, а не по часам или заметности.
1.10 Эффективность инженерии и продуктивность разработчиков: Измерение и улучшение того, насколько эффективно инженеры могут делать свою лучшую работу, на основе многомерных подходов (SPACE и опыт разработчика) вместо единичных, легко подделываемых показателей, и устранение трения и рутины, тормозящих команды.
1.11 Управление разработкой: Ремесло управления инженерами, а не сама карьерная лестница: цикл личных встреч, обратной связи и коучинга, делегирование, гуманное управление результативностью и оценка руководителя как мультипликатора команды, а не по его личной выработке.
1.12 Разнообразие, равенство, инклюзивность и принадлежность: Построение команды, где различия присутствуют, к ним относятся справедливо, людей активно вовлекают и они чувствуют, что им здесь место, потому что инклюзивные команды создают лучшее ПО и потому что это правильно, с честным измерением и без формализма.
1.13 Наставничество, коучинг и обмен знаниями: Целенаправленное развитие людей и распространение экспертизы через наставничество, коучинг и спонсорство, сообщества практики, внутренние доклады, парную работу и документацию как обучение, чтобы знание переживало любого человека, а риск «автобусного фактора» оставался низким.
Как эти главы связаны между собой
Эти главы образуют единую нить. Ценности определяют, что важно организации. Структура и роли определяют, кто выполняет работу и как растёт. Способы работы определяют, как люди координируются. Управление и записи о решениях сохраняют обоснование их выбора. Зависимости идут именно в таком порядке. Культура письменной речи и психологическая безопасность из главы 1.1 служат предпосылками для честной калибровки в главе 1.3, сотрудничества с опорой на документы в главе 1.4 и долговечных записей о решениях в главе 1.6. Границы команд, спроектированные в главе 1.2, главный рычаг масштабирования координации в главе 1.4, где открыто предпочитается снижать потребность в координации, а не добавлять более тяжёлые фреймворки. Главы 1.5 и 1.6 образуют намеренную пару: первая задаёт философию управления, вторая превращает её в устойчивую практику.
Влияние этой части распространяется на всю книгу. Топологии команд из главы 1.2 формируют платформенную инженерию главы 8.4 и ответственность за надёжность в главе 9.1. Записи о решениях, представленные здесь, возвращаются всякий раз, когда делается значимый выбор: от основ архитектуры в главе 3.1 до выбора «купить или построить» и закупок в главе 10.3, а их гарантия через функции пригодности связана с конвейерами поставки главы 8.1. Обучение без поиска виноватых из главы 1.1 лежит в основе управления инцидентами главы 9.3, а обоснованное, документированное принятие решений, которое утверждается во всей этой части, именно то, на чём держится работа по рискам, аудиту и гарантиям главы 10.2. Заложите основы правильно, и всё остальное в книге применять будет гораздо легче.