Как эффективно «продать» хороший дизайн на больших собраниях

Много раз я был свидетелем печальной трагедии. Вот что происходит:

1. Командный обзор проекта для нового проекта.
2. Я вижу простой дизайн, который имеет довольно много отверстий.
3. Я случайно упоминаю дыры и способы их избежать.
4. Предупреждения игнорируются комментариями типа «такого никогда не случится в реальной жизни»
5. В конце концов случается то, что «никогда не случится»
6. Экстренная проверка проекта команды для сломанного проекта.

Так что мне делать? Отказ от отношения «Я тебе говорил» не поможет завоевать друзей и повлиять на людей. Иногда проходят годы, и комментарии к шагу 3 все равно забываются. Я определенно не хочу быть назойливым вредителем, напоминающим миру о хитчах. Я часто сижу и смотрю, как «Титаник» отправляется в Европу.

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

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

Не ставьте людей в режим защиты на собрании, они просто будут бороться с вами за победу. Вы не заставите их согласиться с тем, что земля круглая. Это нормальная политика (например, любой на FoxNews)

Это действительно помогает завоевать уважение других разработчиков. Если вы новый парень в команде, я думаю, что вы SOL. Так что просто соберите командного представителя и действительно постарайтесь добраться до уровня, если вас не уволят сразу. Конечно, если вы всегда пессимистичны, то вы будете просто помечены как «отрицательный» парень.

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

Наконец, я согласен, что вы не хотите выполнять процедуру «Я сказал вам об этом», но обязательно постарайтесь дать подсказки своему боссу / техническому руководителю, когда выяснится, что вы действительно были правы. Может быть, отправить старые письма с вашими старыми комментариями. Спросите их, поможет ли это решить «новую» проблему. Если вы этого не сделаете, они даже не вспомнят, что вы были тем, кто поднял это в первый раз. В конце концов они получат намек, что вы не просто пытаетесь быть понты на собраниях. В следующий раз они дважды подумают о том, чтобы вас оттолкнуть, особенно если выясняется, что ваш «старый» дизайн теперь заменяет текущий сломанный.

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

Люди сходят с ума в собраниях. Сообщите о своих проблемах ключевому человеку за пределами собрания. Они увидят это как менее угрожающее и могут потратить время на то, чтобы услышать ваш аргумент, вместо того, чтобы думать об их защите дизайна. Им также может потребоваться больше времени, чтобы объяснить вам обстоятельства, по которым у вас может быть действительная точка зрения, но это невозможно в версии 1.0.

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

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

Я не вижу, как эта ситуация сильно отличается от одинокого разработчика с бестолковым боссом. К сожалению, я потерял счет тому, сколько раз я был «убежден» построить проект определенным образом и отправить его, несмотря на мои предупреждения о надвигающейся гибели. Таким образом, вы не только строите, но и сами плывете по Титанику прямо в айсберг.

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

Во всяком случае, группа «убежденными» программистов может быть столь же невежественна остроконечными волосы босса, иногда даже больше , потому что они уверенно невежествен, как и упоминает Джефф O . Когда это произойдет, у вас будет достаточно времени, чтобы все исправить. Не пытайтесь заставить услышать единый голос разума через коллективный пердеть мозга. Если вы можете сделать это эффективно, ваше место в конгрессе, а не за письменным столом программного обеспечения.

Поскольку действия говорят громче слов, вы можете:

• Покажите (с тестовыми сценариями), почему проект не будет работать в нормальных условиях. Это, вероятно, приведет к меньшей встрече, на которой вы представляете, и, вероятно, это все, что вам нужно услышать.

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

• Повторите последний проект, который требует переписывания за неделю до его отправки.

Другими словами, первый шаг, независимо от того, что вы делаете, это иметь дело с людьми или (намного) меньшей группой. Если ваши опасения действительно верны, я уверен, что они будут лучше приняты через неделю или две в разработку. Точно так же, как вы заметили, избегайте позиции «я же вам говорил».

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

Хороший (но часто трудный) способ представить «критику» - это задать наводящие вопросы - пусть другой человек попытается ответить на ваш вопрос и сам осознает недостаток. Тогда это похоже на их собственную идею, и они с большей вероятностью будут ее продвигать. Опять же, это лучше всего подходит для частных обсуждений, но может быть более дипломатичным и эффективным способом продвижения вперед в ситуации встречи (Примечание. Старайтесь не вступать в споры или длительные дискуссии, чтобы убедить людей на встрече. Просто изложите идею и попробуйте не стоит задумываться. Может быть, лучше отказаться от этого и затем поговорить с дизайнерами после встречи, чтобы «прояснить то, что я не совсем понял», чем быть «парнем, который сделал простые 30 минут». встреча тратит все мое утро ")

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

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

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

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

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

«Случайное» в «небрежном упоминании дыр» кажется проблемой. Попробуйте использовать (или ввести, если он не существует) какой-то записанный процесс для анализа рисков проекта. Как правило, результатом совещания по анализу рисков является простая таблица из двух столбцов: риск, и какова согласованная стратегия снижения риска («мы думаем, что этого никогда не случится» - приемлемое снижение; важно записать текущее мышление по вопросу в самый раз). Убедитесь, что ваши проблемы записаны как риски. Риски должны регулярно пересматриваться; Скорее всего, мало кто придет к вашей точке зрения задолго до того, как на самом деле случится кризис, и анализ рисков будет действовать как "OMG , который случается»; мы были бы безумны, чтобы продолжать как этот «катализатор». В долгосрочной перспективе бумажный след является полезным доказательством того, чтобы сказать: «Смотрите, у нас здесь есть институциональная проблема» и получить отношение к дизайну или что-то изменилось.

Как реализовать ваши идеи?

Сначала на встречах относитесь к проблемам как к проблемам. Вы исправляете проблемы, вы преодолеваете проблемы. Проблемы - это хорошие вещи, проблемы - нет.

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

• Разработать три одинаковых, но разных подхода
• Скажите своему боссу, что вам нужна его помощь
• Объясните, что вы не уверены, какой из трех методов является наилучшим способом решения проблемы
• Попросите Его / Ее помочь вам выбрать один из трех

1. Это очень сильно. Вы делаете выбор, а не ультиматум. Ультиматумы чаще всего не сбивают, потому что это не их идея и есть только один вариант.

2. Ваше использование слов очень важно здесь. « Мне нужна твоя помощь ».

3. Пусть босс выберет «A», «B» или «C». Фактически, пусть босс создаст опцию «D», вытянув секции из «A», «B» и «C». То, что вы делаете, позволяет вашему боссу сделать выбор.

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

У Proof of Conceptвашей идеи реализованы. Если вы покажете своей команде что-то работающее и решающее текущую проблему, то им это понравится.