Внедрение практики управления ПО в плохо управляемой компании

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

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

Совсем недавно компания начала заниматься разработкой программного обеспечения. Тем не менее, боссы профессионально работали только с небольшими программами на FORTRAN, они никогда не использовали систему управления версиями сами. Они ничего не знают о Scrum, Agile и других подобных подходах к управлению. Что еще хуже, большинство сотрудников — недавние выпускники (включая меня), а некоторые — стажеры. Кроме того, много кода разрабатывается людьми из машиностроения/электротехники. Поскольку менеджеры редко объясняют вещи ясно и открыто, ничто и никто здесь не похож на техлида, скрам-мастера, владельца продукта и так далее. Редко что-либо имеет четко одного ответственного человека. Нередко некоторые сотрудники часами громко разговаривают на темы, не связанные с работой.

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

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

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

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

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

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

пусть бог помилует твою душу. Но чем он отличается от work.stackexchange.com/questions/13910/… и других вопросов?
@aaaaaa: Если бы отсутствие VCS было моей единственной проблемой, я был бы так счастлив.
«Жизненный цикл каждого проекта довольно длинный (2 года+), поэтому не может быть и речи о том, чтобы позволить кому-то попробовать сумасшедшие идеи, чтобы позже о нем или ей можно было судить по конечным результатам или отзывам клиентов». Вы не думали о том, чтобы попытаться это изменить? Настройте все так, чтобы вы могли перейти на Agile и обеспечить постоянную ценность для бизнеса.
я имею в виду, VCS является одним из примеров возможных изменений. Возможно, вам будет интересно прочитать Peopleware

Ответы (4)

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

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

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

Существуют модели того, как происходят изменения. Это непросто и требует МНОГО времени, больше времени, чем вы думаете. Вам необходимо преодолеть организационную инерцию и сетевые эффекты, которые растут нелинейно с размером организации. Название этой теории называется «диффузия инноваций». См. https://www.youtube.com/watch?v=9QnfWhtujPA

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

Самое практичное, что вы можете сделать, — это заручиться поддержкой единомышленников. Начните с малого с небольших проектов, которые устойчивы к сбоям и опыту обучения и которые не видны более крупной организации. Это означает поиск «новаторов», которые готовы рисковать только ради удовольствия и получения вознаграждения за обучение.

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

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

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

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

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

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

Я присоединюсь к тому, что мимоходом сказал @GeorgeM: начните искать новую работу.

Если дела обстоят так, как вы описали, то из-за неумелого руководства риску подвергается сама компания. Итак, вы работаете в отрасли, где поиск работы идет медленно, а ваш нынешний корабль медленно идет ко дну. ПРЫГАТЬ КОРАБЛЬ!

Вы можете наслаждаться работой у конкурента, надеюсь, с меньшим драматизмом.

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

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

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