PM выбрал слишком сложную установку, с которой никто не сталкивался [закрыто]

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

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

Как только мы оказались на полпути к проекту, премьер-министр заявил, что нам нужно использовать сторонние возможности очереди сообщений вместо потоков и реализовать балансировку нагрузки, что в итоге привело к тому, что мы в итоге начали работать с Celery, Redis, RabbitMQ, Nginx, uWSGI. и куча других крупных сторонних сервисов, с которыми никто не имел никакого реального опыта.

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

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

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

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

Это неуместно для премьер-министра "заявлять" в одностороннем порядке. Две причины:

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

2. Если NFR вводится на полпути через проект, это, вероятно, должно быть сделано через контроль изменений . Контроль изменений очень важен с точки зрения управления; это будет не только вклад в ваши требования, но и важный вклад в контрольные примеры QA, руководство по развертыванию и поддержке операций и (здесь действительно важная часть) расписание PM . Если новое требование вводит больше работы, команда разработчиков должна иметь возможность сообщать новые оценки развития, и премьер-министр должен будет решить, смогут ли они жить с новой датой, добавить больше ресурсов или оттолкнуть заинтересованную сторону, которая представила НФР.

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

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

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

Что было бы глупо - это позволить себе пройти смертью .

То, что вы описываете, это то, что вы потеряли критическое чувство. Нет чувства контроля и нет ясного пути к нему.

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

Что вы должны сделать, так это подумать о том, что вы имеете полное право ожидать.

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

Под тестируемым я имею в виду, что они ДОЛЖНЫ сообщать вам, сколько запросов в день / час / минуту они хотят, чтобы они могли выполнять. Дайте понять, что вы намереваетесь построить что-то для этой системы в соответствии с этими спецификациями.

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

Теперь имейте в виду. Это не инструменты, которые вводили код, страдающий от состояния гонки. Вы, ребята, сделали это. Вы должны узнать, КАК вы это сделали, чтобы вы могли отменить это.

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

Серьезно, просто поддаваться этому непрофессионально и смертельно для проекта.

Я был здесь, чувак. Более одного раза. Это заставляет вас чувствовать себя глупо. Это действительно не так. Вы просто потерялись.

Поговори в личку. Честно. Выложи все это. Покажите, что вы готовы учиться, но не хотите, чтобы вас прокатили. Никогда когда-либо разрабатывать или кодировать на основе веры. Заставьте PM показать вам, как делать то, что они хотят. Не притворяйся, что понимаешь, когда не понимаешь. Не говори, что это будет сделано, когда это не будет. Если вы собираетесь верить во что-то, верьте в себя. Вы должны быть готовы сказать НЕТ.

Если это не сработает, отполируйте резюме, потому что оно вам скоро понадобится. Тем или иным способом.

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

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

Не зная контекста и стратегии продукта, используемой вашим руководством, трудно объективно ответить на ваш вопрос.

Вот несколько объективных аргументов. Однако возможно, что это не то, что вы ожидали:

• « Имейте в виду , что никто не знает , как использовать эти продукты еще ».
• Использование только отлично известных инструментов и методов обеспечит высокую производительность. Но это значительно ограничит способность к инновациям. На некоторых рынках это может быть фатальным для вашего продукта. Например, почти 30 лет назад я предложил использовать Windows 3.0 для разработки новой версии продукта CAD, которая была успешной в MS-DOS. Менеджер по продукту возразил, что это не проверенная среда, что она будет слишком сложной и слишком сложной для обучения для команды, и в любом случае, что « Windows никогда не будет основной средой » ... Я позволю вам догадаться об успехе его продукт 2 года спустя.
• Это все вопрос затрат и выгод. Стоимость экспериментов в сравнении с преимуществами масштабируемости и развертывания, обеспечиваемыми третьей стороной, которая имеет опыт работы с огромными установками и большой рабочей нагрузкой.
• Недостатки добавления новой технологии могут быть сглажены с помощью соответствующего обучения или первоначальной поддержки / коучинга опытным консультантом.

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

Существует два подхода к сторонним библиотекам (и другим компонентам):

1. Используйте как можно больше из них
2. Используйте как можно меньше из них

Мой подход (2). Похоже, ваш подход тоже (2), но руководителю проекта этот подход нравится (1).

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

Если вы хотите убедить премьер-министра изменить подход, рассмотрите следующие аргументы:

