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