Здравствуйте, Codealot, Вы писали:
C>Например, совещания. Регулярные, по множеству разнообразных вопросов, с участием десятков человек, как минимум час-два каждый день. C>Очевидный вариант вместо этого — те, кому есть что донести до остальных, могут просто записать это, а все остальные прочитают когда им удобно и зададут вопросы в трекере — и все сэкономят кучу времени. C>Всем этим совещаниям есть какое-то мало-мальски разумное объяснение?
Управление знаниями в команде — это часто такой совершенно неподъёмный челлендж. Если оно как-то работает, лучше не трогать.
Есть люди, которые знают. Есть люди, которые не знают. Есть люди, у которых есть время. Есть люди, у которых нет времени. Есть люди, у которых есть мнения, есть люди у которых нет. Есть люди, у которых есть желание влиять, есть — у кого нет желания. Есть люди, которые не умеют писать. Есть люди, которые не умеют читать. И ещё штук 20 таких аспектов. Вы своим поведением иллюстрируете одно конкретное сочетание конкретных аспектов. Вы никакой не "типичный" случай и не представитель большинства. А процесс должен работать для всех.
Вот вы говорите: "напишите, я прочитаю". А не все люди могут нормально написать. Напишут плохо. Вы им скажете: "да что за херню вы написали?". И вот она — необходимость собраться и поговорить голосом. Или даже нормально вам написали. Вы прочитали и не согласны. И начинаете: "это что же, я значит 3 месяца моей жизни на вот этот дерьмо тратить буду?". И вот она снова — необходимость собраться и поговорить голосом. Или вы из тех, кто "а там плохо было написано, я как понял так и понял, давайте переделаю"?
Здравствуйте, Codealot, Вы писали:
bnk>>Так бы вместо болтовни код поди писал, или чем ты в остальное время занят?
C>Намного лучше я бы писал вместо этого код.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, rosencrantz, Вы писали:
R>>Конечно. В софтдеве дохрена нетехнических людей, которым проще/предпочтительнее поговорить, чем читать/писать.
C>Предпочтительнее — одно, "не умеют" — совсем другое.
Предпочтения — в том же смысле, что и у вас. Общаться через текст — это не "более правильно". Это метод со своими преимуществами, недостатками, требованиями к скиллам участников общения. Вот вы не осиливаете голосом обсуждать, а они не осиливают читать/писать. Кто более прав и почему?
C>Так что не надо мутить воду.
Я пришёл сюдать пить пиво и мутить воду, и я только что закончил пить пиво
R>>Предложите ваш вариант, я расскажу почему он хуже более рискованный.
C>Я уже написал — в самом первом сообщении.
Ваше первое сообщение уже вполне разжевано — там не осталось ничего интересного.
Очевидный вариант вместо этого — те, кому есть что донести до остальных, могут просто записать это, а все остальные прочитают когда им удобно и зададут вопросы в трекере — и все сэкономят кучу времени.
Вот проблемы вашего решения:
1. Некоторые люди (вы конкретно например) с некоторыми специфическими знаниями/компетенциями не ходят на совещание, поэтому не могут во время остановить безумие, порожденное сейлзом и дизайнером.
2. Цель совещания обычно — закрыть какие-то вопросы. Если совещание вопросы не закрывает, это плохо организованное совещание.
3. В вашем варианте вы как раз топите ЗА бесполезные совещания: кто хочет _проговорить_ вопрос — пусть проговаривает, но это вопрос не закроет. Потом его ещё нужно _прописать_. Т.е. в какой момент вопрос будет закрыт — не понятно. Далее — вот вы написали там свои умные замечания в трекер, с ними даже кто-то согласился. Но теперь снова вся эта толпа из 20 человек должна пересмотреть вопрос с учётом ваших замечаний и понять если по-прежнему вся выглядит ок или нет. Сколько таких итераций будет нужно? Сколько времени они займут? На эти вопросы отвечать не обязательно, тут достаточно принять, что "совещание" всегда займёт меньше времени, чем "совещание + что вы там предложили".
То, что вы называете "очевидным вариантом вместо этого" — это не очевидный вариант, это ваше очень личное предпочтение. Есть компании, у которых часть культуры — избегать иерархий и длинных цепочек принятия решений. Судя по тому, что вы пишете — вы попали в такую компанию, но вам чужда эта культура. Некоторые люди специально ищут компании в которых у них будет возможность влиять на проект/продукт. Намного проще выстроить себе комфортную работу ("сидеть и программировать") когда не ждёшь, что решение примут за тебя, а вот так вот приходишь на совещание и говоришь: щас я вам расскажу что и как я буду программировать и почему вы от этого должны писать кипятком. Через 40 минут все уже устали, поэтому получаешь "ок" — и дальше идёшь "сидеть и программировать" не то, что кто-то сказал, а то, что сам хотел.
Короче, совещание — это инструмент. Вы больше выиграете если научитесь им пользоваться в своих грязных личных целях.
Занесла меня нелегкая в новую компанию — и я до сих пор неудержимо фалломорфирую от происходящего здесь. Ну то есть я и раньше догадывался, что тут происходит тот еще бардак, но реальность намного превзошла все мои догадки. Например, совещания. Регулярные, по множеству разнообразных вопросов, с участием десятков человек, как минимум час-два каждый день.
Очевидный вариант вместо этого — те, кому есть что донести до остальных, могут просто записать это, а все остальные прочитают когда им удобно и зададут вопросы в трекере — и все сэкономят кучу времени.
Всем этим совещаниям есть какое-то мало-мальски разумное объяснение?
Здравствуйте, rosencrantz, Вы писали:
R>Управление знаниями в команде — это часто такой совершенно неподъёмный челлендж. Если оно как-то работает, лучше не трогать.
Только если руководство команды не компетентное. А вообще это более чем подъёмная задача, была бы сила воли.
R>Есть люди, которые знают. Есть люди, которые не знают. Есть люди, у которых есть время. Есть люди, у которых нет времени. Есть люди, у которых есть мнения, есть люди у которых нет. Есть люди, у которых есть желание влиять, есть — у кого нет желания. Есть люди, которые не умеют писать. Есть люди, которые не умеют читать. И ещё штук 20 таких аспектов. Вы своим поведением иллюстрируете одно конкретное сочетание конкретных аспектов. Вы никакой не "типичный" случай и не представитель большинства. А процесс должен работать для всех.
Если процесс выливается в совещания по 2 часа, то это говорит о том что он не работает. Тут простая математика, если команда состоит из 5 человек, то одно такое совещание стоит порядка 15 часов работы команды (по пол часа на переключение контекста и ещё 2 часа на само совещание).
R>Вот вы говорите: "напишите, я прочитаю". А не все люди могут нормально написать. Напишут плохо. Вы им скажете: "да что за херню вы написали?". И вот она — необходимость собраться и поговорить голосом. Или даже нормально вам написали. Вы прочитали и не согласны. И начинаете: "это что же, я значит 3 месяца моей жизни на вот этот дерьмо тратить буду?". И вот она снова — необходимость собраться и поговорить голосом. Или вы из тех, кто "а там плохо было написано, я как понял так и понял, давайте переделаю"?
Писать нормальный текст это такой же тренируемый навык как писать нормальный код. Для обсуждения текста давно придумали всякие Вики и Конфлюэнсы и там обсуждение более чем нормально работает. Обсудить текст после написания на порядок проще чем начать с болтовни и закончить "знаниями в головах". Знания должны быть задокументированы, это крайне сильно ускоряет процесс разработки.
Здравствуйте, 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 кнопками которая ходит в базу успешным продуктом, это студенческая поделка. Возможно в этом и кроется главное разногласие.
Здравствуйте, rosencrantz, Вы писали:
R>Есть люди, которые знают. Есть люди, которые не знают. Есть люди, у которых есть время. Есть люди, у которых нет времени. Есть люди, у которых есть мнения, есть люди у которых нет. Есть люди, у которых есть желание влиять, есть — у кого нет желания. Есть люди, которые не умеют писать. Есть люди, которые не умеют читать. И ещё штук 20 таких аспектов.
Ага, есть люди, которые не умеют говорить. Есть люди, которые не умеют слушать. И лично я к этим людям отношусь. Читать/писать — запросто. Разговоры — ужас. На длинных совещаниях обычно я уплываю и перестаю воспринимать, что там говорят. А посидеть десять минут и прочитать — без проблем. Обосновать что я хочу сказать сходу и голосом — да ну нафиг, проще промолчать, пускай сами там мучаются. А написать — без проблем, не торопясь, с гуглом где надо, со ссылочками.
И почему в IT-компаниях, так любят болтать — лично мне не понятно. Точней понятно — менеджеры — как раз их тех, кто хорошо усваивает голос и они проталкивают свою повестку властью данной им свыше, во вред остальным.
Здравствуйте, Antidote, Вы писали:
A>Менеджеры — враги, и только мешают пушистым программистам? Детсад.
Ну, менеджеры так не считают. Но я, например, видел не так уж и много нормальных менеджеров.
Как-то слышу разговор. Менеджер спрашивает у разработчика:
— Ты слышал, что... (дальше что-то по проекту).
— Нет, мне не сказали,— ответил разработчик.
На что последовал вопрос:
— Кто не сказал?
В недалеком прошлом рулила нашим проектом одна дама. Из ее способностей я запомнил одну: умение пятиминутную речь растянуть на час. А, нет, она еще выделяла разработчикам неделю на один юнитест. Да, именно так: ЮНИТЕСТ. Мне так и не удалось выяснить, что это такое.
Здравствуйте, Codealot, Вы писали:
C>Всем этим совещаниям есть какое-то мало-мальски разумное объяснение?
Все зависит от степени происходящего.
С одной стороны, менеджерам по определению дано больше власти. Чем они, в большинстве своем, и пользуются, перекладывая свою работу на разработчиков. Это касается не только совещаний, но и всяких тайм-трекеров, навешивание на разработчиков обязанностей по поддержанию правильно оформленных тикетов, всевозможные отчеты о трудовой деятельности и т.п.
Лечится, как по мне, только постановкой менеджеров в прямую и быструю зависимость от результатов работы разработчиков. Когда его дурь быстро сказывается на эффективности команды, и ему столь же быстро прилетает за это по бошке. Уговоры про то что разработчики должны большую часть времени работать, а не мудя чесать, как показывает практика нифига не действуют.
С другой стороны, телега где разработчики общаются другими только при помощи тикетов, как ты предлагаешь — тоже далеко не уедешь. Такие вещи как командный грумминг или командное же решение какой то сложной проблемы — при голосовом общении на порядок эффективнее самостоятельного копания или перепуливания сообщениями. Лечится это нормальным тимлидом, который новых членов команды активно вовлекает в принятый процесс, а проявляющих особое упорство выпинывает из команды под зад ногой.
Здравствуйте, Codealot, Вы писали:
R>>Предпочтения — в том же смысле, что и у вас. Общаться через текст — это не "более правильно". Это метод со своими преимуществами, недостатками, требованиями к скиллам участников общения. Вот вы не осиливаете голосом обсуждать, а они не осиливают читать/писать. Кто более прав и почему? C>У текстового варианта есть объективные достоинства в виде экономии времени и наличия истории, к которой легко вернуться при необходимости. Никаких достоинств совещаний ты не озвучил, кроме "некоторым людям так больше нравится".
А в чем проблема просить менеджеров по результатам каждого совещания делать краткое текстовое резюме? К тому же конференции можно записывать и где-то хранить, а интересные вещи находить через субтитры? Вот и история.
Здравствуйте, Antidote, Вы писали:
A>Продвигать самого лучшего программиста в менеджеры — почти всегда работает плохо.
Согласен.
A>А откуда их взять
Откуда-то берутся.
Я с одним работал. В течение полутора лет, что он у нас был (потом ушел на повышение), я ни разу не спросил у него: вот я задачу закончил, что дальше? Процесс был построен так, что все было ясно. При этом на совещания я ходил примерно раз в неделю. Иногда проводились летучки, но это было быстро и в контексте выполняемых заданий.
И еще я одну девушку знал. В отличие от упомянутой мною дамы она, став тимлидом, навела в своей команде почти идеальный порядок. Работать с ней было одно удовольствие. Я был в соседней команде. Они делали web, а мы им данные поставляли.
A>Так лафа же
Тут лафа. Но эта же дама как-то выпустила норматив: два часа на починку бага. И тут же, в полном соответствии с закноами Мерфи, обнаружилась пара багов Гейзенберга. Ловили их несколько месяцев. Надо было видеть ее реакцию.
Было еще всякое, но к болтовне это не имеет прямого отношения.
Здравствуйте, reversecode, Вы писали:
R>это только в ко где куча менеджеров
R>но это постепенно убирается R>поскольку программисты и сами себя и между собой не плохо менеджируют
R>нужно ли созваниваться итд тоже сами программисты могут решить R>а созвонится можно раз в один или три месяца, в зависимости от сложности проекта R>когда обговаривается новая фитча или функционал
Из нас с вами у кого-то очень специфический опыт работы. Какие нахрен раз в один-три месяца, если релизы раз в 2 недели, а то и чаще — и в каждом релизе должно быть N готовых фич, которые увидят живые пользователи? Мне кажется вы говорите о каких-то глубоко технических проектах. Большинство проектов — это сделать страничку с 3 кнопками, которая ходит в базу. У таких проектов вся тяжесть не в том, как это запрограммировать, а в том, чтобы запрограммировать именно то, что хочется бизнесу, продукт менеджеру, дизайнерам, юзерам. Вот чем больше перекос в эту сторону, тем больше митинги-совещания имеют смысл.
C>Очевидный вариант вместо этого — те, кому есть что донести до остальных, могут просто записать это, а все остальные прочитают когда им удобно и зададут вопросы в трекере — и все сэкономят кучу времени. C>Всем этим совещаниям есть какое-то мало-мальски разумное объяснение?
добровольным чтением "с листа" глазами — любая информация усваивается в 100-500 раз (!) быстрее, чем на лекциях. Но! "Вертикалы" — не способны к самообразованию. Прочно усваивают знания только "с голоса". Лучше "на личном примере". Обязательно, с "эмоциональным подкреплением".
Более 90% курсантов военных училищ (!) не в состоянии учиться сами читая книжки. Текст учебного курса им обязательно должен наговаривать вслух "альфа-самец" в полковничьих погонах с хорошо поставленным "командным" голосом... Старая (ещё 20-х годов) статистика, собранная по всем ведущим странам мира...
Народ упорно пропускает мимо ушей любое знание, носитель которого не выглядит "авторитетно". Медсестер и санитарок, с их требованиями и рекомендациями, "уважающие себя" поциенты — посылают на хрен, а потом — мрут, от сущей ерунды (особенно в реанимации, после операций)... или остаются калеками... Я молчу про "межведомственные планерки", где вместо поиска решений проблем — сплошное гнутье понтов.
C>Всем этим совещаниям есть какое-то мало-мальски разумное объяснение?
Кому выгодно?
очевидно, тем, кто не умеет, но деятельность надо изображать. Неважно, какую деятельность.
главное, чтобы была красивая картинка.
А заодно — уход от ответственности: вот жеж не я один же решение принимал! Совещание жеж так решило.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Codealot, Вы писали:
C>Так это ж удаленно. Что не мешает им устраивать видео-болтовню на несколько часов практически каждый день.
Издержки удаленной работы. Чтобы все были в курсе. Ты же чаржишь за эти два часа, или?
Так бы вместо болтовни код поди писал, или чем ты в остальное время занят?
Выключи камеру, поставь вместо нее фотку, съешь ещё этих мягких французских булок, да выпей чаю
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, rosencrantz, Вы писали:
R>>А как ты узнаешь какой код нужно писать? Тебе прям детальную спеку дают? Во всяких там скрамо-аджайлах традиционно знания "висят в воздухе" — и митинги нужны именно для того, чтобы у всех воздух был один и тот же. Одна из основных задач продукт менеджера например — вещать на всю команду видение продукта, чтоб народ не в буквах ковырялся, а мог самостоятельно отличить хорошо и плохо.
KP>Всякие там скрамо-аджайлы не требуют того, что бы знания витали в воздухе.
Начни с Agile Manifesto, потом возвращайся, продолжим разговор.
KP>Витающие в воздухе знания как раз и говорят о полной неспособности руководства команды поставить нормальный процесс.
Каким образом говорят и откуда происходит твоё видение "нормального процесса"?
KP>Так же утверждение что одна из основных задач продукт менеджера вещать на всю команду видение продукта ложное.
Нет, всё в порядке с утверждением.
KP>У продукта должен быть некий план развития, если это сложный продукт то ещё необходим процесс согласования со всеми вовлечёнными в него командами. Всё это требует не витующего в воздухе видения, а вполне себе структурированного документа, который отражает фазы развития продукта, фазы интеграции с другими подразделениями, разбивку фич на кварталы и т.д.
Мы всё ещё о коммерчески успешной разработке софта говорим, или уже переключились на один из твоих предыдущих проектов?
Здравствуйте, Codealot, Вы писали:
НС>>Такие вещи как командный грумминг или командное же решение какой то сложной проблемы — при голосовом общении на порядок эффективнее самостоятельного копания или перепуливания сообщениями. C>Как говорится в старом анекдоте — "и ты тоже так говори".
Баба Яга против? Это наблюдаемый факт, ссылку на Agile Manifesto тут уже приводили.
Здравствуйте, kaa.python, Вы писали:
R>>Управление знаниями в команде — это часто такой совершенно неподъёмный челлендж. Если оно как-то работает, лучше не трогать. KP>Только если руководство команды не компетентное.
Считать всех вокруг дураками — неконструктивно.
KP>Если процесс выливается в совещания по 2 часа, то это говорит о том что он не работает. Тут простая математика, если команда состоит из 5 человек, то одно такое совещание стоит порядка 15 часов работы команды
Простая математика говорит что 2 часа совещания это 2, ну пусть два с половиной часа работы команды.
KP>Писать нормальный текст это такой же тренируемый навык как писать нормальный код. Для обсуждения текста давно придумали всякие Вики и Конфлюэнсы и там обсуждение более чем нормально работает.
Нормально, но в разы медленее чем голосом. Неоднократно проверено на практике. А уж если команда привыкла общаться голосом, то появление такого молчуна, требующего от всех писать ему тексты ничего хорошего не принесет.
KP> Обсудить текст после написания
Ну то есть обсудить все же надо?
KP>на порядок проще чем начать с болтовни и закончить "знаниями в головах". Знания должны быть задокументированы, это крайне сильно ускоряет процесс разработки.
Ну вот по итогам митинга ответственный и должен зафиксировать результат. Если это большие митинги, то на то есть проджекты, это их прямая обязанность. Если что то внутрикоманлдное — есть тимлид или ведущий по обсуждаемому вопросу.
Здравствуйте, Codealot, Вы писали:
C>Занесла меня нелегкая в новую компанию — и я до сих пор неудержимо фалломорфирую от происходящего здесь. Ну то есть я и раньше догадывался, что тут происходит тот еще бардак, но реальность намного превзошла все мои догадки. Например, совещания. Регулярные, по множеству разнообразных вопросов, с участием десятков человек, как минимум час-два каждый день.
по описанию явный перебор, особенно для девелоперов которым таски сверху спускают.
C>Очевидный вариант вместо этого — те, кому есть что донести до остальных, могут просто записать это, а все остальные прочитают когда им удобно и зададут вопросы в трекере — и все сэкономят кучу времени.
не, так только с документацией работает и то не всегда
C>Всем этим совещаниям есть какое-то мало-мальски разумное объяснение?
да. прежде чем создать для вас таски в джире, менеджеры, бизнес и сеньер девелоперы тратят кучу времени что бы прояснить все вопросы.
но если туда тащат простых девелоперов, то перебор, конечно. вам там делать нечего... шучу
Здравствуйте, rosencrantz, Вы писали:
R>Здравствуйте, Codealot, Вы писали:
C>>Например, совещания. Регулярные, по множеству разнообразных вопросов, с участием десятков человек, как минимум час-два каждый день. C>>Очевидный вариант вместо этого — те, кому есть что донести до остальных, могут просто записать это, а все остальные прочитают когда им удобно и зададут вопросы в трекере — и все сэкономят кучу времени. C>>Всем этим совещаниям есть какое-то мало-мальски разумное объяснение?
R>Управление знаниями в команде — это часто такой совершенно неподъёмный челлендж. Если оно как-то работает, лучше не трогать.
У меня как минимум 3-4 митинга в неделю, где топ менеджмент обсуждает как космические корабли бороздят просторы большого театра ( одно из них идет прямо сейчас )
к моей непосредственной работе никакого отношения не имеет, но 80 человек как бы должны присутствовать в течении часа двух.
Второе — на обсуждение фичи было потрачено немерянное количество часов на обсуждение словами, когда дошло до имплементации выяснилось что все по разному
понимают обработку ошибок.
Я просто свел все в таблицу и попросил архитектов договориться уже о финальной версии ... если бы эта таблица была изначально, то необходимости в часовых совещаниях бы не было
Более того, last but not least ... то что написано уже является документом к которому можно вернуться и ткнуть носом ... а то что было пробалаболено в течении 2х часов многие могут вспомнить
или понять по разному
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, The Passenger, Вы писали:
TP>>У меня как минимум 3-4 митинга в неделю, где топ менеджмент обсуждает как космические корабли бороздят просторы большого театра ( одно из них идет прямо сейчас ) TP>>к моей непосредственной работе никакого отношения не имеет, но 80 человек как бы должны присутствовать в течении часа двух.
НС>Совещание на 80 человек с топами это клиника.
Здравствуйте, rosencrantz, Вы писали:
R>Есть люди, которые не умеют читать.
Да ладно? В софтдеве?
R>А не все люди могут нормально написать. Напишут плохо.
Пусть пишут, как умеют.
R>Вы прочитали и не согласны. И начинаете: "это что же, я значит 3 месяца моей жизни на вот этот дерьмо тратить буду?". И вот она снова — необходимость собраться и поговорить голосом.
Здравствуйте, Codealot, Вы писали:
R>>Есть люди, которые не умеют читать.
C>Да ладно? В софтдеве?
Конечно. В софтдеве дохрена нетехнических людей, которым проще/предпочтительнее поговорить, чем читать/писать.
R>>А не все люди могут нормально написать. Напишут плохо.
C>Пусть пишут, как умеют.
Я не против.
R>>Вы прочитали и не согласны. И начинаете: "это что же, я значит 3 месяца моей жизни на вот этот дерьмо тратить буду?". И вот она снова — необходимость собраться и поговорить голосом.
C>Зачем голосом?
Предложите ваш вариант, я расскажу почему он хуже более рискованный.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, bnk, Вы писали:
bnk>>Так бы вместо болтовни код поди писал, или чем ты в остальное время занят?
C>Намного лучше я бы писал вместо этого код.
А как ты узнаешь какой код нужно писать? Тебе прям детальную спеку дают? Во всяких там скрамо-аджайлах традиционно знания "висят в воздухе" — и митинги нужны именно для того, чтобы у всех воздух был один и тот же. Одна из основных задач продукт менеджера например — вещать на всю команду видение продукта, чтоб народ не в буквах ковырялся, а мог самостоятельно отличить хорошо и плохо.
но это постепенно убирается
поскольку программисты и сами себя и между собой не плохо менеджируют
нужно ли созваниваться итд тоже сами программисты могут решить
а созвонится можно раз в один или три месяца, в зависимости от сложности проекта
когда обговаривается новая фитча или функционал
Здравствуйте, LaptevVV, Вы писали:
C>>Всем этим совещаниям есть какое-то мало-мальски разумное объяснение? LVV>Кому выгодно? LVV>очевидно, тем, кто не умеет, но деятельность надо изображать. Неважно, какую деятельность. LVV>главное, чтобы была красивая картинка. LVV>А заодно — уход от ответственности: вот жеж не я один же решение принимал! Совещание жеж так решило.
Задачи, которые приходят со стороны бизнеса, "раскладываются" на части — компетенции разных людей. Люди могут отличаться и по "профессии" (дизайнеры вс программисты), и по пониманию разных частей системы. Все эти люди будут иметь возможность внести свой вклад только если их поместить вот в это вот пространство обсуждения задачи. Конкретный обсуждаемый вопрос их может быть не затрагивает, но это только они знают — затрагивает или нет, больше никто. Поэтому им там просто надо быть на этом совещании.
Здравствуйте, rosencrantz, Вы писали:
R>А как ты узнаешь какой код нужно писать? Тебе прям детальную спеку дают?
Достаточно примерного описания. Письменно, в трекере.
R>Во всяких там скрамо-аджайлах традиционно знания "висят в воздухе" — и митинги нужны именно для того, чтобы у всех воздух был один и тот же.
Совершенно идиотская идея, сравнивая этот вариант с другими.
Здравствуйте, rosencrantz, Вы писали:
R>Конечно. В софтдеве дохрена нетехнических людей, которым проще/предпочтительнее поговорить, чем читать/писать.
Предпочтительнее — одно, "не умеют" — совсем другое. Так что не надо мутить воду.
R>Предложите ваш вариант, я расскажу почему он хуже более рискованный.
Здравствуйте, 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>А как ты узнаешь какой код нужно писать? Тебе прям детальную спеку дают? Во всяких там скрамо-аджайлах традиционно знания "висят в воздухе" — и митинги нужны именно для того, чтобы у всех воздух был один и тот же. Одна из основных задач продукт менеджера например — вещать на всю команду видение продукта, чтоб народ не в буквах ковырялся, а мог самостоятельно отличить хорошо и плохо.
Всякие там скрамо-аджайлы не требуют того, что бы знания витали в воздухе. Витающие в воздухе знания как раз и говорят о полной неспособности руководства команды поставить нормальный процесс. Так же утверждение что одна из основных задач продукт менеджера вещать на всю команду видение продукта ложное. У продукта должен быть некий план развития, если это сложный продукт то ещё необходим процесс согласования со всеми вовлечёнными в него командами. Всё это требует не витующего в воздухе видения, а вполне себе структурированного документа, который отражает фазы развития продукта, фазы интеграции с другими подразделениями, разбивку фич на кварталы и т.д.
Здравствуйте, Codealot, Вы писали:
C>Регулярные, по множеству разнообразных вопросов, с участием десятков человек, как минимум час-два каждый день.
Мы когда тут сравнительно недавно, в конце 2019, запускали одну штуку в разработку, у нас тоже так было — потому что никто пока не знает, что конкретно мы делаем, как мы её делаем, есть только примерное направление (и то поменялось, хоть и не сильно), поэтому и появляются совещания вида "вроде бы клиенту надо вот это, но я до конца не уверен, наверно, надо клиенту предложить вот это и вот так, но вдруг у вас будут мысли получше, ну и как конкретно это должно быть выжпрограммисты и знаете, как будет вам самим проще это реализовать"
Прошло два года, свелось к daily на 10 минут и демонстрации и ретроспективе раз в две недели.
Здравствуйте, rosencrantz, Вы писали:
R>Текстовые обсуждения формата эссе-эссе-эссе-эссе (ну типа как на рсдн) ни один вменяемый человек читать не станет. А если не эссе-эссе, а чат — это уж тем более.
Ну ты же читаешь. Или например на SO. Много еще примеров.
Не встречал еще ни одного более-менее адекватного программиста, для которого это вызывало бы проблемы.
R>Донести до остальных — это ваш непосредственный начальник. Самому начальнику по-прежнему нужно будет ходить на совещания, слушать там глупости и отстаивать интересы своего отдела. Или вы так скромно предложили всему вашему начальству до самого директора перестать болтать и общаться только текстом?
То, что происходит там наверху — это вообще совсем отдельная проблема, так что непонятно, зачем ты это сюда приплел. Если они хотят совещаться — пусть. А тем кто работает — зачем это делать?
C>>Это вообще не проблема моего решения. Не передергивай. R>Я выше написал откуда могло возникнуть недопонимание. Вы в обсуждении стабильно гнёте ветку "оставьте меня в покое и дайте писать код". Про реформы уровня предприятия вы вроде ничего не писали?
И опять ты пишешь какую-то бессвязицу. Ты написал этот пункт как "проблему моего решения". Но это — вообще не проблема моего решения, никаким боком.
R>Чего, и продукт менеджер текстом, и дизайнеры текстом, и все дизайн сессии текстом и без картинок?
Ты не поверишь, но в чате можно и картинки вставлять
R>Уточните размеры ваших проектов и вашу роль. Может вас тут на позицию выше взяли, а вы не пояли?
Нет, это совершенно точно не менеджерская позиция. Ни у меня, ни у большинства остальных.
Здравствуйте, Sharov, Вы писали:
S>А в чем проблема просить менеджеров по результатам каждого совещания делать краткое текстовое резюме?
Проблема в том, что они этого не делают.
S> К тому же конференции можно записывать и где-то хранить, а интересные вещи находить через субтитры? Вот и история.
Убогая замена мало-мальски компетентно написанной доки. Попробуй что-нибудь найди, когда таких совещаний в истории сотни, а титры распознаются — как всегда — с ошибками.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Такие вещи как командный грумминг или командное же решение какой то сложной проблемы — при голосовом общении на порядок эффективнее самостоятельного копания или перепуливания сообщениями.
Как говорится в старом анекдоте — "и ты тоже так говори".
Overall, participants created more correct and complex anagrams during video-chat conversations. They also felt more confident in their performance and rated their interactions as more personal and natural during video-chat conversations. Finally, they agreed more with the “calm, emotionally stable” self-description in video-chat.
НС>Overall, participants created more correct and complex anagrams during video-chat conversations. They also felt more confident in their performance and rated their interactions as more personal and natural during video-chat conversations. Finally, they agreed more with the “calm, emotionally stable” self-description in video-chat.
Здравствуйте, vsb, Вы писали:
vsb>Ага, есть люди, которые не умеют говорить. Есть люди, которые не умеют слушать. И лично я к этим людям отношусь. Читать/писать — запросто. Разговоры — ужас. На длинных совещаниях обычно я уплываю и перестаю воспринимать, что там говорят. А посидеть десять минут и прочитать — без проблем. Обосновать что я хочу сказать сходу и голосом — да ну нафиг, проще промолчать, пускай сами там мучаются. А написать — без проблем, не торопясь, с гуглом где надо, со ссылочками.
+1, все мы разные.
vsb>И почему в IT-компаниях, так любят болтать — лично мне не понятно.
Тем, которые умеют говорить, проще за 5 мин объяснить свой подход и получить идеи от остальных, чем писать то же самое часами и ждать потом ответов.
vsb>Точней понятно — менеджеры — как раз их тех, кто хорошо усваивает голос и они проталкивают свою повестку властью данной им свыше, во вред остальным.
Менеджеры — враги, и только мешают пушистым программистам? Детсад.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Считать всех вокруг дураками — неконструктивно.
Что заставляет тебя проводить параллель между некомпетентностью и дураками? Так же не понятно почему "все вокруг", вокруг меня много компетентных людей понимающий как строить процессы разработки.
НС>Простая математика говорит что 2 часа совещания это 2, ну пусть два с половиной часа работы команды.
Простая логика говорит что там я описался и вместо команды должно быть человеко-часа.
НС>Нормально, но в разы медленее чем голосом. Неоднократно проверено на практике. А уж если команда привыкла общаться голосом, то появление такого молчуна, требующего от всех писать ему тексты ничего хорошего не принесет.
Необходимость многих часов больших команд (в оригинальном сообщении сказано: "десятков человек, как минимум час-два каждый день") на обсуждения явный маркер проблем с процессами. Если команда уже работает криво, то надо это постепенно исправлять. И само собой одинокий молчун должен начать подстраиваться под кривой, но работающий процесс, а не на оборот.
НС>Ну то есть обсудить все же надо?
Обсуждения нужны и важны. Основное несогласие было с тем что знания должны где-то там витать и передаваться исключительно устно, так как управление знаниями "это часто такой совершенно неподъёмный челлендж". Ты точно прочитал что я написал или просто хочется поспорить?
НС>Ну вот по итогам митинга ответственный и должен зафиксировать результат. Если это большие митинги, то на то есть проджекты, это их прямая обязанность. Если что то внутрикоманлдное — есть тимлид или ведущий по обсуждаемому вопросу.
То есть ты тоже не считаешь что знания должны "витать в воздухе" и единственное с чем ты не согласен — начать с документа для обсуждения, а не просто закончить им?
Здравствуйте, Codealot, Вы писали:
A>>Тем, которые умеют говорить, проще за 5 мин объяснить свой подход C>Сколько уже работаю — ни одного такого не встречал. Обычно балаболят часами и в конце концов добиваются только очень смутного понимания.
Может это потому-что "Есть люди, которые не умеют слушать. И лично я к этим людям отношусь. " (с)
Здравствуйте, kaa.python, Вы писали:
KP> Так же не понятно почему "все вокруг", вокруг меня много компетентных людей понимающий как строить процессы разработки.
Потому что 90% твоих сообщений про разработку о том что кто то дурак.
НС>>Ну то есть обсудить все же надо? KP>Обсуждения нужны и важны.
Ну вот а ТС, как я понимаю, с этим не согласен.
KP>То есть ты тоже не считаешь что знания должны "витать в воздухе" и единственное с чем ты не согласен — начать с документа для обсуждения, а не просто закончить им?
Я не согласен с исходным заявлением о том что совещания, без указания какой то конкретики, это зло.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Потому что 90% твоих сообщений про разработку о том что кто то дурак.
Ну либо это твоя интерпретация, так же как ты только что проделал выше проведя параллели
KP>>То есть ты тоже не считаешь что знания должны "витать в воздухе" и единственное с чем ты не согласен — начать с документа для обсуждения, а не просто закончить им?
НС>Я не согласен с исходным заявлением о том что совещания, без указания какой то конкретики, это зло.
Совещания, без указания конкретики говорит о том, что никто не подумал о чем же именно будут говорить и решил отвлечь всех участников совещания что бы "подумать вместе". Это зло хотя бы потому, что когда организатор продумывает тему заранее, это очень сильно экономит время, иногда даже делая совещание вообще не нужным.
Здравствуйте, kaa.python, Вы писали:
НС>>Потому что 90% твоих сообщений про разработку о том что кто то дурак. KP>Ну либо это твоя интерпретация
Посмотри на свои сообщения сам.
KP>>>То есть ты тоже не считаешь что знания должны "витать в воздухе" и единственное с чем ты не согласен — начать с документа для обсуждения, а не просто закончить им? НС>>Я не согласен с исходным заявлением о том что совещания, без указания какой то конкретики, это зло. KP>Совещания, без указания конкретики говорит о том, что никто не подумал о чем же именно будут говорить
Без указания конкретики в стартовом посте этого топика, а не в самом совещании.
Здравствуйте, Privalov, Вы писали:
A>>Менеджеры — враги, и только мешают пушистым программистам? Детсад. P>Ну, менеджеры так не считают. Но я, например, видел не так уж и много нормальных менеджеров.
Не спорю, все мы разные. И нормальность оцениваем по-разному
Но да, хороших менеджеров мало. Продвигать самого лучшего программиста в менеджеры — почти всегда работает плохо.
А откуда их взять
P>Как-то слышу разговор. Менеджер спрашивает у разработчика: P>— Ты слышал, что... (дальше что-то по проекту). P>— Нет, мне не сказали,— ответил разработчик. P>На что последовал вопрос: P>— Кто не сказал?
P>В недалеком прошлом рулила нашим проектом одна дама. Из ее способностей я запомнил одну: умение пятиминутную речь растянуть на час. А, нет, она еще выделяла разработчикам неделю на один юнитест. Да, именно так: ЮНИТЕСТ. Мне так и не удалось выяснить, что это такое.
Здравствуйте, The Passenger, Вы писали:
TP>У меня как минимум 3-4 митинга в неделю, где топ менеджмент обсуждает как космические корабли бороздят просторы большого театра ( одно из них идет прямо сейчас ) TP>к моей непосредственной работе никакого отношения не имеет, но 80 человек как бы должны присутствовать в течении часа двух.
TP>Второе — на обсуждение фичи было потрачено немерянное количество часов на обсуждение словами, когда дошло до имплементации выяснилось что все по разному TP>понимают обработку ошибок. TP>Я просто свел все в таблицу и попросил архитектов договориться уже о финальной версии ... если бы эта таблица была изначально, то необходимости в часовых совещаниях бы не было
TP>Более того, last but not least ... то что написано уже является документом к которому можно вернуться и ткнуть носом ... а то что было пробалаболено в течении 2х часов многие могут вспомнить TP>или понять по разному
Здравствуйте, The Passenger, Вы писали:
TP>У меня как минимум 3-4 митинга в неделю, где топ менеджмент обсуждает как космические корабли бороздят просторы большого театра ( одно из них идет прямо сейчас ) TP>к моей непосредственной работе никакого отношения не имеет, но 80 человек как бы должны присутствовать в течении часа двух.
Беспроводные наушники в уши и заниматься своими делами по дому Но это жуть конечно, обычно такое в больших конторах, раздутый штат, и митинги эти потому-что "надо что-то делать"
TP>Второе — на обсуждение фичи было потрачено немерянное количество часов на обсуждение словами, когда дошло до имплементации выяснилось что все по разному TP>понимают обработку ошибок. TP>Я просто свел все в таблицу и попросил архитектов договориться уже о финальной версии ... если бы эта таблица была изначально, то необходимости в часовых совещаниях бы не было
Да уж, ну на ошибках учатся
TP>Более того, last but not least ... то что написано уже является документом к которому можно вернуться и ткнуть носом ... а то что было пробалаболено в течении 2х часов многие могут вспомнить TP>или понять по разному
По ходу совещания кто-то должен записывать решения, с расшаренным скрином, тогда все недопонимания сразу вылезают и обсуждаются.
Здравствуйте, The Passenger, Вы писали:
TP>У меня как минимум 3-4 митинга в неделю, где топ менеджмент обсуждает как космические корабли бороздят просторы большого театра ( одно из них идет прямо сейчас ) TP>к моей непосредственной работе никакого отношения не имеет, но 80 человек как бы должны присутствовать в течении часа двух.
