Что такое масштабируемый процесс управления проектами в малых фирмах развития? - PullRequest
0 голосов
/ 31 августа 2009

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

Мы думали о том, чтобы технический менеджер находился посередине между СР и разработчиками.

SR1, SR2, SR (n) ---> TPM -> Dev1, Dev2

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

Проблемы с текущим процессом:

SR1, SR2 -> Dev1, Dev2 (Adhoc)

  • Отсутствие видимости рабочей нагрузки для наших разработчиков (из-за слишком большого времени простоя или слишком большой рабочей нагрузки для разработчиков)
  • Неспособность спланировать отпуск согласно временам кризиса
  • Edit1: Другая проблема, которую мы забыли опубликовать, заключается в том, что СР проводят утренние собрания, и приоритеты меняются в день в зависимости от их чрезвычайной ситуации.

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

EDIT2: В общем, есть 3 SR или Владельца продукта, 3-4 Разработчика, 1 Технический PM.

Ответы [ 4 ]

2 голосов
/ 31 августа 2009

Не помещайте PM's между торговыми представителями и разработчиками. Здесь есть две несвязанные проблемы.

  • Какие функции вы предоставляете? (Только SR знает это.)

  • Вы делаете успехи; Вы делаете вещи вовремя? (Это то, для чего нужен PM.)

То, что вы хотите, это.

sales rep -> [ developers + PM ]

Далее, вам нужна структура взаимодействия.

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

Это метод Scrum , и он хорошо масштабируется. Он контролирует взаимодействие, не ставя дополнительных людей на пути взаимодействия.

1 голос
/ 31 августа 2009

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

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

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

Добавлен совет: если показатели не будут использоваться для изменения людей, собирайте их вслепую (чтобы участники не знали). Скорее всего, вы получите самую точную информацию.

0 голосов
/ 31 августа 2009

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

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

  • Документируйте все! (Оценки, фактическое потраченное время и над чем каждый человек работает в настоящее время)
  • Используйте удобное для пользователя / разработчика программное обеспечение для легкого сотрудничества между PM / Devs
  • Дайте разработчикам приоритетную очередь (я предпочитаю спрашивать у премьер-министра, что нужно сделать для проекта, а не просто нажимать следующую задачу)
  • Продолжайте анализировать ваш процесс и при необходимости заменяйте области

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

0 голосов
/ 31 августа 2009

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

Для отпуска / планирования, Канбан является одним из вариантов. Другие включают XP и Scrum . IMHO Scrum - это больше философия управления, а XP - методология разработки. Планирование экстремального программирования определенно стоит прочитать.

Клиенты (ваши СР) всегда будут пытаться обойти процесс разработки. "Разве вы не можете просто вставить эту историю в середине итерации?" Вы должны получить руководство и поддержку по любой выбранной вами методологии. Преимущества для СР заключаются в том, что (1) они получают возможность расставить приоритеты для историй (запросы функций) и (2) у них будет лучшее представление о том, когда будут закончены их истории.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...