Как принимать важные технические решения за минимальное время


36

У меня есть 2 дня, чтобы принять очень серьезное решение об инструментах и ​​платформах, которые моя компания собирается использовать для переноса своего приложения WPF на Linux / Android / iOS и так далее.

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

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

Тем не менее, я боюсь, что неправильное решение дорого обойдется компании. Так что, по вашему мнению, является «идеальным» процессом для принятия таких решений?


4
Напишите где-нибудь, что решение практически невозможно принять за два дня. Затем попытайтесь принять не слишком плохое решение и запишите, что ваше решение не самое лучшее. Другими словами, прикрыть свою задницу. Qt5 может быть рассмотрено. Или сделайте ваш продукт веб-приложением HTML5 (возможно, с использованием некоторой библиотеки HTTP-сервера, например, libonion или FastCGI)
Basile Starynkevitch,

2
@gnat Я не согласен, что это субъективный вопрос, даже если есть более одного возможного ответа, но мы все можем извлечь из опыта других.
Flot2011

9
Во многих случаях нет «лучшего варианта», вы можете написать его как PHP-приложение, и оно будет работать. Или вы можете написать это как программу Qt, и она будет работать. Это может быть интерфейс с игровым интерфейсом openGL. Все это приемлемые варианты, трюк состоит в том, чтобы выбрать один, а затем приступить к его работе. Не парализуйте себя сомнениями, если вы что-то выбрали.
gbjbaanb

5
Очень плохой пример, потому что в случае примера есть одна технология, которая является очевидным выбором для этого - Xamarin. Сохраните код .NET, просто замените интерфейс на что-нибудь. Обрабатывает все данные случаи. Итак, это скорее случай «я ничего не знаю о кроссплатформенных системах для .NET».
TomTom

7
Сказать, что двух дней недостаточно, не очень конструктивно. 3 дня будет достаточно? Или вы действительно хотите потратить 2 месяца на это? И насколько лучше будет ваше решение? ~~~~ Если вы говорите, что вам нужна неделя и уверены, что это легко сэкономит сотни часов времени на разработку, обязательно упомяните об этом. Это может не помочь, но всегда есть шанс, что заинтересованным сторонам понравится ваш бизнес.
Деннис Джаэруддин

Ответы:


48

Если все, что у вас есть, это 2 дня, и у вас нет времени на создание прототипа или даже на чтение всех альтернатив, то на самом деле есть только 2 варианта:

  1. спросите кого-то, кто знает и последует их совету. Это может не обязательно означать, что нужно спросить человека, но потратить 2 дня на поиск в блогах и статьях, чтобы найти достаточно информации, чтобы принять решение немного лучше, чем неосведомленное.

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

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


10
+1 за «не бойся принять неправильное решение» Иногда оказаться втянутым в «паралич анализа» хуже, чем вообще не принимать решения. Мы все люди. Делай все возможное и жить дальше.
2006 года

1
колебаться: чередовать или колебаться между различными мнениями или действиями; быть нерешительным.
TankorSmash

10
+1 за «прикрыть себя, придумав архитектуру, которая более отделена и, следовательно, легче изменить»
Дарт Egregious

2
@emodendroket Windows Workflow Foundation.
MetaFight

2
Если ваша проблема не является основной, не ожидайте, что основные решения будут работать хорошо. Это где разъединение и гибкость имеет решающее значение . Ищите фреймворки / библиотеки, которые позволяют легко заниматься своими делами, вместо того, чтобы заставлять вас что-то подкреплять их ожиданиями, когда они, кажется, не ожидали того, что вам нужно делать.
jpmc26

19

Может показаться, что я иду против течения, но я недавно прочитал книгу Эд Кэтмулла « Creativity, Inc. », и там был действительно хороший параграф, посвященный этой ситуации:

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

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

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


12
Хотя я согласен с вами на глобальном уровне, иногда спешить на военное поле довольно самоубийственно.
Flot2011

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

6
@ Flot2011, хотя, если у вас есть степень магистра делового администрирования, вы остаетесь там, где вы есть, и отправляете все свои войска для сражения на любом холме. Если они все умрут, да ладно, вы получите больше войск и продолжите, но на этот раз говорите, что ваш опыт в целом делает вас намного более ... заслуживающими чудовищно большей зарплаты.
gbjbaanb

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

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

10

gbjbaanb делает очень хорошие замечания. Я просто думал, что добавлю немного.

Очевидно, вам не хватает времени, чтобы принять совершенно обоснованное решение. Ваш единственный вариант - попытаться принять решение, которое минимизирует боль в будущем. Я бы предложил:

  1. Четко документируйте природу ситуации: отправьте электронное письмо своим менеджерам (менеджерам) и CC их менеджерам и заинтересованным сторонам. Объясните, что проблема, которую вы назначили, довольно сложная, но вы готовы приложить все усилия. Но обратите внимание, что, учитывая строгие временные ограничения, вы не можете гарантировать, что ваши результаты будут оптимальными.

  2. Найдите платформу / платформу с большим и активным онлайн-сообществом. Последнее, что вы хотите, это застрять в отладке неясной платформы в одиночку.

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

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

