Я работаю в компании, которая переживает стремительный рост, и в будущем прогнозируется дальнейший рост. В настоящее время мы используем универсалов, которые могут работать над несколькими проектами для улучшения коммуникации, командной работы и маневренности.
Даже с универсалами некоторые участники в конечном итоге получают концентрированные знания предметной области в определенных проектах, поэтому некоторые руководители рассматривают возможность перехода в более мелкие специализированные проектные группы, которые станут специалистами в определенной области, что является естественным расширением знаний в этой области и ростом компании. .
Моя проблема в том, что это будет большой сдвиг для стиля работы, который мы делаем, и я не хочу жертвовать коммуникацией, командной работой и маневренностью, если это возможно.
При работе над крупномасштабными проектами (подумайте о разработке Excel или его эквивалента), как вы можете поддерживать тот же уровень общения, командной работы и маневренности между проектными группами?
Короткий ответ: «Вы не поддерживаете тот же уровень общения».
Если использовать ваш пример, вполне справедливо поспорить, что люди, разрабатывающие Excel, никогда не будут призваны внести свой вклад в драйверы устройств.
Чтобы универсал был полезен в нескольких проектах, важно оставаться в курсе этих проектов — знать технологии, знать людей, знать проблемы, знать решения предыдущих проблем и т. д.
В какой-то момент информации слишком много, чтобы не отставать. У вашего универсала будет слишком много широты/недостаточно глубины, чтобы оставаться полезным.
Переход к выделенным командам позволит этим командам полностью сосредоточиться на своей проблемной области. Они жертвуют широтой, чтобы получить (или, по крайней мере, сохранить) глубину.
Мои основные опасения:
С организационной точки зрения переход на эту структуру может сильно повредить текущим проектам. (Я видел это как минимум дважды, и клиенты были очень недовольны.) Есть ли какая-то выгода, которая могла бы компенсировать этот сбой? Этот тип изменений повлияет на сроки, повлияет на способность выпускать продукт (некоторые люди обязательно будут заниматься проектами, с которыми они не очень хорошо знакомы) из-за необходимости изучения нового проекта. Это также невероятно рискованно, так как некоторые вещи могут потеряться в беспорядке, поскольку люди, которым в настоящее время поручено это делать, переходят к другим проектам. Каков был бы план? Есть ли способ сделать поэтапное изменение?
Если перекрестного опыления меньше, возникнут ли у вас проблемы, если кто-то из ключевых участников проекта возьмет другую работу? Разработчики имеют тенденцию перемещаться. Наличие меньшего количества людей, знающих детали проектов, может быть дорогостоящим. Если мы говорим о проектных командах из 5-10 человек, это может не быть проблемой, но если в конкретном проекте команды заканчиваются как 1-2, это может быть проблемой.
Если вы разделяете людей на определенные продуктовые линейки, ограничиваете ли вы их способность получать новые знания (необходимые для большинства хороших программистов) и, таким образом, вынуждаете лучших уходить, чтобы поддерживать свою профессиональную квалификацию? Чем больше у вас проектов с использованием старых технологий, тем хуже может быть.
Насколько легко будет перейти на другие проекты? Как только вы станете экспертом в одном проекте, шансы на то, что вы сдвинетесь с места, значительно уменьшатся. Так что, если разработчики почувствуют, что вы мешаете их карьере, они уйдут толпами, и вы потеряете много текущих знаний. По крайней мере, вам понадобится план, разрешающий переводы в другие проекты, и способ обойти проблему «Я не могу его бросить, потому что он единственный, кто знает…». Карьерный рост важен, чем больше людей, специализирующихся на проектах, тем сложнее продвигаться вверх. Вам нужен план, чтобы справиться с этим. Вы можете рассмотреть возможность перемещения 5-10% разработчиков каждый год и сделать требование, чтобы всем было разрешено менять линейки продуктов не реже одного раза в 5 лет. Это может помочь вызвать перекрестное опыление, дать людям возможность получить новый опыт и сохранить относительно стабильную основную часть команды. Время наращивания должно быть указано в планах проекта, потому что вы знаете, что каждый год у вас будут новые разработчики. Это также помогло бы менеджерам не слишком полагаться на одного человека, поскольку они знают, что в конечном итоге его переведут. Вы также можете убедиться, что люди могут подавать заявки на новые вакансии без одобрения своего нынешнего начальника (чтобы люди не копили деньги).
Я бы спросил вашего босса, что он ожидает получить, чтобы компенсировать возможные проблемы (я уверен, что в текущей ситуации вы можете придумать больше, чем я. Вы также, вероятно, можете увидеть, какие преимущества могут быть).
Вы также должны учитывать, что у вас могут быть специалисты, которым необходимо оставаться кросс-функциональным, несмотря ни на что. Или вы собирались нанять 7 специалистов по бизнес-аналитике (по 1 на проект) вместо 2-х, которые у вас есть (для примера). Лучшим вариантом может быть создание гибридной организации, в которой некоторые из них разрознены, а некоторые нет.
Вы даже можете провести анализ затрат и выгод, который количественно оценивает риски и выгоды обеих возможностей, чтобы он мог увидеть, каковы будут последствия.
Если разработчик пишет 10 000 строк кода в год, а команда из 5 человек работает над проектом в течение 18 месяцев, то можно ожидать, что проект будет иметь 75 000 строк кода, когда он будет запущен в производство. Если он останется в производстве в течение десяти лет, он, вероятно, расширится до 250 000 строк за это время. Это очень гипотетический случай, связанный либо с веб-сайтом, либо с программным обеспечением по подписке — он не обязательно применим к встроенному элементу управления.
100 000 строк кода, разделенных на 50, составляют примерно 2000 страниц, поэтому любой разработчик, участвующий в зрелом проекте, должен держать в голове эквивалент 2000 страниц инструкций. Если вы распределяете людей по нескольким проектам, умножьте это на количество проектов, за которыми им поручено следить.
Это может сработать, если у вас есть люди, которые работают в очень близоруких ролях — ничего, кроме служб данных или определенных видов сводных отчетов или согласованности пользовательского интерфейса для нескольких продуктов. Однако, если вы хотите, чтобы несколько человек полностью разобрались в данном приложении, они должны заниматься этим полный рабочий день. «Кросс-функционал» — это серьезное размывание усилий.
джморт253