Задний план -
Я работаю в генетической компании размером около 100 человек, которая недавно принадлежит корпорации из более чем 8000 человек. За последние 2 года я был нашим менеджером проекта по разработке программного обеспечения и научился выполнять эту работу и передовой опыт, основываясь исключительно на опыте, который я получил здесь, на моих собственных ошибках, книгах, блогах, вебинарах и т. д. Нет " формальное обучение; но у меня есть степень магистра в области биохимии, поэтому по какой-то причине я считался подходящим для этой роли.
Недавно несколько наших сотрудников (сотрудники лаборатории, не входящие в отдел управления проектами) посетили двухнедельную программу обучения зеленого пояса, спонсируемую корпорацией, для личного развития. Теперь эти люди вернулись, и у них есть проект, который нужно завершить, и все эти инструменты зеленого пояса готовы к использованию. Один из проектов сосредоточен на нашем собственном лабораторном программном обеспечении, что на самом деле является небольшим изменением. Если бы я собирал требования, я бы не планировал брать более 1 месяца. Однако с помощью DMAICмодели, моему коллеге удалось сделать это небольшое изменение программного обеспечения за 4 месяца и бесчисленное количество совещаний, а мы только начинаем этап анализа. Я сижу, наблюдая, как это происходит, и просто озадачен, казалось бы, запутанным процессом. (Не говоря уже о том, что я несколько... сбит с толку тем, почему мою работу выполняет кто-то другой.)
Итак, суть моего вопроса такова: может ли кто-нибудь рассказать о полезности методов зеленого пояса для малых или средних программных проектов? Исходя из моего опыта и здравого смысла, это кажется слишком мощным инструментом для данного проекта. Но без какого-либо реального опыта обучения зеленых поясов и всего пары лет опыта управления программным обеспечением я боюсь сказать: «ЭТО МУСОР!» моему высшему руководству (которое, конечно же, думает, что зеленый пояс — это здорово, потому что это делает корпорация).
Мысли?
Добро пожаловать в ПМСЭ! Все зависит от того, что вы хотите от этого. Часто преимущества таких подходов, как шесть сигм, проявляются в лучшем управлении и разработке воспроизводимых рабочих процессов. Это может не привести к более быстрой и дешевой разработке программного обеспечения в ближайшем будущем. Но это имеет преимущества для корпоративных заинтересованных сторон.
Добро пожаловать в ПМСЭ! Приятно видеть вокруг менеджеров из-за пределов ИТ-индустрии.
Я считаю, что слово здесь портняжничать . Это не что-то эксклюзивное для методов зеленого пояса в компании из 100 человек, это также применимо для применения каждого правила PMBoK в проекте с 5 людьми или управления проектом с помощью бумажного блокнота для создания космического корабля.
Методологии должны помогать, они являются средством достижения цели. Когда они приносят больше вреда, чем пользы (как кажется), их следует пересмотреть и... адаптировать.
Если вам нужны какие-то веские аргументы для использования в этом обсуждении, я полагаю, что адаптация проекта упоминается в первых главах PMBoK.
Я работаю в крупной ИТ-компании с 9 до 5, где «Шесть сигм» представлены как обязательная стратегия качества для каждого проекта, будь он большим или маленьким (у меня есть сертификат зеленого пояса). Кроме того, время от времени я консультирую небольшие агентства по развитию, где я консультировал и руководил успешными проектами Six Sigma.
Как вы заметили, проект DMAIC может занять слишком много времени, чтобы быть завершенным, и он может фактически потерять смысл на этом пути. В моей компании проекты, реализация которых занимает более 3 месяцев, помечаются как «проваленные» или не считаются эффективными (одной из причин этого является мысль о том, что ИТ-индустрия меняется слишком быстро, чтобы ждать 3 месяца). -улучшения). Еще одна причина избегать длительных проектов 6s заключается в том, что в какой-то момент фактическое улучшение иногда может оказаться дороже, чем проблема (если встречи проводятся еженедельно и включают 10 сотрудников + 5 менеджеров только для какого-то дешевого проекта, тогда вы могли бы также хочу проверить, разумно ли продолжать).
Что касается вашего фактического вопроса:
Может ли кто-нибудь рассказать о полезности методов зеленого пояса для небольших или средних программных проектов?
Для меня проекты 6s — помимо сокращения количества дефектов — это просто способ выразить улучшение качества в цифрах, поэтому я говорю, что это полностью зависит от того, является ли это просто чудом в вашей компании или оно действительно начинает превращаться в непрерывный процесс . стратегия улучшения . Вероятно, эти люди, которые управляют этими проектами, позже станут зелеными/черными поясами и возглавят другие проекты по улучшению внутри компании, и, по моему опыту, нужно с чего-то начинать, и не все проекты 6s, с которыми вы сталкиваетесь, будут прорывом в Компания. Итак, как было предложено выше, данный проект нуждается в некоторой адаптации или, возможно, не использует такое сложное решение, как DFSS.
На одном курсе 6s один инструктор сказал нам: « Теоретически отдел шести сигм/качества может закрыться, если будет доказано, что время/усилия, затраченные на проекты по созданию решений и улучшений , на самом деле обходятся дороже, чем фактически реализованные решения. .". Дело в том, что 6s может фактически превратиться в недостаток вашей компании, а не решение.
Итак, я говорю, что 6s — это очень интересный, полезный и мощный набор инструментов, однако, по моему личному опыту, не каждый предложенный проект 6s полезен и не должен быть преследованием — всегда должны присутствовать SMART-цели и четкий масштаб проекта. , НО это работа чемпиона по выявлению, в этом случае нужно обращаться не к руководству со словами "ЭТО МУСОР!!", а к чемпиону(ам) проекта.
Кроме того, помните, что улучшения, предлагаемые в 6s, не являются исключительными для крупных корпораций/проектов, вся идея состоит в том, чтобы уменьшить дефекты, и их можно найти в любом проекте, независимо от его размера.