У меня есть 2 дня, чтобы принять очень серьезное решение об инструментах и платформах, которые моя компания собирается использовать для переноса своего приложения WPF на Linux / Android / iOS и так далее.
Очевидно, я могу указать своим старшим, что двух дней вряд ли хватит на чтение обо всех возможных вариантах, а также на попытку, создание прототипов и т. Д. Я могу сказать, что это мне немного не поможет, у меня есть 2 дня, и через 2 дня решение будет принято. Период.
С одной стороны, я разочарован, с другой стороны, я думаю, что в этом подходе есть доля правды, в противном случае я могу легко оказаться под десятками загруженных SDK, фреймворков, API, статей в блогах и т. Д., Выполняя тесты, выполняя примеры и забывая в процессе, для чего все это было.
Тем не менее, я боюсь, что неправильное решение дорого обойдется компании. Так что, по вашему мнению, является «идеальным» процессом для принятия таких решений?
Ответы:
Если все, что у вас есть, это 2 дня, и у вас нет времени на создание прототипа или даже на чтение всех альтернатив, то на самом деле есть только 2 варианта:
спросите кого-то, кто знает и последует их совету. Это может не обязательно означать, что нужно спросить человека, но потратить 2 дня на поиск в блогах и статьях, чтобы найти достаточно информации, чтобы принять решение немного лучше, чем неосведомленное.
Сделайте небольшое исследование всех основных вариантов, а затем выберите один. Иногда лидерство означает не бояться принять неправильное решение, зачастую важнее принять твердое решение, чем колебаться.
Вы можете укрыться, придумав архитектуру, которая более отделена и, следовательно, легче изменить - например, модель клиент / сервер позволит вам заменить вашу технологию пользовательского интерфейса на другую с минимальным нарушением работы.
источник
Может показаться, что я иду против течения, но я недавно прочитал книгу Эд Кэтмулла « Creativity, Inc. », и там был действительно хороший параграф, посвященный этой ситуации:
Я уверен, что это применимо и к вашей ситуации. Может быть, вы можете принять решение сегодня, выбрав один и начать работать над ним. Если это сработает, у вас будет что-то готовое за эти два дня, и вы скажете: «Я выбрал это, и я могу показать вам, что мы можем с этим сделать, потому что я провел несколько тестов ...». Если через день вы заметите, что выбранное решение совершенно не стоит, вы можете выбрать другое и поработать с ним на следующий день. В худшем случае вы будете использовать оба дня для тестирования двух платформ, обнаружив, что ни одна из них не работает - но это в конечном итоге правильный ответ, не так ли? Уберите травку, избавьтесь от неправильных возможных решений, поэтому любое следующее решение будет намного лучше предыдущего. В лучшем случае вы
Очевидно, что через два дня вы не овладеете какой-либо платформой, но, выбрав одну из них как можно скорее, вы получите лучшее представление о том, как она работает (гораздо больше, чем просто читаете об этом), и вы получите лучший ответ.
источник
gbjbaanb делает очень хорошие замечания. Я просто думал, что добавлю немного.
Очевидно, вам не хватает времени, чтобы принять совершенно обоснованное решение. Ваш единственный вариант - попытаться принять решение, которое минимизирует боль в будущем. Я бы предложил:
Четко документируйте природу ситуации: отправьте электронное письмо своим менеджерам (менеджерам) и CC их менеджерам и заинтересованным сторонам. Объясните, что проблема, которую вы назначили, довольно сложная, но вы готовы приложить все усилия. Но обратите внимание, что, учитывая строгие временные ограничения, вы не можете гарантировать, что ваши результаты будут оптимальными.
Найдите платформу / платформу с большим и активным онлайн-сообществом. Последнее, что вы хотите, это застрять в отладке неясной платформы в одиночку.
Как уже упоминалось ранее, gbjbaanb уменьшит ваши трудности и риски при переносе, используя слабосвязанную архитектуру. Если с одним из выбранных вами технологий все станет грушевидным, это облегчит его замену.
Я был в вашей ситуации раньше, и это в конечном итоге превратилось в политический кошмар. Когда система волшебным образом не работала, люди начали указывать пальцами, и все стало ужасно. Вот почему моя рекомендация № 1 - четко документировать, что вы сделали все возможное, несмотря на невероятные шансы .
Удачи :)
источник
Поскольку они фактически дали вам мало времени, чтобы делать больше, чем просто выбирать кандидатов, я бы выбрал следующий подход.
Выберите технологии, которые:
По определению, это исключило бы любую передовую технологию, какой бы хорошей она ни была.
Кроме того, не поддавайтесь желанию использовать технологию X без дальнейшего анализа просто потому, что Фред разработчик использовал ее в прошлом. Маловероятно, что он идеально подойдет, и если Фред перейдет на более экологичные пастбища, то это ваш эксперт по предметной области.
источник
2 дня - это очень короткий период для принятия такого рода решения, но, поскольку вы должны сделать это в течение 2 дней после списка,
Теперь вам нужно найти альтернативы, которые вы можете использовать для всех целевых сред
Для каждой альтернативы найдите поддержку для каждого, чтобы использовать возможности подключения / безопасности, которые использует текущее приложение.
Затем для каждого пользовательского / стороннего компонента выясните, существуют ли простые в использовании альтернативы для каждого.
А затем подумайте, как можно сделать распределение для каждой найденной альтернативы.
Я думаю, что в течение 2 дней это должно быть охватом, который вы сможете охватить, и на основе результатов вы сможете найти решение.
источник
Как бы мне ни нравилось изучать и экспериментировать с новыми вещами, при нехватке времени лучший вариант - всегда делать то, что удобнее или удобнее для работы. Придерживайтесь того, что вы знаете.
Даже если в долгосрочной перспективе станет ясно, что вы не выбрали лучший вариант, все, что вы разработали, тем не менее, остается ценным и оборачивается неким полевым знанием, которое все еще можно использовать и переносить. И это именно потому, что удобный контекст, инструменты, платформа, которую вы выбрали, остаются в стороне и заставляют вас увидеть, что действительно важно.
источник
Составьте список факторов, которые следует учитывать при выборе, таких как: безопасность производительности, стоимость, простота использования, возможность X, возможность познакомиться с разработчиком и т.д.
Это должно занять менее часа (на самом деле это должно занять менее 15 минут), затем сядьте на руководство и предложите им расставить приоритеты по этим факторам. (Вероятность того, что их приоритеты и ваши совпадают, невелика, хотя вы можете в какой-то мере руководить их выбором, предлагая приоритеты.) Теперь вы знаете, что оценивать в отношении технологии.
Выберите три или четыре общих решения вашей проблемы на основе поиска в Интернете.
Затем прочитайте достаточно, чтобы сделать правильное предположение о том, насколько хорошо каждый из вариантов соответствует их основным 3-4 приоритетам. Присвойте числовое значение каждому выбору. Сделайте математику, умножив оценку каждого времени приоритета на значение, установленное для этого приоритета (10 для номера 1, 8 для номера 2, 6 для номера 3 4 для номера 4 или что угодно, что вам больше нравится). Теперь у вас есть числовая оценка для каждой возможности. Как правило, будет очевидно, что лучше всего соответствует поставленным приоритетам. Более того, теперь у вас есть что-то аналитическое, чтобы доказать свой выбор. Они обычно выкупают на ваш выбор, потому что у вас есть номера, чтобы поддержать его. Если числа не поддерживают это, вам нужно спросить себя, почему вы предпочитаете другое, или либо выбрать лучший из числовых, либо вернуться к назначенным номерам.
Концентрируясь на том, какие настоящие приматы вы выберете, вы можете сэкономить много времени на исследования. Вы, вероятно, сможете сделать предположение в течение дня, а затем у вас останется день, чтобы воспользоваться двумя лучшими возможностями, при необходимости загрузить пробные версии и поиграть с ними.
источник