Наскільки ефективно «продати» хороший дизайн на великих зустрічах

Я багато разів був свідком сумної трагедії. Ось що відбувається:

1. Огляд дизайну команди для нового проекту.
2. Я бачу просту конструкцію, яка має досить багато отворів.
3. Я випадково згадую дірки та способи їх уникнути.
4. Попередження ігноруються коментарями типу "що" ніколи не трапляється в реальному житті "
5. Врешті-решт відбудуться речі, які "ніколи не трапляться"
6. Огляд дизайну аварійної команди для зламаного проекту.

То що мені робити? Усунення "я тобі сказав" ставлення не збирається завойовувати друзів та впливати на людей. Іноді роки проходять, і коментарі з кроку 3 все одно забуті. Я точно не хочу бути дратівливим шкідником, що нагадує світ готчей. Я часто сиджу спиною і спостерігаю, як «Титанік» пливе до Європи.

Прикро бачити, як погані конструкції рухаються вперед. Це також засмучує те, що я не можу переконати інших у певній небезпеці поточного шляху. Я найгірше на зборах команди, де кожен має різні способи розуміння різних термінів. Також егоїсти, як правило, перемагають розум та думку. Я шукаю хорошої тактики, щоб переконати людей у ​​групі використовувати нові та складні ідеї.

По можливості запропонуйте зміни, які не додадуть значного часу проекту. Спробуйте і підкресліть, що якщо це не зробити зараз, то перепрацювати пізніше буде набагато болісніше. Буде складніше, якщо ви намагатиметесь переконати свою команду, що повністю новий напрямок краще, тому що це, ймовірно, затримає проект тощо.

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

Це дійсно допомагає мати повагу інших розробників. Якщо ви новий хлопець у команді, я думаю, що ви SOL. Тож просто складіть репутацію команди та дійсно намагайтеся вийти на рівень, якби вас не звільнили з місця. Звичайно, якщо ви завжди песимістичні речі, то вас просто позначають як "негативного" хлопця.

Що стосується простих матеріалів (тобто не впливає на графіки), обов'язково робіть свою роботу найкращим чином. Якщо ви докладете зусиль до негайного виводу (наприклад, побудови тестових випадків або отримання простих (але крутих) функцій), з часом інші люди помітять, що ваш код працює надійно і витримує перевірку часом. Коли ви почнете демонструвати їм кілька акуратних хитрощів з кодом, вони подумають двічі збити вас перед усіма.

Нарешті, я погоджуюся, що ви не хочете виконувати рутину "я вам це сказав", але не забудьте спробувати підказати вашому начальнику / технічному керівництву, коли виявиться, що ви насправді мали рацію. Можливо, надішліть старий електронний лист зі своїми старими коментарями. Запитайте їх, чи це допоможе вирішити "нову" проблему. Якщо ви цього не зробите, вони навіть не згадають, що саме ви виховували це вперше. Врешті-решт вони отримають натяк на те, що ти не просто намагаєшся бути шолом на зустрічах. Наступного разу вони двічі подумають про те, щоб збити вас, особливо якщо це обійдеться тим, що ваш "старий" дизайн замінює поточний зламаний.

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

Люди збожеволіють у громадах. Згадайте про свої занепокоєння щодо ключової людини поза наради. Вони вважають це менш загрозливим і можуть зайняти час, щоб почути ваш аргумент, а не думати про їх захист дизайну. Вони також можуть зайняти більше часу, щоб пояснити вам обставини, чому ви можете мати дійсну точку, але це не представляється можливим звертатися до версії v1.0.

Ключ! Зайдіть на засідання, щоб повністю зрозуміти, яка програма вашого прямого керівника. Можливо, вони розглядають це як незначний проект, і останнє, що їм потрібно на зустрічі, - це найсайєр, який відбирає час від важливіших питань. Попросіть їх допомогти вам.

Якщо ви хочете впливати на них, поговоріть з ними про це поза межами наради дизайну. Інакше вони просто думають, що ви намагаєтесь "набрати очки" від них. Дуже багато людей ніколи не хочуть реально обговорювати зустрічі з "аудиторією".

Я не бачу, як ця ситуація сильно відрізняється від самотнього розробника з неосвіченим босом. На жаль, я втратила підрахунок кількості разів, коли мене переконували будувати проект певним чином і відправляти його, незважаючи на мої застереження про майбутню приреченість. Це залишає вас не лише будівництвом, але й запливте поговорний Титанік прямо в айсберг.

Так само, як ви описували, коли шматочки потрапили у пословичне відро, мої застереження вже давно були забуті. Іноді (на щастя для мене) справи йшли поганими місяцями або більше після того, як я більше не брав участь у проекті. На жаль, це залишило мого наступника думкою, що я повинен бути божевільним, оскільки можна обзавестись, що начальник заперечив будь-яку руку в цьому :)

У всякому разі, група «переконаними» програмістів може бути настільки ж неосвічені загостреними волосся боса, іноді навіть більше , тому що вони впевнено неосвічений, як і згадує Джефф O . Коли це станеться, у вас є достатньо часу, щоб виправити речі. Не намагайтеся зробити так, щоб єдиний голос розуму був почутий над колективним пердетом мозку. Якщо ви можете це зробити ефективно, ваше місце знаходиться в конгресі, а не за столом програмного забезпечення для написання.

Оскільки дії говорять голосніше, ніж слова, ви можете:

• Покажіть (з тестовими сценаріями), чому дизайн не вийде за звичайних обставин. Це, ймовірно, призведе до меншої зустрічі, де ви представителя, і це, мабуть, все, що вам потрібно буде почути.

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

• Повторіть останній проект, який вимагав заздалегідь переписати за тиждень до того, як його мали поставити.

