Хабрахабр

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

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

Хороший архитектор, как и хороший 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. Нет, подожди-подожди. В первую очередь я составляю повестку:

  1. Введение: 10 мин.
  2. Проблема: 15 мин.
    • Нам нужна схема БД
    • Давайте выберем сервер


  3. Мнения: 15 мин.
    • У Джеффа и Моники есть опыт
    • Остальные?


  4. Кофе-брейк: 10 мин.
  5. Обсуждение: 30 мин.
    • Не будем забывать о рисках
    • Спросить Джо про PostgreSQL


  6. Завершение: 10 мин.



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это грабеж!

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть