Как я могу изменить небрежную корпоративную культуру? [закрыто]

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

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

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

Теперь эту конкретную проблему легко решить с помощью MessageBox.Show("DO NOT GIVE TO CLIENTS!");. Однако эта проблема свидетельствует о гораздо более глубокой проблеме: культура нашей компании небрежна. Неряшливое программное обеспечение в порядке и небрежные процессы в порядке. Не беспокойтесь о будущем - приложите достаточно усилий, чтобы он едва заработал, поместите двоичные файлы в ZIP-файл и отправьте его. Достаточно хорош для работы правительства.

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

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

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

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

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

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

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

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

До тех пор, пока лица, принимающие решения, больше не будут терпеть последствия плохого кода и готовы платить / менять свои способы решения проблемы.

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

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

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

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

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

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

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

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

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

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

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