О мозговых штурмах.
Собственно хотел сказать, что brainstorm’ы надо проводить только приглашая разработчиков. Менеджер тоже конечно может сгенирировать идею или направить мысли в нужную русло, но все таки конечном умную идею по инженерной проблеме чаще таки генерирует инженер.
ну так надо ж уточнять - что, мол де, технические проблемы пусть обмозговывают технари. а юридические - юристы. о боже, я похоже нашёл зависимость!!!
а ведь действительно зависимость :))
“все таки конечном умную идею по инженерной проблеме чаще таки генерирует инженер.”
Или тестировщик. Или support engineer. На такие штурмы нужно приглашать тех людей, которые “в теме” задачи. Их должностные инструкции в данном контексте вторичны.
Ну поэтому я и написал “инженер”. По большему счету тестировщик - тоже инженер, просто занимающийся тестирование.
Действительно самое важное, чтобы люди хоть понимали задачу и принимали участие в решение и обсуждение похожих задач.
В этом смысле менеджер, чаще всего человек которое имеет наименее глубокое понимание задачи.
А насчет должностных инструкций - согласен, они тут не причем.
А ещё есть понятие “взгляд со стороны”, которым инженер может не обладать :)))
Кроме того, если проводится мозговой штурм, то важна не частота генерации идей (которая выше у инженера), а её оригинальность.
Для взгляда со стороны, лучше пригласить инженера из другого отдела.
Кстати, в мозговом штурме, зачастую важна как раз частота генерации идей - нужно придумать с десяток идей, а потом отсортировать их и выбрать разумные.
Я не слишком люблю эти штурмы направленные на поиск единственного и правильного решения.
Хотя, конечно соглашусь, оригинальность важна.
а еще лучше, когда приглашаются независимые инженеры, которые могут предложить совсем свежие идеи.
Да, я чуть выше написал, иделально - если инженер с одной стороны знает технологию и проблемную область, а с другой стороны не был вовлечен до этого в решение этой проблемы.
Хорошая статья, узнал много нового!)
Мозговые штурмы полезны, но не когда постоянны они…
О слабостях метода мозгового штурма (англ):
Why Brainstorming is a Weak Tool for Creative Thinking.
В паре фраз: Человек сидит со связанными руками. Можете он играть на скрипке? Не может. Теперь развяжем ему руки… Заиграет он на скрипке? Неизвестно. Мозговые штурмы - развязывание рук… и всё.
Более детально - Serious Creativity.
Да, мозговой штурм - это всего лишь попытка сделать рывок, но действительно не известно, удастся ли рывок или нет.
В любом случае - кто не шутрмует тотне пьет шампанское…
Но ведь далеко не каждый разработчик - инженер. Более полезно приглашать ПМ или team leader, которые разбираются в технической части. Вот с этим согласен. А конечный разработчик очень часто ничем не мотивирован рассказывать как лучше сделать ту или иную вещь.
“Но ведь далеко не каждый разработчик - инженер”
Почему?
Я имею в виду инженер, не как гордое звание, а просто в смысле, что обладатели технического образования или опыта.
Я просто пытался противопоставить это именно менеджерскому составу.
ПМ не всегда самый правильный человек, для таких митингов, особенно если он чистый менеджер. Просто больше уходит времени, на то, чтобы растолковать, в чем собственно проблема.
Я имею ввиду именно ПМ, которые не просто “менеджер”
А почему не каждый разработчик - инженер - потому, что инженер шире понятие, чем кодер. Вот большинство программистов - именно кодеры - работают по заданному алгоритму и не более.
А инженер способен решать поставленную перед ним задачу без всяких алгоритмов и т.д. Возможно сумбурно поясняю, но разница между кодером и инженером - целая пропасть.
Ну, кодер - все таки редкая сейчас штука. Мало кому нужны люди, которые только умеют набивать код.
Но, в целом я согласен - естественно должны присутствовать люди с мозгами.
Не надо кстати сетовать на размер статьи. Даже в очень короткой заметке можно узнать больше чем в целой книге. Краткость сестра таланта
Та, привычка с сетование на длину статей.
Хотя интересно, что самые популярные статьи выходят либо длинные, либо короткие. Средние чаще всего не катят.