Подведение итогов за 2 года опыта, расскажет, как хорошо управлять проектами

программист

Показанные в прошлом (добро пожаловать вперед~~)

Разбирайтесь в технологиях, но также разбирайтесь в управлении Всем привет, я Лузи.

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

Прежде чем я расскажу об этой статье, позвольте мне кратко рассказать о своем управленческом опыте: до этого я провел 3 с половиной года в Baidu и систематически изучал процесс управления проектами Baidu.После прихода в Xiaomi в 2019 году я возглавил команду ShareSave, которая занималась управлением проектами и Управление командой, а затем возглавил группу базового обслуживания зарубежных торговых центров для управления командой в течение 1 года.

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

Примечания: Я не получал сертификат PMP и не проходил систематическое обучение управлению проектами.Содержание статьи основано на опыте.Если есть какие-либо предубеждения, пожалуйста, укажите, и это обязательно улучшится!

Ход проекта

Я делю управление проектом на 4 этапа: этап требований, этап исследований и разработок, этап тестирования и этап запуска.

В процессе управления проектами необходимы инструменты управления проектами, в качестве примера возьмем TB (Teambition).

планирование продукта

Зачем мне отдельно указывать «Планирование продукта», ведь это действительно важно,Планирование продукта похоже на маяк на море, показывая вам путь вперед.

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

Ниже приведены требования к планированию продукта:

нуждается в проверке

На этапе обзора требований продукт должен предоставить полный документ с требованиями.Если есть взаимодействие с пользовательским интерфейсом, необходимо заранее предоставить схему прототипа.Отклоняйте обзоры требований без прототипов.

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

Ниже приведены требования к обзору требований:

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

Ниже приведен процесс этапа спроса (некоторые ссылки могут быть удалены только для справки):

этап разработки

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

Планирование проекта используется для контроля ритма всего проекта., существуют следующие точки опыта:

  1. График проекта не должен заполняться каждый день.Рекомендуется резервировать 20% буфера;
  2. Если время проекта ограничено, вы можете использоватьТестируйте партиямиПуть;
  3. Планируется иметьвеха, разработка, совместная отладка, тестирование, онлайн, приемка и т.д.;
  4. График проекта не только переходит к онлайн-этапу, но также включает онлайн-оттенки серого и приемку проекта;
  5. Планирование внешнего интерфейса зависит от дизайна пользовательского интерфейса.

Ниже приведены требования к расписанию проекта:

Ниже приведен процесс этапа исследований и разработок (некоторые ссылки могут быть удалены, только для справки):

Этап тестирования и запуска

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

Что касается процесса тестирования и запуска, у меня есть следующий опыт:

  1. Тестовая сессия требует, чтобы каждый прошелПрецедент;
  2. Перед тестированием некоторые проекты еще нужно сделатьДемонстрация проекта;
  3. Перед выходом в интернет необходимо пройтиОнлайн план, выделить точки риска;
  4. может потребоваться после выхода в эфирПроверка малого потока или шкала серого;
  5. Некоторые проекты также имеютПринятие проектаСессия, наконец, была открыта для всех.

Ниже приведен процесс этапа тестирования и запуска (некоторые ссылки могут быть удалены только для справки):

Изменение требований

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

Ниже приведены требования к запросам на изменение:

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

ежедневный стендап

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

То, как станция будет открыта, тоже важно.10-15 минут лучше всего, каждый студент должен участвовать в:

  1. Что ты делал вчера?
  2. Что ты собираешься сегодня делать?
  3. В чем проблема?

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

Суммировать

Обобщите несколько важных моментов управления проектами:

  1. планирование продуктаПодобно маяку в море, вы не можете сражаться без разбора;
  2. Документ с требованиямиБудьте максимально подробны и отказывайтесь от обзоров требований без прототипов;
  3. Технические решенияЭто душа всего проекта, и на него стоит потратить больше времени;
  4. Расписание проектаСуществуют вехи и буферы, а расписание должно включать онлайн-оттенки серого и время принятия проекта;
  5. Обзор кода, тестовый примерне может быть меньше;
  6. Онлайн планНеобходимо прогнозировать риски и обеспечивать стабильность онлайн.

Дополнительный! Дополнительный! Вышла еще одна статья по управлению проектамиПроект снова отложен? Рассказываем, как хорошо справляться с управлением рисками проекта, Статьи, посвященные общему управлению проектами, закончились, а статьи, связанные с гибкой разработкой, будут обновлены позже, так что следите за обновлениями!

Лучше не иметь книг, чем не иметь книг.Из-за ограниченных личных возможностей неизбежно возникают упущения и ошибки.Если вы найдете ошибки или у вас есть лучшие предложения, вы можете их критиковать и исправлять.Большое спасибо.Личные контактные данные. :

Категории