Как сохранить молодой и умирающий проект?

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

• Владелец (нетехнический)
  • Руководитель проекта (нетехнический)
    • Ведущий разработчик (технический, но плохой в этом)

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

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

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

Никто в команде не знает, каково будет мнение Владельцев, но все боятся делать волны в этой экономике (особенно я).

Что бы вы сделали?

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

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

Если это не летит, то иди к владельцу. Владелец - парень денег, но он очень быстро сможет увидеть медленный сайт, который никто не посетит == нет денег. Создайте ту же демонстрацию, и перед загрузкой первой страницы он должен будет позвонить ОБОЕМ PM и Lead на своем более удобном ковре.

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

Предполагая, что ваши заявления точны, у вас есть ведущий разработчик, который некомпетентен, и менеджер проекта, который некомпетентен (по крайней мере, в той степени, в которой он не может оценить навыки команды). Хорошо. У вас есть те же возможности, что и у разработчиков в каждой команде по всему миру.

1. Работаете ли вы, не заботясь о здоровье компании.

2. Ищите работу в другом месте.

3. Делайте разумные предложения Ведущему, Премьер-министру и Владельцу и надейтесь, что они будут приняты

Вы можете сделать любую комбинацию из вышеперечисленного одновременно.

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

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

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

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

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

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

Надеюсь, это поможет!

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

Прежде всего, я настоятельно рекомендую вам убедиться в том, что это проблема архитектуры приложения, а не проблема конфигурации VPN. Я видел, что плохо настроенные VPN вызывают именно эту проблему. Знаете ли вы наверняка, что приложение работает медленно в офисе?

Если вы исключили сеть, я бы согласился с предложением KiethS и попросил премьер-министра открыть страницу.

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

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

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

Удостоверьтесь, что вы документируете каждый шаг.

В техническом плане я согласен с предложениями выше. С другой стороны, я чувствую, что это скорее вопрос отношений, нежели технический.

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

Если это не работает, вы можете попробовать поговорить с личкой, а затем с владельцем.

Если ничего не работает, я предлагаю вам поискать новую работу.

Честность - и столько такта, сколько вы можете собрать.

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

Если вы не делаете несколько волн, вы, вероятно, мертвы в воде.

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

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

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

Настоящие мужчины говорят без обид и эмоций. Это хитрость.

Единственная уважительная причина, по которой кто-то может быть с вами недоволен, это то, что вы обижены:

У ВЕДУЩЕГО РАЗРАБОТЧИКА НЕТ НИКАКОГО КЛИЕНТА, ЧТО ЕГО ДЕЛАЕТ Я знал, что это должно было случиться, но никто не слушал меня, бла-бла-бла.

в то время как

Модель кода неверна, потому что ее сложно поддерживать и она медленная. Мы должны быть стратегически настроены в этом направлении и решить эти две проблемы.

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

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

Не считайте меня ответственным за то, что я не несу ответственности за реализацию. Я просто честен.