Как перейти от программиста к руководителю проекта?

Я программист в небольшой компании, привыкший получать проекты от кого-то, кто говорит на собрании: «Сделай веб-сайт электронной коммерции», а потом я просто беру на себя это сделать. Единственные требования, которые я получаю, это те, о которых я прошу.

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

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

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

Допустим, этот проект представляет собой веб-сайт электронной коммерции, который будет состоять из витрины, корзины для покупок и регистрации пользователей, и я хочу, чтобы программист работал над регистрацией пользователей. Я был бы очень признателен, если бы кто-то мог очень точно перечислить, что должно быть предоставлено, поскольку, несмотря на мой лучший гуглинг, все, что я могу найти, это высокоуровневый «пух» по этому поводу. Например:

  • Должен ли я включать диаграммы (UML?), и если да, то какие и что они должны отражать?
  • Должен ли я подготовить письменную документацию (например, спецификацию?), и если да, то какие детали следует включить?
  • Должен ли я предоставлять такие вещи, как функциональные/нефункциональные требования, бизнес-требования и т. д.?
Вау, это сложный вопрос. Чтобы другие могли написать довольно хорошие ответы, попробуйте выделить основной вопрос. Я предполагаю, что это что-то вроде «Как я могу гарантировать, что субподрядчики реализуют требования в рамках описанного сценария?». Как обычно в SE, старайтесь избегать нескольких вопросов в одном сообщении, это сделает ответы размытыми: Вы хотите, чтобы был предоставлен список всех элементов (если да, вы должны предоставить более подробную информацию о своем сценарии)? Вы хотите знать, должны ли вы предоставить UML, уровень детализации UML,...
Похоже, ваша организация все еще довольно мала. Вы выполняете функции, отличные от менеджера проекта? То есть вы все еще работаете над проектом в какой-то технической области, например, в качестве архитектора, дизайнера, разработчика или тестировщика? Я думаю, что лучше подумать о ролях, необходимых для завершения этого проекта, и о том, что делает каждая роль. В это время вы можете быть в нескольких ролях, но со временем это может измениться по мере того, как команда растет и взрослеет.
Кажется, это сводится к следующему: «Что нужно программисту для разработки своих результатов?», Что хорошо, потому что «Как мы поместим SDLC, управляемый проектом?» на месте слишком широк. Тем не менее, чтение между строк - это то, о чем просят. Что я не понимаю из этого вопроса, так это то, почему вы еще не знаете ответа, поскольку в настоящее время являетесь программистом. Следовательно, вы наверняка знаете, что вам нужно для разработки ваших результатов или что вы хотели бы иметь. Я думаю, вам нужно подумать о том, чего вам нужно достичь, разбить это на цели, а затем попросить помощи в реализации каждой цели.
Это вопрос очень высокого уровня, и он даст ответы Google на высоком уровне. Если вам нужны ответы более низкого уровня, вам нужно задавать вопросы более низкого уровня. Это отличный вопрос, но вам нужно нырнуть глубже, а затем соединить части вместе, чтобы помочь вам управлять тем, что выглядит как усилие зрелости PM.
@GoatBreeder, я не верю, что UML все еще актуальны, за исключением соответствия требованиям и академического контекста. Использует ли команда инженеров Google UML?

Ответы (3)

Как говорится в колонке « Худшая неделя в Вашингтоне » в Washington Post: «Поздравляю — или что-то в этом роде…» Отложите в сторону UML, у вас есть более насущные проблемы. Как это часто бывает, ваш вопрос, состоящий из нескольких частей, можно разбить на отдельные вопросы, многие из которых уже были рассмотрены в SE.

  1. Устав проекта
  2. Анализ и управление заинтересованными сторонами. Как вы справляетесь с противоречивыми требованиями заинтересованных сторон? Вы управляете командой? Вы управляете подрядчиками? См. Работа с «единой точкой контакта» и Менеджер проекта — Написание спецификации проекта .
  3. План проэкта
  4. Структура работы

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

Дополнения:

Предупреждение. Не путайте документ MS Project с планом проекта.

Взгляните на http://www.projectmanagement.com/Templates/ . Например, есть план проекта разработки программного обеспечения: «Здесь есть все, что вам нужно для проекта разработки программного обеспечения, от планирования до закрытия». Этот документ требует членства за 249 долларов, но список тем может помочь вам оценить бесплатные предложения в Интернете. План включает в себя:

  • Запуск проекта
  • Приобретать ресурсы
  • Определение требования
  • Детальный дизайн
  • Конфигурация системы
  • Приобретение и установка системы
  • Разработка приложения
  • Перенос данных
  • Системная документация
  • Тестирование
  • Подготовка
  • Реализация производства
  • ЗАКРЫВАТЬ

Менее подробным является план проекта JPACE: «Сроки решают все, даже в управлении проектами. Ключом к успешному проекту является использование JPACE, то есть правильное обоснование, планирование, активация, контроль и завершение». План проекта поможет вам сделать именно это».

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

Как вы сами знаете, разработчики привыкли к отсутствию требований. Как только сайт начнет собираться, вы скоро получите людей, говорящих: «Сделайте его более синим!» так далее

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

Я согласен с WaltHouser, вам обязательно нужно установить полное управление проектами. Это то, куда вы должны пойти в середине срока.

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

  • Спецификация системы/подсистемы
  • Проектный документ системы/подсистемы (по крайней мере, интерфейсная часть)

Вы найдете в Википедии хорошие шаблоны для обоих документов, поищите MIL-STD 498. Стандарт устарел, тем не менее, шаблоны очень полезны.

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

  • Требования должны быть атомарными
  • Использование должен, должен, должен, может как специальные слова
  • Использование схемы для аналогичных категорий требований

Я написал это в части SSDD: Сосредоточьтесь на интерфейсах , особенно. те, которые соединяют разные команды разработчиков. Рассмотрите их как можно подробнее.

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

Как перейти от программиста к руководителю проекта?
СпросиСетьПолитика конфиденциальности1y, 0v