Совещания — это узаконенный грабеж

В разработке всё дело в творчестве, не так ли? Это искусство, а не наука. Мы, разработчики, решаем сложные задачи, и зачастую наши решения совершенно не очевидны. Мы экспериментируем, внедряем новшества, исследуем и расследуем. Чтобы делать всё это, мы разговариваем. Мы вместе сидим в переговорках, конференциях в скайпе или каналах в слаке; мы обсуждаем свои решения; мы спрашиваем мнения коллег; мы спорим о лучших идеях. Без сомнения, совещания — ключевой компонент современного проектирования ПО… и это очень печально наблюдать.

Хороший архитектор, как и хороший PM, не нуждается в совещаниях и никогда их не организует.

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

Скажем, я архитектор, которому нужно спроектировать схему реляционной базы данных в новом проекте, у меня есть команда из пяти программистов, и я хочу, чтобы они помогли мне с проектированием. Это очень логичное и адекватное желание, т.к. хороший архитектор всегда обсуждает все возможные варианты с командой перед тем, как принять окончательное решение. Так что, я собираю совещание? Нет!

Хороший архитектор

Я прошу Джеффа, одного из наших программистов, создать черновик схемы БД, но на самом деле я не говорю с ним об этом. Я ценю и уважаю его время — нет нужды беспокоить его этим организационным шумом, поэтому я просто создаю тикет и назначаю на Джеффа. Когда у него есть время, он создает черновик и возвращает пул-реквест. Я его просматриваю, добавляю немного комментариев перед тем, как он обновит ветку, и в конце концов мёржу.

Отлично: у нас есть черновик.

В конце документа Джефф, к тому же, перечислил допущения, риски и вопросы. Например, вот что я от него получил (это Markdown, очень удобный формат для простых технических документов; я очень рекомендую его):

## Tables
user (id INT, name VARCHAR, email VARCHAR);
payment (id INT, date DATETIME, amount INT);
order (id INT, details VARCHAR, user_id INT FK(user));

## Assumptions
- All payments will be in whole dollars, no cents.
- All users will have only one email.
- There will be no search feature required.

## Risks
- Order details may not fit into VARCHAR.
- Foreign keys may not be supported in the DBMS.

## Concerns
- Would NoSQL be more suitable?
- What is the DB server we'll use?

Я не знаю, сколько времени Джефф потратил на этот документ, но я только что создал его за 10 минут. Конечно, это очень простая схема для очень простого проекта. Но даже если Джефф потратил на это час, каждая минута этого часа полезна для проекта. Я имею в виду, что каждый доллар, который я заплатил Джеффу за это время, вернулся ко мне в виде текстового документа.

Теперь у меня есть черновик, и я делаю следующий шаг. Я прошу Монику взглянуть на него и предложить изменения. Опять же, это еще час, и я получаю пул-реквест с изменениями, исправлениями, новыми допущениями, рисками и вопросами. Я не говорю с Моникой: в этом нет нужды. У нее есть вся информация, которая нужна ей для работы со схемой БД. Она хороший инженер, и я доверяю ее способности формулировать свое мнение в письменном виде.

Нет никакой необходимости сидеть вместе в одной комнате или стоять перед доской. Моника достаточно умна, чтобы делать свою работу самостоятельно. У нее уже есть все идеи, которые выразил Джефф; ей не нужно с ним разговаривать.

Как только я вмержил ее пул-реквест (после надлежащего ревью и исправлений), у меня есть новая версия документа schema.md.

Более того, у меня есть гит-история этого документа, а также история пул-реквестов с комментариями. Это намного лучше, чем заметки по ходу встречи или даже видеозапись совещания. Любой, кто позже присоединится к проекту, сможет понять, как мы пришли к такому выводу, что нам нужно использовать PostgreSQL и хранить денежные суммы без центов. Всё это — там, в истории гита и тикетах на гитхабе, навсегда с нами.

Что, если мне понадобится больше мнений? Или если я всё еще не уверен, что схема достаточно хороша? Без проблем: я прошу кого-нибудь другого отревьюить ее еще раз и отправить мне пул-реквест с изменениями. Я даже могу попросить Джеффа сделать это еще раз после нескольких итераций с другими программистами!

Более того, я могу добавить в документ собственные вопросы и на следующей итерации попросить Джеффа обратить на них внимание и принять по ним решения.

Чем больше мы передаем документ по кругу, тем лучше он становится, и каждая минута, за которую платит проект, превращается в осязаемый продукт — документ с историей изменений!

Вот как профессиональный архитектор собирает мнения и принимает сложные решения. Теперь давайте посмотрим, что сделал бы плохой архитектор.

Плохой архитектор

Сперва я собираю совещание. Нет, погодите: я планирую его в Google Calendar. Нет, подожди-подожди. В первую очередь я составляю повестку:

Уверен: вы понимаете, о чем я, и видели такие повестки у своих «архитекторов». Тем не менее, мой первый шаг сделан. Я запланировал полуторачасовое совещание, на котором будут присутствовать все программисты. Мы повеселимся и попьем кофе. Мы обсудим проблему, выслушаем все мнения и найдем лучшее решение. Мы задокументируем его в schema.md и вернемся к своим задачам.

