Что делать в качестве разработчика, если в течение многих лет его команде не хватало инноваций в продуктах, не использовались методологии проекта mgmt и хранились плохие практики Software Dev? [закрыто]

14

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

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

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

Продукт в нашей команде - это лишь малая часть того, откуда компания получает свой доход, поскольку у нее есть зонтик продуктов (эта компания не является компанией, занимающейся программным обеспечением и аппаратным обеспечением; поэтому, по крайней мере на данный момент, нет постоянных судебных разбирательств, что создает рабочие места нестабильность). За эти годы я узнал из опыта других разработчиков, и мой опыт заключается в том, что для того, чтобы по-настоящему узнать команду разработчиков, требуется время, не дни и не недели, а несколько месяцев. В процессе собеседования, если команда хочет нанять вас или нуждается в вас; они заставляют все звучать великолепно, и они могут сказать вам, что вы хотите услышать. Однако реальность меняется, когда вы начинаете работать в этой команде и начинаете копаться в коде и переходить к полному процессу SDLC. Это когда вы, как разработчик, начинаете видеть реальность работы, в которую попали. Эта реальность затрудняет желание перейти от одной компании к другой, потому что трудно понять, будет ли компания, в которую вы переходите, лучше или хуже. Да, вы можете прочитать обзоры Glassdoor и т. Д., Но сколько из этих онлайн-обзоров реальны, а не от HR?

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

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

  • Отсутствие координации управления проектами: в результате этого некоторые проекты доставляются с опозданием, с ошибками, а некоторые клиенты жалуются (клиенты также сообщают об ошибках), или бюджет используется слишком быстро до выполнения проекта и т. Д. Я предоставил их Несколько советов по координации проектов и идеи в настоящее время регулярно используются для отслеживания хода выполнения проектов и задач.

  • Плохая практика разработки программного обеспечения: запах кода виден на большинстве, если не на всех файлах, нет документации, избыточность кода, внешний и конечный уровни, смешанные в одном файле, устаревшие инструменты разработки, нет реальной среды тестирования или инструментов тестирования (просто скопируйте и вставьте файлы из среды разработки в производство, а затем вручную протестируйте, чтобы все выглядело хорошо, и выпустите). Большинство инструментов разработки, которые я использую для разработки и тестирования, неизвестны команде, поскольку команда использует только 2 IDE для разработки кода, а контроль исходного кода доступен только для среды разработки. Другие разработчики пытались использовать последние фреймворки для улучшения текущих проблем, но менеджеру это не нравится из-за того, «что, если вы уйдете, тогда кто будет поддерживать этот код? Давайте оставим так, как есть». Некоторые из этих разработчиков уже ушел и перешел в другую компанию.

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

Большое спасибо за ваши отзывы и время

ками
источник
Сменить работу? ...
Роберт Харви
1
Как примечание, многие обзоры Glassdoor являются реальными в моем опыте.
Теластин
1
Является ли ваш менеджер менеджером по разработке или менеджером по продукту, т.е. тем, кто определяет приоритетность элементов, которые должны быть разработаны на основе ценности для бизнеса, которую они представляют?
Марьян Венема
4
Вы понимаете, что большие шары грязи действительно работают , верно?
Дени де Бернарди
4
По крайней мере, некоторые части Джоэла Спольски « Как все сделать, когда ты только хрюкаешь» актуальны.
AakashM

Ответы:

18

Цитата Мартина Фаулера актуальна: «Вы можете изменить свою организацию или изменить свою организацию». Учитывая, что вы, очевидно, решили изменить свою организацию (сделать ее лучше) вместо того, чтобы изменить свою организацию (работать в другой организации), вот несколько предложений.

Во-первых, многое зависит от деталей властных структур и политики на работе. Один менеджер по разработке программного обеспечения или несколько? Если их несколько, есть ли среди них те, кто не склонен к изменениям? Сколько там разработчиков программного обеспечения? Заинтересованы ли разработчики в изменении? Если это так, есть некоторые изменения, которые вы сможете внести даже без одобрения руководства. (Как говорит Фаулер в « Рефакторинге» , вам, возможно, даже не придется говорить об этом руководству. Предположительно, вас нанимают для разработки программного обеспечения как можно лучше, поэтому, если есть лучший способ сделать это, просто сделайте это.)

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

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

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

  • Не пытайтесь изменить все сразу. Найти самые большие болевые точки и начать там. Привлеките всех на борт, помогая им увидеть, как ваши изменения решают эти болевые точки.
  • Понимать перспективы других. Шор рассказывает о том, как изменения, которые он продвигал с точки зрения разработки программного обеспечения, были отклонены руководителем проекта, потому что он (Шор) не учел, как изменения повлияют на руководителя проекта.
  • В конце концов, вы будете нуждаться в некоторых поддержки со стороны выше, даже если вы побуждая большинство изменений самостоятельно. Шор говорит о своем защитнике («кто-то, с кем я работаю, у которого больше влияния, чем у меня, и он думает в целом в том же духе, что и я»).
