Что я могу сделать, чтобы снизить риск, связанный с разработчиками средней квалификации?

Как премьер-министру, вам нужно играть в захват власти; докажите своему руководству, что вы, как менеджер проекта, должны иметь право перемещать ресурсы, в том числе менять их, чтобы повысить вероятность успеха. Однако примите тот факт, что вы можете не получить мощности, необходимой для реального запуска проекта. Многие из нас находятся в той же самой лодке.

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

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

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

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

Действительно, гибель проекта НЕ неизбежна. В конечном итоге вы можете быть очень удивлены своей командой и добиться выдающихся результатов, потому что ваши требования к персоналу могут быть слишком пессимистичными, или вам повезло, или эта команда среднего звена талантлива по своей природе, или комбинация этих и другие переменные. Имейте в виду, что опыт и оценка являются слабыми предикторами производительности. Я использую аналогию с тем, что мы видим в авиации. Нам всегда нравится 20 000-часовой седовласый капитан, который возит нас, но кого мы отправляем на войну на этих сложных истребителях, бомбардировщиках и транспортных средствах? 24-летний парень и девушка, работающие от 600 до 800 часов, удивляются... и с большим успехом.

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

Удачи!

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

Но это не так. Клиент установил бы сроки для проекта, и если бы вы их не достигли, вы в конечном итоге потеряли бы удовлетворенность клиента. Так что лучше убедить свое руководство нанять квалифицированного человека и платить ему, чем нанимать неквалифицированного человека и платить меньше.

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

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

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

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

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

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

Идея, лежащая в основе этого, состоит в том, чтобы иметь что-то «потенциально» выпускаемое как можно скорее, чтобы:

• Дайте вам и команде необходимую уверенность в том, что в худшем случае есть что-то, что вы могли бы отправить. Не стоит недооценивать уверенность в команде!
• Вы можете выявить проблемы в самый ранний момент и...
• Вы можете планировать заранее и запланировать учебные занятия iE для критических частей, где ваши разработчики не имеют знаний. Или скорректировать команду, если это необходимо.
• Вы можете запустить всю цепочку (план->внедрение->QA->проверка клиента) с самого начала, поэтому вы не столкнетесь с неожиданными проблемами за 2 дня до релиза.
• У членов команды достаточно времени, чтобы понять всю настройку и требования, поскольку они могут видеть весь процесс и фактический вариант использования в качестве рабочего примера. Это часто приводит к улучшениям/решениям, которых вы не ожидали и не видели в модели предварительного планирования, поскольку это косвенно вовлекает экспертов в этапы планирования. Обязательно выслушайте их и дайте им возможность высказать свое мнение.

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

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

Лучший способ донести свою позицию до руководства — использовать метрики. Как предложил @David, я бы задокументировал риски и начал их отслеживать. Как только вероятность риска начнет расти и начнет влиять на сроки (убедитесь, что вы определили это на самом раннем этапе), доведите эти цифры до высшего руководства и постарайтесь убедить их.

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

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