Как да вземем ефективни решения чрез сравняване на алтернативи

Снимка от rawpixel в Unsplash

Не по-добре, не по-лошо ... просто различно

„React.js е толкова по-добър от Angular“. „Java е гадно, никой вече не го използва… ние трябва да използваме Golang“. „Ананасът е най-лошият гарнитура за пица“. Вероятно сте чували едно от тези много прави мнения. Единият вариант е най-добрият, другият е най-лошият, X е по-добър от Y и т.н. Но Java все още е един от най-популярните езици в света. Angular дава приличен бой на React.js. Пица с ананас ... е, това е Ewwww.

Означава ли това, че повече от половината от хората са непознати? Или не знаем как да кажем коя технология е по-добра или да направим правилния избор? Може би трябва да спрем да използваме термини като „по-добър“, „по-лош“, „най-добър“ и плитки сравнения, когато оценяваме алтернативите. Вместо това трябва да се съсредоточим върху предимствата на всяко решение, недостатъците и кое от тях е по-подходящо за нашия конкретен проблем.

Оценка на алтернативи

Един от начините да направите това е чрез създаване на таблица за сравнение на алтернативи:

  • Напишете различните алтернативи в заглавката. Използвайте всяка колона, за да оцените една алтернатива. Изберете 2–5 алтернативи.
  • Напишете различните свойства, които смятате за важни за оценка на различните алтернативи. Изберете 2–5 най-важни свойства за сравнение.
  • Запазете последния ред за обобщаване. Няма по-добро / по-лошо решение, съсредоточете се върху това защо всяка алтернатива решава проблема.

„На какво трябва да вярвате, за да изберете този подход?“

Например, нека приемем, че имаме проблем, който може да бъде решен по два начина. Единият е S.O.L.I.D, а другият е хакерски. Някои биха могли да кажат, че винаги трябва да използваме решение на S.O.L.I.D, независимо от обстоятелствата. Това означава ли, че всеки, който използва хаки код, е лош разработчик? Съмнявам се.

Нека сложим алтернативите в таблица:

След като съставим тази таблица, можем да се съсредоточим върху долната линия и да я свържем директно към нашата цел.

Пример за случаи на „доставка възможно най-бързо и сме добре с компромиси с бъдещото качество“ може да бъде:

  • Тежка грешка, която съществува в системата. Всеки ден, който преминава без решение, може да причини дълготрайни щети.
  • Имаме договор с клиент за доставка на решението на конкретна дата. Ако пропуснем крайния срок, може да има правни последици.
  • Компанията има проблеми с паричните потоци. Предоставянето на решението рано може да има огромно влияние върху стабилността на нашия бизнес.

Както можете да видите, използването на S.O.L.I.D не винаги е по-добрият подход. Ако ни интересува качеството на кода, определено трябва да го подразбираме, но трябва да сме сигурни, че знаем компромиси. Изберете едно решение над другото, защото вярвате, че това е най-добрият път за постигане на вашите цели. Не го правете само защото чичо Боб или някой от вашата компания каза, че е по-добре.

Не правете отзиви само за да получите „печат“

Снимка на Hello Lightbulb на Unsplash

В много компании прегледите (дизайнерски ревюта, прегледи на продукти и т.н.) имат същия ритуал. Собственикът на функцията пише спецификацията. Тогава техният мениджър го преглежда. Групата насрочва среща за преглед на спец. Повече от веднъж има чувството, че целта на тези срещи е да получат печат от заинтересованите страни, а не да участват в открита дискусия. Причините, поради които това може да се случи:

  • Ако вече имате готова спецификация, защо ще ви трябват 7 или повече души, които да се съберат в една стая и да я „преодолеят“?
  • Срещите обикновено са скучни и могат да се превърнат в монолог, когато собственикът на функцията чете спецификациите, които са написали.
  • Понякога тези срещи са склонни към изнизване. Разговорът може да се съсредоточи върху неща, които не са от решаващо значение за успеха на функцията („защо използваме int32, а не int16?“, „Струни или enums?“, „Раздели или интервали?“).
  • Някои хора са по-интровертни от други. Чуват ли се всички гласове или има само няколко души, които участват в разговора?
  • Разговорът по някои подробности може да отнеме повече от очакваното. След това изтича време, преди собственикът на функцията да може да покрие цялата спецификация, понякога дори и по-малко от половината от нея. Това може да е разочароващо. Освен това, ако се изисква последваща среща, тя също може да отложи вземането на решения и целия график на проекта.

Бъдете подготвени с алтернативи и цели, а не с решението

В настоящата ми компания ние предприемаме различен подход. Прегледите се правят офлайн, като се използва Paper (ползват се от неговите функции като споделяне, коментари, задачи, което прави сътрудничеството по-ефективно). Всеки друг онлайн редактор може да работи.

За дизайнерските срещи използваме различен шаблон. Лицето, което взема решение, избира 3–4 най-важни отворени въпроса, които са от решаващо значение за успеха на функцията. След това съставят алтернативна таблица, каквато видяхме преди. Те също могат да препоръчат алтернатива, но не трябва да бъдем много уверени в това. Целта на срещата е да се избере подходящият подход въз основа на целите на проекта.

След това срещата се превръща от монолог, който е фокусиран върху „щамповането“ на решение на открит разговор за най-добрия подход. Публиката се превръща от одобряващи в съветници. Собственикът на функцията не е необходимо да „защитава“ избраното от тях решение. Превръща се в вземащ решение, който решението си се основава на съветите на заинтересованите страни. Като зададете време (10–15 минути) за всеки въпрос, можете да сте сигурни, че покривате всички открити въпроси. Решение се взема от собственика на функцията, когато времето изтече.

Да се ​​уверим, че гласът на всеки е чут, дори и интровертите, е също толкова лесно, колкото „Хей Джейн, не сме чули вашето мнение, коя опция смятате, че ще служи на нашите цели? X, Y или Z? "

Затова следващия път, когато искате да сравните две или повече алтернативи, заменете „React.js е по-добър от Angular“ с „React.js е по-лесен за учене, по-гъвкав и се актуализира по-често, така че ако се стремим бързо да увеличите новите инженери и да се движим по-бързо с най-добрите технологии, това трябва да бъде изборът ни между тези две “.

Що се отнася до „Ананасът е най-лошият гарнитура за пица“ - може би някои неща не трябва да имат алтернативи.

Благодарим ви, че отделихте 4 минути от вашето време до следващия път.

-Alon

Специални благодарности на:

  • Ерик Сух, който заложи на създаването на процеса на инженерни прегледи в Dropbox
  • Pierpaolo Baccichet, Steve Eisner, Gal Zellermayer, James Cowling и Devdatta Akhawe, всички от които дадоха ценни отзиви, както като ранни тестери на процеса, така и като рецензенти
  • Rina Artstain & Keren за корекция, преглед на тази статия и предоставяне на страхотни технически отзиви