Джош Келли
источник
4
практический совет, слишком часто разработчики думают только с точки зрения кодовой базы, а не с точки зрения бизнеса, и упускают огромную картину, которая составляет то, что мы делаем и почему мы это делаем.
gbjbaanb
Шор говорит о своем защитнике («кто-то, с кем я работаю, у которого больше влияния, чем у меня, и он думает в целом в том же духе, что и я» - к этому я должен добавить «но не пытается ничего изменить». Не ожидайте Слишком много,
говорит Моуг, восстановите Монику
10

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

На тот случай, если вы решили не покидать компанию (первая строка в вашем вопросе как-то об этом говорила):

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

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

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

Дэн Пичельман
источник
2
Извините, мне пришлось понизить голос, потому что в ОП особо сказано, что он не ищет совета в духе «Ищите новую работу».
KChaloux
4
@KChaloux - Спасибо за отзыв. Большая часть моего ответа не «искать новую работу», но я чувствовал, что отказ от этого будет плохой услугой и приведет к неполному ответу.
Дэн Пичельман
9

Похоже, пришло время узнать о дойных коровах. Иди сюда и сюда . И посмотрите на Матрицу роста доли . GSM предоставляет некоторую дополнительную информацию о том, почему дойная корова является хорошим состоянием.

Investopedia (вторая ссылка), вероятно, имеет лучшую цитату в этом случае.

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

Как вы заметили, у проекта «дойная корова» есть некоторые положительные стороны.

  • Это стабильно
  • Скромная степень нового развития гарантирована
  • Всегда есть работа по исправлению ошибок.

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

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

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

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

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

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


источник
2
+1, я видел компании, работающие в этом режиме более десяти лет. Как только они получат некоторую инерцию, они будут бегать очень долго.
GrandmasterB
2
Действительно проницательный. Программисты, по-видимому, в основном предполагают, что они работают или должны работать над «звездными» проектами с высокими инвестициями и высокой доходностью, и ссылка на Матрицу роста доли объясняет, почему это может быть совершенно не так. Было бы неплохо узнать, будут ли проекты дойных коров подходить для вовлеченных работников - это важная работа, но означает ли низкая стоимость денежных затрат низкую зарплату на одного работника или просто меньше работников? И они, как правило, не будут передовыми технологиями.
PSR
1
@psr - мой опыт показывает, что это может быть полезно и для рабочих. На самом деле, я видел лучшие предложения от более стабильных компаний. Но я никогда не работал на настоящую «зеленую область», организацию, в которой не было бы ничего хорошего. «Низкие денежные затраты» - это относительный термин, который вращается вокруг альтернативных издержек больше, чем что-либо еще. Средства всегда были доступны для проектов, которые могли бы продемонстрировать соответствующую рентабельность инвестиций. Однако в некоторые годы этот порог рентабельности был выше, чем другие, из-за внутренней конкуренции за эти средства.
5

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

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

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

В экономическом обосновании необходимо рассмотреть, как влияют на доходы бизнеса:

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

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

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

И, конечно, нужно показать, как принятие лучших практик развития повлияет на эти цифры.

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

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

Марьян Венема
источник
Спасибо за ваше время и обратную связь. Я согласен, главная причина, по которой высшее руководство не видит этих проблем, заключается в том, что вы упомянули: «жалобы клиентов не обращаются к людям, которые заботятся и / или могут сделать что-то, чтобы обеспечить лучший результат», если разработчик может что-то сделать чтобы избежать этого?
Ками
@kami: Помимо: начните собирать цифры, чтобы их заметили те, кого это волнует? Нет, не сильно, если вы ограничиваете себя ролью разработчика. Если вы хотите, чтобы что-то изменилось, вам придется выйти за пределы того, чтобы быть разработчиком. Разберитесь со своими фигурами, сначала представьте их своему менеджеру, и только тем, кто выше / рядом с ним / ней, когда он не принимает меры. Не перебирайте его / ее голову с вашими результатами, прежде чем позволить ему / ей сиять вашей работой. Это будет иметь большое значение для достижения желаемых результатов.
Марьян Венема
Благодарю. Нынешний менеджер по продукту был программистом, который каким-то образом стал менеджером, а теперь является менеджером по разработке, менеджером по продукту и менеджером проектов.
Ками
@kami: к сожалению, хорошо известный рецепт падения из-за «Принципа Питера: почему вещи всегда идут не так» . Оригинальная книга: Принцип Питера
Марьян Венема
4

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

Страх перемен На тему изменения вещей в лучшую сторону я понимаю, почему страхи менеджмента меняются. Люди привыкли к вещам определенным образом, и если вы измените его, пользователи будут бунтовать (возможно). Перемены - это страшные вещи, и, как правило, они требуют много размышлений и изучения, прежде чем сделать. Вам нужны данные, чтобы показать, что это лучше и что пользователи хотят этого. Говоря о Gmail, вы можете заняться чем-то вроде «Лаборатории Google», где вы можете включить / отключить новые функции, чтобы пользователи могли попробовать. Затем подключите некоторые данные для резервного копирования ваших изменений.

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

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

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

И наконец, помните, что изменение сложно и требует времени. Держись там и начинай с малого и наращивай.

barrem23
источник