Хороший архитектор, как и хороший 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. Нет, подожди-подожди. В первую очередь я составляю повестку:
- Введение: 10 мин.
- Проблема: 15 мин.
- Нам нужна схема БД
- Давайте выберем сервер
- Мнения: 15 мин.
- У Джеффа и Моники есть опыт
- Остальные?
- Кофе-брейк: 10 мин.
- Обсуждение: 30 мин.
- Не будем забывать о рисках
- Спросить Джо про PostgreSQL
- Завершение: 10 мин.
Уверен: вы понимаете, о чем я, и видели такие повестки у своих «архитекторов». Тем не менее, мой первый шаг сделан. Я запланировал полуторачасовое совещание, на котором будут присутствовать все программисты. Мы повеселимся и попьем кофе. Мы обсудим проблему, выслушаем все мнения и найдем лучшее решение. Мы задокументируем его в
schema.md и вернемся к своим задачам.Вместо передачи этих сухих и скучных Git-документов у нас будет настоящее человеческое общение с приятным кофе-брейком, на котором мы обменяемся мнениями о последней серии «Теории Большого взрыва». В конце концов, разве не это мы все любим в своей офисной работе?
Я так не думаю.
Я считаю, что совещания демотивируют, поглощают время впустую, сжигают деньги и ухудшают качество. Те, кто их организует, либо не представляют, что делают, либо тихо грабят компанию, на которую работают.
Совещания были нужны нам 30 лет назад, когда у нас не было ноутбуков и гитхаба. Но даже тогда у нас были ручка и бумага.
Я говорю о встречах, предназначенных для того, чтобы собрать или распространить информацию, обсудить или предложить что-либо или найти решение в технической области. Единственная уважительная причина для встреч — чтение языка тела людей, с которыми вы имеете дело. Политики, бизнесмены, игроки в покер, психиатры, терапевты и т.д. — им нужны встречи, т.к. они должны читать наши тела, а не только мысли.
Действительно ли нас волнует тело Моники, когда мы проектируем схему БД? Ну, когда как, верно? Но если серьезно, нам за это не платят.
Совещания демотивируют
Лучшая мотивация для творческой личности — видеть результат своего творчества. Если не ошибаюсь, наслаждение процессом творчества без всяких результатов — это очевидный признак психического заболевания. Здоровый творческий человек, такой как разработчик ПО, например, хочет видеть, как его усилия превращаются во что-то ценное и — в идеале — осязаемое.
Совещания никогда не производят ничего осязаемого и редко — что-то ценное. Иногда у нас есть «протоколы» совещаний, но они просто маленькие клочки бумаги с кратким конспектом того, о чем мы говорили. Не настоящий "продукт" для творческой личности.
Таким образом, они меня демотивируют, т.к. я просто не вижу, во что превратились 2 часа моей жизни. На самом деле мы ничего не создаем, мы просто обсуждаем. Обратите внимание: я говорю о совещаниях, а не о совместной работе над чем-либо, как, например, в парном программировании.
Вы можете сказать, что некоторые совещания действительно приводят к отличным идеям, которые являются осязаемым результатом. Вы можете сказать, что эти идеи могли возникнуть только при прямом контакте, лицом к лицу. Вы также можете сказать, что многие блестящие технические решения были придуманы именно благодаря магической синергии друзей, мыслящих в одном направлении, в одно время и в одной комнате. В этом аргументе есть смысл, но я вернусь к нему позже.
Совещания поглощают время впустую
Думаю, это очевидно. Первые несколько минут совещания вы сосредоточены, потом начинаете смотреть свою ленту в Твиттере и рисовать каракули. Все делают то же самое — не потому, что мы ленивы, а потому, что нет необходимости полностью фокусироваться на совещании.
Пока Моника работает с документом, добавляя комментарии и предложения, она полностью сосредоточена на результате — в основном, потому, что больше некому ей помочь. Она должна предоставить этот пул-реквест, и я ее жду. Ее концентрация так же высока, как была бы на совещании, когда кто-нибудь спросил бы ее о чем-то напрямую и она должна была бы дать подробный ответ.
Ее время оптимизировано для получения соответствующего результата, в то время как другие делают что-то другое.
На совещании, с другой стороны, мы все в лучшем случае не очень сконцентрированы. И чем дольше совещание, тем мы медленнее. К тому же, чем больше там людей, тем меньше мы заинтересованы и тем интереснее для нас становятся наши обновления в фейсбуке. Полагаю, для вас это не удивительно, если вы уже как минимум несколько месяцев в индустрии разработки.
Совещания сжигают деньги
Это тесно связано с предыдущим выводом. Совещания находятся в числе наибольших потребителей бюджета любого вида деятельности на проекте просто потому, что всем, кто сидит в той комнате или в той конференции в скайпе, платят, тогда как они производят почти такой же результат, какой может выдать один человек. Или намного меньший.
Хоть это и может прозвучать радикально, я должен сказать, что считаю совещания узаконенным способом грабить проект. Большинство организаторов совещаний (архитекторы, CTO, CEO, программисты) не понимают этого. Они верят, что, чем больше они разговаривают, тем лучшие они инженеры. А их начальники по ошибке ценят в своих подчиненных этот вид деятельности.
Это грабеж!
Я сказал вам сделать набросок схемы БД. И вот вы идете ко мне и просите устроить совещание, т.к. некоторые «аспекты» непонятны? Вы где-нибудь учились разработке ПО? Вы знаете, как работать с техническими документами? Вы способны писать таким образом, чтобы любой мог понять и ответить вам, тоже письменно? Нет? И теперь вы хотите, чтобы проект заплатил не только вам за набросок схемы БД, но и мне за разговор с вами и еще нескольким ребятам за то, что они посидят рядом с нами и попереписываются со своими друзьями? По сути, вы хотите ограбить владельца проекта. Ни больше ни меньше.
Совещания ухудшают качество
Качество улучшается, когда его контролируют. Когда кто-то каждый день говорит мне, что мой код полон ошибок и нуждается в улучшениях, мое качество улучшается. Когда никому нет дела до того, что я делаю и насколько хороши мои результаты, мое качество падает независимо от того, насколько я самомотивирован.
Совещания поощряют групповые достижения и отбивают охоту от индивидуальных. В конце совещания зачастую не понятно, кто именно предложил хорошую идею и кто приложил наибольшие усилия. Иными словами, в конце совещания я не знаю, насколько я хорош. Я такой же, каким был месяц назад, или уже лучше как инженер?
Они больше улыбаются и спрашивают меня: «Что думаешь?» — чаще, чем прошлым летом; это должно что-то значить, правда? Уверен, вы понимаете, что это не тот вид обратной связи, который ожидал бы серьезный инженер.
Серьезный разработчик хочет производить осязаемые результаты и получать осязаемую обратную связь, вроде денег или ревью кода. Я хочу знать, что неправильно в моем наброске схемы БД и что я упустил. И я хочу, чтобы это было где-то задокументировано. Вот это делает меня лучше, и вот так я учусь и расту.
Как насчет моментов озарения?
Итак, как насчет настоящего творчества и пресловутых моментов озарения? Иногда необходимо «думать вслух» для того, чтобы придумать что-то, не так ли? Все мы знаем, как важно бывает общаться лицом к лицу, когда мы исследуем или разрабатываем что-то новое. Где бы мы были без совещаний? Мы не можем просто работать с документами; нам нужно разговаривать друг с другом для того, чтобы высказывать свои идеи. Разве это не очевидно?
У меня только один аргумент по этому поводу. Разве Эйнштейн придумал свою теорию на совещании с коллегами? Я так не думаю. А он решал намного большую проблему, чем проектирование схемы БД.
Позвольте мне подвести итог. Совещания — это деятельность, для которой практически не нужно навыков, тогда как документирование идей текстом и диаграммами — намного более трудная работа. Поэтому тренируйтесь и заставляйте себя работать с документами, а джуниоры пусть наслаждаются своими совещаниями.
Комментарии (217)
rsashka
28.03.2019 20:40+5Это рассуждения разработчика или в крайнем случае архитектора, но никак не менеджера.
И пример глупый. Разве кто-то для разработки схемы БД собирает совещание?
А вот для объяснения (обсуждения) самого проекта совещание нужно обязательно.
Оно нужно для погружения в контекст нового проекта, обсудить его ограничения и приоритеты, слегка мотивировать команду, получить от команды обратную связь и т.д.
s-kozlov Автор
29.03.2019 06:36Это рассуждения разработчика или в крайнем случае архитектора, но никак не менеджера.
Это рассуждения менеджера с большим опытом, который, к тому же, несколько лет управляет чисто распределенной командой без instant messaging и совещаний.rsashka
29.03.2019 11:50который, к тому же, несколько лет управляет чисто распределенной командой
Так может быть именно в этом дело? Для распределенной команды стиль работы и способ постановки задач в корне отличается от совместной работы в одном офисе.
Например, существует хороше правило «трех писем», (если переписка по вопросу растянулась на три ответа Re:, то нужно отрывать одно место от кресла и идти ножками к оппоненту, что бы в живую обсудить возникшие в переписке непонятки, и только после это писать четвертое письмо, которое должно фиксировать устно достигнутые договоренности).
Но такой прием крайне не эффективен для удаленных сотрудников. Поэтому меньшим злом и будет четкие, письменно поставленные задачи (примерно так, как описано в статье).
Но к сожалению, это будет работать только для хорошо формализируемых заданий, а такие бывают в основном при багфиксинге и создании небольших фич для существующего продукта.
Для новых проектов с большой долей неопределенности, совещания позволяют эффективно обмениваться информацией между участниками команды.
NightGhost
29.03.2019 17:07+1Но такой прием крайне не эффективен для удаленных сотрудников
Практически тоже самое делаем в распределённой команде. Если в жире идёт больше трёх комментов одного осуждения, и явно ожидается четвёртое – собирается созвон, затем в жиру фиксируется результат, иначе это может продолжаться бесконечно, при том с достаточно большими лагами.
s-kozlov Автор
29.03.2019 19:36Четкие, письменно поставленные задачи — это не «меньшее зло», а нормальный процесс. Неспособность нормально поставить процесс — это обыкновенное разгильдяйство и непрофессионализм, хоть в офисе, хоть удаленно.
rsashka
29.03.2019 20:35+1А еще лучше, большая красная кнопка «Выполнить».
К сожалению, в реальном мире бывают и форс мажор и неправильно понятые задачи. Выше как раз и шла речь о том, что же можно сделать, если возникли подобные непонятки, а работать приходится с той командой, которая у тебя есть на текущий момент.
s-kozlov Автор
29.03.2019 06:36Разве кто-то для разработки схемы БД собирает совещание?
Вы таки не поверите…
s-kozlov Автор
29.03.2019 06:37А вот для объяснения (обсуждения) самого проекта совещание нужно обязательно.
Оно нужно для погружения в контекст нового проекта, обсудить его ограничения и приоритеты, слегка мотивировать команду, получить от команды обратную связь и т.д.
Не нужно, и в статье это подробно расписано.rsashka
29.03.2019 13:00Не нужно, и в статье это подробно расписано.
В статье приведены однобокие примеры, вырванные их контекста.
Какой состав команды? Насколько она сработана? Насколько хорошо знает используемые технологии? Каким опытом обладает каждый из членов команды? Какие отношения между членами команды? Какие ожидания по срокам завершения проекта? и т.д.…
И каждый из ответов может повлиять на необходимость проводить совещания.
dimm_ddr
29.03.2019 15:42Я — тестировщик. Моя работа — задавать вопросы о которых никто не подумал, потому что я нахожусь в уникальной позиции, у меня другое мышление (если интересно я могу углубится и объяснить почему так и почему это логично, но это уже сильно оффтоп будет). Вы представляете сколько мне нужно прочитать писем и документов чтобы понять что хотел получить клиент, как его понял менеджер и что собираются делать разработчики? И сколько писем мне нужно будет написать чтобы узнать ответы на вопросы которые у меня появляются и которые никто до меня не задал? Я уж не говорю что написание документации которая мне нужна займет на порядок больше времени чем совещание где это будет проговорено соответствующим человеком. И что никто и никогда такую документацию не пишет.
s-kozlov Автор
29.03.2019 19:41+1Я уж не говорю что написание документации которая мне нужна займет на порядок больше времени чем совещание где это будет проговорено соответствующим человеком.
Угу, давайте сейчас выгадаем пару часов. Ну и что, что потом придется объяснять это снова и снова (а иногда и пытаться вспомнить через полгода, хе-хе).
Areso
31.03.2019 21:23А вот для этого, обычно, вещи, сказанные устно, фиксируются в Протоколе (да-да, о нем было сказано в статье).
dimm_ddr
01.04.2019 12:22Не так. Документация пишется параллельно разработке и маленькими частями после того как все важные вопросы были проговорены и достигнуто более-менее одинаковое понимание конечного результата. И да, естественно, в процессе возникают отклонения от первоначальной задачи, цели меняются, подводные камни выявляются и обходятся и так далее. Поэтому те несколько часов которые были бы потрачены на документацию в начале никак не уменьшат проблемы потом. Потому что написанную документацию все равно придется переписывать и дописывать и по многу.
Более того, эту документацию придется еще каким-то образом организовывать чтобы было понятно что в ней — всего лишь предварительные планы, а что — уже скорректированная реализация. Я вообще не уверен что в сколько-то большом проекте это в принципе возможно.
sshikov
29.03.2019 10:39Это рассуждения Yegor Bugayenko. Вы просто поищите в гугле, и составьте себе собственное представление.
saipr
28.03.2019 21:15Совещания никогда не производят ничего осязаемого и редко — что-то ценное.
Так это не совещание. Да и совещание как неодушвленный прндмет не может ничего производит. Производят люди, которые присутствуют на совещании. Но если они на совещании отбывают повинность, то и результат тт, о котором пишет автор.
s-kozlov Автор
29.03.2019 06:39Но если они на совещании отбывают повинность, то и результат тт, о котором пишет автор.
На совещании на 3+ человек обычно двое разговаривают, а остальныеотбывают повинностьрисуют каракули.
ivanych
28.03.2019 22:03+4В целом согласен с автором. Но проблема в том, что автор смотрит на мир через розовые очки.
Автор думает, что будет так:
1. Джефф проектирует базу
2. Моника вносит полезные улучшения
3. Профит!
А на самом деле будет так:
1. Джефф проектирует базу
2. Моника считает, что всё надо делать по другому и переписывает написанное Джеффом
3. Всё, работа зашла в тупик и без обсуждения вживую, голосом, это не разрулить
Поэтому я склоняюсь к более реалистичному сценарию:
1. Архитектор проектирует базу
2. Если архитектору нужно мнение Джеффа и Моники — он просит их посмотреть проект и написать комментарии
3. Архитектор вносит правки по комментариям, если сочтет это нужным.
4. Профит
JustDont
28.03.2019 22:43+1Вот тут как раз соль в том, что совещания, как способ немножко (много — не получится) совместить взгляды на проблему — это как раз очень нужный элемент процесса. Хорошее совещание — это такое совещание, после которого участники думают примерно об одном и том же. И если взгляды удалось достаточно совместить — то вот тут и начинается дальнейшая продуктивная деятельность без мнений о том, что нужно всё переделать.
s-kozlov Автор
29.03.2019 06:45Автор оригинальной статьи считает, что архитектор должен быть диктатором. Поэтому взгляды на проблему совмещаются через него: все обмениваются мнениями в письменном виде, но окончательное решение принимает архитектор, а не семиголовая гидра.
TheYellingChives
29.03.2019 13:03Так если всё построенно на диктатуре, то совещания не проводятся. Зачем? Само слово «совещание» подразумевает получение/распространение советов.
niknamezanat
29.03.2019 13:48Не увидел противоречия с автором в плане получения советов. Ответственность за проект в целом несёт архитектор, а не семиголовая гидра, в которой потом никогда концов не найдёшь, Поэтому после прихода к какому-то общему знаменателю, всё фиксируется на бумаге и распространяется через архитектора. С учётом того что могут быть не довольные и их даже может быть большинство, то тут точно не демократия
TheYellingChives
29.03.2019 16:58Ну так я и не спорю. Если первое и последнее слово за архитектором, а советы ему не нужны, то и в совещаниях нет смысла и проводить их врядли кто-то разумный будет.
s-kozlov Автор
29.03.2019 19:46+1Архитектор выслушивает разные аргументы, а окончательное решение принимает сам. Не вижу противоречия.
s-kozlov Автор
29.03.2019 06:41Моника считает, что всё надо делать по другому и переписывает написанное Джеффом
Это просто вредительство и непрофессионализм. Моника должна получить втык, при рецидиве — увольнение. Ее просили сделать ревью, а не переделать.ivanych
29.03.2019 09:21+1С чего бы вдруг? Проект Моники может быть лучше и возможно втык надо давать Джеффу, за которым всё пришлось переделывать.
s-kozlov Автор
29.03.2019 11:13-1Если Моника знает, как сделать лучше, она должна кратко описать это в комментарии и дождаться апрува, а не самовольничать. Это же обыкновенный профессионализм и дисциплина.
ivanych
29.03.2019 16:14В каком ещё комментарии? В статье говорится о том, что Моника вносит правки непосредственно в документ, написанный Джеффом.
Но пусть даже она просто написала комментарий. Там будет написано так — «тут всё надо переделать». Что дальше? Дальше ей нужно будет написать другой документ, со своим видением? К которому уже Джефф напишет комментарий «тут всё надо переделать»?
Нет, это неработает без обсуждения вживую.s-kozlov Автор
29.03.2019 19:48В статье говорится о том, что Моника вносит правки непосредственно в документ, написанный Джеффом.
Где конкретно?
s-kozlov Автор
29.03.2019 19:48В каком ещё комментарии?
На том же гитхабе можно комментировать строчки кода.
s-kozlov Автор
29.03.2019 19:49-2Там будет написано так — «тут всё надо переделать».
Если в вашей команде кто-то может оставить такой комментарий и его после этого считают профессионалом, то мне вас жаль.
niknamezanat
29.03.2019 13:42Может и лучше, но кто будет давать втык Джеффу и почему? Только потому, что кто-то оказался лучше, чем Джефф?
ivanych
29.03.2019 16:18Я не предлагаю давать втык никому из них. Это я просто перефразировал утверждение предыдущего комментатора, показывая, что это работает в обе стороны.
Вместо этого я предлагаю вообще не полагаться на то, что Джефф и Моника сами как-то там устаканят решение письменно. Не устаканят.s-kozlov Автор
29.03.2019 19:50+1Они и не устаканивают сами, устаканивает архитектор в конечном счете.
sshikov
29.03.2019 10:53Это тоже взгляд через розовые очки :) Да, вариант когда архитектор все проектирует (а точнее, просто самый умный из команды) — он иногда близок к идеалу. Но увы, в жизни ресурсы самого умного всегда ограничены, поэтому его задачи приходится делегировать менее умным или опытным членам команды.
superyateam
29.03.2019 12:03+1На 100% согласен с вами.
У нас в компании — под такие вопросы создается Design Topic в конфлуенс, все желающие смотрят. Автор указывает тех, кто обязательно должны прокомментировать. Все работает идеально.
vadimr
28.03.2019 22:20У автора не построена связка между коммуникацией и деятельностью, вот и всё, что можно сказать. У него в голове только связка между мышлением и деятельностью, классическая советская традиция образования. В этом нет ничего плохого, но это только одна возможная проекция.
А что касается тикетов, то их можно раздавать только в совершенно понятной, причём понимаемой всеми одинаково, предметной области.s-kozlov Автор
29.03.2019 06:46У автора не построена связка между коммуникацией и деятельностью
Что вы имеете в виду? Коммуникации бывают письменными, я гарантирую это.vadimr
29.03.2019 08:39Коммуникации бывают письменными, но мысль автора состоит в том, что коммуникацию желательно максимально сократить, как издержку работы. Вдобавок, он сужает коммуникацию до передачи информации о задаче.
Ещё у меня есть нехорошее подозрение, что цель деятельности автор для себя сформулировал, как выполнение проекта, в то время как в жизни очень редко встречаются случаи, для которых это было бы верно. Обычно выполнение проектов и для отдельных людей, и для организации является инструментом или побочным результатом. В этом вообще беда проектного подхода.s-kozlov Автор
29.03.2019 11:18Коммуникации бывают письменными, но мысль автора состоит в том, что коммуникацию желательно максимально сократить, как издержку работы.
Мы собрались, чтобы сделать проект и заработать денег или приятно провести время и обсудить сериалы? Полагаю, первое. Так что коммуникации должны быть максимально эффективными, что чаще всего подразумевает их сокращение по сравнению со средней ситуацией в нашей индус-трии.vadimr
29.03.2019 12:05Во-первых, я бы уточнил формулировку ситуации. Мы собрались, чтобы заработать денег и приятно и полезно провести время, одним из средств достижения чего является проект. В предельном случае может даже так получиться, что для нашего бизнеса невыгодно успешное выполнение проекта, а уж баланс стоимости и качества – это вообще обычное дело.
Во-вторых, сама по себе коммуникация является одним из средств выполнения проекта.
Относительно среднего рассуждать не берусь. Видел я фирмы, перегруженные совещаниями, это, конечно, плохо. Но это не значит, что плохи сами совещания, а просто каждый инструмент нужно применять правильно.s-kozlov Автор
29.03.2019 19:54+1Мы собрались, чтобы заработать денег и приятно и полезно провести время
Продукт овнеру все равно, приятно вы проведете время или будете ненавидеть каждую минуту, посвященную проекту. И если вы вместо наиболее эффективного выполнения своей работы ищете компромиссы между эффективностью и обсуждением сериалов, то вы просто грабите продукт овнера, только и всего.vadimr
29.03.2019 19:58Чьи это проблемы? Крепостное право в России отменили в 1861 году. Собственник может, конечно, поискать других программистов, которые будут работать на его благо, ненавидя каждую минуту, но почему-то такие запросы редко приводят к коммерческому успеху.
s-kozlov Автор
29.03.2019 06:48А что касается тикетов, то их можно раздавать только в совершенно понятной, причём понимаемой всеми одинаково, предметной области.
Спорно. Не могли бы вы развернуть свою мысль?vadimr
29.03.2019 08:44Чтобы получатель правильно понял мысль отправителя, у них должно быть построено одинаковое понимание смысла и контекста применения используемых слов. Либо заранее, либо в процессе коммуникации.
s-kozlov Автор
29.03.2019 11:21Неочевидные термины должны быть задокументированы. Или вы считаете, что рассказывать их персонально каждому новичку — это эффективная организация коммуникации?
vadimr
29.03.2019 12:07Насколько я в курсе, задокументировать все неочевидные термины можно только на языке Ифкуиль, но его мало кто знает. А в практическом плане, если для сложной задачи документировать всё, что может показаться неочевидным, то возникнет объём документации такой толщины, что её мало кто сможет освоить.
dimm_ddr
29.03.2019 15:47+1мало кто сможет освоить
Ее и написать то никто не сможет. Документация вообще подлая вещь, она устаревает постоянно, но неизвестно в каких местах и когда именно. Более того, неизвестно соответствует ли она в принципе проекту, это надо еще выяснять. Я не говорю что документация не нужна, но это тоже инструмент который нужно уметь применять и проблем с ним не меньше чем с совещаниями.s-kozlov Автор
29.03.2019 19:56+1Документация вообще подлая вещь, она устаревает постоянно, но неизвестно в каких местах и когда именно. Более того, неизвестно соответствует ли она в принципе проекту, это надо еще выяснять.
Так происходит потому, что ее пишут для галочки и потом всем на нее пофиг. Поддерживать документацию трудно и скучно, а отрывать от работы соседа по кабинету просто и весело.
mapron
30.03.2019 19:15Я люблю писать документацию) Но что-то никто не хочет платить за работу технического писателя по ставке ведущего программиста)
s-kozlov Автор
31.03.2019 11:09-2Зато хотят платить по ставке ведущего программиста за «работу» кхм-бола?)
mapron
31.03.2019 11:15-1кхм-бола? это вы завуалировали так «пиздабола»?
Очень вежливо с вашей стороны, ничего не скажешь, следите за тоном.
В чем вопрос? Сомнения в том, какую должность/зарплату я занимаю? может быть еще и фото расчетного листка приложить для вас?))
Может я некорректно выразился, поясню мысль: я по большей части разрабатываю софт, но нередко приходится писать и документацию, и спецификации, и мне реально нравится это делать (но не могу поручиться, что я был бы рад ТОЛЬКО этим заниматься каждый день весь год). Намек был лишь только на то что все люди разные, и утверждать, что все прям сознательно отлынивают от написания доки, как-то чересчур категорично.s-kozlov Автор
31.03.2019 11:27Мда… Прошу прощения, если задел, но вообще-то я про вас лично не писал и не намекал. Никто не хочет платить за работу техписа — это везде так. За работу peace-door-ball-а — тоже. Все мы выполняем эту «работу», когда сидим/стоим на «митингах».
dimm_ddr
01.04.2019 12:26Покажите мне организации где техническую документацию пишут не для галочки и тщательно следят за ее достоверностью и актуальностью. Кроме военных и какого-нибудь НАСА где стоимость ошибки астрономическая. Но компаний вроде НАСА по миру единицы, я думаю мы все же о более общем случае говорим, не?
Поддерживать исчерпывающую документацию — это гигантский труд, который, очевидно, бизнесу придется оплачивать. А польза от него совершенно не очевидна.
Поэтому то, что я описал происходит не потому что документацию поддерживают для галочки, а потому что на нее тратят столько ресурсов, сколько выглядит адекватным на нее тратить. Обычно это не очень много.
wladyspb
29.03.2019 15:55Я, с вашего позволения, немного вклинюсь в дискуссию.
Вот например(реальный пример), у нас есть проект, который приносит деньги и активно развивается. У начальства возникает идея о том, как можно увеличить доход посредством новой классной фичи. У него есть идея, и примерное понимание технической реализации. Из задачи, поставленной простыми словами, я не понимаю почти ничего. ПМ понимает частично, и даёт мне формализованное представление своего видения задачи. Я начинаю делать, у меня возникают вопросы, на которые ПМ ответить не может. В результате мы собираемся вместе, директор описывает идею, чертит графики, ПМ задаёт уточняющие вопросы, предлагает варианты, я обрабатываю крайние кейсы, вношу уточнения — что реально, что сложнореализуемо, что лучше вообще не делать. Фича обрастает подробностями, в процессе появляются новые идеи, дорабатываются старые, понимание всех участников постепенно приходит к единой картине. Двухчасовое совещание даёт наконец возможность начать нормальную работу над реализацией нового функционала, я распределяю часть задач по команде, часть беру себе. До совещания — не было даже общего понимания терминов, используемых в фиче. Т.е. кто-то считает что «фжа-рзы» — это «ар-ит-кв» а кто-то уверен что «ра-ук-пф».s-kozlov Автор
29.03.2019 19:59Высокое начальство и заказчики — это отдельная песня. Самостоятельного составления четких ТЗ от них не дождешься. Так что должен быть человек, который болтает с заказчиком и даже играет в гольф.
Am0ralist
29.03.2019 20:43+2А теперь представьте это по другому:
Начальство хочет глобальную фичу по автоматизации процессов в конторе, по этому поводу постоянно созывает совещания, на которые созываются обязательно все начальники разных подразделений. Каждый раз принимается новое шедевральное решение, иногда противоречащее решению вчерашнего или недельного совещания, иногда — законам РФ и правилам бухучета.
Фича обрастают такими подробностями, которые грозят полностью остановить процесс автоматизации. При этом программист обещает сделать всё, но не въезжает в требования пользователей.
В итоге банально приходится воплощать в жизнь анекдот про челночную дипломатию, выцепая начальников отделов по одному и выбивая из них понимание того, что они хотят и что они возможно получат. После чего уже эти вещи ты раскладываешь по полочкам, собираешь связанную картинку и разжевываешь программисту.
Внимание вопрос: угадайте какие должностные обязанности у меня в этот момент были прописаны? )
andvgal
28.03.2019 23:54+4Настоящие продуктивные совещания видел только у немцев. Что Россия, что Америка, что Средняя Азия, что дальняя Азия… — с переменным успехом из-за отсутствия продуктивной культуры в регионе в целом.
Если на совещании нет заранее заданной темы (agenda) и протокола (meeting minutes) — для меня это первый звоночек бесполезного времяпрепровождения. Во-вторых, совещание требуется проводить, а не "общаться".
Поэтому, опытный архитектор даже очевидным вещам даёт определение. Автор решил всех перехитрить и дал его: "Совещания — это узаконенный грабеж". В итоге, комментаторы пытаются обсуждать какие-то отвлечённые "совещания" на основе своего отрицательного или положительного опыта вместо обсуждения "узаконенного грабежа".
Статья радикальна и однобока, а любая крайность вряд ли тянет на взвешенный идеал.
s-kozlov Автор
29.03.2019 06:50Радикальность — это «фишка» автора. С одними его статьями я категорически согласен, прочитав другие — сомневаюсь, не сумасшедший ли он.
sshikov
30.03.2019 09:35Радикальность — это фишка идиотов. Кто никогда не сомневается в своей правоте? Правильно — только идиот. Умным людям свойственно сомневаться, и избегать радикальных утверждений. Или ограничивать их применимость.
>сейчас маятник сильно отклонился
Где это «сейчас»? У нас в проекте в пятницу прошло два совещания. Уложились в полчаса и 15 минут. Позволю себе цитату из Смешариков:
Крош:
-Ну, никакого прогресса! Вам не кажется, что мы остановились в своем развитии?
Ежик:
-Только не надо обобщатьs-kozlov Автор
31.03.2019 11:11Кто никогда не сомневается в своей правоте?
А при чем тут радикальность? Можно придерживаться радикальных взглядов («бей жидов!») и при этом в них сомневаться («а вдруг они тоже люди?»).
s-kozlov Автор
31.03.2019 11:12У нас в проекте в пятницу прошло два совещания. Уложились в полчаса и 15 минут.
Это великое достижение или для чего вы этот пример привели?sshikov
31.03.2019 15:37+1Для того, чтобы автор не обобщал свои реалии на других. Если он не умеет организовывать совещания так, чтобы они были краткими, и приносили пользу — пусть пойдет и поучится. Благо есть у кого — многие умеют. Собственно, излишнее обобщение — это основное возражение, которое возникает после прочтения.
s-kozlov Автор
29.03.2019 06:54Насчет радикальности этой статьи согласен. Иногда без «митинга» не обойтись. С другой стороны, насколько я вижу, сейчас маятник сильно отклонился в сторону бесконечных митингов,
петтингов, опенспейсов, покера и прочего — будем откровенными — говна, которое подменяет своим «бла-бла» реальную работу. Именно поэтому такие статьи сейчас полезны. Маятник нужно толкать в обратную сторону.
vagon333
29.03.2019 06:33Зависит от организации совещания.
Совещания зачастую экономят массу времени и денег.
В коллективном обсуждении проявляются мелкие детали, которые иначе могут решаться домысливанием, причем каждым участником по-своему.
meranged
29.03.2019 07:561) распределённая команда
2) у членов команды разный опыт как на проекте, так и в профессии
3) смена приоритетов и изменение требований
4) ужесточение сроков
5) необходимость перестроить работу в связи, например, с болезнью одного из ведущих разработчиков
…
Список можно продолжать. Если тут не будет правильно организованных митингов, то проект будет гарантированно провален. Если только, конечно, команда не состоит из одних самоорганизующихся супергероев-сеньёров-телепатов с неограниченным ресурсом времени.
1c80
29.03.2019 08:59+1Эти обсуждения бессмысленны. Нет смысла бросаться в крайности, совещание бывает нужно, а бывает просто по регламенту, по привычке, в независимости от того нужно оно действительно или нет, именно в этом все проблемы.
Не делать лишних, мешающих движений, вот задача для настоящего руководителя, универсальных алгоритмов тут нет, так как это нужно чувствовать.
Eldhenn
29.03.2019 09:29+2Создание архитектуры — это узаконенный грабёж. Допустим, мне, программисту, надо решить задачу. Что делает хороший программист? Решает задачу. Что делает плохой программист? Собирает команду из аналитика, архитектора, техписа, тестировщика и менеджера проекта, команда идёт к заказчику, пишет vision, потом пишет функциональные требования, потом ТЗ, потом в трёх итерациях принимает схему БД…
В то время как хороший программист давно уже скачал готовый node.js модуль, собрал с заказчика бабло и давно уже запивает 40см флорентину Jack Daniels.
vadimr
29.03.2019 09:35Вообще, любую постановку задачи можно грубо разбить на три уровня:
– чего хочет заказчик;
– что написано в ТЗ;
– чего хотим мы.
Дальше внутри каждого из этих уровней происходит дальнейшее дробление:
– чего хочет руководство заказчика;
– чего хотят представители заказчика, принимавшие участие в постановке задачи;
– чего хотят люди, которые будут эксплуатировать результат разработки;
– что написано в тексте ТЗ;
– что написано в стандартах на эту тему;
– что написано в договоре на выполнение работ;
– чего хочет наше руководство;
– чего хочет проектная команда;
– чего хочет данный конкретный разработчик;
и т.д. Весь этот баланс интересов и требований руководитель проекта должен держать в голове целиком, а другие члены проектной команды – в значительной части. Его невозможно формально сформулировать (потому что тогда мы вырнёмся просто к расширенному ТЗ) и непросто передать друг другу. А модель последовательного уточнения требований ТЗ, конечно, хороша в теории своей простотой, но на практике всего этого не учитывает.s-kozlov Автор
29.03.2019 11:27держать в голове
Вот он — корень зла. Потом эта голова попадает под колеса, и всё надо начинать сначала. Замечательно, как мы мечтали!
Его невозможно формально сформулировать (потому что тогда мы вырнёмся просто к расширенному ТЗ) и непросто передать друг другу.
Это полная чушь хотя бы потому, что итоговая программа формальна. Если начальник ставит программисту размытые требования, задача конкретизации ложится на программиста и он вынужден ее выполнить, т.к. компилятор и процессор — бездушные машины, которым чуждо вот это ваше «держать в голове». Но это не программист у нас хороший, а начальник хреновый.vadimr
29.03.2019 12:10Программа, безусловно, формальна, но вот программный продукт, который, помимо программы, включает в том числе и работу по её внедрению на объект эксплуатации и в головы разработчиков и пользователей – неформален.
По поводу колёс. Риск падения кирпича на голову руководителя проекта – головная боль его босса, а не самого руководителя проекта. Да, фирма обязана как-то хеджировать в том числе и вариант неуспешного завершения проекта, в этом ничего нового или необычного нет. Фокс про это много писал в своей книжке о разработке ПО.
ggo
29.03.2019 09:38+1CVS не нужны, вы просто не умеете сразу писать правильный код.
Планы накатов/откатов не нужны, вы просто не умеете сразу правильно конфигурить.
Стендбаи не нужны, вы просто не умеете правильно прокладывать провода.
Совещания тоже не нужны…
Wyrd
29.03.2019 09:44Команда сеньоров обходится без совещаний и стендапов. Команда принсиплов общается исключительно через мерж риквесты.
tgz
29.03.2019 10:12Для схемы базы это может и работает. А что посложнее уже таким способом не сдлать. Для каждой задачи нужен свой инструмент. Зачем ограничиваться чем-то одним?
vladvul
29.03.2019 11:51лично меня совещания очень мотивируют. Ты узнал новости проекта, послушал людей которые многое сделали, сам рассказал, высказали идеи. С новыми силами за работу, запуск уже виден.
Это бесценно в нашей отрасли, где дефицит мотивации.s-kozlov Автор
29.03.2019 20:03+1Ты узнал новости проекта, послушал людей которые многое сделали, сам рассказал, высказали идеи.
… а тут и 18:00 уже, всем хороших выходных! Еще бы такое не мотивировало. Как говорится, совещания — отличная альтернатива работе.
uvelichitel
29.03.2019 11:53+1Продукт совещаний — слаженная команда, а не схема реляционной базы данных. Схема базы — продукт слаженной команды.
trueMoRoZ
29.03.2019 12:20Какое счастье, что я не социопат-интроверт и что работа приносит мне не только бабло, но и радость через общение с другими людьми.
s-kozlov Автор
29.03.2019 20:09+1«Какое счастье, что я не зануда-моралист и что работа приносит мне не только зарплату, но и прочие ништяки через дырку в заборе».
modix
30.03.2019 06:19То есть радость приносит бабло, общение с другими людьми, но не сама работа? Если так, то сомнительное счастье…
s-kozlov Автор
30.03.2019 06:21Это веяние последних лет, когда программисты стали хорошо зарабатывать. Раньше все эти «экстраверты» шли на экономы и юрфаки, теперь вот www.youtube.com/watch?v=evE4SpLRl78
tsul
29.03.2019 13:13Люди разные. Для кого-то больше продуктивны пулл-реквесты, для кого-то — совещания. И дело не в теле Моники (возможно, для кого-то — и в нём тоже).
Хороший архитектор этого понимать не обязан, а вот хороший ПМ — очень даже.
valis
29.03.2019 14:01Я как архитектор перед стартом разработки собираю совещание, на которых присуствуют:
— Бизнес аналитики
— Разработчики
— Тестировщики
Собираю с целью:
— Убедится что все участники одинаково поняли суть задачи и предлагаемое решение.
— Получить обратную связь по рискам и возможным проблемам (тут как раз и нужны бизнес аналитики — они должны донести эти риски до бизнеса)
— Если есть несколько вариантов реализации — выбрать компромиссный по рискам и срокам.
— Тупо чтобы все участники увидели друг друга и поняли кто какую роль исполняет в данном проекте (потом им гораздо легче коммуницировать между собой не используя для этого нагруженный ресурс архитектора)
Заметьте — я здесь не решают конкретные точечные вопросы (это действительно у всех отнимает время и такие вопросы решаются в рабочем порядке).
eefadeev
29.03.2019 14:47ИТ — это не про компьютеры (базы данных и т.п.). ИТ — это про людей (общение, knowlege sharing, смыслы и идеи и вот это вот всё). Мне показалось что статья предлагает совершенно ложный выбор между двумя крайностями: совещание (как единственный метод общения) и их полное отсутствие (как цепочка актов аутичных участников). То есть, по сути, провоцирует :)
fukkit
29.03.2019 15:05+1Совещания помимо удовлетворения простых человеческих потребностей «пообщаться» на более-менее профессиональные темы с себе подобными, а не втыкать всё время в тикеты с реквестами, нужны также и для неформального обмена мнениями.
В поэтапном плане не напишешь вещей типа: «этот костыль перепишем позже», «ту мудацкую хотелку начнем делать после актирования основного функционала, за доп. плату» — и прочие мнения, указания, договоренности, необходимые команде, но плохо формализуемые в документах.
Конечно же, совещаниями, как и всем остальным можно команду зае… ть. На то архитектору (или все-таки тим лиду?) голова и выделена, чтобы искать системный баланс, как в проекте, так и в используемых инструментах управления исполнителями.
Losted
29.03.2019 15:07+2Автор, видимо, никогда не работал на проектах с более чем одной командой из разных частей организации(ий). Удачи с тикетами!
s-kozlov Автор
29.03.2019 20:13+1Да автор вообще никогда нигде не работал, а про разработку ему Изя по телефону напел.
egigd
29.03.2019 15:42Здоровый творческий человек, такой как разработчик ПО, например, хочет видеть, как его усилия превращаются во что-то ценное и — в идеале — осязаемое.
Как разработчик ПО может превратить свои усилия во что-то осязаемое?..
они меня демотивируют, т.к. я просто не вижу, во что превратились 2 часа моей жизни. На самом деле мы ничего не создаем, мы просто обсуждаем
Я так понимаю, что перед автором всегда ставят задачи на пару часов максимум, что он желает видеть результат через два часа…
У меня (я правда не ПО занимаюсь), например, запросто может уйти пару дней просто на сидение на месте и обдумывание, как же мне решить какую-либо проблему. И я не представляю, как может быть иначе при решении сложных творческих задач…dimm_ddr
29.03.2019 15:51Как разработчик ПО может превратить свои усилия во что-то осязаемое?
Запрограммировав погрузчик некорректно и сломав склад амазона например. Или местного бандита, для еще большей осязаемости последствий своих усилий…
s-kozlov Автор
29.03.2019 20:15+1Я так понимаю, что перед автором всегда ставят задачи на пару часов максимум, что он желает видеть результат через два часа…
Нет, там 2 часа занимает митинг.egigd
30.03.2019 01:34Вы не поняли, о чём я писал…
s-kozlov Автор
30.03.2019 06:03Возможно, но не могли бы вы тогда переформулировать?
Насколько я понял, автор не ощутит результата от двухчасового митинга ни в момент его окончания, ни через час, ни через день. С этой точки зрения я не понимаю, откуда следует, что он ожидает получить результат через 2 часа.egigd
30.03.2019 06:37Смею предположить, что как минимум часть проектов, в которых участвовал автор и в которых были совещания, закончились созданием необходимого заказчику программного обеспечения.
Тем не менее автор пишет «я просто не вижу, во что превратились 2 часа моей жизни», хотя они (вместе с ещё 200-2000 другими часами) превратились в то самое программное обеспечение.
Делаем вывод, что увидеть результат именно этих двух часов он желал сразу по их окончании.s-kozlov Автор
31.03.2019 11:17А можно ли доказать, что эти два часа таки превратились в ПО? Или можно было обойтись и без них? Вот в чем вопрос.
Exponent
29.03.2019 15:58Всегда ненавидел совещания. Но тут проблема скорее психологическая, все зависит от целей конкретного человека. У меня в конце дня должен быть результат, иначе что-то не так. А у многих моих колег цель совсем другая, сделать поменьше и точно в 17:00 свалить домой.
jMas
29.03.2019 16:06Реальность такова, что при недостаточном опыте участников обсуждения, комментарии в гитхабе превращаются в бесконечное обсуждение без определенной цели (где отыскать правду почти невозможно — каждый считает, что ему нужно вставить свои 5 копеек, перетянуть одеяло), что можно сказать и про совещания. Мое мнение, что проблема не в совещаниях или комментариях к пиарам, а в том, что в головах участников не сформулирована цель к которой все должны стремиться, и нет хороших арбитров контролирующих этот процесс.
s-kozlov Автор
29.03.2019 20:19+1Зато бесконечные митинги отлично маскируют разгильдяйство и отсутствие элементарных навыков, создавая видимость продуктивной работы. С гитхабом так не выйдет, увы.
jMas
29.03.2019 22:45Назовите причины, пожалуйста. Не встречали запущенных (не организованных) репозиториев?
s-kozlov Автор
30.03.2019 06:05В том то и дело, что по репозиторию это сразу видно.
mayorovp
30.03.2019 21:27На совещаниях это тоже сразу видно. Вопрос лишь в том, что нужно руководителю — получить результат или он сам первый ибэдэшник.
s-kozlov Автор
31.03.2019 11:21-1Что именно видно на совещаниях? Сидят 5 человек, полтора часа о чем-то трут, расходятся с ощущением «мы молодцы». Никто не считает количество потраченных человеко-часов, из них — ожидания, пока все соберутся, приветствий, прощаний, смолтолков, сколько реально человек «работают» и сколько — рисуют каракули. Что видно-то?
jetcar
29.03.2019 16:15совещания интересны тем кто любит поболтать, из моего опыта программисты не любят поболтать, потому обычно совещания организуют менеджеры.
на совещании можно легко манипулировать и впаривать своё решение особенно если хорошо подготовился, а остальные не смогут сходу опровергнуть, ну кроме мегагениев которые на все вопросы могут найти ответ в голове, а не в гугле, так что обычно это не выяснение истины, а выяснение кто авторитетнее, даже в общем чатике обсудить чтото будет полезнее так как не требует немедленного ответа и тут даже интроверты могут свободно высказать своё мнение
Koguro
29.03.2019 16:33Уже начал было придумывать как вступить в обоснованную дискуссию с автором. А потом, наконец, увидел, что это перевод Бугаенко…
bopoh13
29.03.2019 16:42При работе с git есть особенности:
- Изменения нужно коммитить сразу (как есть), иначе можно наделать ошибок, и на правки затратить гораздо больше времени, (чем на совещания).
- Не вносить дополнительные изменения в черновик перед коммитом, если они написаны более суток назад (как следствие из первого).
- Работая в команде нужно создавать отдельную ветку (на что намекал автор статьи).
nikandr23
29.03.2019 18:16теоретически все правильно и логично.
если тебе нужна датабаза, то:
— ты должен понимать чо именно тебе надо. с деталями. чтоб не возникали фразы «мы не мелочимся, считаем цены в тысячах баксов».
— ты обращаешься не к Погромистам а к ДБ Архитекту. который хотя бы слышал про «Нормализацию».
dustd
29.03.2019 20:24+1Главная ошибка статьи — в примере. Статья повествует не о вреде совещаний, а о том, как переложить свои обязанности на другого сотрудника. Смысл утверждения «Но даже если Джефф потратил на это час, каждая минута этого часа полезна для проекта. Я имею в виду, что каждый доллар, который я заплатил Джеффу за это время, вернулся ко мне в виде текстового документа.» верен только в одном случае — автор не архитектор, а работодатель. В противном случае — он вообще лишнее звено, и вся работа может быть сделана без него.
s-kozlov Автор
29.03.2019 20:25-1Это называется делегированием. Архитектор может непосредственно заниматься другой задачей, пока Джефф обдумывает схему. Архитектор-хирург, делающий всю важную работу — такой экстремизм разве что у Брукса был.
speshuric
29.03.2019 21:01+3Егор Бугаенко, конечно, знатный тролль. И в данном контексте это не оскорбление, а, скорее, комплимент: это важное умение — красиво набросить "интересную тему" на вентилятор.
Но что касается сути статьи, тут из-за однобокости и максималистичности подачи потерялся простой факт. Каналы коммуникации обладают сильно разными свойствами. Вот давайте посмотрим на такую табличку:
(Сделал я. Только что. Оценки субъективные из головы — кому не нравится, может, предложить свои варианты цифр, если из-за этого будут другие выводы — обсудим. Картинкой, потому что в предпросмотре таблица не отображается)
Тут:
- Latency, с – сколько проходит времени от создания информации (проговаривания или печати) до её восприятия. Важно, что эта latency в письменном тексте не может быть меньше, чем время, на то, чтобы дописать сообщение/текст и отправить его.
- Скорость создания (знаков/мин) – по моим наблюдениям, говорим мы обычно (если не диктор новостей) со скоростью 300-600 знаков (кроме пробелов и знаков препинания, если стенографировать), печатаем 100-300 знаков/мин, если хоть немного задумываемся, скорость падает (см "письмо, комментарий"). Реальные текстовые документы, если есть готовое в голове пишутся не быстрее 1500-3000 знаков в час (25-50 знаков в минуту), требется время на вычитку. Важный документ перед публикацией перечитывается столько раз, что скорость набора неважна. Скорость мессенджера, конечно, взята "компьютерная": на мобиле и набор, и восприятие медленнее.
- Скорость приема (знаков/мин) – а) скорость восприятия на слух обычно выше, чем комфортно говорить, поэтому лекции/доклады часто удобнее в ютубе просматривать на повышенной скорости; б) скорость чтения среднего ИТ-специалиста 1500-3000 знаков/мин, если умеет скорочтение, то 3000-6000, в) скорость чтения документов выше, потому что мы их редко читаем "до буквы" — в таблице вариант именно "с пропусками"
- КПД отдачи вербализируемой информации – в обычной речи обычно очень невысокий КПД реальной информации, хорошо если половина. Если мы пишем, то этот коэффициент возрастает (в зависимости от внимательности к тексту).
- КПД приёма вербализируемой информации – но информация теряется не только при её создании, но и при чтении/слушании. По опыту техник быстрого чтения знаю, что среднее восприятие среднего текста у среднего человека примерно 60%, у попыток воспринять информацию на слух — реально и 40% завышено, а если не видеть собеседника, то еще ниже.
- КПД приёма невербализируемой информации – эмоции, жесты, мимика — всё это (как и в статье замечено) теряется в письменном общении. Причем если в сообщении в телеге язык менее формален и есть смайлики, то из условного RFC это обычно вычищено.
Кроме этого есть еще несколько особенностей модели.
- Во всех кейсах мы полудуплексные. Либо отдаём информацию, либо принимаем. Се ля ви.
- Схемы/визуализации. Голосом они почти никак не передаются, для этого обычно используются презентации. Схемы существенно снижают (в знаках в минуту) скорость создания контента, но часто оно того стоит. Я их не рассматриваю для упрощения.
- Асинхронность. В личном общении её почти нет. В мессенджере и письмах — ограниченная.
- Возможность почти мгновенно прервать незаконченное сообщение/работу (перебить) — уберфича личного общения. Мы можем прервать собеседника на полуслове ("Слушай, ну это же не имеет отношения к теме собрания"). Да, у приёма есть большая цена (в том числе из-за полудуплексности), если все начнут всех перебивать, то обмен информацией ломается. Но именно из-за его эффективности мы все умеем его использовать :) Положительный эффект в том, что говорящему не нужно заканчивать речь. Попробуйте перебить того, кто пишет вам сейчас письмо (ой, мы же об этом и не знаем даже :) )
Каждый канал идеален для своих задач. То, о чем написал Егор — для писем и простых документов. Общение один на один если требуется многократно обмениваться репликами. Мессенджер для асинхронной координации (например, при устранении инцидента.)
Конечно, эти каналы часто используются совместно, чтобы оптимизировать передачу под конкретную задачу:
- Парное программирование вносит скорость личного общения в код ревью (строки 4 и 5)
- Доклад на конференции — это одновременно и мультиплексирование общения, и обогащение презентацией и быстрое получение обратной связи ("а теперь вопросы")
- Протокол совещания позволяет не протерять информацию
Посмотрев на эту модель становится очевидно, что есть много кейсов в разработке ПО, когда общение будет эффективнее переписки. Да, общение не идеально для передачи информации по КПД, но обладает свернизким latency и возможностью прервать недоделанное сообщение. А что касается объёмов — так ведь суть беседы руководителя один на один с сотрудником по кадровым вопросам часто может быть выражена в трёх строках. Но зачастую требует десятки реплик с каждой стороны.
Ну и еще: часто стоимость часа работы (пусть даже 10 высокооплачиваемых сотрудников) ничто по сравнению с возможностью вывести продукт раньше. Если совещание приблизит time to market, то это может окупить несколько недель "экономной" переписки.
jMas
29.03.2019 23:10+2Кстати, как вывод могу добавить, что на совещаниях можно понять настроение с которым подана повестка дня (нужно поднажать, например). Приоритезировать задачи и довести до каждого значимость отдельных задачь. В сухих текстах или выкладках на гитхабе — это сделать трудно. Могут возразить, например, "мы выбираем гитхаб — потому что это место где можно спокойно обсудить дела", но с точки зрения бизнеса это выглядит так: "задет критический функционал и бизнес теряет деньги и бросает в команду тикеты, а они отскакивают обратно через месяц". Прятаться за обсуждениями пиаров в гитхабе — это хороший способ уйти от срочных дел. (Мое мнение.)
speshuric
29.03.2019 23:13Одни от работы прячутся в комментах к пулл-реквестам, другие в совещаниях на 20+ участников. А работает-то кто? :)))))
jMas
29.03.2019 23:29+2Это разный взгляд с разных колоколен. Одни не любят разговаривать и решать дела на совещаниях — говорят, что совещания — это трата времени. Другие привыкли решать дела совещаниями и говорят, что мне проще 10 минут поговорить, чем целый день переписываться. И у каждого типа общения есть свои крайности. Каждый любит кинуть камень в чужой огород. Что отличает работающего от не работающего? Его дальнейшие действия после совещания / комментирования пиара на гитхабе.
s-kozlov Автор
30.03.2019 06:15Спасибо за подробный комментарий! Это всё верно, и иногда, ИМХО, личное общение лучше, но не тут не хватает одного важного параметра, по которому устная речь продует с разгромным счетом: использование информации через некоторое время. Из-за этого, в частности, я ненавижу видео-туториалы, видосы с конференций… ну и сами конференции.
isden
30.03.2019 08:42> Из-за этого, в частности, я ненавижу видео-туториалы, видосы с конференций… ну и сами конференции.
Вот да. И хорошо еще, если у туториала есть краткое описание с тезисами, тогда хоть как-то можно через поиск найти нужный видосик и отмотать примерно куда нужно.
Daddy_Cool
30.03.2019 00:57+1Разве Эйнштейн придумал свою теорию на совещании с коллегами?
Ну как бы да.
www.ng.ru/nauka/2015-11-25/9_myth.htmls-kozlov Автор
30.03.2019 06:19Не нашел там про момент озарения во время «митинга».
И кстати, слово Гильберту:
Любой мальчик на улицах Гёттингена понимает в четырёхмерной геометрии больше, чем Эйнштейн. И тем не менее именно Эйнштейн, а не математики, сделал эту работу.
egigd
30.03.2019 06:42В этот момент он переезжает из Праги в Цюрих, где привлекает к сотрудничеству своего друга по студенческим временам – специалиста по геометрии М. Гроссмана, который выводит его на многомерную риманову геометрию. В итоге в мае-июне 1913 года появляется их совместная статья, в которой ОТО представлена почти в законченном виде.
Am0ralist
30.03.2019 09:58Хм, а где здесь написано, что работали они путем созыва совещаний?
Парная работа? Так во многих случаях совместные научные работы путем рецензии чужого текста происходят, а не путем единовременной генерации текста. При личном происходит обмен знаниями в разных областях, объяснения теорий и т.п., но представить себе это в виде совещания, каким должно быть ОТО…egigd
30.03.2019 14:02А где требование, чтобы они текст писали сидя рядом?..
Если «При личном происходит обмен знаниями в разных областях, объяснения теорий и т.п.», то это важнейший этап создания ОТО.Am0ralist
30.03.2019 14:08Исходное:
Разве Эйнштейн придумал свою теорию на совещании с коллегами?
Так-то понятно, что парная работа или передача знаний между специалистами в разных разделах — важна. Но это не называется «совещанием».
PS. egigd:
Совещание — это заседание или собрание, посвященное обсуждению каких-либо вопросов.
Собрание (греч. ????????? «синантиси») — совместное присутствие группы людей в определённом месте для обсуждения разных тем или решения определённых проблем.
Заседание — это совещание или собрание, посвященное обсуждению каких-либо вопросов и решению проблем.
А так вы договоритесь, что и посещение школы или института — это совещания. И собеседование на приём работы — это совещание. Общение друзей и шашлыки — это совещания. Посещение психолога — это тоже совещание, видимо. И даже семейная жизнь — это совещание.
Так вот, решение конкретной задачи в том же институте в двоём-троём, проведение совместных расчетов, объяснение одним студентом другому или лекторам группе — никогда совещанием не назывались. И если вы будете менторствовать в своей конторе — никто это не назовет совещанием.egigd
30.03.2019 14:12Если вы даёте определение «совещания — это узаконенный грабеж», то да, не называется.
Но нормальные люди определяют иначе «совещание — встреча нескольких людей с целью совместного обсуждения каких-либо вопросов». И вот тогда это очень даже называется совещанием.
puyol_dev2
30.03.2019 06:30-1Согласен с автором статьи. 2 часа 10 минут общего времени будет потрачено, если разработка ТЗ для БД будет последовательна, при условии, что Архитектор, программист (Джефф) и инженер (Моника) будут заниматься этим поочередно. Касаемо совещания на 1,5 часа, будет потрачено уже 4,5 часа общего времени (при учете, что на совещании будет всего 3 человека) + время на перенесение результатов протокола в ТЗ
schrodenkatzen
30.03.2019 13:33Лучшее в письменной форме не экономия времени, а её асинхронность.
Можно подумать минуту над ответом в одно предложение, можно пол-дня и даже день иногда писать почти эссе по очень сложной проблеме.
Устная речь очень сильно ограничена — обычно можно сказать либо то что ты знаешь, либо то что придет первым в голову(или в основном молчать и в итоге прослыть задротом, аутистом и асоциалом, если ты при этом не начальник)
Пиьсмо позволяет передавать очень концентрированную и сложную мысль
По моему опыту у попыток делать все письменно и направленно есть свои Сцилла и Харибда
1) В компаниях где правят чистые бизнесмены они очень редко по настоящему полагаются на письмо. Глаза в глаза можно извлечь больше информации из не горящего желанием тебе её давать, можно давить харизмой или просто статусом.
Хорошее письмо это навык специалистов, а не предпринимателей(и даже не активных менеджеров)
2) Другой сорт компаний легко вязнет в бюрократии, это уже идет со среднего слоя, от тех кто не управляет компанией, но и не просто исполнитель. Бумажка это всегда прикрытие задницы.
Айтишные компании ещё очень динамичны, а где-то в торговой компании формальные таски становятся швахом
3) Любая система бумагообмена это структурированное публичное пространство которое ещё и должно стать основным.
Как быть с любым инфообменом кроме как по прямой chain of command непонятно. Если его вести вне системы это её делает бесполезной и заведомо отсталой от жизни, если делать заставить всей информацией обмениваться публично то о многом будут молчать.s-kozlov Автор
31.03.2019 11:31Лучшее в письменной форме не экономия времени, а её асинхронность.
Кстати, в статье это упоминается вскользь:
нет нужды беспокоить его этим организационным шумом
schrodenkatzen
30.03.2019 13:36П.С.
Уж не знаю были ли в патентном бюро Эйнштейна совещания, но Фейнман свои таблицы придумал в стрип-клубе.
(Правда стрип-клуб все равно лучше чем совещания — там хотя бы насильно не расходуют твое внимание)
igor-sheludko
30.03.2019 13:52Какой-то анти-скрам :) Часто бывает что исполнители критикуют технологии менеджмента потому что видели примеры неправильного применения технологий менеджмента :)
jMas
31.03.2019 17:57Мной замечено, что часто те кто внедряет что то напоминающее "скрам" не сильно понимают ради чего это делается. Это похоже на: "мне нужен вот именно этот фотоаппарат, потому что без него я не смогу стать фотографом". То есть, когда цель внедрения не обоснована, точнее не осознана (мы понимаем, что что-то не так, но не понимаем зачем нам это нужно). И получаем нечто внешне содержащее все элементы (признаки) скрама, но на деле каждый элемент введен сугубо в угоду шаблона "скрам" (причем каждый элемент не работает как нужно — на совещаниях не поднимаются насущные вопросы, вопросы не записываются, а если записываются то не решаются, ..., люди не видят фидбэка на их запросы, и ходят на совещания повтыкать в телефоны).
Опять таки, если это перенести в Git, то это тоже самое совещание умноженное на время отклика каждого из участников. Причем, если участники не понимают цели — результат будет примерно такой же — вопросы решаться не будут. Где то на хабре была статья о том, как один разработчик попробовал внедрить на предприятии систему, где все действия сотрудников были выражены в виде тикетов. Если кратко: случился коллапс данной системы. (Статья "Ад своими руками".)
Ktator
31.03.2019 04:36Статья – полнейший бред.
Во-первых, демагогическое сравнение в разделах «хороший архитектор» и «плохой архитектор» в стиле: утрируем точку зрения оппонента до состояния посмешища и с успехом её победим.
Во-вторых,я просто создаю тикет и назначаю на Джеффа
А вы своё время посчитали? Или тикет появился мгновенно? Если задача не проходная и не тривиальная, то, возможно, её описание будет занимать больше нескольких строчек? Может быть, ваша письменная речь быстрее устной? А если Джефф не понял, то обсуждение превратится в чат, да? Вот вы поставили задачу пятерым, у троих появились вопросы, вот у вас чат с тремя одновременно, вы прыгаете с пятого на десятое, а собеседники ждут. Верх производительности!
Далее, о принятии ключевых решений. Коллектив всегда знает больше, чем один человек. Вы предлагаете, очевидно, совершать их в одиночку? А могло бы выясниться, что кто-то из зала предложил более удачное решение или вскрыл проблему вашего.
И вот вы идете ко мне и просите устроить совещание, т.к. некоторые «аспекты» непонятны? Вы где-нибудь учились разработке ПО?
Очень мотивирует работать. Если тебе задача непонятна, то ты не умеешь программировать. Отношения как между врагами. Собственно, одна эта фраза из статьи демонстрирует всю её суть, остальное можно даже не читать.
начинаете смотреть свою ленту в Твиттере и рисовать каракули.
Если вы за этим пришли на совещание, то они, конечно, не нужны. Но это поведение школьника, а не профессионала.
PS: Если вдруг кому непонятно, то я не «за совещания». Я за здравый смысл.
PPS: Уважаемый s-kozlov, я вижу, что это перевод. Но вы же выбрали этот текст для перевода и его отстаиваете в комментариях, так что вопросы к вам.
s-kozlov Автор
31.03.2019 11:40Что ж, я тоже могу сказать, что этот комментарий — полнейший бред.
То, что, хотя устная речь быстрее письменной, без документов придется повторять одно и то же снова и снова, — это уже говорили.
То, что решения принимаются отнюдь не в одиночку, описано в статье.
То, что в совещании при непонятных аспектах плохо не то, что ты их не понял, а то, как именно ты решил устранять пробелы, — это основная тема статьи.Ktator
31.03.2019 12:13То, что, хотя устная речь быстрее письменной, без документов придется повторять одно и то же снова и снова, — это уже говорили.
Вот вы снова (вслед за автором) утрируете. Где я говорил, что документы не нужны?
То, что решения принимаются отнюдь не в одиночку, описано в статье.
Не откажите в любезности, процитируйте, пожалуйста. Я не нашёл.
То, что в совещании при непонятных аспектах плохо не то, что ты их не понял, а то, как именно ты решил устранять пробелы, — это основная тема статьи.
В статье описан пример задания для десятиминутной работы программиста двумя способами. Один способ при помощи «тикетов», другой способ при помощи «полуторачасового совещания», заведомо плохой. На основе этого примера делается ничем не обоснованный на мой взгляд вывод, что совещания плохие всегда и везде. При чём здесь, то, что вы написали в этом комментарии, я понять не могу.
soniq
31.03.2019 22:48+1Статью дочитал до середины, комментарии вообще не читал. Да и коммент мой никто наверное не увидит, но не могу не высказаться.
Когда я работал архитектором в одной крупной и уважаемой компании, то совещаний я организовывал достаточно много. И не потому что я был плохим архитектором. Просто совещания это достаточно важный инструмент в работе по одной очевидной причине: не всем повезло с такими Мониками, что можно закинуть ей таску в джиру и она все сделает хорошо и в срок. Люди все разные, и каждый лучше понимает по своему. Приходилось использовать все способы коммуникации: подходить ножками к столу человека и там обсуждать, просить подойти и обсуждать у меня, звонить по телефону, писать длинные письма, писать короткие письма, писать письма на большие группы и личные записки, писать в чат, писать статьи в вики и просить комментировать, просить написать статью и самому комментировать, ставить таски в трекере, назначать совещания с кучей участников, совещаться в маленьком составе, многочасовые совещания и совещания по пятнадцать минут. В каждой отдельной ситуации требовался разный подход, но встречи часто были самым эффективным способом получить информацию от людей или донести свою мысль.
А закинуть человеку встречу в каледарь — это всего лишь способ сказать: «Хэй, мне требуется твоё участие, выдели время»
yurrig
Если так рассуждать, то и парное программирование — грабеж проекта. Совещания, при правильном подходе, вполне продуктивны.
s-kozlov Автор
А разве нет? Парное программирование выгодно только тогда, когда выхлоп в единицу времени в 2 раза больше, чем при традиционном программировании. Я в такие сказки не верю, хотя и был бы рад ошибиться.
ArsenAbakarov
Парное программирование помогает быстрее обучать стажеров/джунов до более высокого уровня, да, крадется время у более опытных разработчиков, но в перспективе команда выигрывает (опустим случай, когда большая текучка кадров)
s-kozlov Автор
Верно, нанимаешь джунов — будь добр обучай. Правда, тут может быть недопонимание, о каких именно джунах мы говорим: вчерашний выпускник вуза по айтишной специальности, который уже умеет кодить, но не имеет опыта Коммерческой Разработки™, или вчерашний разносчик пиццы.
barker
s-kozlov Автор
Не понимаю, что тут смешного. Вспоминаю себя в начале карьеры. С первого рабочего дня надо мной не надо было стоять и показывать, как сделать таску, а кодил я уже тогда получше некоторый «сеньоров», с которыми довелось столкнуться. А ведь я был далеко не лучшим на потоке, можно даже сказать — отстающим.
Может, просто надо из приличных вузов набирать людей?
barker
Я ничуть не умаляю (в целом) достоинства выпускников вузов по айтишной специальности, более того, я сам такой выпускник в общем-то. И в том числе (помимо контактов по работе) именно поэтому может меня улыбнул слишком общий выбранный квантор. А на самом деле тут как повезёт (и это как минимум). Плюс прикол в том, что те выпускники, которые умеют кодить, к окончанию вуза обычно уже работают.
mclander
А те кто не работают… Грусть…
s-kozlov Автор
Ну я не работал. Немного жалею об этом, но переоценивать «коммерческую разработку» тоже не стоит. Люди, бывают, годами в ней варятся и пишут хуже второкурсника.
Face_of_Boe
А те, кто не умеют — устраивают совещания
mamokino
Да, где-то 5-15 из 100 человек такие.
s-kozlov Автор
Ну, так я не просто так про приличные вузы добавил)
APaMazur
Это что вы считаете «приличными ВУЗами»
Просто я имел опыт общения с выпускниками ВМК МГУ, Физтеха…
Ребята есть очень хорошие, но статистика удручающая и до 5-15 человек она далека
При этом много ребят умных, но отлично видно, что образование им впрок не пошло, учили их не так, не тому и надо еще учить, учить, учить и учить
katzen
(озарённо хлопнув себя по лбу) Точно! Надо было просто уничтожить все плохие вузы и бездарей отправить в хорошие — вот зажили-бы то, а?
s-kozlov Автор
Кого волнуют бездари? Не берите их на работу. Или только такие идут?
mamokino
Вы и надежный способ знаете как их определить на этапе приёма в ВУЗы и приёма на работу с, хотя бы, 90% вероятностью?
s-kozlov Автор
90%? Да легко.
Areso
ЕГЭ по информатике несколько сложнее решения FizzBuzz'ов.
katzen
Вы же буквы прочитали, но очевидный смысл почему-то не восприняли. Как так вышло? Это последствия вашего обучения или что-то индивидуальное?
s-kozlov Автор
Ну я могу вам теми же словами ответить. Дальше что?
yurrig
Это, безусловно, не каждодневная практика, но часто в неочевидных ситуациях работа в паре позволяет гораздо быстрее добраться до решения, и итераций намного меньше приходится делать. Относится и к проектированию, и к кодированию. Статистику я не собирал, так что цифрами подкрепить не смогу, но по ощущениям, часто в 2-3 раза быстрее получается, чем в одиночку. Сразу оговорюсь, я имею в виду только свою область — CADы для электронной индустрии, и свой опыт.
s-kozlov Автор
Ну вот то-то и оно. Мозг прекрасно умеет себя обманывать, плохо чувствует время и производительность.
MIKEk8
А где аргументы с вашей стороны? Статистика которое учитывает не только сколько бы второй человек сам написал за это время, но и то сколько времени ушло бы на исправление ошибок (как мелких логических, так и архитектурных), последующая поддержка не очевидных вещей, отдельное проведение код ревю (хотя наверно это тоже трата времени).
s-kozlov Автор
Как вам такой аргумент
, Илон Маск? Аргументы нужны как раз темшарлатанам, кто обещает прирост производительности в разы.etho0
Ну так вы и обещаете «прирост производительности в разы.», не?
poxvuibr
Иронично, что в защиту своей точки зрения, вы даёте ссылки на сообщество lesswrong, созданное благодаря Юдковскому, который написал книгу Гарри Поттер и методы рационального мышления, в которой в значительной мере изложены принципы lesswrong.
Ирония в том, что в книге для решения проблем рекомендуется как раз совещание, на котором нужно подробно обсудить проблему, хорошо её осознать и потом делать предложения по её решению. Что, собственно, противоречит основному посылу переведённой вами статьи.
ksbes
Да, но за одним столом часы превращаются в секунды.
К тому же работает эффект «большого брата» — неудобно гадить в коде, когда за тобой смотрят.
Парное программирование в норме — это когда нужно быстро сделать хорошо работающий код ценой двукратного увеличения расхода человеко-часов.
Хорошо это или плохо — зависит от конкретной ситуации. Это как спорить что лучше инвалидная мотоколяска или суперкар?
s-kozlov Автор
А гадить в коде, который будет проходить через ревью, удобно?
ksbes
Да. Ведь гадишь сейчас — а ревью потом. В режиме вдохновения или загона человек живёт здесь и сейчас и даже на несколько часов вперёд не думает. Пока пройдёт цикл нашли — ткнули носом — исправил, время ушло, успел позаниматься чем-то более «важным». А тут кодеревью прямо в момент забивания кода.
Кодеревью работает когда дедлайна ещё не видно или только-только замаячил на горизонте
RPG18
Парное программирование это не про выхлоп в единицу времени в 2 раза больше. Изначально оно планировалось, для повышения качества выходного продукта. Пока один пишет код, другой продумывает все возможные неприятны ситуации. Это не говоря о ситуациях, когда опытный программист заходит в тупик(потому что он долго занимается одной задачей), а второй помогает выйти из тупика, потому что у него более свежий взгляд.
s-kozlov Автор
Для того, чтобы продумывать неприятные ситуации и помогать друг другу выходить из тупиков, совсем не обязательно сидеть за одним столом.
Ndochp
Попадание в тупик в парном программировании детектится за полминуты, в одиночном — за пару дней.
dimm_ddr
Необязательно, но так критически сокращается время на коммуникацию, что позволяет не терять концентрации. А когда ты пишешь вопрос другому разработчику, а тот решил вот сейчас сходить на обед или просто в потоке и его еще пару часов оттуда не ждать — то тебе приходится сидеть и ждать или переключаться на другую задачу. Или идти дальше в этой без ответа. Все три варианта хуже чем получить ответ сразу же потому что человек вот он и занимается именно тем что помогает тебе.
s-kozlov Автор
Тоже верно. Автор, кстати, сторонник парного программирования (возможно, кому-то покажется это противоречащим данной статье, но это нормально). «Получить ответ сразу же» — при парном программировании работает, т.к. отвечающему не нужно переключаться. Но что мы видим сплошь и рядом? Программист сталкивается с проблемой и, зачастую даже не потрудившись «покурить маны», ищет в своем
скотном двореопенспейсе жертву, имевшую дело с чем-то подобным. Вот с этой чумой нужно бороться.akurilov
Да, это отдельная песня, когда к тебе 42 раза в день приходят люди что нибудь быстренько спросить во время вдумчивого дебага
Gorthauer87
Такое прекрасно через ревью делается. Но вообще мне очень понравилась практика, когда автор очень большого пул реквеста по зуму рассказывает о нем ревьюверам голосом. Вот это, черт возьми, круто помогает въехать в специфику.
RPG18
На ревью обычно выносят уже готовую задачу.
s-kozlov Автор
Найдите ошибку. Организационную.
dimm_ddr
Не ради спора про конкретный случай, но в целом практика ревью, когда несколько человек заранее посмотрев код потом слушают автора и оставляют комментарии — это просто классика, такой подход даже в том же совершенном коде описан. Очевидно что организовывать такое сборище на каждый пулреквест смысла нет — придется целыми днями только этим и заниматься. Поэтому при определенной организации, мне кажется, вполне возможно иметь большие пулреквесты с полноценной ревью сессией из нескольких человек и даже, при желании, администратором. Опять же — возможен вариант когда этот большой пул реквест является именно что компиляцией более мелких изменений, которые в свою очередь были проверены в обычном порядке.
Другое дело что я ни разу не видел ни компании где бы это делали, ни людей у которых было бы желание такой бюрократией заниматься на регулярной основе.
isden
> Пока один пишет код, другой продумывает все возможные неприятны ситуации.
А чем это лучше code review?
Минусы вот я сходу могу назвать, и все они связаны со «стоянием над душой» в процессе разработки и невозможностью спокойно подумать, набрасывая при этом разные и иногда глупые варианты. А плюсы какие?
s-kozlov Автор
Плюсы те же самые, как ни странно, просто разные люди по-разному реагируют на одинаковые раздражители.
APaMazur
Если так рассуждать, вы получите сразу все увлекательные радости эффективного менеджмента
Джуны наговнокодят, сеньоры выгорят, сопьются и свалят, миддлы, вероятнее всего, успеют сделать и то, и то, опыт
Рассматривать персонал как станок для печати денег на все часы, за которые вы им платите, в некоторых сферах можно, но не в IT, тут все против вас: и конкурентный рынок труда, и довольно высокие психологические нагрузки, и высокий средний уровень жизни персонала, и все это в условиях, когда никто и нигде особо не готовит «готовых специалистов»
В итоге — да, персонал приходится учить, а тут парное программирование и кодревью — один из лучших инструментов, и заниматься этим должен кто-то из довольно опытных «дорогих» разработчиков, ужас какой
Также работать в IT стандартные 40 часов постоянно невозможно физически, да в режиме аврала можно и 60, и 80, но редко и по необходимости, а из недели в неделю выдаивая персонал нагруженной работой без кофебрейков, совещаний и прочего «грабежа» 40 часов нагруженной работы вы получите выгоревший уставший штат, который начнет разбегаться и разваливаться, если, конечно, вы не платите вдвое больше рынка или не приковываете разработчиков к батарее
Короче говоря, рассуждая о затратах времени и бабках — не забывайте, что есть еще командная рабочая атмосфера, обучение и прочие, казалось бы, побочные вещи, без которых команда функционировать нормально и долго не может
Другой разговор, что есть персонажи, которые любят совещаниями злоупотреблять, это тема отдельной беседы, но говорить «у вас есть гит, нечего тратить рабоче время на потрепаться» — как минимум, наивно, даже если 80% совещаний, кажется, тратят время впустую
s-kozlov Автор
Опишите, пожалуйста, правильный подход.
yurrig
Формализовать врядли смогу, да и не люблю я формальные схемы. Вкратце, для нашей команды работающий подход выглядит примерно так — собираются 2-3 человека, которые в теме, брейнстормят проблему, рисуют картинки, собирают в кучку юзкейсы, набрасывают вчерне план действий. Потом идут реализовывать POC. Если надо, опять собираются и обсуждают, куда и как дальше двигаться. Постепенно из POC вырастает финальная имплементация.
s-kozlov Автор
Согласен, brainstorm иногда может быть эффективным (например, когда нужно придумать название продукта).
xsevenbeta
Даже если просто кому-то проговариваешь и озвучиваешь свою проблему/идею — очень часто тут же находишь решение. Думаю это свойство работы мозга, наверняка уже кем-то изученное.
Коллективный разум рулит. Люди очень разные, с разным опытом, разными характерами и жизненными стратегиями. Нельзя так же забывать про когнитивные искажения. Например, если человек думает что нашёл источник проблемы — ему очень сложно будет заметить другие возможные причины возниконвения проблемы. Он будет всё время искать подтверждение своей версии.
Совещания бывают разные. Когда произошло падение прод.сервера, главное фокусироваться не на поиске виновных, а на причинах и способе решения проблем. Акцент напоиске виновных это вообще мега-непродуктивно и это бич любой работы. Если вы на работе думаете не о том, как быстро решить проблему и не допустить её в дальнейшем, а преимущественно о том, как уйти от ответственности — с таких работ надо валить. Это очень нездорово. Конкретно я говорю про сферу ИТ. Концентрация на наказаниях виновных убирает очень важный элемент — личную ответственность и профессиональную «гордость». Когда «стыдно», что сервис упал это одно. Когда действуешь от мотивации «сделать лучше, чтобы не попало» — качество работы неизмеримо хуже.
Так же на совещаниях важно умеь грамотно управлять расфокусировкой внимания и его сужением. Есть время для брейншторма, когда любая идея не подвергается критике. Есть время, когда надо лезть в детали глубже.
Людей надо постоянно подгонять и учить говорить ближе к сути. Предварительная небольшая переписка всем участникам позволит не тратить время совещание на озвучивание проблемы на совещании (можно только кратко объяснить ещё раз).
Я видел очень эффективные совещания и двухчасовые, которые легко было бы уложить в пять-десять минут.
s-kozlov Автор
Вот только реальная жизнь подтверждает обратное. Подавляющее большинство шедевров созданы одиночками. Исключения настолько редки, что можно по пальцам пересчитать всех этих братьев Гримм, Ильфа и Петрова и
братьевсестер Вачовски.drinkius
Хочется посмотреть на шедевральный коммерческий самолёт, собранный одиночкой
Tsimur_S
да даже самый известный не коммерческий собран братьями, которых автор собирается по пальцам считать.
alemiks
это вы про братьев Райт? Среди которых один был идеологом?)
alemiks
так-то у самолёта один главный конструктор и тыща человек, которые крутят гайки. Разработка ПО это же тоже творческий процесс. Хотя может вы сравниваете разработку с вытачиванием болтов на станке?
vadimr
Ситуация в инженерном деле вовсе не такова, что все, кроме главного конструктора, крутят гайки. Главный конструктор большого проекта вообще может мало что лично делать в техническом отношении, и уж точно он не сам всё разрабатывает. Скорее его техническая роль ближе к тому, чтобы взвесить предложения подчинённых и выбрать из них лучшие.
s-kozlov Автор
Ну, так можно и подмастерьев, добавляющих второстепенные детали, считать полноправными соавторами картины, но сами понимаете…
drinkius
Аналогии творчества и технической работы не считаю правильными. Картина — намного менее сложный продукт, где общий эскиз, композиция — действительно могут делать главного мастера — единственным полноправным автором. Но в технических специальностях вклад каждого отдельного сотрудника, допустим, сделавшего какой-то модуль в системе — пропорционально более существенен, нежели вклад подмастерья, раскрасившего одну фигурку в картине
s-kozlov Автор
В статье описано, как можно вести обсуждения в письменном виде и чем это лучше совещаний.
s-kozlov Автор
Насчет падения сервера и поиска виноватых не понял, при чем тут это.
s-kozlov Автор
Если более общо, их надо учить выражать свои мысли кратко, четко и по существу. А болтовня способствует обратному. В принципе, она и нужна на проекте тогда, когда люди не могут нормально выразить свои мысли в письменном виде, и чаще всего это признак отсутствия соответствующих навыков.
mayorovp
У нас применяется такой подход: Скайп-конференция на 5-15 минут. В течении совещания при желании можно пить чай :-)