Іншими словами, перший крок, незалежно від того, що ви робите, - це мати справу з людьми або (набагато) меншою групою. Якщо ваші занепокоєння дійсно справедливі, я впевнений, що вони будуть краще отримувати тиждень-два в розробці. Просто, як ви зазначали, уникайте позиції "я вам це сказав".

Якщо можливо, перегляньте дизайн перед (або навіть після) зустрічі та поговоріть із дизайнерами приватно. Збивайте людей на зустрічі перед усіма своїми колегами, як правило, змушуйте їх негайно захищатись і з упевненістю ставитись до ваших пропозицій, і це може призвести до репутації "винищувача проблем", навіть якщо ви думаєте, що ви корисні.

Хороший (але часто важкий) спосіб висловити "критику" - це задавати провідні питання - нехай інша людина спробує відповісти на ваше запитання і усвідомити для себе недолік. Тоді це здається набагато більше схожим на їхню власну ідею, і вони будуть швидше сприймати її вперед. Знову ж таки, це найкраще працює в приватних дискусіях, але може бути більш дипломатичним та ефективним шляхом вперед у ситуації зустрічі (Примітка. Намагайтеся уникати аргументів або тривалої дискусії, щоб переконати людей у ​​зустрічі. Просто переконайтесь у цій ідеї та спробуйте Можливо, краще відмовитися від цього, а потім поспілкуватися з дизайнерами після зустрічі, щоб "прояснити щось, що я не зовсім зрозумів", ніж бути "хлопцем, який зробив просту 30 хвилин зустріч витрачати цілий ранок ")

Інший підхід - надіслати свої пропозиції (дипломатично) електронному листу головному дизайнеру (або відповідному, але невеликому списку розповсюдження). Це може допомогти розглянути ваші ідеї, а також надасть вам «паперовий слід» для підтримки будь-якої ситуації «Я тобі це сказав» у майбутньому (якщо справи йдуть у формі груші, у вас, принаймні, є доказ того, що ви намагалися допомогти, але були Але якщо справи стають такими поганими, ви, ймовірно, не працюєте в потрібній компанії)

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

Зустрівшись із сценарієм "що ніколи не відбудеться", пригадай їм усі часи минулого, коли їм доводилося виправляти ті пункти, "які ніколи не трапляться". Але ти повинен бути обережним, щоб не натрапити на те, як "я тобі це сказав". Я вважаю, що найефективніше вирішувати минулі проблеми (і як дорого і боляче їх було виправити), обговорюючи, чому ви вважаєте, що ми повинні зробити щось для цього проекту, як приклади того, чому ви вважаєте це важливим, перш ніж вони принесуть "те, що ніколи не станеться »цитата.

Я думаю, що, можливо, вашою проблемою є те, що ви кажете, що ви випадково згадуєте спосіб уникнути проблеми. Можливо, вам слід озброїтися більшою кількістю інформації та показати їм детальніше, чому це ризик для системи. Іноді це означає підняти тему на другій зустрічі після того, як ви встигли зробити невелике дослідження. Побудуйте діловий випадок для того, як дешево це зробити зараз, пороку того, як дорого це зробити пізніше.

Здається, що найкраща ставка - працювати над тим, щоб потрапити на лідируючу позицію команди. Скористайтеся цими можливостями, щоб вказати на сили, які ви бачили, що це відбулося, і цього можна було уникнути. У цьому вам не потрібно буде продавати свою команду.

Здається, "випадковий" у "випадково згадує дірки" є проблемою. Спробуйте використати (або внести, якщо його немає) якийсь списаний процес для аналізу ризиків проекту. Зазвичай результатом зустрічі з аналізу ризиків є проста таблиця з двома стовпцями: ризик і те, що узгоджена стратегія зменшення ризику ("ми думаємо, що ніколи не трапляється") є прийнятним пом'якшенням; важливо - записати поточне мислення на цей час). Переконайтеся, що ваші проблеми фіксуються як ризики. Ризики слід регулярно переглядати; Швидше за все, небагато людей зіткнуться з вашою точкою зору задовго до того, як криза насправді відбудеться, і перегляд ризиків діятиме як "OMG, що все-таки відбудеться"; ми були б божевільні продовжувати подібний каталізатор. Більш тривалий термін, паперовий слід є корисним свідченням для того, щоб сказати, "дивись, ми маємо тут інституційну проблему" та отримати ставлення до дизайну чи чогось іншого змінити.

Як реалізувати свої ідеї

По-перше, на зустрічах називають проблеми проблемами. Ви виправляєте проблеми, долаєте виклики. Виклики - це хороші речі, проблеми - ні.

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

• Розробити три подібних, але різних підходи
• Скажіть своєму начальникові, що вам потрібна його допомога в чомусь
• Поясніть, що ви не впевнені, який із трьох методів є найкращим способом дій для вирішення проблеми
• Попросіть Його / Її допомогти вибрати один із трьох

1. Це надзвичайно потужно. Те, що ви робите, - це вибір, а не ультиматум. Ультиматуми частіше тоді не збиваються, бо це не їх ідея, і існує лише один варіант.

2. Вживання ваших слів тут дуже важливе. " Мені потрібна ваша допомога ".

3. Нехай начальник вибере "А", "В" або "С". Фактично дозвольте начальнику створити варіант "D", витягнувши розділи з "A", "B" і "C". Що ви робите, це дозволяти вашому начальникові робити вибір.

У цей момент ви могли б менше піклуватися, який варіант він обере, адже це всі ваші ідеї. Він подумає, що насправді вирішує проблему, тому що ти дозволиш, щоб рішення стало його.

У Proof of Conceptвашій ідеї реалізовані. Якщо ви покажете своїй команді щось працює і вирішує поточну проблему під рукою, то їм це сподобається.