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

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

Хороший архитектор, как и хороший 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, программисты) не понимают этого. Они верят, что, чем больше они разговаривают, тем лучшие они инженеры. А их начальники по ошибке ценят в своих подчиненных этот вид деятельности.

Это грабеж!

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

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


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

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

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

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

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


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

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

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

Similar posts

Comments 227

    +14
    Если так рассуждать, то и парное программирование — грабеж проекта. Совещания, при правильном подходе, вполне продуктивны.
      –2
      Если так рассуждать, то и парное программирование — грабеж проекта.

      А разве нет? Парное программирование выгодно только тогда, когда выхлоп в единицу времени в 2 раза больше, чем при традиционном программировании. Я в такие сказки не верю, хотя и был бы рад ошибиться.
        +10
        Парное программирование помогает быстрее обучать стажеров/джунов до более высокого уровня, да, крадется время у более опытных разработчиков, но в перспективе команда выигрывает (опустим случай, когда большая текучка кадров)
          +3
          Верно, нанимаешь джунов — будь добр обучай. Правда, тут может быть недопонимание, о каких именно джунах мы говорим: вчерашний выпускник вуза по айтишной специальности, который уже умеет кодить, но не имеет опыта Коммерческой Разработки™, или вчерашний разносчик пиццы.
            +14
            вчерашний выпускник вуза по айтишной специальности, который уже умеет кодить
            хе-хе
              –10
              Не понимаю, что тут смешного. Вспоминаю себя в начале карьеры. С первого рабочего дня надо мной не надо было стоять и показывать, как сделать таску, а кодил я уже тогда получше некоторый «сеньоров», с которыми довелось столкнуться. А ведь я был далеко не лучшим на потоке, можно даже сказать — отстающим.
              Может, просто надо из приличных вузов набирать людей?
                +10
                Я ничуть не умаляю (в целом) достоинства выпускников вузов по айтишной специальности, более того, я сам такой выпускник в общем-то. И в том числе (помимо контактов по работе) именно поэтому может меня улыбнул слишком общий выбранный квантор. А на самом деле тут как повезёт (и это как минимум). Плюс прикол в том, что те выпускники, которые умеют кодить, к окончанию вуза обычно уже работают.
                  0
                  А те кто не работают… Грусть…
                    +1
                    Ну я не работал. Немного жалею об этом, но переоценивать «коммерческую разработку» тоже не стоит. Люди, бывают, годами в ней варятся и пишут хуже второкурсника.
                      +4
                      А те, кто не умеют — устраивают совещания
                    –1
                    С первого рабочего дня надо мной не надо было стоять и показывать, как сделать таску, а кодил я уже тогда получше некоторый «сеньоров», с которыми довелось столкнуться.

                    Да, где-то 5-15 из 100 человек такие.
                      –3
                      Ну, так я не просто так про приличные вузы добавил)
                        0
                        Это что вы считаете «приличными ВУЗами»
                        Просто я имел опыт общения с выпускниками ВМК МГУ, Физтеха…
                        Ребята есть очень хорошие, но статистика удручающая и до 5-15 человек она далека
                        При этом много ребят умных, но отлично видно, что образование им впрок не пошло, учили их не так, не тому и надо еще учить, учить, учить и учить
                      +5
                      надо из приличных вузов набирать людей?

                      (озарённо хлопнув себя по лбу) Точно! Надо было просто уничтожить все плохие вузы и бездарей отправить в хорошие — вот зажили-бы то, а?
                        –1
                        Кого волнуют бездари? Не берите их на работу. Или только такие идут?
                          +1
                          Кого волнуют бездари? Не берите их на работу. Или только такие идут?

                          Вы и надежный способ знаете как их определить на этапе приёма в ВУЗы и приёма на работу с, хотя бы, 90% вероятностью?
                            0
                              0
                              ЕГЭ по информатике несколько сложнее решения FizzBuzz'ов.
                            –1
                            Вы же буквы прочитали, но очевидный смысл почему-то не восприняли. Как так вышло? Это последствия вашего обучения или что-то индивидуальное?
                              0
                              Ну я могу вам теми же словами ответить. Дальше что?
                  +5
                  Это, безусловно, не каждодневная практика, но часто в неочевидных ситуациях работа в паре позволяет гораздо быстрее добраться до решения, и итераций намного меньше приходится делать. Относится и к проектированию, и к кодированию. Статистику я не собирал, так что цифрами подкрепить не смогу, но по ощущениям, часто в 2-3 раза быстрее получается, чем в одиночку. Сразу оговорюсь, я имею в виду только свою область — CADы для электронной индустрии, и свой опыт.
                    –1
                    Статистику я не собирал, так что цифрами подкрепить не смогу, но по ощущениям, часто в 2-3 раза быстрее получается, чем в одиночку.

                    Ну вот то-то и оно. Мозг прекрасно умеет себя обманывать, плохо чувствует время и производительность.
                      +1
                      А где аргументы с вашей стороны? Статистика которое учитывает не только сколько бы второй человек сам написал за это время, но и то сколько времени ушло бы на исправление ошибок (как мелких логических, так и архитектурных), последующая поддержка не очевидных вещей, отдельное проведение код ревю (хотя наверно это тоже трата времени).
                        0
                        Как вам такой аргумент, Илон Маск? Аргументы нужны как раз тем шарлатанам, кто обещает прирост производительности в разы.
                          +1
                          Ну так вы и обещаете «прирост производительности в разы.», не?
                        +4

                        Иронично, что в защиту своей точки зрения, вы даёте ссылки на сообщество lesswrong, созданное благодаря Юдковскому, который написал книгу Гарри Поттер и методы рационального мышления, в которой в значительной мере изложены принципы lesswrong.


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

                          0
                          Да, но за одним столом часы превращаются в секунды.

                          К тому же работает эффект «большого брата» — неудобно гадить в коде, когда за тобой смотрят.

                          Парное программирование в норме — это когда нужно быстро сделать хорошо работающий код ценой двукратного увеличения расхода человеко-часов.
                          Хорошо это или плохо — зависит от конкретной ситуации. Это как спорить что лучше инвалидная мотоколяска или суперкар?
                            0
                            А гадить в коде, который будет проходить через ревью, удобно?
                              +1
                              Да. Ведь гадишь сейчас — а ревью потом. В режиме вдохновения или загона человек живёт здесь и сейчас и даже на несколько часов вперёд не думает. Пока пройдёт цикл нашли — ткнули носом — исправил, время ушло, успел позаниматься чем-то более «важным». А тут кодеревью прямо в момент забивания кода.
                              Кодеревью работает когда дедлайна ещё не видно или только-только замаячил на горизонте
                        +5
                        Парное программирование это не про выхлоп в единицу времени в 2 раза больше. Изначально оно планировалось, для повышения качества выходного продукта. Пока один пишет код, другой продумывает все возможные неприятны ситуации. Это не говоря о ситуациях, когда опытный программист заходит в тупик(потому что он долго занимается одной задачей), а второй помогает выйти из тупика, потому что у него более свежий взгляд.
                          0
                          Для того, чтобы продумывать неприятные ситуации и помогать друг другу выходить из тупиков, совсем не обязательно сидеть за одним столом.
                            +7
                            Попадание в тупик в парном программировании детектится за полминуты, в одиночном — за пару дней.
                              +2
                              Необязательно, но так критически сокращается время на коммуникацию, что позволяет не терять концентрации. А когда ты пишешь вопрос другому разработчику, а тот решил вот сейчас сходить на обед или просто в потоке и его еще пару часов оттуда не ждать — то тебе приходится сидеть и ждать или переключаться на другую задачу. Или идти дальше в этой без ответа. Все три варианта хуже чем получить ответ сразу же потому что человек вот он и занимается именно тем что помогает тебе.
                                +1
                                Тоже верно. Автор, кстати, сторонник парного программирования (возможно, кому-то покажется это противоречащим данной статье, но это нормально). «Получить ответ сразу же» — при парном программировании работает, т.к. отвечающему не нужно переключаться. Но что мы видим сплошь и рядом? Программист сталкивается с проблемой и, зачастую даже не потрудившись «покурить маны», ищет в своем скотном дворе опенспейсе жертву, имевшую дело с чем-то подобным. Вот с этой чумой нужно бороться.
                                  0

                                  Да, это отдельная песня, когда к тебе 42 раза в день приходят люди что нибудь быстренько спросить во время вдумчивого дебага

                              0

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

                                0
                                На ревью обычно выносят уже готовую задачу.
                                  +3
                                  автор очень большого пул реквеста

                                  Найдите ошибку. Организационную.
                                    +1
                                    Не ради спора про конкретный случай, но в целом практика ревью, когда несколько человек заранее посмотрев код потом слушают автора и оставляют комментарии — это просто классика, такой подход даже в том же совершенном коде описан. Очевидно что организовывать такое сборище на каждый пулреквест смысла нет — придется целыми днями только этим и заниматься. Поэтому при определенной организации, мне кажется, вполне возможно иметь большие пулреквесты с полноценной ревью сессией из нескольких человек и даже, при желании, администратором. Опять же — возможен вариант когда этот большой пул реквест является именно что компиляцией более мелких изменений, которые в свою очередь были проверены в обычном порядке.
                                    Другое дело что я ни разу не видел ни компании где бы это делали, ни людей у которых было бы желание такой бюрократией заниматься на регулярной основе.
                                  0
                                  > Пока один пишет код, другой продумывает все возможные неприятны ситуации.

                                  А чем это лучше code review?
                                  Минусы вот я сходу могу назвать, и все они связаны со «стоянием над душой» в процессе разработки и невозможностью спокойно подумать, набрасывая при этом разные и иногда глупые варианты. А плюсы какие?
                                    +2
                                    Плюсы те же самые, как ни странно, просто разные люди по-разному реагируют на одинаковые раздражители.
                                  +1
                                  Если так рассуждать, вы получите сразу все увлекательные радости эффективного менеджмента
                                  Джуны наговнокодят, сеньоры выгорят, сопьются и свалят, миддлы, вероятнее всего, успеют сделать и то, и то, опыт
                                  Рассматривать персонал как станок для печати денег на все часы, за которые вы им платите, в некоторых сферах можно, но не в IT, тут все против вас: и конкурентный рынок труда, и довольно высокие психологические нагрузки, и высокий средний уровень жизни персонала, и все это в условиях, когда никто и нигде особо не готовит «готовых специалистов»
                                  В итоге — да, персонал приходится учить, а тут парное программирование и кодревью — один из лучших инструментов, и заниматься этим должен кто-то из довольно опытных «дорогих» разработчиков, ужас какой
                                  Также работать в IT стандартные 40 часов постоянно невозможно физически, да в режиме аврала можно и 60, и 80, но редко и по необходимости, а из недели в неделю выдаивая персонал нагруженной работой без кофебрейков, совещаний и прочего «грабежа» 40 часов нагруженной работы вы получите выгоревший уставший штат, который начнет разбегаться и разваливаться, если, конечно, вы не платите вдвое больше рынка или не приковываете разработчиков к батарее
                                  Короче говоря, рассуждая о затратах времени и бабках — не забывайте, что есть еще командная рабочая атмосфера, обучение и прочие, казалось бы, побочные вещи, без которых команда функционировать нормально и долго не может
                                  Другой разговор, что есть персонажи, которые любят совещаниями злоупотреблять, это тема отдельной беседы, но говорить «у вас есть гит, нечего тратить рабоче время на потрепаться» — как минимум, наивно, даже если 80% совещаний, кажется, тратят время впустую
                                    0
                                    Code sharing еще.
                                    В парном программировании экономится время второго разработчика, которому потом надо будет в код въезжать.
                                    +3
                                    Совещания, при правильном подходе, вполне продуктивны.

                                    Опишите, пожалуйста, правильный подход.
                                      +3
                                      Формализовать врядли смогу, да и не люблю я формальные схемы. Вкратце, для нашей команды работающий подход выглядит примерно так — собираются 2-3 человека, которые в теме, брейнстормят проблему, рисуют картинки, собирают в кучку юзкейсы, набрасывают вчерне план действий. Потом идут реализовывать POC. Если надо, опять собираются и обсуждают, куда и как дальше двигаться. Постепенно из POC вырастает финальная имплементация.
                                        0
                                        Согласен, brainstorm иногда может быть эффективным (например, когда нужно придумать название продукта).
                                        +2
                                        Даже если просто кому-то проговариваешь и озвучиваешь свою проблему/идею — очень часто тут же находишь решение. Думаю это свойство работы мозга, наверняка уже кем-то изученное.

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

                                        Совещания бывают разные. Когда произошло падение прод.сервера, главное фокусироваться не на поиске виновных, а на причинах и способе решения проблем. Акцент напоиске виновных это вообще мега-непродуктивно и это бич любой работы. Если вы на работе думаете не о том, как быстро решить проблему и не допустить её в дальнейшем, а преимущественно о том, как уйти от ответственности — с таких работ надо валить. Это очень нездорово. Конкретно я говорю про сферу ИТ. Концентрация на наказаниях виновных убирает очень важный элемент — личную ответственность и профессиональную «гордость». Когда «стыдно», что сервис упал это одно. Когда действуешь от мотивации «сделать лучше, чтобы не попало» — качество работы неизмеримо хуже.

                                        Так же на совещаниях важно умеь грамотно управлять расфокусировкой внимания и его сужением. Есть время для брейншторма, когда любая идея не подвергается критике. Есть время, когда надо лезть в детали глубже.
                                        Людей надо постоянно подгонять и учить говорить ближе к сути. Предварительная небольшая переписка всем участникам позволит не тратить время совещание на озвучивание проблемы на совещании (можно только кратко объяснить ещё раз).

                                        Я видел очень эффективные совещания и двухчасовые, которые легко было бы уложить в пять-десять минут.
                                          –5
                                          Коллективный разум рулит.

                                          Вот только реальная жизнь подтверждает обратное. Подавляющее большинство шедевров созданы одиночками. Исключения настолько редки, что можно по пальцам пересчитать всех этих братьев Гримм, Ильфа и Петрова и братьев сестер Вачовски.
                                            +11
                                            Хочется посмотреть на шедевральный коммерческий самолёт, собранный одиночкой
                                              +3
                                              да даже самый известный не коммерческий собран братьями, которых автор собирается по пальцам считать.
                                                +2
                                                это вы про братьев Райт? Среди которых один был идеологом?)
                                                Братья Райт всегда являлись для общества единым образом, совместно обладая правами на свои изобретения. Тем не менее, биографы обращают внимание, что Уилбур в 1899—1900 годах был инициатором авиационных проектов, писал о «своей» машине и «своих» планах до того, как Орвилл стал принимать серьёзное участие в проектах брата; только после появляются слова «мы» и «наш»
                                                0
                                                так-то у самолёта один главный конструктор и тыща человек, которые крутят гайки. Разработка ПО это же тоже творческий процесс. Хотя может вы сравниваете разработку с вытачиванием болтов на станке?
                                                  +2
                                                  Ситуация в инженерном деле вовсе не такова, что все, кроме главного конструктора, крутят гайки. Главный конструктор большого проекта вообще может мало что лично делать в техническом отношении, и уж точно он не сам всё разрабатывает. Скорее его техническая роль ближе к тому, чтобы взвесить предложения подчинённых и выбрать из них лучшие.
                                                  0
                                                  Ну, так можно и подмастерьев, добавляющих второстепенные детали, считать полноправными соавторами картины, но сами понимаете…
                                                    0
                                                    Аналогии творчества и технической работы не считаю правильными. Картина — намного менее сложный продукт, где общий эскиз, композиция — действительно могут делать главного мастера — единственным полноправным автором. Но в технических специальностях вклад каждого отдельного сотрудника, допустим, сделавшего какой-то модуль в системе — пропорционально более существенен, нежели вклад подмастерья, раскрасившего одну фигурку в картине
                                                  0
                                                  Посчитайте, сколько Нобелевских премий было получено в последние 10 лет гениями-одиночками, а сколько — командами ученых. Вы будете очень удивлены. Я уже вижу в ваших глазах слезы катарсиса.
                                                    +1
                                                    Памятуя Гейма, который соавтором статьи о диамагнитной левитации вписывал своего хомяка, и кота Ф.Д.Ч. Уилларда — похоже существуют какие-то административные барьеры на пути истинных одиночек.
                                                  +2
                                                  Нельзя так же забывать про когнитивные искажения. Например, если человек думает что нашёл источник проблемы — ему очень сложно будет заметить другие возможные причины возниконвения проблемы.

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

                                                      Если более общо, их надо учить выражать свои мысли кратко, четко и по существу. А болтовня способствует обратному. В принципе, она и нужна на проекте тогда, когда люди не могут нормально выразить свои мысли в письменном виде, и чаще всего это признак отсутствия соответствующих навыков.
                                                      0
                                                      У нас применяется такой подход: Скайп-конференция на 5-15 минут. В течении совещания при желании можно пить чай :-)
                                                    +25
                                                    Это рассуждения разработчика или в крайнем случае архитектора, но никак не менеджера.
                                                    И пример глупый. Разве кто-то для разработки схемы БД собирает совещание?
                                                    А вот для объяснения (обсуждения) самого проекта совещание нужно обязательно.
                                                    Оно нужно для погружения в контекст нового проекта, обсудить его ограничения и приоритеты, слегка мотивировать команду, получить от команды обратную связь и т.д.
                                                      –7
                                                      Это рассуждения разработчика или в крайнем случае архитектора, но никак не менеджера.

                                                      Это рассуждения менеджера с большим опытом, который, к тому же, несколько лет управляет чисто распределенной командой без instant messaging и совещаний.
                                                        +1
                                                        который, к тому же, несколько лет управляет чисто распределенной командой
                                                        Так может быть именно в этом дело? Для распределенной команды стиль работы и способ постановки задач в корне отличается от совместной работы в одном офисе.

                                                        Например, существует хороше правило «трех писем», (если переписка по вопросу растянулась на три ответа Re:, то нужно отрывать одно место от кресла и идти ножками к оппоненту, что бы в живую обсудить возникшие в переписке непонятки, и только после это писать четвертое письмо, которое должно фиксировать устно достигнутые договоренности).
                                                        Но такой прием крайне не эффективен для удаленных сотрудников. Поэтому меньшим злом и будет четкие, письменно поставленные задачи (примерно так, как описано в статье).

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

                                                          Практически тоже самое делаем в распределённой команде. Если в жире идёт больше трёх комментов одного осуждения, и явно ожидается четвёртое – собирается созвон, затем в жиру фиксируется результат, иначе это может продолжаться бесконечно, при том с достаточно большими лагами.
                                                            +1
                                                            Четкие, письменно поставленные задачи — это не «меньшее зло», а нормальный процесс. Неспособность нормально поставить процесс — это обыкновенное разгильдяйство и непрофессионализм, хоть в офисе, хоть удаленно.
                                                              +1
                                                              А еще лучше, большая красная кнопка «Выполнить».
                                                              К сожалению, в реальном мире бывают и форс мажор и неправильно понятые задачи. Выше как раз и шла речь о том, что же можно сделать, если возникли подобные непонятки, а работать приходится с той командой, которая у тебя есть на текущий момент.
                                                                0
                                                                Special cases aren't special enough to break the rules.
                                                          +3
                                                          Разве кто-то для разработки схемы БД собирает совещание?

                                                          Вы таки не поверите…
                                                            +1
                                                            Конечно не поверю. Не поверю, что в результате может получиться что-то стоящее ;-)
                                                              0
                                                              Вы считаете, что цель типичных «митингующих» — что-то стоящее?)
                                                                0

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

                                                            –6
                                                            А вот для объяснения (обсуждения) самого проекта совещание нужно обязательно.
                                                            Оно нужно для погружения в контекст нового проекта, обсудить его ограничения и приоритеты, слегка мотивировать команду, получить от команды обратную связь и т.д.

                                                            Не нужно, и в статье это подробно расписано.
                                                              +4
                                                              Не нужно, и в статье это подробно расписано.
                                                              В статье приведены однобокие примеры, вырванные их контекста.

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

                                                              И каждый из ответов может повлиять на необходимость проводить совещания.
                                                                +5
                                                                Я — тестировщик. Моя работа — задавать вопросы о которых никто не подумал, потому что я нахожусь в уникальной позиции, у меня другое мышление (если интересно я могу углубится и объяснить почему так и почему это логично, но это уже сильно оффтоп будет). Вы представляете сколько мне нужно прочитать писем и документов чтобы понять что хотел получить клиент, как его понял менеджер и что собираются делать разработчики? И сколько писем мне нужно будет написать чтобы узнать ответы на вопросы которые у меня появляются и которые никто до меня не задал? Я уж не говорю что написание документации которая мне нужна займет на порядок больше времени чем совещание где это будет проговорено соответствующим человеком. И что никто и никогда такую документацию не пишет.
                                                                  +1
                                                                  Я уж не говорю что написание документации которая мне нужна займет на порядок больше времени чем совещание где это будет проговорено соответствующим человеком.

                                                                  Угу, давайте сейчас выгадаем пару часов. Ну и что, что потом придется объяснять это снова и снова (а иногда и пытаться вспомнить через полгода, хе-хе).
                                                                    0
                                                                    А вот для этого, обычно, вещи, сказанные устно, фиксируются в Протоколе (да-да, о нем было сказано в статье).
                                                                      0
                                                                      Не так. Документация пишется параллельно разработке и маленькими частями после того как все важные вопросы были проговорены и достигнуто более-менее одинаковое понимание конечного результата. И да, естественно, в процессе возникают отклонения от первоначальной задачи, цели меняются, подводные камни выявляются и обходятся и так далее. Поэтому те несколько часов которые были бы потрачены на документацию в начале никак не уменьшат проблемы потом. Потому что написанную документацию все равно придется переписывать и дописывать и по многу.
                                                                      Более того, эту документацию придется еще каким-то образом организовывать чтобы было понятно что в ней — всего лишь предварительные планы, а что — уже скорректированная реализация. Я вообще не уверен что в сколько-то большом проекте это в принципе возможно.
                                                                  +1
                                                                  Это рассуждения Yegor Bugayenko. Вы просто поищите в гугле, и составьте себе собственное представление.
                                                                    0
                                                                    Он конечно человек своеобразный, но денег на 0crat вроде бы зарабатывает. Может, в его словах все таки что-то есть?
                                                                  +4
                                                                  Совещания никогда не производят ничего осязаемого и редко — что-то ценное.

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

                                                                    +2
                                                                    Но если они на совещании отбывают повинность, то и результат тт, о котором пишет автор.

                                                                    На совещании на 3+ человек обычно двое разговаривают, а остальные отбывают повинность рисуют каракули.
                                                                      +3
                                                                      В этом примере просто плохо построен процесс коммуникации.
                                                                        0

                                                                        Здесь ключевое слово "обычно". А еще есть русская традиция


                                                                        на троих или третьим будешь!

                                                                        Можно еще вспомнить греческие симпозиумы.

                                                                          –1
                                                                          Вот с такими вот «обычаями» и нужно бороться!
                                                                            0

                                                                            К чему эта борьба у нас в итоге привела мы знаем. Повторения не надо. А чему способствовали симпозиумы в Древней Греции мы тоже знаем.

                                                                              +1
                                                                              Ну и к чему же? С перегибами нужно бороться порой даже противоположными крайностями, главное — не увлекаться.
                                                                      +23
                                                                      В целом согласен с автором. Но проблема в том, что автор смотрит на мир через розовые очки.

                                                                      Автор думает, что будет так:

                                                                      1. Джефф проектирует базу
                                                                      2. Моника вносит полезные улучшения
                                                                      3. Профит!

                                                                      А на самом деле будет так:

                                                                      1. Джефф проектирует базу
                                                                      2. Моника считает, что всё надо делать по другому и переписывает написанное Джеффом
                                                                      3. Всё, работа зашла в тупик и без обсуждения вживую, голосом, это не разрулить

                                                                      Поэтому я склоняюсь к более реалистичному сценарию:

                                                                      1. Архитектор проектирует базу
                                                                      2. Если архитектору нужно мнение Джеффа и Моники — он просит их посмотреть проект и написать комментарии
                                                                      3. Архитектор вносит правки по комментариям, если сочтет это нужным.
                                                                      4. Профит

                                                                        +12
                                                                        Вот тут как раз соль в том, что совещания, как способ немножко (много — не получится) совместить взгляды на проблему — это как раз очень нужный элемент процесса. Хорошее совещание — это такое совещание, после которого участники думают примерно об одном и том же. И если взгляды удалось достаточно совместить — то вот тут и начинается дальнейшая продуктивная деятельность без мнений о том, что нужно всё переделать.
                                                                          0
                                                                          Автор оригинальной статьи считает, что архитектор должен быть диктатором. Поэтому взгляды на проблему совмещаются через него: все обмениваются мнениями в письменном виде, но окончательное решение принимает архитектор, а не семиголовая гидра.
                                                                            –1
                                                                            Так если всё построенно на диктатуре, то совещания не проводятся. Зачем? Само слово «совещание» подразумевает получение/распространение советов.
                                                                              +2
                                                                              Не увидел противоречия с автором в плане получения советов. Ответственность за проект в целом несёт архитектор, а не семиголовая гидра, в которой потом никогда концов не найдёшь, Поэтому после прихода к какому-то общему знаменателю, всё фиксируется на бумаге и распространяется через архитектора. С учётом того что могут быть не довольные и их даже может быть большинство, то тут точно не демократия
                                                                                0
                                                                                Ну так я и не спорю. Если первое и последнее слово за архитектором, а советы ему не нужны, то и в совещаниях нет смысла и проводить их врядли кто-то разумный будет.
                                                                                +1
                                                                                Архитектор выслушивает разные аргументы, а окончательное решение принимает сам. Не вижу противоречия.
                                                                                  0
                                                                                  Иди делегирует принятие решения разработчику, если особой разницы между вариантами не видит, но желает иметь самостоятельных разработчиков, а не бегающих к нему за каждым чихом
                                                                            –8
                                                                            Моника считает, что всё надо делать по другому и переписывает написанное Джеффом

                                                                            Это просто вредительство и непрофессионализм. Моника должна получить втык, при рецидиве — увольнение. Ее просили сделать ревью, а не переделать.
                                                                              +17
                                                                              С чего бы вдруг? Проект Моники может быть лучше и возможно втык надо давать Джеффу, за которым всё пришлось переделывать.
                                                                                –10
                                                                                Если Моника знает, как сделать лучше, она должна кратко описать это в комментарии и дождаться апрува, а не самовольничать. Это же обыкновенный профессионализм и дисциплина.
                                                                                  +5
                                                                                  В каком ещё комментарии? В статье говорится о том, что Моника вносит правки непосредственно в документ, написанный Джеффом.

                                                                                  Но пусть даже она просто написала комментарий. Там будет написано так — «тут всё надо переделать». Что дальше? Дальше ей нужно будет написать другой документ, со своим видением? К которому уже Джефф напишет комментарий «тут всё надо переделать»?

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

                                                                                    Где конкретно?
                                                                                      0
                                                                                      В каком ещё комментарии?

                                                                                      На том же гитхабе можно комментировать строчки кода.
                                                                                        –3
                                                                                        Там будет написано так — «тут всё надо переделать».

                                                                                        Если в вашей команде кто-то может оставить такой комментарий и его после этого считают профессионалом, то мне вас жаль.
                                                                                      +4
                                                                                      Может и лучше, но кто будет давать втык Джеффу и почему? Только потому, что кто-то оказался лучше, чем Джефф?
                                                                                        +1
                                                                                        Я не предлагаю давать втык никому из них. Это я просто перефразировал утверждение предыдущего комментатора, показывая, что это работает в обе стороны.

                                                                                        Вместо этого я предлагаю вообще не полагаться на то, что Джефф и Моника сами как-то там устаканят решение письменно. Не устаканят.
                                                                                          +1
                                                                                          Они и не устаканивают сами, устаканивает архитектор в конечном счете.
                                                                                    0
                                                                                    Это тоже взгляд через розовые очки :) Да, вариант когда архитектор все проектирует (а точнее, просто самый умный из команды) — он иногда близок к идеалу. Но увы, в жизни ресурсы самого умного всегда ограничены, поэтому его задачи приходится делегировать менее умным или опытным членам команды.
                                                                                      +2
                                                                                      На 100% согласен с вами.
                                                                                      У нас в компании — под такие вопросы создается Design Topic в конфлуенс, все желающие смотрят. Автор указывает тех, кто обязательно должны прокомментировать. Все работает идеально.
                                                                                      +6
                                                                                      У автора не построена связка между коммуникацией и деятельностью, вот и всё, что можно сказать. У него в голове только связка между мышлением и деятельностью, классическая советская традиция образования. В этом нет ничего плохого, но это только одна возможная проекция.

                                                                                      А что касается тикетов, то их можно раздавать только в совершенно понятной, причём понимаемой всеми одинаково, предметной области.
                                                                                        +1
                                                                                        У автора не построена связка между коммуникацией и деятельностью

                                                                                        Что вы имеете в виду? Коммуникации бывают письменными, я гарантирую это.
                                                                                          +7
                                                                                          Коммуникации бывают письменными, но мысль автора состоит в том, что коммуникацию желательно максимально сократить, как издержку работы. Вдобавок, он сужает коммуникацию до передачи информации о задаче.

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

                                                                                            Мы собрались, чтобы сделать проект и заработать денег или приятно провести время и обсудить сериалы? Полагаю, первое. Так что коммуникации должны быть максимально эффективными, что чаще всего подразумевает их сокращение по сравнению со средней ситуацией в нашей индус-трии.
                                                                                              +1
                                                                                              Во-первых, я бы уточнил формулировку ситуации. Мы собрались, чтобы заработать денег и приятно и полезно провести время, одним из средств достижения чего является проект. В предельном случае может даже так получиться, что для нашего бизнеса невыгодно успешное выполнение проекта, а уж баланс стоимости и качества – это вообще обычное дело.

                                                                                              Во-вторых, сама по себе коммуникация является одним из средств выполнения проекта.

                                                                                              Относительно среднего рассуждать не берусь. Видел я фирмы, перегруженные совещаниями, это, конечно, плохо. Но это не значит, что плохи сами совещания, а просто каждый инструмент нужно применять правильно.
                                                                                                0
                                                                                                Мы собрались, чтобы заработать денег и приятно и полезно провести время

                                                                                                Продукт овнеру все равно, приятно вы проведете время или будете ненавидеть каждую минуту, посвященную проекту. И если вы вместо наиболее эффективного выполнения своей работы ищете компромиссы между эффективностью и обсуждением сериалов, то вы просто грабите продукт овнера, только и всего.
                                                                                                  0
                                                                                                  Чьи это проблемы? Крепостное право в России отменили в 1861 году. Собственник может, конечно, поискать других программистов, которые будут работать на его благо, ненавидя каждую минуту, но почему-то такие запросы редко приводят к коммерческому успеху.
                                                                                                    0
                                                                                                    И тем не менее сути этих компромиссов это не меняет.
                                                                                                      0
                                                                                                      “Политика – искусство компромисса”.
                                                                                                        0
                                                                                                        Да-да) Именно поэтому честные люди в политику не идут)
                                                                                          0
                                                                                          А что касается тикетов, то их можно раздавать только в совершенно понятной, причём понимаемой всеми одинаково, предметной области.

                                                                                          Спорно. Не могли бы вы развернуть свою мысль?
                                                                                            +2
                                                                                            Чтобы получатель правильно понял мысль отправителя, у них должно быть построено одинаковое понимание смысла и контекста применения используемых слов. Либо заранее, либо в процессе коммуникации.
                                                                                              –1
                                                                                              Неочевидные термины должны быть задокументированы. Или вы считаете, что рассказывать их персонально каждому новичку — это эффективная организация коммуникации?
                                                                                                +5
                                                                                                Насколько я в курсе, задокументировать все неочевидные термины можно только на языке Ифкуиль, но его мало кто знает. А в практическом плане, если для сложной задачи документировать всё, что может показаться неочевидным, то возникнет объём документации такой толщины, что её мало кто сможет освоить.
                                                                                                  +1
                                                                                                  мало кто сможет освоить
                                                                                                  Ее и написать то никто не сможет. Документация вообще подлая вещь, она устаревает постоянно, но неизвестно в каких местах и когда именно. Более того, неизвестно соответствует ли она в принципе проекту, это надо еще выяснять. Я не говорю что документация не нужна, но это тоже инструмент который нужно уметь применять и проблем с ним не меньше чем с совещаниями.
                                                                                                    +1
                                                                                                    Документация вообще подлая вещь, она устаревает постоянно, но неизвестно в каких местах и когда именно. Более того, неизвестно соответствует ли она в принципе проекту, это надо еще выяснять.

                                                                                                    Так происходит потому, что ее пишут для галочки и потом всем на нее пофиг. Поддерживать документацию трудно и скучно, а отрывать от работы соседа по кабинету просто и весело.
                                                                                                      0
                                                                                                      Я люблю писать документацию) Но что-то никто не хочет платить за работу технического писателя по ставке ведущего программиста)
                                                                                                        –5
                                                                                                        Зато хотят платить по ставке ведущего программиста за «работу» кхм-бола?)
                                                                                                          0
                                                                                                          кхм-бола? это вы завуалировали так «пиздабола»?
                                                                                                          Очень вежливо с вашей стороны, ничего не скажешь, следите за тоном.
                                                                                                          В чем вопрос? Сомнения в том, какую должность/зарплату я занимаю? может быть еще и фото расчетного листка приложить для вас?))
                                                                                                          Может я некорректно выразился, поясню мысль: я по большей части разрабатываю софт, но нередко приходится писать и документацию, и спецификации, и мне реально нравится это делать (но не могу поручиться, что я был бы рад ТОЛЬКО этим заниматься каждый день весь год). Намек был лишь только на то что все люди разные, и утверждать, что все прям сознательно отлынивают от написания доки, как-то чересчур категорично.
                                                                                                            0
                                                                                                            Мда… Прошу прощения, если задел, но вообще-то я про вас лично не писал и не намекал. Никто не хочет платить за работу техписа — это везде так. За работу peace-door-ball-а — тоже. Все мы выполняем эту «работу», когда сидим/стоим на «митингах».
                                                                                                              0
                                                                                                              Хорошо. Про митинги ситуация неоднозначная, поэтому спорить не буду)
                                                                                                        +1
                                                                                                        Покажите мне организации где техническую документацию пишут не для галочки и тщательно следят за ее достоверностью и актуальностью. Кроме военных и какого-нибудь НАСА где стоимость ошибки астрономическая. Но компаний вроде НАСА по миру единицы, я думаю мы все же о более общем случае говорим, не?
                                                                                                        Поддерживать исчерпывающую документацию — это гигантский труд, который, очевидно, бизнесу придется оплачивать. А польза от него совершенно не очевидна.
                                                                                                        Поэтому то, что я описал происходит не потому что документацию поддерживают для галочки, а потому что на нее тратят столько ресурсов, сколько выглядит адекватным на нее тратить. Обычно это не очень много.
                                                                                                    0
                                                                                                    Я, с вашего позволения, немного вклинюсь в дискуссию.
                                                                                                    Вот например(реальный пример), у нас есть проект, который приносит деньги и активно развивается. У начальства возникает идея о том, как можно увеличить доход посредством новой классной фичи. У него есть идея, и примерное понимание технической реализации. Из задачи, поставленной простыми словами, я не понимаю почти ничего. ПМ понимает частично, и даёт мне формализованное представление своего видения задачи. Я начинаю делать, у меня возникают вопросы, на которые ПМ ответить не может. В результате мы собираемся вместе, директор описывает идею, чертит графики, ПМ задаёт уточняющие вопросы, предлагает варианты, я обрабатываю крайние кейсы, вношу уточнения — что реально, что сложнореализуемо, что лучше вообще не делать. Фича обрастает подробностями, в процессе появляются новые идеи, дорабатываются старые, понимание всех участников постепенно приходит к единой картине. Двухчасовое совещание даёт наконец возможность начать нормальную работу над реализацией нового функционала, я распределяю часть задач по команде, часть беру себе. До совещания — не было даже общего понимания терминов, используемых в фиче. Т.е. кто-то считает что «фжа-рзы» — это «ар-ит-кв» а кто-то уверен что «ра-ук-пф».
                                                                                                      0
                                                                                                      Высокое начальство и заказчики — это отдельная песня. Самостоятельного составления четких ТЗ от них не дождешься. Так что должен быть человек, который болтает с заказчиком и даже играет в гольф.
                                                                                                        +2
                                                                                                        А теперь представьте это по другому:
                                                                                                        Начальство хочет глобальную фичу по автоматизации процессов в конторе, по этому поводу постоянно созывает совещания, на которые созываются обязательно все начальники разных подразделений. Каждый раз принимается новое шедевральное решение, иногда противоречащее решению вчерашнего или недельного совещания, иногда — законам РФ и правилам бухучета.
                                                                                                        Фича обрастают такими подробностями, которые грозят полностью остановить процесс автоматизации. При этом программист обещает сделать всё, но не въезжает в требования пользователей.
                                                                                                        В итоге банально приходится воплощать в жизнь анекдот про челночную дипломатию, выцепая начальников отделов по одному и выбивая из них понимание того, что они хотят и что они возможно получат. После чего уже эти вещи ты раскладываешь по полочкам, собираешь связанную картинку и разжевываешь программисту.
                                                                                                        Внимание вопрос: угадайте какие должностные обязанности у меня в этот момент были прописаны? )
                                                                                                +10

                                                                                                Настоящие продуктивные совещания видел только у немцев. Что Россия, что Америка, что Средняя Азия, что дальняя Азия… — с переменным успехом из-за отсутствия продуктивной культуры в регионе в целом.


                                                                                                Если на совещании нет заранее заданной темы (agenda) и протокола (meeting minutes) — для меня это первый звоночек бесполезного времяпрепровождения. Во-вторых, совещание требуется проводить, а не "общаться".


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


                                                                                                Статья радикальна и однобока, а любая крайность вряд ли тянет на взвешенный идеал.

                                                                                                  +1
                                                                                                  Радикальность — это «фишка» автора. С одними его статьями я категорически согласен, прочитав другие — сомневаюсь, не сумасшедший ли он.
                                                                                                    +1
                                                                                                    Радикальность — это фишка идиотов. Кто никогда не сомневается в своей правоте? Правильно — только идиот. Умным людям свойственно сомневаться, и избегать радикальных утверждений. Или ограничивать их применимость.

                                                                                                    >сейчас маятник сильно отклонился
                                                                                                    Где это «сейчас»? У нас в проекте в пятницу прошло два совещания. Уложились в полчаса и 15 минут. Позволю себе цитату из Смешариков:

                                                                                                    Крош:
                                                                                                    -Ну, никакого прогресса! Вам не кажется, что мы остановились в своем развитии?
                                                                                                    Ежик:
                                                                                                    -Только не надо обобщать
                                                                                                      0
                                                                                                      Радикальность — это фишка идиотов.

                                                                                                      Довольно радикальное утверждение.
                                                                                                        0
                                                                                                        Кто никогда не сомневается в своей правоте?

                                                                                                        А при чем тут радикальность? Можно придерживаться радикальных взглядов («бей жидов!») и при этом в них сомневаться («а вдруг они тоже люди?»).
                                                                                                          0
                                                                                                          У нас в проекте в пятницу прошло два совещания. Уложились в полчаса и 15 минут.

                                                                                                          Это великое достижение или для чего вы этот пример привели?
                                                                                                            +3
                                                                                                            Для того, чтобы автор не обобщал свои реалии на других. Если он не умеет организовывать совещания так, чтобы они были краткими, и приносили пользу — пусть пойдет и поучится. Благо есть у кого — многие умеют. Собственно, излишнее обобщение — это основное возражение, которое возникает после прочтения.
                                                                                                        +1
                                                                                                        Насчет радикальности этой статьи согласен. Иногда без «митинга» не обойтись. С другой стороны, насколько я вижу, сейчас маятник сильно отклонился в сторону бесконечных митингов, петтингов, опенспейсов, покера и прочего — будем откровенными — говна, которое подменяет своим «бла-бла» реальную работу. Именно поэтому такие статьи сейчас полезны. Маятник нужно толкать в обратную сторону.
                                                                                                        +4
                                                                                                        Зависит от организации совещания.
                                                                                                        Совещания зачастую экономят массу времени и денег.
                                                                                                        В коллективном обсуждении проявляются мелкие детали, которые иначе могут решаться домысливанием, причем каждым участником по-своему.
                                                                                                          +5
                                                                                                          1) распределённая команда
                                                                                                          2) у членов команды разный опыт как на проекте, так и в профессии
                                                                                                          3) смена приоритетов и изменение требований
                                                                                                          4) ужесточение сроков
                                                                                                          5) необходимость перестроить работу в связи, например, с болезнью одного из ведущих разработчиков

                                                                                                          Список можно продолжать. Если тут не будет правильно организованных митингов, то проект будет гарантированно провален. Если только, конечно, команда не состоит из одних самоорганизующихся супергероев-сеньёров-телепатов с неограниченным ресурсом времени.
                                                                                                            +5
                                                                                                            Эти обсуждения бессмысленны. Нет смысла бросаться в крайности, совещание бывает нужно, а бывает просто по регламенту, по привычке, в независимости от того нужно оно действительно или нет, именно в этом все проблемы.
                                                                                                            Не делать лишних, мешающих движений, вот задача для настоящего руководителя, универсальных алгоритмов тут нет, так как это нужно чувствовать.
                                                                                                              +13
                                                                                                              Создание архитектуры — это узаконенный грабёж. Допустим, мне, программисту, надо решить задачу. Что делает хороший программист? Решает задачу. Что делает плохой программист? Собирает команду из аналитика, архитектора, техписа, тестировщика и менеджера проекта, команда идёт к заказчику, пишет vision, потом пишет функциональные требования, потом ТЗ, потом в трёх итерациях принимает схему БД…
                                                                                                              В то время как хороший программист давно уже скачал готовый node.js модуль, собрал с заказчика бабло и давно уже запивает 40см флорентину Jack Daniels.
                                                                                                                –6
                                                                                                                В огороде бузина, а в Киеве дядька…
                                                                                                                  +2

                                                                                                                  Не совсем понял, в чей огород это камень

                                                                                                                    –3
                                                                                                                    Хорошо, другой вариант: при чем тут городская баня?
                                                                                                                      +2

                                                                                                                      У меня в семье бабушки про бузину и дядьку тоже шутили, обычно это обозначало бессвязность речи. Вот и вопрос — где тут бессвязность?

                                                                                                                +1
                                                                                                                Вообще, любую постановку задачи можно грубо разбить на три уровня:
                                                                                                                – чего хочет заказчик;
                                                                                                                – что написано в ТЗ;
                                                                                                                – чего хотим мы.

                                                                                                                Дальше внутри каждого из этих уровней происходит дальнейшее дробление:
                                                                                                                – чего хочет руководство заказчика;
                                                                                                                – чего хотят представители заказчика, принимавшие участие в постановке задачи;
                                                                                                                – чего хотят люди, которые будут эксплуатировать результат разработки;

                                                                                                                – что написано в тексте ТЗ;
                                                                                                                – что написано в стандартах на эту тему;
                                                                                                                – что написано в договоре на выполнение работ;

                                                                                                                – чего хочет наше руководство;
                                                                                                                – чего хочет проектная команда;
                                                                                                                – чего хочет данный конкретный разработчик;

                                                                                                                и т.д. Весь этот баланс интересов и требований руководитель проекта должен держать в голове целиком, а другие члены проектной команды – в значительной части. Его невозможно формально сформулировать (потому что тогда мы вырнёмся просто к расширенному ТЗ) и непросто передать друг другу. А модель последовательного уточнения требований ТЗ, конечно, хороша в теории своей простотой, но на практике всего этого не учитывает.
                                                                                                                  +2
                                                                                                                  держать в голове

                                                                                                                  Вот он — корень зла. Потом эта голова попадает под колеса, и всё надо начинать сначала. Замечательно, как мы мечтали!
                                                                                                                  Его невозможно формально сформулировать (потому что тогда мы вырнёмся просто к расширенному ТЗ) и непросто передать друг другу.

                                                                                                                  Это полная чушь хотя бы потому, что итоговая программа формальна. Если начальник ставит программисту размытые требования, задача конкретизации ложится на программиста и он вынужден ее выполнить, т.к. компилятор и процессор — бездушные машины, которым чуждо вот это ваше «держать в голове». Но это не программист у нас хороший, а начальник хреновый.
                                                                                                                    +2
                                                                                                                    Программа, безусловно, формальна, но вот программный продукт, который, помимо программы, включает в том числе и работу по её внедрению на объект эксплуатации и в головы разработчиков и пользователей – неформален.

                                                                                                                    По поводу колёс. Риск падения кирпича на голову руководителя проекта – головная боль его босса, а не самого руководителя проекта. Да, фирма обязана как-то хеджировать в том числе и вариант неуспешного завершения проекта, в этом ничего нового или необычного нет. Фокс про это много писал в своей книжке о разработке ПО.
                                                                                                                  +10
                                                                                                                  CVS не нужны, вы просто не умеете сразу писать правильный код.

                                                                                                                  Планы накатов/откатов не нужны, вы просто не умеете сразу правильно конфигурить.

                                                                                                                  Стендбаи не нужны, вы просто не умеете правильно прокладывать провода.

                                                                                                                  Совещания тоже не нужны…
                                                                                                                    +1

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

                                                                                                                    0
                                                                                                                    Для схемы базы это может и работает. А что посложнее уже таким способом не сдлать. Для каждой задачи нужен свой инструмент. Зачем ограничиваться чем-то одним?
                                                                                                                      +1
                                                                                                                      лично меня совещания очень мотивируют. Ты узнал новости проекта, послушал людей которые многое сделали, сам рассказал, высказали идеи. С новыми силами за работу, запуск уже виден.
                                                                                                                      Это бесценно в нашей отрасли, где дефицит мотивации.
                                                                                                                        +1
                                                                                                                        Ты узнал новости проекта, послушал людей которые многое сделали, сам рассказал, высказали идеи.

                                                                                                                        … а тут и 18:00 уже, всем хороших выходных! Еще бы такое не мотивировало. Как говорится, совещания — отличная альтернатива работе.
                                                                                                                        +4
                                                                                                                        Продукт совещаний — слаженная команда, а не схема реляционной базы данных. Схема базы — продукт слаженной команды.
                                                                                                                          +2
                                                                                                                          Для полной слаженности предлагаю собираться не в скайпе, а в сауне.
                                                                                                                            0
                                                                                                                            У нас была такая практика, пока сауна была рядом. Много ценных идей почерпнул от коллег.
                                                                                                                              –2
                                                                                                                              Много ценных идей почерпнул от коллег.

                                                                                                                              Половником?
                                                                                                                          –1
                                                                                                                          Какое счастье, что я не социопат-интроверт и что работа приносит мне не только бабло, но и радость через общение с другими людьми.
                                                                                                                            +1
                                                                                                                            «Какое счастье, что я не зануда-моралист и что работа приносит мне не только зарплату, но и прочие ништяки через дырку в заборе».
                                                                                                                              +1
                                                                                                                              То есть радость приносит бабло, общение с другими людьми, но не сама работа? Если так, то сомнительное счастье…
                                                                                                                                0
                                                                                                                                Это веяние последних лет, когда программисты стали хорошо зарабатывать. Раньше все эти «экстраверты» шли на экономы и юрфаки, теперь вот www.youtube.com/watch?v=evE4SpLRl78
                                                                                                                              +2
                                                                                                                              Люди разные. Для кого-то более продуктивны пулл-реквесты, для кого-то — совещания. И дело не в теле Моники (возможно, для кого-то — и в нём тоже).

                                                                                                                              Хороший архитектор этого понимать не обязан, а вот хороший ПМ — очень даже.
                                                                                                                                +2
                                                                                                                                Добавить что ли тег «тело Моники»…
                                                                                                                                +3
                                                                                                                                Я как архитектор перед стартом разработки собираю совещание, на которых присуствуют:
                                                                                                                                — Бизнес аналитики
                                                                                                                                — Разработчики
                                                                                                                                — Тестировщики
                                                                                                                                Собираю с целью:
                                                                                                                                — Убедится что все участники одинаково поняли суть задачи и предлагаемое решение.
                                                                                                                                — Получить обратную связь по рискам и возможным проблемам (тут как раз и нужны бизнес аналитики — они должны донести эти риски до бизнеса)
                                                                                                                                — Если есть несколько вариантов реализации — выбрать компромиссный по рискам и срокам.
                                                                                                                                — Тупо чтобы все участники увидели друг друга и поняли кто какую роль исполняет в данном проекте (потом им гораздо легче коммуницировать между собой не используя для этого нагруженный ресурс архитектора)

                                                                                                                                Заметьте — я здесь не решают конкретные точечные вопросы (это действительно у всех отнимает время и такие вопросы решаются в рабочем порядке).
                                                                                                                                  +2
                                                                                                                                  ИТ — это не про компьютеры (базы данных и т.п.). ИТ — это про людей (общение, knowlege sharing, смыслы и идеи и вот это вот всё). Мне показалось что статья предлагает совершенно ложный выбор между двумя крайностями: совещание (как единственный метод общения) и их полное отсутствие (как цепочка актов аутичных участников). То есть, по сути, провоцирует :)
                                                                                                                                    +1
                                                                                                                                    Совещания помимо удовлетворения простых человеческих потребностей «пообщаться» на более-менее профессиональные темы с себе подобными, а не втыкать всё время в тикеты с реквестами, нужны также и для неформального обмена мнениями.

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

                                                                                                                                    Конечно же, совещаниями, как и всем остальным можно команду зае… ть. На то архитектору (или все-таки тим лиду?) голова и выделена, чтобы искать системный баланс, как в проекте, так и в используемых инструментах управления исполнителями.
                                                                                                                                      +4
                                                                                                                                      Автор, видимо, никогда не работал на проектах с более чем одной командой из разных частей организации(ий). Удачи с тикетами!
                                                                                                                                      0
                                                                                                                                      Здоровый творческий человек, такой как разработчик ПО, например, хочет видеть, как его усилия превращаются во что-то ценное и — в идеале — осязаемое.

                                                                                                                                      Как разработчик ПО может превратить свои усилия во что-то осязаемое?..

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

                                                                                                                                      Я так понимаю, что перед автором всегда ставят задачи на пару часов максимум, что он желает видеть результат через два часа…
                                                                                                                                      У меня (я правда не ПО занимаюсь), например, запросто может уйти пару дней просто на сидение на месте и обдумывание, как же мне решить какую-либо проблему. И я не представляю, как может быть иначе при решении сложных творческих задач…
                                                                                                                                        +2
                                                                                                                                        Как разработчик ПО может превратить свои усилия во что-то осязаемое?
                                                                                                                                        Запрограммировав погрузчик некорректно и сломав склад амазона например. Или местного бандита, для еще большей осязаемости последствий своих усилий…
                                                                                                                                          +1
                                                                                                                                          Я так понимаю, что перед автором всегда ставят задачи на пару часов максимум, что он желает видеть результат через два часа…

                                                                                                                                          Нет, там 2 часа занимает митинг.
                                                                                                                                            0
                                                                                                                                            Вы не поняли, о чём я писал…
                                                                                                                                              0
                                                                                                                                              Возможно, но не могли бы вы тогда переформулировать?
                                                                                                                                              Насколько я понял, автор не ощутит результата от двухчасового митинга ни в момент его окончания, ни через час, ни через день. С этой точки зрения я не понимаю, откуда следует, что он ожидает получить результат через 2 часа.
                                                                                                                                                0
                                                                                                                                                Смею предположить, что как минимум часть проектов, в которых участвовал автор и в которых были совещания, закончились созданием необходимого заказчику программного обеспечения.
                                                                                                                                                Тем не менее автор пишет «я просто не вижу, во что превратились 2 часа моей жизни», хотя они (вместе с ещё 200-2000 другими часами) превратились в то самое программное обеспечение.
                                                                                                                                                Делаем вывод, что увидеть результат именно этих двух часов он желал сразу по их окончании.
                                                                                                                                                  0
                                                                                                                                                  А можно ли доказать, что эти два часа таки превратились в ПО? Или можно было обойтись и без них? Вот в чем вопрос.
                                                                                                                                          +2
                                                                                                                                          Всегда ненавидел совещания. Но тут проблема скорее психологическая, все зависит от целей конкретного человека. У меня в конце дня должен быть результат, иначе что-то не так. А у многих моих колег цель совсем другая, сделать поменьше и точно в 17:00 свалить домой.
                                                                                                                                            +1

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

                                                                                                                                              0
                                                                                                                                              Зато бесконечные митинги отлично маскируют разгильдяйство и отсутствие элементарных навыков, создавая видимость продуктивной работы. С гитхабом так не выйдет, увы.
                                                                                                                                                +1

                                                                                                                                                Назовите причины, пожалуйста. Не встречали запущенных (не организованных) репозиториев?

                                                                                                                                                  0
                                                                                                                                                  В том то и дело, что по репозиторию это сразу видно.
                                                                                                                                                    +2

                                                                                                                                                    Бизнесу важен результат в виде комментариев на гитхабе или продаж продукта?

                                                                                                                                                      0
                                                                                                                                                      На совещаниях это тоже сразу видно. Вопрос лишь в том, что нужно руководителю — получить результат или он сам первый ибэдэшник.
                                                                                                                                                        –3
                                                                                                                                                        Что именно видно на совещаниях? Сидят 5 человек, полтора часа о чем-то трут, расходятся с ощущением «мы молодцы». Никто не считает количество потраченных человеко-часов, из них — ожидания, пока все соберутся, приветствий, прощаний, смолтолков, сколько реально человек «работают» и сколько — рисуют каракули. Что видно-то?
                                                                                                                                                          +2

                                                                                                                                                          Очень поверхностно.

                                                                                                                                                +4
                                                                                                                                                совещания интересны тем кто любит поболтать, из моего опыта программисты не любят поболтать, потому обычно совещания организуют менеджеры.
                                                                                                                                                на совещании можно легко манипулировать и впаривать своё решение особенно если хорошо подготовился, а остальные не смогут сходу опровергнуть, ну кроме мегагениев которые на все вопросы могут найти ответ в голове, а не в гугле, так что обычно это не выяснение истины, а выяснение кто авторитетнее, даже в общем чатике обсудить чтото будет полезнее так как не требует немедленного ответа и тут даже интроверты могут свободно высказать своё мнение
                                                                                                                                                  +4
                                                                                                                                                  Уже начал было придумывать как вступить в обоснованную дискуссию с автором. А потом, наконец, увидел, что это перевод Бугаенко…
                                                                                                                                                    +1
                                                                                                                                                    Он не стремается отвечать по-русски на русскоязычные комментарии в своем блоге.
                                                                                                                                                      +1

                                                                                                                                                      Конечно нет, но зачем кормить тролля?

                                                                                                                                                    0

                                                                                                                                                    При работе с git есть особенности:


                                                                                                                                                    1. Изменения нужно коммитить сразу (как есть), иначе можно наделать ошибок, и на правки затратить гораздо больше времени, (чем на совещания).
                                                                                                                                                    2. Не вносить дополнительные изменения в черновик перед коммитом, если они написаны более суток назад (как следствие из первого).
                                                                                                                                                    3. Работая в команде нужно создавать отдельную ветку (на что намекал автор статьи).
                                                                                                                                                      0
                                                                                                                                                      теоретически все правильно и логично.

                                                                                                                                                      если тебе нужна датабаза, то:
                                                                                                                                                      — ты должен понимать чо именно тебе надо. с деталями. чтоб не возникали фразы «мы не мелочимся, считаем цены в тысячах баксов».
                                                                                                                                                      — ты обращаешься не к Погромистам а к ДБ Архитекту. который хотя бы слышал про «Нормализацию».
                                                                                                                                                        +2
                                                                                                                                                        Главная ошибка статьи — в примере. Статья повествует не о вреде совещаний, а о том, как переложить свои обязанности на другого сотрудника. Смысл утверждения «Но даже если Джефф потратил на это час, каждая минута этого часа полезна для проекта. Я имею в виду, что каждый доллар, который я заплатил Джеффу за это время, вернулся ко мне в виде текстового документа.» верен только в одном случае — автор не архитектор, а работодатель. В противном случае — он вообще лишнее звено, и вся работа может быть сделана без него.
                                                                                                                                                          –2
                                                                                                                                                          Это называется делегированием. Архитектор может непосредственно заниматься другой задачей, пока Джефф обдумывает схему. Архитектор-хирург, делающий всю важную работу — такой экстремизм разве что у Брукса был.
                                                                                                                                                          +2
                                                                                                                                                          image
                                                                                                                                                            +4

                                                                                                                                                            Егор Бугаенко, конечно, знатный тролль. И в данном контексте это не оскорбление, а, скорее, комплимент: это важное умение — красиво набросить "интересную тему" на вентилятор.


                                                                                                                                                            Но что касается сути статьи, тут из-за однобокости и максималистичности подачи потерялся простой факт. Каналы коммуникации обладают сильно разными свойствами. Вот давайте посмотрим на такую табличку:

                                                                                                                                                            (Сделал я. Только что. Оценки субъективные из головы — кому не нравится, может, предложить свои варианты цифр, если из-за этого будут другие выводы — обсудим. Картинкой, потому что в предпросмотре таблица не отображается)


                                                                                                                                                            Тут:


                                                                                                                                                            • Latency, с – сколько проходит времени от создания информации (проговаривания или печати) до её восприятия. Важно, что эта latency в письменном тексте не может быть меньше, чем время, на то, чтобы дописать сообщение/текст и отправить его.
                                                                                                                                                            • Скорость создания (знаков/мин) – по моим наблюдениям, говорим мы обычно (если не диктор новостей) со скоростью 300-600 знаков (кроме пробелов и знаков препинания, если стенографировать), печатаем 100-300 знаков/мин, если хоть немного задумываемся, скорость падает (см "письмо, комментарий"). Реальные текстовые документы, если есть готовое в голове пишутся не быстрее 1500-3000 знаков в час (25-50 знаков в минуту), требется время на вычитку. Важный документ перед публикацией перечитывается столько раз, что скорость набора неважна. Скорость мессенджера, конечно, взята "компьютерная": на мобиле и набор, и восприятие медленнее.
                                                                                                                                                            • Скорость приема (знаков/мин) – а) скорость восприятия на слух обычно выше, чем комфортно говорить, поэтому лекции/доклады часто удобнее в ютубе просматривать на повышенной скорости; б) скорость чтения среднего ИТ-специалиста 1500-3000 знаков/мин, если умеет скорочтение, то 3000-6000, в) скорость чтения документов выше, потому что мы их редко читаем "до буквы" — в таблице вариант именно "с пропусками"
                                                                                                                                                            • КПД отдачи вербализируемой информации – в обычной речи обычно очень невысокий КПД реальной информации, хорошо если половина. Если мы пишем, то этот коэффициент возрастает (в зависимости от внимательности к тексту).
                                                                                                                                                            • КПД приёма вербализируемой информации – но информация теряется не только при её создании, но и при чтении/слушании. По опыту техник быстрого чтения знаю, что среднее восприятие среднего текста у среднего человека примерно 60%, у попыток воспринять информацию на слух — реально и 40% завышено, а если не видеть собеседника, то еще ниже.
                                                                                                                                                            • КПД приёма невербализируемой информации – эмоции, жесты, мимика — всё это (как и в статье замечено) теряется в письменном общении. Причем если в сообщении в телеге язык менее формален и есть смайлики, то из условного RFC это обычно вычищено.

                                                                                                                                                            Кроме этого есть еще несколько особенностей модели.


                                                                                                                                                            1. Во всех кейсах мы полудуплексные. Либо отдаём информацию, либо принимаем. Се ля ви.
                                                                                                                                                            2. Схемы/визуализации. Голосом они почти никак не передаются, для этого обычно используются презентации. Схемы существенно снижают (в знаках в минуту) скорость создания контента, но часто оно того стоит. Я их не рассматриваю для упрощения.
                                                                                                                                                            3. Асинхронность. В личном общении её почти нет. В мессенджере и письмах — ограниченная.
                                                                                                                                                            4. Возможность почти мгновенно прервать незаконченное сообщение/работу (перебить) — уберфича личного общения. Мы можем прервать собеседника на полуслове ("Слушай, ну это же не имеет отношения к теме собрания"). Да, у приёма есть большая цена (в том числе из-за полудуплексности), если все начнут всех перебивать, то обмен информацией ломается. Но именно из-за его эффективности мы все умеем его использовать :) Положительный эффект в том, что говорящему не нужно заканчивать речь. Попробуйте перебить того, кто пишет вам сейчас письмо (ой, мы же об этом и не знаем даже :) )

                                                                                                                                                            Каждый канал идеален для своих задач. То, о чем написал Егор — для писем и простых документов. Общение один на один если требуется многократно обмениваться репликами. Мессенджер для асинхронной координации (например, при устранении инцидента.)


                                                                                                                                                            Конечно, эти каналы часто используются совместно, чтобы оптимизировать передачу под конкретную задачу:


                                                                                                                                                            • Парное программирование вносит скорость личного общения в код ревью (строки 4 и 5)
                                                                                                                                                            • Доклад на конференции — это одновременно и мультиплексирование общения, и обогащение презентацией и быстрое получение обратной связи ("а теперь вопросы")
                                                                                                                                                            • Протокол совещания позволяет не протерять информацию

                                                                                                                                                            Посмотрев на эту модель становится очевидно, что есть много кейсов в разработке ПО, когда общение будет эффективнее переписки. Да, общение не идеально для передачи информации по КПД, но обладает свернизким latency и возможностью прервать недоделанное сообщение. А что касается объёмов — так ведь суть беседы руководителя один на один с сотрудником по кадровым вопросам часто может быть выражена в трёх строках. Но зачастую требует десятки реплик с каждой стороны.


                                                                                                                                                            Ну и еще: часто стоимость часа работы (пусть даже 10 высокооплачиваемых сотрудников) ничто по сравнению с возможностью вывести продукт раньше. Если совещание приблизит time to market, то это может окупить несколько недель "экономной" переписки.

                                                                                                                                                              +2

                                                                                                                                                              Кстати, как вывод могу добавить, что на совещаниях можно понять настроение с которым подана повестка дня (нужно поднажать, например). Приоритезировать задачи и довести до каждого значимость отдельных задачь. В сухих текстах или выкладках на гитхабе — это сделать трудно. Могут возразить, например, "мы выбираем гитхаб — потому что это место где можно спокойно обсудить дела", но с точки зрения бизнеса это выглядит так: "задет критический функционал и бизнес теряет деньги и бросает в команду тикеты, а они отскакивают обратно через месяц". Прятаться за обсуждениями пиаров в гитхабе — это хороший способ уйти от срочных дел. (Мое мнение.)

                                                                                                                                                                0
                                                                                                                                                                Одни от работы прячутся в комментах к пулл-реквестам, другие в совещаниях на 20+ участников. А работает-то кто? :)))))
                                                                                                                                                                  +4

                                                                                                                                                                  Это разный взгляд с разных колоколен. Одни не любят разговаривать и решать дела на совещаниях — говорят, что совещания — это трата времени. Другие привыкли решать дела совещаниями и говорят, что мне проще 10 минут поговорить, чем целый день переписываться. И у каждого типа общения есть свои крайности. Каждый любит кинуть камень в чужой огород. Что отличает работающего от не работающего? Его дальнейшие действия после совещания / комментирования пиара на гитхабе.

                                                                                                                                                                0
                                                                                                                                                                Спасибо за подробный комментарий! Это всё верно, и иногда, ИМХО, личное общение лучше, но не тут не хватает одного важного параметра, по которому устная речь продует с разгромным счетом: использование информации через некоторое время. Из-за этого, в частности, я ненавижу видео-туториалы, видосы с конференций… ну и сами конференции.
                                                                                                                                                                  0
                                                                                                                                                                  Так для этого составляется протокол совещания, и отправляется всем участникам. Конечно, если была повестка и цели, и было что записывать в протокол.
                                                                                                                                                                    0
                                                                                                                                                                    Вот все бы так делали: после совещания занести всю ценную инфу в документацию, тикеты и т.д.
                                                                                                                                                                    0
                                                                                                                                                                    > Из-за этого, в частности, я ненавижу видео-туториалы, видосы с конференций… ну и сами конференции.

                                                                                                                                                                    Вот да. И хорошо еще, если у туториала есть краткое описание с тезисами, тогда хоть как-то можно через поиск найти нужный видосик и отмотать примерно куда нужно.
                                                                                                                                                                  +1
                                                                                                                                                                  Разве Эйнштейн придумал свою теорию на совещании с коллегами?

                                                                                                                                                                  Ну как бы да.
                                                                                                                                                                  www.ng.ru/nauka/2015-11-25/9_myth.html
                                                                                                                                                                    0
                                                                                                                                                                    Не нашел там про момент озарения во время «митинга».
                                                                                                                                                                    И кстати, слово Гильберту:
                                                                                                                                                                    Любой мальчик на улицах Гёттингена понимает в четырёхмерной геометрии больше, чем Эйнштейн. И тем не менее именно Эйнштейн, а не математики, сделал эту работу.
                                                                                                                                                                      0
                                                                                                                                                                      В этот момент он переезжает из Праги в Цюрих, где привлекает к сотрудничеству своего друга по студенческим временам – специалиста по геометрии М. Гроссмана, который выводит его на многомерную риманову геометрию. В итоге в мае-июне 1913 года появляется их совместная статья, в которой ОТО представлена почти в законченном виде.
                                                                                                                                                                        +1
                                                                                                                                                                        Хм, а где здесь написано, что работали они путем созыва совещаний?
                                                                                                                                                                        Парная работа? Так во многих случаях совместные научные работы путем рецензии чужого текста происходят, а не путем единовременной генерации текста. При личном происходит обмен знаниями в разных областях, объяснения теорий и т.п., но представить себе это в виде совещания, каким должно быть ОТО…
                                                                                                                                                                          0
                                                                                                                                                                          А где требование, чтобы они текст писали сидя рядом?..
                                                                                                                                                                          Если «При личном происходит обмен знаниями в разных областях, объяснения теорий и т.п.», то это важнейший этап создания ОТО.
                                                                                                                                                                            +1
                                                                                                                                                                            Исходное:
                                                                                                                                                                            Разве Эйнштейн придумал свою теорию на совещании с коллегами?

                                                                                                                                                                            Так-то понятно, что парная работа или передача знаний между специалистами в разных разделах — важна. Но это не называется «совещанием».

                                                                                                                                                                            PS. egigd:
                                                                                                                                                                            Совещание — это заседание или собрание, посвященное обсуждению каких-либо вопросов.
                                                                                                                                                                            Собрание (греч. Συνάντηση «синантиси») — совместное присутствие группы людей в определённом месте для обсуждения разных тем или решения определённых проблем.
                                                                                                                                                                            Заседание — это совещание или собрание, посвященное обсуждению каких-либо вопросов и решению проблем.

                                                                                                                                                                            А так вы договоритесь, что и посещение школы или института — это совещания. И собеседование на приём работы — это совещание. Общение друзей и шашлыки — это совещания. Посещение психолога — это тоже совещание, видимо. И даже семейная жизнь — это совещание.
                                                                                                                                                                            Так вот, решение конкретной задачи в том же институте в двоём-троём, проведение совместных расчетов, объяснение одним студентом другому или лекторам группе — никогда совещанием не назывались. И если вы будете менторствовать в своей конторе — никто это не назовет совещанием.
                                                                                                                                                                              +1
                                                                                                                                                                              Если вы даёте определение «совещания — это узаконенный грабеж», то да, не называется.
                                                                                                                                                                              Но нормальные люди определяют иначе «совещание — встреча нескольких людей с целью совместного обсуждения каких-либо вопросов». И вот тогда это очень даже называется совещанием.
                                                                                                                                                                                +1
                                                                                                                                                                                Ну и в догонку к PS предыдущего поста:
                                                                                                                                                                                0
                                                                                                                                                                                Вот собеседование точно совещание. Советуемся подходим мы друг другу или нет. :)
                                                                                                                                                                      0
                                                                                                                                                                      Согласен с автором статьи. 2 часа 10 минут общего времени будет потрачено, если разработка ТЗ для БД будет последовательна, при условии, что Архитектор, программист (Джефф) и инженер (Моника) будут заниматься этим поочередно. Касаемо совещания на 1,5 часа, будет потрачено уже 4,5 часа общего времени (при учете, что на совещании будет всего 3 человека) + время на перенесение результатов протокола в ТЗ
                                                                                                                                                                        +3
                                                                                                                                                                        Лучшее в письменной форме не экономия времени, а её асинхронность.
                                                                                                                                                                        Можно подумать минуту над ответом в одно предложение, можно пол-дня и даже день иногда писать почти эссе по очень сложной проблеме.

                                                                                                                                                                        Устная речь очень сильно ограничена — обычно можно сказать либо то что ты знаешь, либо то что придет первым в голову(или в основном молчать и в итоге прослыть задротом, аутистом и асоциалом, если ты при этом не начальник)

                                                                                                                                                                        Пиьсмо позволяет передавать очень концентрированную и сложную мысль

                                                                                                                                                                        По моему опыту у попыток делать все письменно и направленно есть свои Сцилла и Харибда
                                                                                                                                                                        1) В компаниях где правят чистые бизнесмены они очень редко по настоящему полагаются на письмо. Глаза в глаза можно извлечь больше информации из не горящего желанием тебе её давать, можно давить харизмой или просто статусом.
                                                                                                                                                                        Хорошее письмо это навык специалистов, а не предпринимателей(и даже не активных менеджеров)

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

                                                                                                                                                                        3) Любая система бумагообмена это структурированное публичное пространство которое ещё и должно стать основным.
                                                                                                                                                                        Как быть с любым инфообменом кроме как по прямой chain of command непонятно. Если его вести вне системы это её делает бесполезной и заведомо отсталой от жизни, если делать заставить всей информацией обмениваться публично то о многом будут молчать.
                                                                                                                                                                          0
                                                                                                                                                                          Лучшее в письменной форме не экономия времени, а её асинхронность.

                                                                                                                                                                          Кстати, в статье это упоминается вскользь:
                                                                                                                                                                          нет нужды беспокоить его этим организационным шумом