Я работаю разработчиком в небольшой ИТ-фирме с 4 разработчиками и 2 руководителями проектов. В настоящее время мы реализуем своего рода традиционное управление проектами, в котором рабочий процесс для данного проекта выглядит следующим образом:
Каждый проект, который мы делаем, разрабатывается с учетом конкретных потребностей нашего клиента. Это означает, что оценки задач иногда неверны (сложно оценить задачу, которую вы никогда раньше не выполняли) или что определенные технические проблемы возникают только тогда, когда мы находимся в середине разработки. Это сильно расстраивает наших менеджеров проектов, так как обычно это означает, что мы превышаем нашу предполагаемую стоимость разработки и нашу норму прибыли для проектов.
Однако наибольшее разочарование вызывает несоблюдение сроков, обещанных клиентам. Это потому, что в любой момент времени у нас всегда есть 3 или более проектов в активной разработке. Кроме того, клиенты часто звонят разработчикам напрямую с вопросами/техническими проблемами/чрезвычайными ситуациями. Также возникают дополнительные накладные расходы, когда задачи передаются от одного разработчика другому, что затем необходимо объяснить разработчику, который получает задачу.
Каждую неделю один из менеджеров проекта назначает разработчикам задачи, которые необходимо выполнить на этой неделе, чтобы уложиться в сроки. Из 38 назначаемых рабочих часов на каждого разработчика 4 часа остаются нераспределенными для учета непредвиденных событий. Также к нам присоединился новый разработчик, который присоединился к нам всего три недели назад, и ему время от времени требуется техническая помощь, которая также в среднем занимает от 2 до 3 часов моего времени каждую неделю.
В заключение, этих 4 часов до сих пор никогда не было достаточно. Общение с руководством, высокоприоритетные ошибки, ... занимает более 4 часов каждую неделю. Руководство винит разработчиков в том, что они не могут расставить приоритеты, и говорит, что нам следует приложить больше усилий для проведения точных оценок и фактического соблюдения сроков.
Мой вопрос заключается в следующем: каков правильный подход здесь? Как мы можем лучше оценить объем и продолжительность проекта, а также эффективно установить и соблюдать его сроки? Что нужно изменить?
Заранее спасибо.
В этом подходе так много классических проблем, что трудно выбрать лучшее место для начала! Во-первых, я скажу, что подход Agile может подойти вам лучше из-за того, как он обрабатывает функциональные требования и технические долги (ошибки и проблемы), однако лично у меня нет прямого опыта работы с этой моделью. Я уверен, что кто-нибудь придет и обсудит этот подход. Тем временем, предположив, что вы хотите придерживаться модели водопада:
Менеджеры проектов собирают функциональные требования: это не традиционная задача управления проектами, она больше подходит для бизнес-аналитиков и системных аналитиков. БА обучены выявлять точные функциональные требования и представлять их таким образом, чтобы клиент мог их одобрить и (надеюсь) команда разработчиков может использовать их в своих процессах оценки и разработки.
Планирование: очевидно, что руководители проектов не планируют проекты с достаточным запасом непредвиденных обстоятельств, чтобы учесть непредвиденные проблемы, последствия переполнения других проектов и критические ошибки и проблемы. Мне не кажется, что это проблема оценки (зависит от того, насколько на самом деле дикие оценки разработчиков и насколько они отличаются от реальности). Это больше похоже на безнадежно оптимистичное планирование и несоответствие ожиданиям. Это все области, в которых, возможно, менеджеры по проектам могли бы извлечь пользу из дополнительного обучения.
Планирование мощностей: люди, которые отвечают за планирование распределения и назначения пула ресурсов (вы не говорите, являются ли они также менеджерами по проектам), должны стать умнее с их пониманием различных показателей производительности команды. Некоторые всегда будут быть быстрее/более продуктивным, чем другие, и при формировании команды для любого данного проекта это знание должно учитываться при планировании — притворяться, что все работают так же быстро, как и самый быстрый член команды, несколько бредовый и всегда будет приводить к перебору. оптимистическое планирование. Также важно принимать во внимание влияние на существующих членов команды добавления новых членов, которых необходимо обучать/наставлять или даже просто ассимилировать в команду — эффект никогда не бывает только на производительности нового человека, он влияет на производительность всех вокруг этого человека. Другая сторона медали планирования мощностей заключается в том, что в чистом окружении компании-разработчика программного обеспечения/консалтинговой компании использование ресурсов имеет решающее значение. Ни одна компания не может позволить себе иметь людей на скамейке запасных, поэтому среда, ориентированная на продажи, всегда будет перегружать персонал («потеря активов»). людей могло быть и лучше. Менеджмент также должен сыграть свою роль в этом и понять, что если вы будете слишком сильно давить на людей, то можно будет срезать углы, качество упадет, и больше времени будет потрачено на исправление проблем с качеством. Кроме того, обычно будет нанесен ущерб отношениям или репутации. Сбалансировать это с незаряженной «скамейкой» недостаточно загруженных людей — всегда сложная задача.
Руководство винит разработчиков в том, что они не могут расставить приоритеты: на это есть простой ответ: разработчики НЕ расставляют приоритеты. ПМ, может быть. БА, может быть. Клиент, всегда (как только вы попадете в UAT). Кто-то где-то должен обсуждать и уравновешивать нерешенные проблемы и информировать команду разработчиков о порядке приоритетности ошибок. Все просто: разработчики, вероятно, являются худшей группой людей, которых можно попросить расставить приоритеты по ошибкам и проблемам, поскольку они (обычно) не имеют более высокого уровня/ориентированного на бизнес взгляда на проект. По моему личному опыту, я, как PM, обычно содействую приоритизации вопросов. На этапе SIT мы делаем это, используя риск-ориентированный подход (чтобы упростить его,
И последнее: вы не упоминаете тестирование в водопадном процессе. Это потому, что вы этого не делаете, или просто потому, что это «настолько очевидно», что не нуждается в упоминании? Если вы переходите прямо от разработчика/модульного тестирования к клиенту/вводу в эксплуатацию, то вы напрашиваетесь на неприятности. Команде необходимо провести системное и интеграционное тестирование (SIT) до того, как клиент увидит это, и это должно быть должным образом спланировано кем-то, кто разбирается в тестировании; не PM и уж точно НЕ разработчик. Именно здесь задачи, выполняемые надлежащими бизнес-аналитиками, вступают в свои права, поскольку их спецификации используются профессионалами по тестированию для создания тестовых случаев, а затем для доказательства того, что продукт работает в этих тестовых случаях. К тому времени, когда клиент увидит код, он уже должен пройти все тесты, которые клиент когда-либо будет запускать для него.быть простой вещью (хотя почему-то это никогда не бывает!)
Надеюсь, это поможет. Удачи!
РЕДАКТИРОВАТЬ после повторного чтения вопроса: учитывая, что это небольшая компания, у вас, вероятно, нет возможности добавлять BA и тестировать ресурсы. Однако я серьезно задаюсь вопросом, зачем нужны два менеджера проекта для четырех разработчиков. Для такого количества людей я не понимаю, как вам нужно более одного менеджера проектов, управляющего несколькими проектами. Если бы вы отказались от продакт-менеджера и заменили его бизнес-аналитиком, у которого есть опыт тестирования, это, на мой взгляд, было бы гораздо лучшим сочетанием.
Безусловно, управлять одновременными проектами с ограниченными ресурсами непросто. В последнее время я столкнулся с этими проблемами и нашел выход, внедрив Agile и некоторые элементы KANBAN.
Я убедился, что есть инструмент управления задачами PM +, который поддерживает меня во всех процессах на протяжении всего жизненного цикла проекта. Я внедрил Redmine для управления проектами и задачами. Связал всех членов команды с порталом, определил спринты после проведения схватки схватки и дальнейшего проведения ежедневных скрамов, чтобы обеспечить соблюдение сроков проекта / задачи. К сожалению, я, как проектный менеджер, также отвечал за сбор и документирование требований, а затем за тестирование их на стадии подготовки.
Подводя итог, я бы предложил вам следующие быстрые шаги:
Эти шаги в значительной степени справились бы с хаосом, связанным с управлением несколькими проектами.
Тьяго Кардосо