• Время учиться. Каждая внешняя библиотека требует времени для изучения, и в это время компетентный программист может написать желаемую функциональность, особенно если огромная библиотека была выбрана просто для выполнения очень простой вещи, которая могла бы быть сделана в нескольких сотнях строк кода.
• Заменяемость.Если у вас есть внешняя библиотека, как вы можете гарантировать, что если ее разработка остановлена, вы можете заменить ее другой подобной библиотекой? Мое решение состоит в том, чтобы избегать внешних библиотек всякий раз, когда я могу, и всякий раз, когда это невозможно, я пишу простую оболочку, чтобы абстрагировать ту часть интерфейса программирования, которую я хочу. Обычно интерфейс, который я хочу, намного проще, чем интерфейс, предлагаемый библиотекой. Тогда мой код обращается к внешней библиотеке только через эту оболочку, что облегчает замену. Сборка всего вашего приложения на какой-то платформе - это большое нет-нет. Сервлеты? Да, они были здесь в течение длительного периода времени и продолжают оставаться здесь в обозримом будущем. Шаблонные движки? Да, хотя они не являются полностью заменяемыми (вы обычно выбираете один и остаетесь с этим), ценность, которую они приносят, огромна, поэтому выбирайте внимательно - и имейте в виду, что при переключении шаблонизаторов у вас может быть два шаблонизатора в одном приложении, но обычно не может быть двух фреймворков в одном приложении. Apache Struts? Нет, фреймворки приходят в моду и быстро выходят из моды, и обычно у вас не может быть двух фреймворков в одном приложении.
• Версия ад. Выбрав внешнюю библиотеку, вы должны обновить ее, чтобы избежать уязвимостей в безопасности, и обновление может привести к поломке. Хорошо спроектированные компоненты (такие как Java JRE) совместимы с различными версиями, но мой опыт показывает, что большинство библиотек дерьмово из-за навязывания огромного адского варианта. Кроме того, для компонента X может потребоваться версия Z 1, а для компонента Y может потребоваться версия Z 2, и вы не обязательно сможете связать версию Z 1 и версию 2 в одном приложении.
• Уязвимости безопасности. При выборе внешней библиотеки увеличивается число легко уязвимых уязвимостей в вашем приложении. Кто-то может утверждать, что разработанный внутри компании код напоминает безопасность из-за неясности, но, опять же, я бы сказал, что это все еще форма безопасности.
• Лицензионные проблемы. Каждая внешняя библиотека налагает свою собственную лицензию на части вашей программы. Например, библиотеки GPL нельзя использовать в программах не-GPL, а библиотеки LGPL также требуют распространения исходного кода вместе с двоичными файлами, что может занимать значительные объемы полосы пропускания.
• Время запуска приложения. Каждая большая внешняя библиотека замедляет время запуска вашего приложения. Написав простую, скудную библиотеку, вы можете значительно сократить время запуска приложения.
• След памяти. Наличие X, требующего Y, требующего Z, требующего A, требующего B, требует одновременно X + Y + Z + A + B в памяти. Реализуя только эквивалент X, давайте назовем его X ', вам нужно просто X' в памяти. И обычно объем памяти X меньше объема памяти X.
• Ошибка риска. Чем больше строк во внешнем компоненте, тем выше риск того, что вы столкнетесь с ошибкой, которую будет трудно исправить из-за огромного количества кода, который вам нужно понять. Если вы делаете это собственными силами, вы обычно делаете это с меньшим количеством строк кода (чтобы делать то, что вам нужно, ничего больше), и, следовательно, с меньшим риском ошибок.
• Customizability. Если я сам пишу SQL-запросы, я знаю, как выглядит запрос и насколько хорошо он работает на заданном ядре базы данных и заданном наборе индексов. Если, с другой стороны, запрос SQL написан внешним компонентом, я ничего не знаю о его производительности. Раньше я работал в компании, где каждая веб-страница загружалась по несколько секунд. Я подозревал, что причина в том, что библиотека Hibernate, которую они использовали, автоматически получала слишком много данных из базы данных, когда все, что вам было нужно, это один элемент, а не все элементы, связанные с этим конкретным элементом. Я покинул компанию, прежде чем обнаружил истинную причину медлительности, потому что мне не нравился подход использования огромного количества существующих библиотек.

Будьте осторожны, особенно если библиотека называет себя фреймворком . Это означает, что библиотека требует от вас построения всего приложения вокруг себя. Как правило, у вас не может быть двух фреймворков в одном приложении; они будут сражаться друг с другом без мирного сосуществования. Утилита для веб-разработки? Да, пожалуйста, их слишком мало. Если я когда-нибудь найду библиотеку лучше, чем я использую сейчас, я могу использовать вновь найденную библиотеку в новом коде, продолжая использовать старую библиотеку в старом коде. Фреймворк веб-разработки? Большой гудок НЕТ!

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

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

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

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

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

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

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

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