Как управлять проектом без глубоких знаний во всей включенной технологии? [закрытый]

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

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

Это из Scrum, но это применимо, даже если вы не используете Scrum. В Scrum только разработчик может дать оценку того, сколько времени потребуется, чтобы что-то сделать. Менеджерам не разрешается давать, рекомендовать или каким-либо образом изменять эту оценку. Так что в первую очередь доверяйте этой оценке.

Но ... большинство программистов по своей природе чрезмерно самоуверенны. Если программист говорит, что 2 дня, то на выполнение задачи у него может уйти 3 дня. Смета не отражает реальности (сначала).

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

Будьте сердечны во всем этом. Наша цель - получить точные и надежные оценки, а не оказывать давление на людей. Все дело в том, чтобы научить людей делать более точные оценки. Поверьте, точная оценка важнее, чем соблюдение сроков. Относительно легко сказать клиенту, что проект будет отложен на 1 неделю, если к концу этой недели вы действительно сможете выполнить проект. С другой стороны, если неоднократно говорить клиенту, что проект будет завершен «завтра», клиент быстро потеряет к вам доверие.

Еще несколько примечаний:

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

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

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

вероятно, вам следует доверять оценкам вашего разработчика, но ожидайте, что они не всегда будут на 100% точными, помните, что это оценки. Также хорошей идеей может быть использование процесса, в который встроено признание того, что оценки - это только оценки, и который либо не требует их (например, Kanban), либо имеет встроенные функции для адаптации к природе оценок (например, Scrum).

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

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

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

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

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

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

Возможно, ваш процесс может помочь вам ... из ваших комментариев выше я увидел:

• Шаг 1 - PM должен связаться с клиентом, чтобы построить проект план ...
• Шаг 2 - создание макетов ---
• Шаг 3 - получение одобрения этих двух документов от клиента и руководства ....
• Шаг 4 - запуск проекта

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

Чтобы убедиться, что все ожидания оправдаются, возьмите с собой доверенного разработчика на Шаг 1 . Прежде чем представить план, просто спросите разработчика; «как долго мы сможем построить это с командой, состоящей из n наших разработчиков?»

У этого есть несколько преимуществ:

1. Более точные оценки
2. Устанавливает более точные ожидания как для клиента, так и для команды разработчиков
3. Увеличить приверженность этим оценкам команды разработчиков

1 и 2 должна быть очевидна, но пункт 3 важен, поскольку людям редко нравится работать с оценками, установленными кем-то другим. Хотя вы не сможете использовать всю команду разработчиков для оценки, используйте надежного советника.

Я также управляю некоторыми небольшими проектами, некоторые COBOL, некоторые MS, в основном java. Я действительно знаю только java, и мои навыки тоже нуждаются в обновлении. Мы используем инструмент оценки объема работ, на самом деле это просто лист excel с полями, которые заполняет разработчик для оценки воздействия. Это помогает разработчикам разбить проблему на более мелкие части, заставляет их действительно продумать шаги, которые необходимо выполнить, и это дает нам более точную оценку. Все, что помогает разработчику, помогает и вам. :) Затем, когда мы закончили, мы сравниваем смету с фактическими данными и делаем базовую оценку для дальнейшего использования. Мы определяем хорошую смету как имеющую расхождение в 10% или меньше.

Не доверяйте слепо оценкам разработчика - вы не знаете, на чем он основывается, никто никогда не может знать на 100% технологию/фреймворк или модель данных, или бизнес-правила, или что-то еще. Знайте, что он включил в смету. Я считаю, что доверие нужно заслужить. Если разработчик раньше давал плохие сметы, будете ли вы доверять сметам, которые он представит в следующий раз? Я определенно не буду, если не увижу улучшения.

Я был разработчиком, и у меня тоже было немало плохих смет. (Может быть, поэтому я сейчас меньше разработчик и больше менеджер...)