Что я понял, благодаря неуспехам. Реджинальд Брейдвайт

Эта книга больше не о программировании, а скорее об отношении к работе и индустрии в целом. Что делать, чего не делать, почему так, и к чему приводят неправильные решения.

Онлайн‑версию в оригинале можно прочитать бесплатно. Она довольно короткая, я осилил за вечер.

Глава 1. Что я понял, благодаря неуспехам

Разработка проекта может провалиться, если хотя бы одна из составляющих хромает:

  • компетентность разработчиков;
  • адекватные ожидания от качества продукта;
  • пригодность предлагаемых решений в разработке и управлении;
  • компетентность проектного руководства и коммуникаций.

Люди

Слабые команды проигрывают. Признак слабой команды: если вы бы собрались уйти с работы и не захотели забрать с собой никого из коллег, команда слабая.

Слабые продукт‑оунеры тоже проигрывают. Признавать, что у проекта проблемы и пора вносить изменения — сложно и страшно, но необходимо.

Внешние навязанные ограничения (государственные, например) как правило вредят.

Действие

Получать обратную связь надо быстро — fail fast! Чем раньше узнаете, что у вас проблемы, тем проще найти решение. Работает как в отношении кода, так и продукта в целом.

Детали

Детали и спорные решения в проекте должны быть всегда видны всем. Перестать следить за деталями — начать хоронить проект.

Расписание

Дедлайны — обязательны. Продукт‑оунерам и инвесторам важно знать, что происходит и когда очередная часть проекта будет готова.

Сила

Если вы хотите внести изменение в проект, будьте готовы доказывать пользу своего решения всем и каждому.

История

Гипотеза, основанная на действиях из прошлого, может не сработать в будущем.

«Если бы мы больше времени уделили планированию, то спланировали бы лучше; так было в прошлом проекте» — вовсе не факт.

Уметь заканчивать

Уходить из проекта тоже иногда полезно. Игра в героя, который тащит на себе всё, может плохо сказаться как на здоровье «героя», так и на здоровье проекта. Иногда вам не обязательно заканчивать то, что начали вы. Иногда вам не обязательно заканчивать то, что начали другие.

Глава 2. Дизайн софта

Строить лучше

Чтобы понять детали проекта, надо узнать, чем он отличается ото всех других. Самые важные архитектурные решения опираются именно на отличия проекта от других.

Лучшая архитектура

Архитектура тем лучше, чем точнее и детальнее описывает конкретно этот проект. Она должна быть компактной, но детально описывать особенности.

Глава 3. Теория, которая подтверждает наблюдения

Теория D, теория P, и почему они важны

Если мы верим в теорию D (deterministic — что процесс можно описать полностью, и если что‑то не сходится, то у нас просто не хватает данных), то мы верим, что проект можно спланировать заранее и полностью.

Если мы верим в теорию P (probabilistic — что предсказать полностью ничего нельзя, а только какие‑то части и только с какой‑то точностью), то мы верим, что планировать следует только какие‑то части проекта, и когда что‑то идёт не так, нам надо добавить в план новую информацию, чтобы скорректировать его.

Вера определяет поведение

Адепты теории D верят, что:

  • можно спланировать проект заранее;
  • можно заранее просчитать, сколько понадобится времени на реализацию;
  • самое важное в разработке — планирование;
  • использование готовых решений позволит ускорить разработку и тратить меньше ресурсов на поиск разработчиков.

Адепты теории P верят, что:

  • спланировать можно только какие‑то части проекта, но не проект целиком;
  • при расчёте времени все, все, все лгут, зачастую — неосознанно;
  • самое важное в разработке — обучение, зачастую — на ошибках;
  • командная работа лучше одиночной;
  • использовать фреймворки следует осторожно, сравнив, какие проблемы они позволят решить и какие принесут с собой.

Глава 5. Проект‑менеджмент как рынок с информацией

В паровом двигателе одна из самых важных частей — трубы, потому что они позволяют пару переходить от одних частей к другим. В проекте важно, чтобы информация циркулировала от одних частей команды к другим.

Проект похож на рынок, где какая‑то информация ценится там, где её не хватает. Задача менеджеров в том, чтобы уметь отделять ценную информацию (которая поможет предсказать исход проекта или его части) от неценной; уметь «покупать» её у разработчиков и «продавать» её руководству или инвесторам.

Глава 6. Кирпичи

Софт делается не из кирпичей

Аналогия с кирпичами опасна. Кирпичи — слишком простые. Если понятно, как работать с одним кирпичом, понятно, как работать с остальными. В софте не так. Мало того, что там не всегда понятно, как обращаться с «кирпичами», там ещё и непонятно, сколько их надо, чтобы собрать проект.

При добавлении людей в проект, которые не понимают, как он работает, появляется опасность наплодить кучу неработающего кода. Необходимо выделить минимальные знания для работы над проектом и не нарушать это правило при наборе людей.

Разработку трудно параллелить

«Кирпичи» из которых состоит софт, связаны друг с другом в каком‑либо виде. Чтобы разрабатывать их параллельно, требуется изначально продумать, как они должны взаимодействовать — что не всегда получается хорошо.

Если добавлять людей в проект, чтобы распараллелить разработку на поздних стадиях (когда какая‑то часть уже написана), то продуктивность даже упадёт.

Вторая беда с аналогией про кирпичи в том, что она позволяет думать, будто можно оценить прогресс по количеству использованных кирпичей. Но софт — трансфинитивен (простите, я не смог перевести иначе).

Важную роль также играет и «куда положить какой кирпич» и «как его соединить с другими». Одна ошибка может откатить отметку прогресса сильно назад.

Третье отличие от кирпичей: с развитием проекта меняются клиентские требования, поэтому прогресс придётся пересчитывать постоянно.

Глава 7. Цикл «попытка‑провал»

Весь смысл этого цикла в том, чтобы создать план, но заранее понимать, что план не выдержит столкновения с реальностью. Поэтому лучше напороться на проблемы раньше (fail fast!).

Обратная связь

Есть ошибка, при которой софт разрабатывается инкрементами вместо итераций.

Инкремент — часть софта, которая сама по себе закончена, но не несёт ценности для бизнеса. Итерация — законченная часть, которая несёт ценность бизнесу.

Чтобы обратная связь работала, это должна быть обратная связь от настоящих пользователей. Единственный способ получать такую обратную связь и получать её быстро — итеративная разработка.

Глава 8. Облысение софта

Технический долг приводит к нерабочему продукту.

Глава 9. Мышиная ловушка

Архитектура мышиной ловушки — набор несовместимых компонентов, используемых не по их прямому назначению, непонятно как связанных между собой хрупкими костылями.

Глава 10. Утиное программирование

Это менеджерский антипаттерн; мнение, что всё, что не связано с программистами, языками программирования или инструментами — программированием не является.

Глава 11. Не получается найти хороших продажников

Мы верим в свой продукт. Но продажникам надо убедить потребителей, что у тех есть потребность, а наш продукт может её удовлетворить и что эту потребность надо закрыть сейчас. Они готовы взять риски, но только за то, что могут контролировать.

Эту книгу дополнят

Некоторые другие книги о программировании:

И вообще:

← Болеть за продукт Sapiens. Юваль Ной Харари →