Здравствуйте, rosencrantz, Вы писали:
R>Предпочтения — в том же смысле, что и у вас. Общаться через текст — это не "более правильно". Это метод со своими преимуществами, недостатками, требованиями к скиллам участников общения. Вот вы не осиливаете голосом обсуждать, а они не осиливают читать/писать. Кто более прав и почему?
У текстового варианта есть объективные достоинства в виде экономии времени и наличия истории, к которой легко вернуться при необходимости. Никаких достоинств совещаний ты не озвучил, кроме "некоторым людям так больше нравится".
R>Вот проблемы вашего решения:
R>1. Некоторые люди (вы конкретно например) с некоторыми специфическими знаниями/компетенциями не ходят на совещание, поэтому не могут во время остановить безумие, порожденное сейлзом и дизайнером.
Я писал не про случай "в дополнение к совещаниям", а "вместо совещаний".
R>2. Цель совещания обычно — закрыть какие-то вопросы. Если совещание вопросы не закрывает, это плохо организованное совещание.
Это вообще не проблема моего решения. Не передергивай.
R>3. В вашем варианте вы как раз топите ЗА бесполезные совещания: кто хочет _проговорить_ вопрос — пусть проговаривает, но это вопрос не закроет. Потом его ещё нужно _прописать_. Т.е. в какой момент вопрос будет закрыт — не понятно. Далее — вот вы написали там свои умные замечания в трекер, с ними даже кто-то согласился. Но теперь снова вся эта толпа из 20 человек должна пересмотреть вопрос с учётом ваших замечаний и понять если по-прежнему вся выглядит ок или нет. Сколько таких итераций будет нужно? Сколько времени они займут? На эти вопросы отвечать не обязательно, тут достаточно принять, что "совещание" всегда займёт меньше времени, чем "совещание + что вы там предложили".
Ничего подобного я не делаю. Никаких совещаний вообще, кроме тех случаев, когда это служит заведомо не относящимся к работе целям — например, совместно напиться до поросячьего визга.
R>а вот так вот приходишь на совещание и говоришь: щас я вам расскажу что и как я буду программировать и почему вы от этого должны писать кипятком. Через 40 минут все уже устали, поэтому получаешь "ок" — и дальше идёшь "сидеть и программировать" не то, что кто-то сказал, а то, что сам хотел.
Держи карман шире. Ничего подобного здесь не происходит.
И напротив — я работал в компаниях, где длинных цепочек не было, но коммуникации были в основном текстом.
Здравствуйте, LaptevVV, Вы писали:
LVV>А заодно — уход от ответственности: вот жеж не я один же решение принимал! Совещание жеж так решило.
Можно предложить решение проблемы на суд коллег. В случае, если проблема неочевидная, или решение противоречивое. Чтоб не быть сусаниным, заведшим в тупик.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, rosencrantz, Вы писали:
R>>Предпочтения — в том же смысле, что и у вас. Общаться через текст — это не "более правильно". Это метод со своими преимуществами, недостатками, требованиями к скиллам участников общения. Вот вы не осиливаете голосом обсуждать, а они не осиливают читать/писать. Кто более прав и почему?
C>У текстового варианта есть объективные достоинства в виде экономии времени и наличия истории, к которой легко вернуться при необходимости. Никаких достоинств совещаний ты не озвучил, кроме "некоторым людям так больше нравится".
У совещания высокая интерактивность. Там где текстом можно зафигачить целое эссе, а потом получить комментарий: у вас ошибка в третьей строчке, на совещании можно поднять руку как только первое кривое утверждение слышишь. Это экономит кучу времени и сил. Это если один на один. А если ещё 18 человек сидят вокруг и слушают — у них здорово выстраивается картинка что откуда появилось. Текстовые обсуждения формата эссе-эссе-эссе-эссе (ну типа как на рсдн) ни один вменяемый человек читать не станет. А если не эссе-эссе, а чат — это уж тем более.
R>>Вот проблемы вашего решения:
R>>1. Некоторые люди (вы конкретно например) с некоторыми специфическими знаниями/компетенциями не ходят на совещание, поэтому не могут во время остановить безумие, порожденное сейлзом и дизайнером.
C>Я писал не про случай "в дополнение к совещаниям", а "вместо совещаний".
Да ну. Вы написали:
те, кому есть что донести до остальных, могут просто записать это
Донести до остальных — это ваш непосредственный начальник. Самому начальнику по-прежнему нужно будет ходить на совещания, слушать там глупости и отстаивать интересы своего отдела. Или вы так скромно предложили всему вашему начальству до самого директора перестать болтать и общаться только текстом?
R>>2. Цель совещания обычно — закрыть какие-то вопросы. Если совещание вопросы не закрывает, это плохо организованное совещание.
C>Это вообще не проблема моего решения. Не передергивай.
Я выше написал откуда могло возникнуть недопонимание. Вы в обсуждении стабильно гнёте ветку "оставьте меня в покое и дайте писать код". Про реформы уровня предприятия вы вроде ничего не писали?
R>>а вот так вот приходишь на совещание и говоришь: щас я вам расскажу что и как я буду программировать и почему вы от этого должны писать кипятком. Через 40 минут все уже устали, поэтому получаешь "ок" — и дальше идёшь "сидеть и программировать" не то, что кто-то сказал, а то, что сам хотел.
C>Держи карман шире. Ничего подобного здесь не происходит. C>И напротив — я работал в компаниях, где длинных цепочек не было, но коммуникации были в основном текстом.
Чего, и продукт менеджер текстом, и дизайнеры текстом, и все дизайн сессии текстом и без картинок? Уточните размеры ваших проектов и вашу роль. Может вас тут на позицию выше взяли, а вы не пояли?
Здравствуйте, Codealot, Вы писали:
C>Всем этим совещаниям есть какое-то мало-мальски разумное объяснение?
Отсутствие нормальных процессов в команде либо неправильно сформированная команда ведет к такому эффекту. Корень проблемы всегда был в неквалифицированном менеджменте.
Сделать с этим ты ничего не сможешь, если напрягает то проще всего сменить работу. Можно попробовать влиться в эти забавные процессы и попытаться получить какие-то ништяки лично для себя. Но вариант выше с чаем и булочками мне кажется более разумным.
Здравствуйте, rosencrantz, Вы писали:
R>Управление знаниями в команде — это часто такой совершенно неподъёмный челлендж. Если оно как-то работает, лучше не трогать.
Только если руководство команды не компетентное. А вообще это более чем подъёмная задача, была бы сила воли.
R>Есть люди, которые знают. Есть люди, которые не знают. Есть люди, у которых есть время. Есть люди, у которых нет времени. Есть люди, у которых есть мнения, есть люди у которых нет. Есть люди, у которых есть желание влиять, есть — у кого нет желания. Есть люди, которые не умеют писать. Есть люди, которые не умеют читать. И ещё штук 20 таких аспектов. Вы своим поведением иллюстрируете одно конкретное сочетание конкретных аспектов. Вы никакой не "типичный" случай и не представитель большинства. А процесс должен работать для всех.
Если процесс выливается в совещания по 2 часа, то это говорит о том что он не работает. Тут простая математика, если команда состоит из 5 человек, то одно такое совещание стоит порядка 15 часов работы команды (по пол часа на переключение контекста и ещё 2 часа на само совещание).
R>Вот вы говорите: "напишите, я прочитаю". А не все люди могут нормально написать. Напишут плохо. Вы им скажете: "да что за херню вы написали?". И вот она — необходимость собраться и поговорить голосом. Или даже нормально вам написали. Вы прочитали и не согласны. И начинаете: "это что же, я значит 3 месяца моей жизни на вот этот дерьмо тратить буду?". И вот она снова — необходимость собраться и поговорить голосом. Или вы из тех, кто "а там плохо было написано, я как понял так и понял, давайте переделаю"?
Писать нормальный текст это такой же тренируемый навык как писать нормальный код. Для обсуждения текста давно придумали всякие Вики и Конфлюэнсы и там обсуждение более чем нормально работает. Обсудить текст после написания на порядок проще чем начать с болтовни и закончить "знаниями в головах". Знания должны быть задокументированы, это крайне сильно ускоряет процесс разработки.
Здравствуйте, rosencrantz, Вы писали:
R>А как ты узнаешь какой код нужно писать? Тебе прям детальную спеку дают? Во всяких там скрамо-аджайлах традиционно знания "висят в воздухе" — и митинги нужны именно для того, чтобы у всех воздух был один и тот же. Одна из основных задач продукт менеджера например — вещать на всю команду видение продукта, чтоб народ не в буквах ковырялся, а мог самостоятельно отличить хорошо и плохо.
Всякие там скрамо-аджайлы не требуют того, что бы знания витали в воздухе. Витающие в воздухе знания как раз и говорят о полной неспособности руководства команды поставить нормальный процесс. Так же утверждение что одна из основных задач продукт менеджера вещать на всю команду видение продукта ложное. У продукта должен быть некий план развития, если это сложный продукт то ещё необходим процесс согласования со всеми вовлечёнными в него командами. Всё это требует не витующего в воздухе видения, а вполне себе структурированного документа, который отражает фазы развития продукта, фазы интеграции с другими подразделениями, разбивку фич на кварталы и т.д.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, rosencrantz, Вы писали:
R>>А как ты узнаешь какой код нужно писать? Тебе прям детальную спеку дают? Во всяких там скрамо-аджайлах традиционно знания "висят в воздухе" — и митинги нужны именно для того, чтобы у всех воздух был один и тот же. Одна из основных задач продукт менеджера например — вещать на всю команду видение продукта, чтоб народ не в буквах ковырялся, а мог самостоятельно отличить хорошо и плохо.
KP>Всякие там скрамо-аджайлы не требуют того, что бы знания витали в воздухе.
Начни с Agile Manifesto, потом возвращайся, продолжим разговор.
KP>Витающие в воздухе знания как раз и говорят о полной неспособности руководства команды поставить нормальный процесс.
Каким образом говорят и откуда происходит твоё видение "нормального процесса"?
KP>Так же утверждение что одна из основных задач продукт менеджера вещать на всю команду видение продукта ложное.
Нет, всё в порядке с утверждением.
KP>У продукта должен быть некий план развития, если это сложный продукт то ещё необходим процесс согласования со всеми вовлечёнными в него командами. Всё это требует не витующего в воздухе видения, а вполне себе структурированного документа, который отражает фазы развития продукта, фазы интеграции с другими подразделениями, разбивку фич на кварталы и т.д.
Мы всё ещё о коммерчески успешной разработке софта говорим, или уже переключились на один из твоих предыдущих проектов?
Здравствуйте, rosencrantz, Вы писали:
R>Начни с Agile Manifesto, потом возвращайся, продолжим разговор.
Если ты пытаешься натянуть на "витание в воздухе" вот этого утверждения, то ты его просто не понял. Знания бывают слишком объемными что бы хоть где-то витать
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
KP>>Витающие в воздухе знания как раз и говорят о полной неспособности руководства команды поставить нормальный процесс. R>Каким образом говорят и откуда происходит твоё видение "нормального процесса"?
Видение происходит из работы и руководства командами в больших проектах.
KP>>Так же утверждение что одна из основных задач продукт менеджера вещать на всю команду видение продукта ложное.
R>Нет, всё в порядке с утверждением.
. На любом более менее сложном проекта такая методика не сработает.
Расскажи, пожалуйста, что будет вещать менеджер проекта на команду если команде надо организовать интеграцию работ с командами из Сингапура, Германии, США и Израиля где при этом часть команд вообще внешние компании? Какие там витания в воздухе? Требования должны быть задокументированы и доступны команде для понимания направления развития
KP>>У продукта должен быть некий план развития, если это сложный продукт то ещё необходим процесс согласования со всеми вовлечёнными в него командами. Всё это требует не витающего в воздухе видения, а вполне себе структурированного документа, который отражает фазы развития продукта, фазы интеграции с другими подразделениями, разбивку фич на кварталы и т.д.
R>Мы всё ещё о коммерчески успешной разработке софта говорим, или уже переключились на один из твоих предыдущих проектов?
Да, именно о нём, но я не считаю формочку с 3 кнопками которая ходит в базу успешным продуктом, это студенческая поделка. Возможно в этом и кроется главное разногласие.
Здравствуйте, Codealot, Вы писали:
R>>Предпочтения — в том же смысле, что и у вас. Общаться через текст — это не "более правильно". Это метод со своими преимуществами, недостатками, требованиями к скиллам участников общения. Вот вы не осиливаете голосом обсуждать, а они не осиливают читать/писать. Кто более прав и почему? C>У текстового варианта есть объективные достоинства в виде экономии времени и наличия истории, к которой легко вернуться при необходимости. Никаких достоинств совещаний ты не озвучил, кроме "некоторым людям так больше нравится".
А в чем проблема просить менеджеров по результатам каждого совещания делать краткое текстовое резюме? К тому же конференции можно записывать и где-то хранить, а интересные вещи находить через субтитры? Вот и история.
Здравствуйте, Codealot, Вы писали:
C>Регулярные, по множеству разнообразных вопросов, с участием десятков человек, как минимум час-два каждый день.
Мы когда тут сравнительно недавно, в конце 2019, запускали одну штуку в разработку, у нас тоже так было — потому что никто пока не знает, что конкретно мы делаем, как мы её делаем, есть только примерное направление (и то поменялось, хоть и не сильно), поэтому и появляются совещания вида "вроде бы клиенту надо вот это, но я до конца не уверен, наверно, надо клиенту предложить вот это и вот так, но вдруг у вас будут мысли получше, ну и как конкретно это должно быть выжпрограммисты и знаете, как будет вам самим проще это реализовать"
Прошло два года, свелось к daily на 10 минут и демонстрации и ретроспективе раз в две недели.
Здравствуйте, Codealot, Вы писали:
C>Всем этим совещаниям есть какое-то мало-мальски разумное объяснение?
Все зависит от степени происходящего.
С одной стороны, менеджерам по определению дано больше власти. Чем они, в большинстве своем, и пользуются, перекладывая свою работу на разработчиков. Это касается не только совещаний, но и всяких тайм-трекеров, навешивание на разработчиков обязанностей по поддержанию правильно оформленных тикетов, всевозможные отчеты о трудовой деятельности и т.п.
Лечится, как по мне, только постановкой менеджеров в прямую и быструю зависимость от результатов работы разработчиков. Когда его дурь быстро сказывается на эффективности команды, и ему столь же быстро прилетает за это по бошке. Уговоры про то что разработчики должны большую часть времени работать, а не мудя чесать, как показывает практика нифига не действуют.
С другой стороны, телега где разработчики общаются другими только при помощи тикетов, как ты предлагаешь — тоже далеко не уедешь. Такие вещи как командный грумминг или командное же решение какой то сложной проблемы — при голосовом общении на порядок эффективнее самостоятельного копания или перепуливания сообщениями. Лечится это нормальным тимлидом, который новых членов команды активно вовлекает в принятый процесс, а проявляющих особое упорство выпинывает из команды под зад ногой.
Здравствуйте, rosencrantz, Вы писали:
R>Текстовые обсуждения формата эссе-эссе-эссе-эссе (ну типа как на рсдн) ни один вменяемый человек читать не станет. А если не эссе-эссе, а чат — это уж тем более.
Ну ты же читаешь. Или например на SO. Много еще примеров.
Не встречал еще ни одного более-менее адекватного программиста, для которого это вызывало бы проблемы.
R>Донести до остальных — это ваш непосредственный начальник. Самому начальнику по-прежнему нужно будет ходить на совещания, слушать там глупости и отстаивать интересы своего отдела. Или вы так скромно предложили всему вашему начальству до самого директора перестать болтать и общаться только текстом?
То, что происходит там наверху — это вообще совсем отдельная проблема, так что непонятно, зачем ты это сюда приплел. Если они хотят совещаться — пусть. А тем кто работает — зачем это делать?
C>>Это вообще не проблема моего решения. Не передергивай. R>Я выше написал откуда могло возникнуть недопонимание. Вы в обсуждении стабильно гнёте ветку "оставьте меня в покое и дайте писать код". Про реформы уровня предприятия вы вроде ничего не писали?
И опять ты пишешь какую-то бессвязицу. Ты написал этот пункт как "проблему моего решения". Но это — вообще не проблема моего решения, никаким боком.
R>Чего, и продукт менеджер текстом, и дизайнеры текстом, и все дизайн сессии текстом и без картинок?
Ты не поверишь, но в чате можно и картинки вставлять
R>Уточните размеры ваших проектов и вашу роль. Может вас тут на позицию выше взяли, а вы не пояли?
Нет, это совершенно точно не менеджерская позиция. Ни у меня, ни у большинства остальных.
Здравствуйте, Sharov, Вы писали:
S>А в чем проблема просить менеджеров по результатам каждого совещания делать краткое текстовое резюме?
Проблема в том, что они этого не делают.
S> К тому же конференции можно записывать и где-то хранить, а интересные вещи находить через субтитры? Вот и история.
Убогая замена мало-мальски компетентно написанной доки. Попробуй что-нибудь найди, когда таких совещаний в истории сотни, а титры распознаются — как всегда — с ошибками.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Такие вещи как командный грумминг или командное же решение какой то сложной проблемы — при голосовом общении на порядок эффективнее самостоятельного копания или перепуливания сообщениями.
Как говорится в старом анекдоте — "и ты тоже так говори".
Здравствуйте, Codealot, Вы писали:
НС>>Такие вещи как командный грумминг или командное же решение какой то сложной проблемы — при голосовом общении на порядок эффективнее самостоятельного копания или перепуливания сообщениями. C>Как говорится в старом анекдоте — "и ты тоже так говори".
Баба Яга против? Это наблюдаемый факт, ссылку на Agile Manifesto тут уже приводили.
Здравствуйте, kaa.python, Вы писали:
R>>Управление знаниями в команде — это часто такой совершенно неподъёмный челлендж. Если оно как-то работает, лучше не трогать. KP>Только если руководство команды не компетентное.
Считать всех вокруг дураками — неконструктивно.
KP>Если процесс выливается в совещания по 2 часа, то это говорит о том что он не работает. Тут простая математика, если команда состоит из 5 человек, то одно такое совещание стоит порядка 15 часов работы команды
Простая математика говорит что 2 часа совещания это 2, ну пусть два с половиной часа работы команды.
KP>Писать нормальный текст это такой же тренируемый навык как писать нормальный код. Для обсуждения текста давно придумали всякие Вики и Конфлюэнсы и там обсуждение более чем нормально работает.
Нормально, но в разы медленее чем голосом. Неоднократно проверено на практике. А уж если команда привыкла общаться голосом, то появление такого молчуна, требующего от всех писать ему тексты ничего хорошего не принесет.
KP> Обсудить текст после написания
Ну то есть обсудить все же надо?
KP>на порядок проще чем начать с болтовни и закончить "знаниями в головах". Знания должны быть задокументированы, это крайне сильно ускоряет процесс разработки.
Ну вот по итогам митинга ответственный и должен зафиксировать результат. Если это большие митинги, то на то есть проджекты, это их прямая обязанность. Если что то внутрикоманлдное — есть тимлид или ведущий по обсуждаемому вопросу.
Здравствуйте, rosencrantz, Вы писали:
R>Есть люди, которые знают. Есть люди, которые не знают. Есть люди, у которых есть время. Есть люди, у которых нет времени. Есть люди, у которых есть мнения, есть люди у которых нет. Есть люди, у которых есть желание влиять, есть — у кого нет желания. Есть люди, которые не умеют писать. Есть люди, которые не умеют читать. И ещё штук 20 таких аспектов.
Ага, есть люди, которые не умеют говорить. Есть люди, которые не умеют слушать. И лично я к этим людям отношусь. Читать/писать — запросто. Разговоры — ужас. На длинных совещаниях обычно я уплываю и перестаю воспринимать, что там говорят. А посидеть десять минут и прочитать — без проблем. Обосновать что я хочу сказать сходу и голосом — да ну нафиг, проще промолчать, пускай сами там мучаются. А написать — без проблем, не торопясь, с гуглом где надо, со ссылочками.
И почему в IT-компаниях, так любят болтать — лично мне не понятно. Точней понятно — менеджеры — как раз их тех, кто хорошо усваивает голос и они проталкивают свою повестку властью данной им свыше, во вред остальным.
Ничего подобного здесь не происходит.