Вместо передачи этих сухих и скучных Git-документов у нас будет настоящее человеческое общение с приятным кофе-брейком, на котором мы обменяемся мнениями о последней серии «Теории Большого взрыва». В конце концов, разве не это мы все любим в своей офисной работе?

Я так не думаю.

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

Совещания были нужны нам 30 лет назад, когда у нас не было ноутбуков и гитхаба. Но даже тогда у нас были ручка и бумага.

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

Действительно ли нас волнует тело Моники, когда мы проектируем схему БД? Ну, когда как, верно? Но если серьезно, нам за это не платят.

Совещания демотивируют

Лучшая мотивация для творческой личности — видеть результат своего творчества. Если не ошибаюсь, наслаждение процессом творчества без всяких результатов — это очевидный признак психического заболевания. Здоровый творческий человек, такой как разработчик ПО, например, хочет видеть, как его усилия превращаются во что-то ценное и — в идеале — осязаемое.

Совещания никогда не производят ничего осязаемого и редко — что-то ценное. Иногда у нас есть «протоколы» совещаний, но они просто маленькие клочки бумаги с кратким конспектом того, о чем мы говорили. Не настоящий "продукт" для творческой личности.

Таким образом, они меня демотивируют, т.к. я просто не вижу, во что превратились 2 часа моей жизни. На самом деле мы ничего не создаем, мы просто обсуждаем. Обратите внимание: я говорю о совещаниях, а не о совместной работе над чем-либо, как, например, в парном программировании.

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

Совещания поглощают время впустую

Думаю, это очевидно. Первые несколько минут совещания вы сосредоточены, потом начинаете смотреть свою ленту в Твиттере и рисовать каракули. Все делают то же самое — не потому, что мы ленивы, а потому, что нет необходимости полностью фокусироваться на совещании.

Пока Моника работает с документом, добавляя комментарии и предложения, она полностью сосредоточена на результате — в основном, потому, что больше некому ей помочь. Она должна предоставить этот пул-реквест, и я ее жду. Ее концентрация так же высока, как была бы на совещании, когда кто-нибудь спросил бы ее о чем-то напрямую и она должна была бы дать подробный ответ.

Ее время оптимизировано для получения соответствующего результата, в то время как другие делают что-то другое.

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

Совещания сжигают деньги

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

Хоть это и может прозвучать радикально, я должен сказать, что считаю совещания узаконенным способом грабить проект. Большинство организаторов совещаний (архитекторы, CTO, CEO, программисты) не понимают этого. Они верят, что, чем больше они разговаривают, тем лучшие они инженеры. А их начальники по ошибке ценят в своих подчиненных этот вид деятельности.

Это грабеж!

Я сказал вам сделать набросок схемы БД. И вот вы идете ко мне и просите устроить совещание, т.к. некоторые «аспекты» непонятны? Вы где-нибудь учились разработке ПО? Вы знаете, как работать с техническими документами? Вы способны писать таким образом, чтобы любой мог понять и ответить вам, тоже письменно? Нет? И теперь вы хотите, чтобы проект заплатил не только вам за набросок схемы БД, но и мне за разговор с вами и еще нескольким ребятам за то, что они посидят рядом с нами и попереписываются со своими друзьями? По сути, вы хотите ограбить владельца проекта. Ни больше ни меньше.

Совещания ухудшают качество

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

Совещания поощряют групповые достижения и отбивают охоту от индивидуальных. В конце совещания зачастую не понятно, кто именно предложил хорошую идею и кто приложил наибольшие усилия. Иными словами, в конце совещания я не знаю, насколько я хорош. Я такой же, каким был месяц назад, или уже лучше как инженер?

Они больше улыбаются и спрашивают меня: «Что думаешь?» — чаще, чем прошлым летом; это должно что-то значить, правда? Уверен, вы понимаете, что это не тот вид обратной связи, который ожидал бы серьезный инженер.

Серьезный разработчик хочет производить осязаемые результаты и получать осязаемую обратную связь, вроде денег или ревью кода. Я хочу знать, что неправильно в моем наброске схемы БД и что я упустил. И я хочу, чтобы это было где-то задокументировано. Вот это делает меня лучше, и вот так я учусь и расту.

Как насчет моментов озарения?

Итак, как насчет настоящего творчества и пресловутых моментов озарения? Иногда необходимо «думать вслух» для того, чтобы придумать что-то, не так ли? Все мы знаем, как важно бывает общаться лицом к лицу, когда мы исследуем или разрабатываем что-то новое. Где бы мы были без совещаний? Мы не можем просто работать с документами; нам нужно разговаривать друг с другом для того, чтобы высказывать свои идеи. Разве это не очевидно?

У меня только один аргумент по этому поводу. Разве Эйнштейн придумал свою теорию на совещании с коллегами? Я так не думаю. А он решал намного большую проблему, чем проектирование схемы БД.

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

Автор: s-kozlov

Источник