Мне интересно знать, как справиться с текущим процессом разработки программного обеспечения, который не менялся годами и в конечном итоге приведет к провалу продукта и команды. Да, возможно, самый простой способ решить эту проблему - это смена рабочих мест, но с такой экономикой легче сказать, чем сделать. Однако, если у вас есть конкретные примеры, и вы видели или неоднократно сталкивались в одной и той же ситуации и считаете, что лучшее решение для решения этих проблем - это покинуть компанию, поддержите ваш ответ. Дело в том, что на этот вопрос действительно есть ответ, особенно если несколько экспертов по этому вопросу в конечном итоге указывают, что лучший путь - это маршрут А.
Я знаю, что многие разработчики были или находятся в похожих ситуациях. Это одна из главных причин, по которой компании переходят от того, чтобы быть # 1 на их рынке, чтобы стать последними или даже вне рынка. Надеемся, что ответы в этом посте помогут другим разработчикам, сталкивающимся с подобными препятствиями. В небольшой или большой команде разработчиков это обычно происходит:
- Некоторые разработчики, похоже, не заботятся о них и решают идти по пути и предпочитают оставлять код с большим количеством запаха кода таким, какой он есть, и процессом разработки, как есть,
- Другие устают от изменений, уходят в отставку и переходят в другую компанию,
- Другие, кажется, боятся говорить и предпочитают молчать,
- Иногда очень мало разработчиков или просто кто-то пытается высказаться за улучшение продукта, и говорит команде, как важно следовать лучшим практикам кодирования и как это выгодно для клиентов, пользователей и команды. Разработчики такого типа обычно решают остаться в команде по причинам, таким как компания предлагает преимущества, которые предлагают очень немногие разработчики программного обеспечения, или продукт имеет большой потенциал и т. Д.
Продукт в нашей команде - это лишь малая часть того, откуда компания получает свой доход, поскольку у нее есть зонтик продуктов (эта компания не является компанией, занимающейся программным обеспечением и аппаратным обеспечением; поэтому, по крайней мере на данный момент, нет постоянных судебных разбирательств, что создает рабочие места нестабильность). За эти годы я узнал из опыта других разработчиков, и мой опыт заключается в том, что для того, чтобы по-настоящему узнать команду разработчиков, требуется время, не дни и не недели, а несколько месяцев. В процессе собеседования, если команда хочет нанять вас или нуждается в вас; они заставляют все звучать великолепно, и они могут сказать вам, что вы хотите услышать. Однако реальность меняется, когда вы начинаете работать в этой команде и начинаете копаться в коде и переходить к полному процессу SDLC. Это когда вы, как разработчик, начинаете видеть реальность работы, в которую попали. Эта реальность затрудняет желание перейти от одной компании к другой, потому что трудно понять, будет ли компания, в которую вы переходите, лучше или хуже. Да, вы можете прочитать обзоры Glassdoor и т. Д., Но сколько из этих онлайн-обзоров реальны, а не от HR?
Как лучше всего решить проблемы, изложенные ниже, учитывая, что менеджер с самого начала всегда сопротивлялся изменениям, а предыдущие разработчики делали то же самое годами?
Отсутствие инноваций в продуктах в течение многих лет: продукт имеет большой потенциал и приносит хороший доход компании, но продукт выглядит так, как будто он был изготовлен 20 лет назад. Некоторые пользователи жаловались на то, что продукт не удобен и не интуитивен, а другие упоминали, что они используются для таких приложений, как Gmail, и разочаровываются при использовании продукта из-за отсутствия аналогичных функций. Основная проблема здесь заключается в том, что когда вы, как разработчик, пытаетесь внести изменения в продукт и начинаете перемещать основные элементы продукта всего на пару пикселей (чтобы сделать его более удобным для пользователя или интуитивно понятным), менеджер паникует и говорит вам положить его туда, где это было. Если вы попытаетесь добавить функцию, которая будет полезна для пользователей, менеджер попросит вас удалить ее из-за того, что «пользователи привыкли делать процесс таким, какой он есть и т. Д.» Я думаю, что вы столкнулись с необходимостью сопротивления изменениям, улучшениям и инновациям (менеджер не открыт для изменений, даже если вы, как разработчик, приводите веские аргументы в пользу преимуществ). У компании есть несколько конкурентов в этой области (продукты немногих из них намного более конкурентоспособны), но каким-то образом компания поддерживает постоянных клиентов в течение многих лет.
Отсутствие координации управления проектами: в результате этого некоторые проекты доставляются с опозданием, с ошибками, а некоторые клиенты жалуются (клиенты также сообщают об ошибках), или бюджет используется слишком быстро до выполнения проекта и т. Д. Я предоставил их Несколько советов по координации проектов и идеи в настоящее время регулярно используются для отслеживания хода выполнения проектов и задач.
Плохая практика разработки программного обеспечения: запах кода виден на большинстве, если не на всех файлах, нет документации, избыточность кода, внешний и конечный уровни, смешанные в одном файле, устаревшие инструменты разработки, нет реальной среды тестирования или инструментов тестирования (просто скопируйте и вставьте файлы из среды разработки в производство, а затем вручную протестируйте, чтобы все выглядело хорошо, и выпустите). Большинство инструментов разработки, которые я использую для разработки и тестирования, неизвестны команде, поскольку команда использует только 2 IDE для разработки кода, а контроль исходного кода доступен только для среды разработки. Другие разработчики пытались использовать последние фреймворки для улучшения текущих проблем, но менеджеру это не нравится из-за того, «что, если вы уйдете, тогда кто будет поддерживать этот код? Давайте оставим так, как есть». Некоторые из этих разработчиков уже ушел и перешел в другую компанию.
Таким образом, я уверен, что подобные ситуации случаются со многими разработчиками в других компаниях, но из-за других обстоятельств разработчик может предпочесть остаться в команде, чем идти в другую компанию по таким причинам, как (удобство работы, гибкость работы, преимущества компании или только потому, что лучшей возможности не наступило). Я не знаю ни одной идеальной компании, но как бы вы, как разработчик, вели себя и подходили ко всем этим вопросам, чтобы сохранять позитивность и в конечном итоге способствовать изменениям для улучшения продукта и улучшения процесса разработки программного обеспечения (если у вас много лет опыта разработки или только несколько)? Я знаю, что это сообщение длинное, но я предпочел дать дополнительные подробности, чтобы увеличить шансы на получение более полезной обратной связи.
Большое спасибо за ваши отзывы и время