Общаться в профессиональной среде, ходить на конференции и митапы, просто посидеть вечерком в приятном баре с профессионалом высокого уровня и обсудить какие-то классные идеи: всё это может помочь в работе. Среди этих ресурсов одно из первых мест занимают книги.
Под катом я расскажу вам о литературе, которая оказала на меня влияние как на управленца и разработчика. И, как мне кажется, может быть полезна любому, кто хочет вырасти в этих областях.
За мою практику я прочитал немало книг, но некоторые оказали большее влияние на становление разработчиком, а затем управленцем. Я разбил книги по нескольким разделам.
Практика
Книги из практического блока можно просто читать, независимо от того, разработчик вы сейчас или руководитель. Они все классные. Я рекомендую их всем, и они довольно простые прочитали, и можно сразу использовать.
Specification by Example
Книга понравилась мне настолько, что побудила написать первую статью на Хабре. Гойко Аджич автор книги сам описывает ее как книгу о разработке ПО без единой строчки кода. Ее фокус находится на пересечении управления требованиями, проектного менеджмента, DevOps и тестирования (в том числе автоматизированного). Если DevOps часто описывают как infrastructure as code, то Specification by Example это своего рода requirements as code. Проработав некоторое время в корпоративном сегменте индустрии любой разработчик рано или поздно узнает о том, насколько неполными, неточными, противоречивыми и устаревшими бывают требования и насколько сложно, долго и дорого бывает переделывать программы, написанные по таким требованиям. Существуют тяжелые методы борьбы с этим недугом. Например ГОСТ 34 до сих пор используется в госсекторе, несмотря на то, что он безнадежно устарел.
Specification by Example гораздо более гибкая и менее формальная техника, позволяющая, впрочем, заказчику и исполнителю говорить на одном языке, понятном обоим. Кроме того, ГОСТы описывают форму проектной документации, но не дают конкретных советов по проектному управлению и никак не поощряют коммуникацию и совместную работу по улучшению требований и нахождению лучших (более быстрых, качественных и дешевых) способов решения проблем. Примеры переформулированных требований из книги гарантированно не оставят вас равнодушными. Техникой контрольных примеров мы пользуемся уже восемь лет, и она позволяет экономить какое-то невероятное количество времени и избегать недопониманий.
На основе техники, описанной в книге, даже разработан продукт SpecFlow. Нам он показался излишне громоздким. Но вам, возможно, подойдет. О связи требований и автоматизированного теста на примере SpecFlow можно почитать в этой статье.
Event Storming
Это даже не книга, а своего рода комикс. Если вы любите стикеры, доски и kanban, то event storming скорее всего тоже зайдет. Со временем мы пришли к тому, что большинство web-проектов сразу создаем на основе CQRS-архитектуры, даже если на старте хранилище данных всего одно. Это позволяет по мере развития проектов независимо оптимизировать стеки чтения и записи. И в момент, когда запросы к БД становятся уже совершенно безобразными, воткнуть очередь с денормализоваными хранилищами.
Подробно о всех преимуществах CQRS перед классической n-layer- и onion-архитектурой я рассказывал в докладе Быстрорастворимое проектирование.
Причем здесь Event Storming? Это техника специфицирования в терминах DDD, CQRS и Event Sourcing в форме увлекательной игры со стикерами, фломастерами и доской (доска может быть физической или виртуальной, но с физической гораздо веселее). С точки зрения наглядности, метод не успевает за Activity и BPMN-диаграммами. Но он гораздо более легковесный и прост в освоении и понимании.
Impact Mapping
И снова книга Гойко Аджича. Часть идей в ней пересекается со Specification by Example, но у книг разные целевые аудитории. Spec by Example лучше подойдет для разработчиков, архитекторов, тестировщиков, аналитиков и менеджеров среднего звена. Impact Mapping инструмент, в первую очередь, для бизнеса: владельцев продукта (или даже компании), маркетинга и топ-менеджмента. Spec by Example лишь поощряет общение с целью поиска оптимальных решений. Impact Mapping это формальный процесс для стратегического планирования. Его можно использовать не только в разработке ПО, но и для стратегического планирования, в целом. Например, в этом году мы использовали Impact Mapping для приоритизации и планирования задач в HR.
Теория + практика
Теоретически-практические книжки чуть более сложные. Я бы рекомендовал начать с DDD это очень холиварная тема! Возможно, DDD это не то, что вам нужно на этапе создания стартапа, но попробуйте обратить внимание не на технические аспекты, а на высокоуровневые паттерны. На то, как DDD предлагает общаться с экспертами, выделять главное, и на то, что продукт порой важнее используемых технологий. Если вам это зайдет, то дальше начнется протоптанная другими тропа: DDD -> CQRS -> Event Sourcing. Чаще всего все эти три темы обсуждаются в одном комьюнити. Как только вы разберетесь, что собой представляет каждая из концепций, вы поймете почему.
Немного особняком стоит книга Скотта Влашина про DDD в мире функционального программирования. Во-первых, ФП в изложении Влашина это не сложно. Обратите на книгу внимание хотя бы поэтому. Во-вторых, даже если в ближайшие десятилетия вы не собираетесь никуда сворачивать с тропинки объектно-ориентированного программирования, изучение других способов решения знакомых проблем может быть точкой роста. Я большой фанат гипотезы лингвистической относительности (и фильма Прибытие удачно выигрывающего эту гипотезу). В каком-то смысле знание языков программирования может влиять на ваше мировоззрение также, как знание естественных языков.
Теория
Факты и заблуждения профессионального программирования
Если эти книги вам знакомы или показались неинтересными, а вы хотите прочесть что-то более фундаментальное, рекомендую книгу Роберта Гласса Факты и заблуждения профессионального программирования. Она в свое время помогла мне перестать проваливать сроки реализации проектов, потому что я понял, что некоторые числа, которые были в моей голове, в три раза отличались от реальности. Книга хороша тем, что Роберт Гласс всю свою жизнь фактически проработал в аэрокосмической отрасли и собирал реальную статистику о том, сколько времени занимает анализ, разработка, тестирование, как неточны оценки, как часто меняются требования и как на самом деле сложно адаптироваться к таким изменениям.
Мифический человеко-месяц
Книга Фредерика Брукса, несмотря на то, что ей уже 100500 лет, и вы можете встретить в тексте что-то про перфокарты, это фундаментальный труд. Закон Брукса никуда не делся и, кажется, не денется. Понимание этого закона (девять матерей не родят дитя за один месяц) поможет принимать критические и зачастую контринтуитивные управленческие решения. Юбилейное издание включает в себя статью Серебряной пули нет, с которой тоже не грех ознакомиться всем и каждому.
Сколько стоит программный продукт
Большинство знает другую книгу МакКонела Совершенный код. Для кого-то она даже стала своеобразной Библией программирования. Если вы уже программируете хорошо и хотите научиться лучше оценивать трудозатраты на разработку, прочтите Software Estimation: Demystifying the Black Art (Сколько стоит программный продукт; в оригинале название звучит точнее, не находите?:). Книжка сложная, со статистикой, но ничего лучшего об оценке я не видел. Гарантирую, качество оценки тех, кто использует методы и советы из книги, многократно превосходит качество оценки тех, кто делает это по наитию.
Лютая теория и даже философия
Но если этого вам мало, и вы хотите улучшить свое умение думать о процессе, в целом, понять разницу между управлением, организацией и даже не прочь почитать что-то философское, то Г. П. Щедровицкий Оргуправленческое мышление это то, что вам нужно. Книга очень сложно читается, это конспект лекций для руководителей стройки атомных электростанций в СССР. На момент строительства никакой методологии Как строить атомные АС просто не существовало. Стройки велись по всему СССР, что делало каждый проект уникальным. В этих условиях успех строительства напрямую зависел от качества организации и от управления стройкой. В терминологии Щедровицкого эти два слова значат совсем не одно и тоже. В ходе лекций автор пытается найти баланс между первым и вторым. Труд просто фундаментальный и где-то философский, предназначенный для организаторов и руководителей с большой буквы.
Цель. Процесс непрерывного улучшения
Производственный роман и по совместительству введение в теорию ограничений Элияху Голдратта иллюстрирует изменчивость реального мира и наивность планов, игнорирующих случайные события. После прочтения книги вы научитесь видеть картину в целом и больше не дадите частностям запутать вас.
На этом мой список книг подходит к концу. Выбирайте полезные для себя и enjoy!
TechLead Conf 2021 конференция, полностью посвященная инженерным процессам и практикам откроет свои двери уже совсем скоро: 30 июня и 1 июля она пройдет в Radisson Slavyanskaya (Москва).Расписаниеуже готово.Билетыв продаже. А ещё у нас открытдоступк докладам TechLead Conf 2020.
До встречи в офлайне!