Удачи :)


17
Re: # 1. Никому не нравится плаксивый неудачник, поэтому просто подчеркните, что вы сделали все возможное, чтобы справиться с невозможными обстоятельствами, а затем вы выглядите как энергичный победитель, играющий в команде! Управлению нравятся такие вещи. Между прочим, есть много причин, по которым большая перезапись не работает, выбор одной технологии над другой обычно является наименьшей проблемой.
gbjbaanb

Да, я понял, что это было немного плаксивым, поэтому я изменил его.
MetaFight

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

3
Вместо этого я бы определил конкретные риски и перевел бы их на управление. Например: «Исходя из наших текущих знаний, мы считаем, что технология A является лучшим выбором. Однако из-за короткого срока мы не смогли проверить, может ли этот подход справиться с ожидаемой рабочей нагрузкой этой системы». Затем руководство может либо принять риск, либо уменьшить его, заказав дальнейший анализ.
меритон - забастовка

+1 за точку № 2. Выберите решение, за которым стоит зрелое и хорошо развитое сообщество. Если вам подходит более одного такого решения, вы всегда можете просматривать онлайн-форумы, блоги, оставлять вопросы и т. Д. И выяснять, какое вам подходит. лучший
Арнаб Бхагабати

5

Поскольку они фактически дали вам мало времени, чтобы делать больше, чем просто выбирать кандидатов, я бы выбрал следующий подход.

Выберите технологии, которые:

  • Иметь большую базу пользователей
  • Иметь активную поддержку (по любым каналам)
  • Активно развиваются

По определению, это исключило бы любую передовую технологию, какой бы хорошей она ни была.

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


Хотя, если технология X достаточно хорошо подходит, и Фред хочет обучить других разработчиков, это может стать хорошим способом дать толчок команде.
CVN

Конечно - если это помечает другие поля ...
Робби Ди

4

2 дня - это очень короткий период для принятия такого рода решения, но, поскольку вы должны сделать это в течение 2 дней после списка,

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

Теперь вам нужно найти альтернативы, которые вы можете использовать для всех целевых сред

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

Затем для каждого пользовательского / стороннего компонента выясните, существуют ли простые в использовании альтернативы для каждого.

А затем подумайте, как можно сделать распределение для каждой найденной альтернативы.

Я думаю, что в течение 2 дней это должно быть охватом, который вы сможете охватить, и на основе результатов вы сможете найти решение.


4

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

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


2

Составьте список факторов, которые следует учитывать при выборе, таких как: безопасность производительности, стоимость, простота использования, возможность X, возможность познакомиться с разработчиком и т.д.

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

Выберите три или четыре общих решения вашей проблемы на основе поиска в Интернете.

Затем прочитайте достаточно, чтобы сделать правильное предположение о том, насколько хорошо каждый из вариантов соответствует их основным 3-4 приоритетам. Присвойте числовое значение каждому выбору. Сделайте математику, умножив оценку каждого времени приоритета на значение, установленное для этого приоритета (10 для номера 1, 8 для номера 2, 6 для номера 3 4 для номера 4 или что угодно, что вам больше нравится). Теперь у вас есть числовая оценка для каждой возможности. Как правило, будет очевидно, что лучше всего соответствует поставленным приоритетам. Более того, теперь у вас есть что-то аналитическое, чтобы доказать свой выбор. Они обычно выкупают на ваш выбор, потому что у вас есть номера, чтобы поддержать его. Если числа не поддерживают это, вам нужно спросить себя, почему вы предпочитаете другое, или либо выбрать лучший из числовых, либо вернуться к назначенным номерам.

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


То, что вы описали, называется «Процесс аналитической иерархии». Это самая распространенная техника, которую я когда-либо использовал для проведения торговых исследований. Его сила в том, что он помогает выбрать оптимальный вариант достаточно объективно и учитывает мнения всех заинтересованных сторон. Я был удивлен, увидев, насколько сложные сайты делают эту технику кажущейся. Не позволяйте очевидной сложности, демонстрируемой веб-сайтами, повлиять на вас, она действительно очень проста в использовании. В любом случае, поскольку я не смог найти хороший пример, я полагаю, что Википедия является такой же хорошей отправной точкой, как и любой en.wikipedia.org/wiki/Analytic_hierarchy_process .
Данк


Это действительно так просто. Мы также проводим опросы, в которых каждый присваивает значение каждой категории, чтобы определить, что все считают наиболее важным, чтобы мы могли применять весовые коэффициенты к каждой категории. В конце концов, команда разработчиков считает, что скорость процессора и память всегда являются приоритетными, но парни из аппаратного обеспечения, похоже, придерживаются противоположных мнений, потому что для них важно время автономной работы. Конечно, клиент, как правило, учитывает как минимум половину веса рейтинга и не заботится о проблемах программного или аппаратного обеспечения. Описания онлайн кажутся действительно сложными, когда это не так.
Данк
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.