Половина моих статей начинается с того, что индустрия разработки очень молода, фундаментального образования нет, а цена копирования нулевая. Большинство разработчиков постоянно делают что-то новое. Конечно, если исключить тех счастливчиков, которые занимаются внедрением не меняющихся десятилетиями ERP систем «с чистого листа» или штампованием сайтов-визиток под копирку. Но у таких ребят проблем нет, поэтому не рассказываю.
С одной стороны, разработчики постоянно делают что-то новое. А как человеческий мозг подходит к работе с новым? А неизвестно. Мне нравится гипотеза, что мозг постоянно строит и обновляет модели окружающего мира. Для работы с окружающим миром мозг рассматривает несколько моделей и всегда выбирает самую «сильную». Как определяется сила модели? На основании жизненного опыта разработчика.
Жизненный опыт определяет поведение
Если разработчик привык решать задачи за несколько часов и у него случается «затык», то тим лид может слушать «сейчас, уже почти-почти все готово» на протяжении недель. Не потому что разработчик плохой или глупый. А потому что автоматика. В картине мира, которую мозг моделирует для разработчика, оно действительно почти готово. И чтобы мозг поменял свои модели, нужен другой жизненный опыт. Много другого жизненного опыта. А индустрия у нас меняется быстрее, чем этот опыт накапливается.
Если разработчик привык писать код сам, то ему никогда не придет в голову искать open source решение, даже если самому писать месяц, а чужую библиотеку прикрутить можно за день. И снова — не потому что разработчик плохой или глупый. А потому что автоматика. Случается и обратная ситуация, когда привыкший к работе с open source боец будет месяц допиливать чужое решение, когда самому код можно написать за пару дней.
Таких примеров множество. Есть подозрение, что механики, которые наш мозг использует для моделирования окружающего мира, не очень хорошо работают, когда задачи каждый раз новые. Эти когнитивные искажения порождают «худшие практики» и «типовые проблемы», про которые так любят писать книги, статьи и в блогах. Только вот все рекомендации ограничиваются «просто не делайте так». Но как можно «не делать так», если это человеческая природа? Нельзя просто взять и не съесть булочку. Она вкусная.
Кривое зеркало бытовой логики
Жизненный опыт шепчет разработчику, что в предыдущих проектах он начал путаться в собственном коде через полгода разработки. Разработчику страшно, он начинает «окапываться», вместо решения задач создавая себе инструменты и универсальные компоненты «на всякий случай». Если вовремя не прервать этот процесс, то разработка Универсальной Шины Данных может длиться годами, были прецеденты. Познакомьтесь, Yagni.
Мозг создает для разработчика логичную картину мира, и разработчик уверен, что объективная реальность выглядит именно так. В его картине мира есть воображаемые пользователи с воображаемыми потребностями, есть воображаемый план развития продукта на многие годы вперед и воображаемая эволюция архитектуры. А через год оказывается, что продукт изнутри и снаружи наполнен никому не нужными «фичами», а архитектура подготовлена к изменениям, которых не будет. А те, что будут, почти всегда являются неожиданностью. Познакомьтесь, «ползучий фичеризм».
Список худших практик можно продолжать долго. «Not Invented Here», «Визуальное Программирование», перфекционизм, прокрастинация и множество других интересных штук, которые только и ждут, чтобы убить наш проект. Все они более-менее известны и мы даже научились с ними бороться.
Борьба с собственным мозгом
Большим прорывом в разработке стало использование Agile методологий, которые «заточены» на постоянное решение новых задач в условиях отсутствия надежного фундамента. «Agile» декларирует принцип: «передвигаемся вперед небольшими перебежками, меняем направление, если ошиблись». Для практического использования Agile есть те самые методологии. Да-да, Маркс и Энгельс — это разные люди, а «Agile методологии» — это отдельно Agile как принцип и отдельно методологии, которые этот принцип пытаются воплотить в разных практиках. К примеру, широко известная методология Scrum «заточена» на защиту от срыва сроков, а условно-конкурирующая с ней Kanban — на решение максимального количества задач в единицу времени.
Scrum, Kanban и другие методологии состоят из практик: инструкций как организовывать работу и коммуникации в команде. При этом можно выделить ряд практик, которые применяются в большинстве методологий. Одна из таких практик — «daily stand-up meeting», несколько видоизмененная «утренняя планерка», используемая в управлении уже много сотен лет.
В классическом варианте утренний стендап выглядит так. Команда собирается лично или в скайпе, после чего каждый участник по часовой стрелке говорит вслух три вещи:
- Что он делал вчера.
- Что он будет делать сегодня.
- Какие видит сложности.
Ключевыми в этой практике являются два момент:
- Говорить надо быстро.
- Говорить можно только эти три вещи. Явно запрещены вопросы, обсуждения, дополнения, высказывание мнений и прочее, о чем мы так любим поговорить.
Утренний стендап является эталонным образцом коридора: создает такие условия, при которых участникам команды очень легко делать правильные вещи и очень трудно делать вещи неправильные.
Правильно построенный коридор
Утренний стендап решает две задачи. Первая и самая главная: позволяет команде и тим лиду как можно раньше понять, у кого и что идет не так. Не дожидаясь двухнедельных «еще полчаса и все будет готово». Кроме этого, стендап немного дисциплинирует команду. Зная, что завтрашнее публичное выступление неизбежно, как восход солнца, разработчик будет обращать больше внимания на то, что и как он планируют делать. Никто не хочет позориться перед командой и придумывать объяснения восьмичасовому рассматриванию во вконтакте котиков.
Чтобы стендап работал во благо команды, его надо готовить правильно.
Стендап должен быть публичный, даже если «публичность» сделана через скайп. Это активизирует наши стайные модели поведения — никто не хочет быть хуже коллег.
Стендап должен быть неизбежен, как восход солнца. Человеческий мозг постоянно тыкает окружающее палочкой, пытаясь построить более экономные по ресурсам модели. Стендап нельзя переносить, даже если сейчас два человека в офисе. Это ритуал. Если участники пойму, что переносить МОЖНО — то перенос будет делаться под любым предлогом и процесс «потухнет» сам собой.
И, наконец, правила стендапа должны быть жестко оговорены заранее и также жестко соблюдаться. Каждый участник команды говорит три вещи и передает слово другому. Попытки задавать вопросы, обсуждать, жаловаться на жизнь и рассказывать о покемонах пресекаются заклинанием «без обид, мы договорились это обсуждать после стендапа». Вообще, апеллировать к «мы договорились» очень удобно. Главное — не забудьте действительно договориться. До начала первого стендапа. Иначе магия не будет работать.