The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Разработка программного обеспечения – это все о творчестве, верно? Это искусство, а не наука. Как инженеры-программисты, мы решаем сложные задачи, и наши решения часто далеко неочевидны. Мы экспериментируем, инновируем, проводим исследования и расследования. Для всего этого мы общаемся. Мы сидим вместе в наших переговорных комнатах, делаем конференц-звонки в Skype или общаемся в каналах Slack; мы обсуждаем наши решения, спрашиваем мнение коллег и спорим о лучших идеях. Нет сомнений, что встречи – ключевой компонент современной дисциплины разработки программного обеспечения… и очень печально видеть это.
Хороший архитектор программного обеспечения, а также хороший менеджер проекта, не нуждается в встречах и никогда их не организует.
Встречи демотивируют, тратят время, сжигают деньги и снижают качество. Но об этом поговорим позже. А сейчас давайте обсудим предлагаемую альтернативу.
Предположим, я архитектор, который должен разработать схему для реляционной базы данных в новом проекте, и у меня есть команда из пяти программистов, которым я хочу помочь мне с этим проектированием. Это очень логичное и подходящее желание, так как хороший архитектор всегда обсуждает все возможные варианты с доступными участниками команды, прежде чем принять окончательное решение. Итак, я устраиваю встречу? Нет!
A Good Architect
Я прошу Джеффа, одного из наших программистов, создать черновик схемы базы данных, но фактически не общаюсь с ним об этом. Я ценю и уважаю его время — нет необходимости беспокоить его этой организационной суетой, поэтому я просто создаю тикет и назначаю его Джеффу. Когда у него будет время, он создает черновик и возвращает запрос на слияние. Я его рассматриваю и оставляю некоторые комментарии, прежде чем он обновляет ветку, и, наконец, я сливаю это.
Отлично, у нас есть черновик.
В конце документа Джефф также перечислил предположения, риски и заботы. Вот, что я получил от него (это Markdown, очень удобный формат для простых технических документов; я настоятельно рекомендую его).
## Tables
пользователь (id INT, имя VARCHAR, электронная почта VARCHAR); платеж (id INT, дата DATETIME, сумма INT); заказ (id INT, описание VARCHAR, user_id INT FK(user));
## Assumptions
* Все платежи будут производиться в целых долларах, без центов.
* У всех пользователей будет только один адрес электронной почты.
* Не будет необходимости в функции поиска.
## Risks
* Детали заказа могут не поместиться в VARCHAR.
* В DBMS может отсутствовать поддержка внешних ключей.
## Concerns
* Было бы лучше использовать NoSQL?
* What is the DB server we'll use?
Я не знаю, сколько времени Джефф потратил на этот документ, но я просто создал его за 10 минут. Конечно, это очень простая схема для очень простого проекта. Но даже если Джефф потратил на нее час, каждая минута этого часа ценна для проекта. Я имею в виду, что каждый доллар, который я плачу Джеффу за его время, возвращается мне в виде текстового документа.
Теперь у меня есть черновик и я перехожу к следующему шагу. Я прошу Монику взглянуть на него и предложить изменения. Снова проходит час и я получаю запрос на слияние с изменениями, исправлениями, новыми предположениями, новыми рисками и новыми вопросами. Я не общаюсь с Моникой - нет необходимости в этом. У нее есть всю необходимую информацию для работы с схемой БД. Она хороший инженер, и я доверяю ее способности выразить свое мнение в письменной форме.
Нет необходимости сидеть в одной комнате или стоять у доски. Моника достаточно умна, чтобы справиться с этой работой самостоятельно. У нее уже есть все идеи, высказанные Джеффом перед ней; ей также нет необходимости разговаривать с ним.
После правильного обзора и исправлений, когда я подтвержу ее запрос на слияние, у меня будет новая версия моего документа schema.md.
Кроме того, у меня есть история Git этого документа, а также история запросов на объединение с комментариями. Это гораздо лучше, чем заметки совещаний или даже видеозапись совещания. Любой, кто присоединится к проекту позже, сможет понять, как мы пришли к решению использовать PostgreSQL и хранить денежные суммы без копеек. Все это доступно в истории Git и GitHub-запросах навсегда с нами.
Что, если мне нужно больше мнений? Или если я все еще не уверен в том, что схема достаточно хороша? Нет проблем; я попрошу кого-то другого еще раз просмотреть ее и прислать мне запрос на объединение с изменениями. Я даже могу попросить Джеффа сделать это снова после нескольких итераций с другими программистами!
Кроме того, я могу добавить свои собственные замечания в документ и на следующей итерации попросить Джеффа обратить на них внимание и решить их.
Чем больше мы обращаемся к этому документу, тем лучше он становится. И каждая минута, потраченная на проект, превращается в осязаемый продукт: документ с историей изменений!
Вот как профессиональный архитектор собирает мнения и принимает сложные решения. Теперь посмотрим, что сделал бы плохой архитектор.
A Bad Architect
Сначала я созваниваюсь на собрание. Нет, подождите; я назначаю его в Google Календаре. Нет, подождите, подождите. Прежде всего, я создаю повестку дня:
1. Introduction: 10 min
2. Problem: 15 min
- We need a DB schema
- Let's choose a server
3. Opinions: 15 min
- Jeff and Monica have experience
- Others?
4. Coffee break: 10 min
5. Discussion: 30 min
- Let's not forget risks
- Ask Joe about PostgreSQL
6. Conclusions: 10 min
Я уверен, вы знаете, о чем я говорю, и видели такие планы у ваших “архитекторов”. В любом случае, мой первый шаг сделан. Я назначил собрание продолжительностью полтора часа, на котором будут присутствовать все программисты. Мы хорошо проведем время и выпьем кофе. Обсудим проблему, выслушаем все мнения и найдем лучшее решение. Задокументируем это в файле schema.md и вернемся к своим задачам.
Вместо распространения этих сухих и скучных документов Git, у нас будет настоящее человеческое общение с приятным перерывом на кофе, где мы будем обмениваться мнениями о последнем эпизоде «Теории большого взрыва». Разве это не то, что нам всем нравится в нашей офисной работе?
I don’t think so.
Я думаю, что встречи размотивируют, тратят время, растрачивают деньги и ухудшают качество. Те, кто их организуют, либо не имеют представления о том, что делают, либо молча грабят компанию, в которой работают.
Нам были нужны встречи 30 лет назад, когда у нас не было ноутбуков и GitHub. Но даже тогда у нас была ручка и бумага.
Я говорю о встречах, которые предназначены для сбора или распространения информации, обсуждения или предложения чего-либо, или поиска решения в технической области. Единственная правильная цель встреч - это наблюдение за языком тела людей, с которыми вы имеете дело. Политики, бизнесмены, игроки в покер, психологи, врачи и т.д. - им нужны встречи, потому что они должны наблюдать за нашими телами, а не только за нашими мыслями.
Действительно ли нам важно тело Моники, когда мы разрабатываем схему базы данных? Ну, это зависит, верно? Но давайте будем серьезными; за это нам не платят.
Meetings Demotivate
Лучшая мотивация для творческого человека - увидеть результаты своего творчества. Если я не ошибаюсь, наслаждаться процессом творчества без каких-либо результатов - явный признак психического расстройства. Здоровый и творческий человек, например, программист, хочет видеть, как его усилия превращаются в что-то ценное и, желательно, осязаемое.
Встречи практически никогда не приводят к конкретным результатам и редко что-то ценное. Иногда у нас есть “протоколы” наших встреч, но это всего лишь краткие записи на листочках с кратким резюме того, о чем мы говорили. Не настоящий “продукт” для творческого человека.
Таким образом, они снижают мою мотивацию, потому что я просто не вижу, во что превратились два часа моей жизни. Мы там на самом деле не создаем ничего, мы просто обсуждаем. Обратите внимание; я говорю о собраниях, а не о коллективной работе над чем-либо, например, как в парном программировании.
Вы можете сказать, что некоторые встречи действительно порождают отличные идеи, которые являются очень осязаемыми результатами. Вы можете сказать, что только в прямой, личной обстановке эти идеи могут появиться. Вы также можете сказать, что многие яркие технические решения были изобретены именно благодаря волшебному синергетическому эффекту друзей, мыслящих в одном направлении, в одно и то же время и в одной комнате. Этот аргумент имеет смысл, но я рассмотрю его позже.
Meetings Waste Time
Я думаю, это очевидно. В первые несколько минут встречи вы сосредоточены; затем начинаете проверять ленту своего Twitter и рисовать каракули. Все делают то же самое — не потому что мы ленивые, а потому что на встрече нет необходимости полностью сосредотачиваться.
В то время как Моника работает с документом, оставляя комментарии и предложения, она полностью сосредоточена на результате — в основном потому, что некому помочь ей. Ей нужно отправить этот запрос на слияние, и я жду ее. Ее концентрация такая же высокая, как на совещании, когда кто-то задает ей прямой вопрос, и ей нужно дать подробный ответ.
Ее время оптимизировано для достижения подходящего результата, в то время как все остальные занимаются чем-то другим.
На встрече, с другой стороны, мы в лучшем случае слабо концентрируемся. И чем длиннее встреча, тем медленнее мы работаем. Кроме того, чем больше людей присутствует, тем меньше нас это волнует, и тем больше мы заинтересованы в обновлениях на Facebook. Я думаю, что для вас это не является сюрпризом, если вы хотя бы несколько месяцев работаете в сфере разработки программного обеспечения.
Meetings Burn Money
Это тесно соотносится с предыдущим заключением. Встречи являются одними из крупнейших потребителей бюджета любого типа деятельности в проекте, просто потому, что они оплачивают каждого, кто находится в той комнате или на той конференции Skype, при этом результат, который они производят, почти равен тому, что может достичь один человек. Или гораздо меньше.
Хотя это может показаться экстремальным, я должен сказать, что я считаю совещания легализованным способом обокрасть проект. Большинство организаторов совещаний (архитекторы, главные технические директоры, генеральные директоры, программисты и т. д.) не осознают этого. Они верят, что чем больше они говорят, тем лучше они инженеры. И их начальники, по ошибке, ценят такой вид активности со стороны своих подчиненных.
It’s robbery!
Я сказал тебе создать проект схемы базы данных. А сейчас ты приходишь ко мне и просишь встречи, потому что некоторые “аспекты” не ясны? Ты где-нибудь изучал разработку программного обеспечения? Ты знаешь, как работать с техническими документами? Ты способен писать так, чтобы все другие могли понимать и отвечать тебе также письменно? Нет? И теперь ты хочешь, чтобы проект не только заплатил тебе за проект схемы базы данных, но и заплатил мне за разговор с тобой, а также за то, чтобы еще несколько парней сидели рядом с нами и писали сообщения своим друзьям? По сути, ты хочешь ограбить владельца этого проекта. Ни больше, ни меньше.
Meetings Degrade Quality
Качество повышается, когда оно контролируется. Когда кто-то каждый день говорит мне, что мой код содержит ошибки и требует улучшений, мое качество повышается. Когда никому не важно, что я делаю или насколько хороши мои результаты, мое качество падает, несмотря на мою собственную мотивацию.
Встречи способствуют достижению групповых результатов и не поощряют индивидуальные достижения. Конец встречи часто неясен, кто именно предложил хорошую идею и кто внес наибольший вклад. Другими словами, в конце встречи я не знаю, насколько хорошо я себя проявил. Я остался таким же, как месяц назад, или я стал лучшим инженером?
Они улыбаются больше и чаще спрашивают меня “что ты думаешь?”, чем прошлым летом; это, должно быть, означает что-то, верно? Я уверен, что вы понимаете, что это не тот тип обратной связи, который ожидал бы серьезный инженер.
Серьезный разработчик программного обеспечения хочет получать конкретные результаты и обратную связь, например, деньги или обзоры кода. Я хочу знать, что было неправильно в моем черновике схемы базы данных и что я пропустил. И я хочу, чтобы это было документировано где-то. Именно это делает меня лучше, и так я узнаю и расту.
What About the A-ha! Moment?
А что насчет настоящего творчества или известного момента “а-ха!”? Иногда необходимо “мыслить вслух”, чтобы что-то изобрести, верно? Мы все знаем, насколько важным может быть личное общение, когда мы исследуем и разрабатываем что-то новое. Где бы мы были без встреч? Просто невозможно работать только с документами; нам нужно общаться друг с другом, чтобы выразить свои идеи. Разве это не очевидно?
У меня есть только один аргумент в пользу этого. Эйнштейн изобрел свою теорию на совещании со своими коллегами? Я не думаю. И он решал намного большую проблему, чем проектирование схемы базы данных.
Let me summarize. Meetings are an activity that requires almost no skill, while documenting ideas in text and diagrams is a way more difficult job to do. So train and discipline yourself to work with documents and let juniors enjoy their meetings.
Translated by ChatGPT gpt-3.5-turbo/30 on 2023-08-29 at 06:30
