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; мы обсуждаем наши решения; мы спрашиваем мнение наших коллег; и спорим о лучших идеях. Нет сомнения, что встречи являются ключевым компонентом современной дисциплины разработки программного обеспечения … и очень печально видеть это.
Хороший архитектор программного обеспечения, а также хороший менеджер проекта, не нуждаются во встречах и никогда их не организуют.
Встречи демотивируют, тратят время, тратят деньги и снижают качество. Но об этом позже. Пока давайте обсудим предложенную альтернативу.
Предположим, что я архитектор, которому нужно разработать схему для реляционной базы данных в новом проекте, и у меня есть команда из пяти программистов, которым я хочу помочь мне с этим проектированием. Это очень логичное и уместное желание, так как хороший архитектор всегда обсуждает все возможные варианты с доступными членами команды, прежде чем принять окончательное решение. Так что я вызываю встречу? Нет!
Я попросил Джеффа, одного из наших программистов, создать эскиз схемы БД, но фактически не обсуждал это с ним. Я ценю и уважаю его время - нет необходимости беспокоить его этой организационной суетой, поэтому я просто создаю тикет и назначаю его Джеффу. Когда у него появится время, он создает эскиз и возвращает запрос на слияние. Я его проверяю, оставляю комментарии, прежде чем он обновит ветку, и, наконец, я сливаю его.
Отлично, у нас есть эскиз.
В конце документа Джефф также перечислил предположения, риски и проблемы. Например, вот что я получил от него (это Markdown, очень удобный формат для простых технических документов; я настоятельно рекомендую его).
Я не знаю, сколько времени Джефф потратил на этот документ, но я только что создал его за 10 минут. Конечно, это очень простая схема для очень простого проекта. Но даже если Джефф потратил на это час, каждая минута этого часа ценна для проекта. Я имею в виду, что каждый доллар, который я плачу Джеффу за его время, возвращается мне в виде текстового документа.
Теперь у меня есть черновик, и я перехожу к следующему шагу. Я прошу Монику взглянуть на него и предложить изменения. Опять-таки, это еще один час, и я получил ответ с изменениями, исправлениями, новыми предположениями, новыми рисками и новыми заботами. Я не говорю с Моникой - нет необходимости в этом. У нее есть вся необходимая информация для работы с схемой базы данных. Она хороший инженер, и я доверяю ее способности выразить свое мнение в письменной форме.
Нет необходимости сидеть вместе в одной комнате или стоять у доски. Моника достаточно умна, чтобы справиться с этой работой самостоятельно. У нее уже есть все идеи, выраженные Джеффом перед ней; ей также нет необходимости говорить с ним.
После того, как я объединю ее запрос на объединение (после надлежащего обзора и исправлений), у меня будет новая версия моего документа schema.md.
Более того, у меня есть история Git этого документа, а также история запросов на объединение с комментариями. Это намного лучше, чем записи встреч или даже видеозапись встречи. Каждый, кто присоединится к проекту позже, сможет понять, как мы пришли к решению использовать PostgreSQL и хранить денежные суммы без центов. Все это есть в истории Git и билетах GitHub, навсегда с нами.
Что, если мне нужно больше мнений? Или если я все еще не уверен, что схема достаточно хороша? Нет проблем; я попрошу кого-то еще просмотреть ее еще раз и отправить мне запрос на объединение с изменениями. Я даже могу попросить Джеффа сделать это снова после нескольких итераций с другими программистами!
Более того, я могу добавить свои собственные заботы в документ, и на следующей итерации попросить Джеффа обратить на них внимание и разрешить.
Чем больше мы обращаемся к этому документу, тем лучше он становится. И каждая минута, за которую проект платит, превращается в материальный продукт: документ с историей изменений!
Вот как профессиональный архитектор собирает мнения и принимает сложные решения. Теперь давайте посмотрим, что сделал бы плохой архитектор.
Сначала я созваниваюсь на собрание. Нет, подождите; я запланирую его в Google Календаре. Нет, подождите, подождите. Прежде всего, я создаю повестку дня:
Я уверен, что вы понимаете, о чем я говорю, и вы видели эти программы от своих “архитекторов”. В любом случае, мой первый шаг сделан. Я назначил собрание продолжительностью полтора часа, на котором будут присутствовать все программисты. Мы будем веселиться и пить кофе. Мы обсудим проблему, выслушаем все мнения и найдем лучшее решение. Мы задокументируем это в файле schema.md и вернемся к нашим задачам.
Вместо того чтобы распространять эти сухие и скучные документы Git, у нас будет настоящее общение между людьми с приятным перерывом на кофе, где мы поделимся своими мнениями о последнем эпизоде сериала “Теория большого взрыва”. Ведь именно это нравится нам в наших офисных работах, не так ли?
Я считаю, что встречи демотивируют, тратят время, сжигают деньги и ухудшают качество работы. Те, кто их организует, либо не имеют понятия, что они делают, либо молча грабят компанию, для которой работают.
Нам нужны были встречи 30 лет назад, когда у нас не было ноутбуков и GitHub. Но даже тогда у нас были ручка и бумага.
Я говорю о встречах, которые предназначены для сбора или распространения информации, обсуждения или предложения чего-либо, или поиска решения в технической области. Единственная допустимая цель встреч - это читать язык тела людей, с которыми вы имеете дело. Политики, бизнесмены, игроки в покер, психотерапевты, врачи и т. д. - им нужны встречи, потому что им необходимо читать наши тела, а не только наши мысли.
Действительно ли нам важно, как выглядит Моника, когда мы разрабатываем схему базы данных? Ну, это зависит, верно? Но давайте будем серьезными; мы не получаем за это оплату.
Лучшая мотивация для творческого человека заключается в возможности видеть результаты своего творчества. Если я не ошибаюсь, наслаждаться процессом творчества без каких-либо результатов - очевидный признак психического расстройства. Здоровый и творческий человек, например, программист, хочет видеть, как его усилия превращаются в нечто ценное и, по возможности, осязаемое.
Встречи практически никогда не приводят к созданию чего-либо осязаемого и редко дают что-то ценное. Иногда у нас есть “протоколы” наших встреч, но это всего лишь краткие записки на листах бумаги с кратким изложением того, о чем мы говорили. Это не настоящий “продукт” для творческого человека.
Таким образом, они лишь лишают меня мотивации, потому что я просто не вижу, во что превратились два часа моей жизни. Мы на самом деле ничего не создаем там, мы просто обсуждаем. Обратите внимание; я говорю о встречах, а не о совместной работе над чем-то, например, в парном программировании.
Можно сказать, что некоторые встречи на самом деле порождают отличные идеи, которые являются очень осязаемыми результатами. Можно сказать, что только в прямой, личной встрече эти идеи могут появиться. Можно также сказать, что множество ярких технических решений были изобретены именно благодаря магическому синергетическому эффекту, когда друзья мыслят в одном направлении, в одно и то же время и в одной комнате. Этот аргумент имеет смысл, но я к этому вернусь позже.
Я думаю, это очевидно. В первые несколько минут встречи вы сосредоточены, затем начинаете проверять свою ленту в Twitter и рисовать на полях. Все делают то же самое, не потому что мы ленивые, а потому что нет необходимости полностью сосредотачиваться на встрече.
Тем временем Моника работает с документом, оставляет комментарии и предлагает свои идеи, она полностью сосредоточена на результате, главным образом, потому что некому помочь ей. Ей нужно представить этот запрос на слияние, и я жду ее. Ее концентрация такая же высокая, как на встрече, когда кто-то задает ей прямой вопрос, и она должна дать подробный ответ.
Ее время оптимизировано для достижения подходящего результата, в то время как все остальные делают что-то другое.
С другой стороны, на встрече мы все сосредоточены, в лучшем случае, скромно. И чем дольше встреча, тем медленнее мы. Кроме того, чем больше людей присутствует, тем меньше нам это важно, и тем больше интереса мы проявляем к обновлениям на Facebook. Я предполагаю, что это не слишком удивительно для вас, если вы работаете в индустрии разработки программного обеспечения хотя бы несколько месяцев.
Это тесно соответствует предыдущему заключению. Встречи являются одним из самых больших потребителей бюджета в любом типе деятельности в проекте, просто потому что они платят каждому, кто сидит в этой комнате или на этой конференции Skype, в то время как результат, который они производят, практически равен тому, что может доставить один человек. Или гораздо меньше.
Несмотря на то, что это может звучать крайне, я должен сказать, что считаю встречи легализованным способом ограбить проект. Большинство организаторов встреч (архитекторы, главные технические директоры, генеральные директоры, программисты и т. д.) этого не осознают. Они считают, что чем больше они говорят, тем лучше они инженеры. И их начальники, по ошибке, ценят такого рода деятельность со стороны своих подчиненных.
Я сказал тебе создать проект схемы базы данных. Теперь ты приходишь и просишь назначить встречу, потому что некоторые “аспекты” неясны? Ты где-нибудь изучал программную инженерию? Ты умеешь работать с технической документацией? Ты способен писать так, чтобы все остальные могли понять и отвечать тебе письменно? Нет? Теперь ты хочешь, чтобы проект оплачивал не только тебя за проект схемы базы данных, но и меня за разговоры с тобой, а также нескольких других парней, которые будут сидеть рядом с нами и писать сообщения своим друзьям? Ты в основном хочешь ограбить владельца этого проекта. Ни больше, ни меньше.
Качество повышается, когда оно контролируется. Когда кто-то говорит мне каждый день, что мой код содержит ошибки и требует улучшений, мое качество повышается. Когда никому не важно, что я делаю и насколько хорошие у меня результаты, мое качество понижается, несмотря на мою самомотивацию.
Встречи способствуют коллективным достижениям и не поощряют индивидуальные. В конце встречи часто неясно, кто именно предложил хорошую идею и кто внес самые значительные усилия. Другими словами, по окончании встречи я не знаю, насколько хорош я. Я все еще такой же, как месяц назад, или я стал лучшим инженером?
Они улыбаются больше и чаще спрашивают меня “что ты думаешь?” по сравнению с прошлым летом; это, должно быть, что-то значит, верно? Я уверен, вы понимаете, что это не тот вид обратной связи, который серьезный инженер ожидал бы.
Серьезный разработчик программного обеспечения хочет получать осязаемые результаты и получать конкретную обратную связь, такую как деньги или рецензии на код. Я хочу знать, что было неправильно в моем проекте схемы базы данных и что я упустил. И я хочу, чтобы это было где-то задокументировано. Именно это делает меня лучше, и именно так я учусь и расту.
А теперь, что насчет настоящего творчества или того известного момента “а-ха!”? Иногда необходимо “мыслить вслух”, чтобы что-то изобрести, верно? Мы все знаем, насколько важным может быть прямая коммуникация, когда мы исследуем и разрабатываем что-то новое. Где бы мы были без встреч? Мы не можем просто работать с документами; нам необходимо общаться друг с другом, чтобы высказать наши идеи. Это же очевидно?
У меня есть только одна аргументация по этому поводу. Эйнштейн изобрел свою теорию на совещании со своими коллегами? Я не думаю. И он решал гораздо большую проблему, чем проектирование схемы базы данных.
Позвольте мне подвести итог. Встречи - это деятельность, требующая почти никаких навыков, в то время как документирование идей в тексте и диаграммах является гораздо более сложной задачей. Поэтому тренируйте и дисциплинируйте себя работать с документами, а позвольте младшим наслаждаться своими встречами.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-28 at 15:14
