Минимальные методы управления проектами для программных проектов, выполняемых одним человеком

Я много работал над проектами в одиночку — проектами «один человек». Обычно это небольшие проекты в области программного обеспечения. У многих из них нет других клиентов, кроме меня (которые фактически пользуются конечным продуктом); у некоторых есть другие пользователи.

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

Как минимум, у меня всегда есть:

  • Видение того, что я собираюсь сделать
  • Описание содержания, описывающее большую часть работы
  • Реестр рисков с моими 5-10 основными рисками для мониторинга
  • Место для перечисления предметов закупки (графика/звук)

Не вдаваясь в подробности, какие еще аспекты я должен включить в свои проекты?

Редактировать: с технической стороны я обычно использую вариант Agile/Scrum — бэклог продукта и оценки каждой истории в баллах, без спринтов, только релизы.

Должны ли мы сделать это вопросом сообщества?
Вы не можете @ashes999, это может сделать только модератор, иначе ваш вопрос должен получить огромное количество ответов или правок.
Да, я, наверное, просто выберу ответ и побегу с ним.

Ответы (10)

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

Вы забудете вещи. Список существует, чтобы сэкономить ваше время.

Отлично, я знал, что забыл это. Это укусило меня раньше в прошлых проектах. Важно отслеживать вопросы, причем отдельно от «основной» работы.
Для этого я бы рекомендовал Trac . Он основан на веб-браузере, имеет систему тикетов, вехи, интерфейс Subversion VC и вики-систему, полезную для заметок и документации. Он бесплатный, должен работать на всех платформах и достаточно прост в настройке. Кроме того, он имеет приятный интерфейс плагина .
Мне лично нравится прикреплять его к той же электронной таблице и указывать, что это ошибка для небольших проектов. Привет, однако.

Отслеживайте свое время на каждой задаче.

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

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

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

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

  • План (убедитесь, что у вас есть хороший список действий, которые объясняют, как добраться до вашего видения)
  • Отслеживайте свой план, возвращайтесь к своему списку хотя бы раз в неделю и смотрите, где вы находитесь с точки зрения ваших первоначальных оценок.
  • закройте книги в конце, заархивировав документы проекта в центральном месте. Это поможет вам в будущем.
Неплохо, но все это общие действия — планирование, отслеживание и архивирование. Я больше ищу конкретные виды деятельности, которые приносят мне пользу.
Может быть, я не понимаю вопроса. Не могли бы вы добавить к вашему вопросу свои болевые точки? что заставляет вас задаться вопросом, правильно ли вы выполняете действия по управлению проектами для своих самоуправляемых проектов. Спасибо за быстрый ответ.
Если бы я знал свои болевые точки, я бы не задавал вопрос :) У меня был бы список проблем и выработанные пути их решения. Я хочу объединить свои практики с лучшими практиками других менеджеров проекта.
@Ivo, я очень ценю, что вы указали на это, так как я использую SO более 2 лет, но мне никогда не представляли этот момент. Я действительно считаю, что использование приветствия и подписи добавляет тон и индивидуальность сообщению каждого участника, позволяя каждому дискуссионному форуму жить своей собственной жизнью. Я думаю, мы все согласимся с тем, что PMы должны быть мастерами общения, а общение невозможно без правильного тона. Тем не менее, я ценю и приму ваше предложение во внимание.
@Geo Добро пожаловать, это не выговор. Я просто часто слышу, как модники жалуются, поэтому решил указать на это. В любом случае, это не значит, что мне не нравятся ваши ответы :-)

Поскольку мы говорим о программной области, не начинайте разработку только с:

Видение того, что я собираюсь сделать

Создайте быструю блок-схему функциональности вашего проекта.

В Интернете есть много бесплатных программ для создания блок-схем, таких как giffy или SlickPlan .

Это экономит ваше время и проблемы, даже если это небольшой проект.

  • Управления источником
  • Модульные тесты
  • Автоматизированные сборки
  • Спецификация
  • График
  • Отслеживание ошибок

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

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

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

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

Не только в смысле настойчивости, но и в смысле не брать на себя слишком много сразу. Для одного человека я думаю, что канбан-доска и строго ограниченный WIP — идеальный вариант для управления одним проектом.

Остальная часть моего фреймворка :

Ограничьте количество задач, которые у вас есть в процессе, даже если это то, чего вы ждете.

На самом деле отслеживать свое время. Это даст вам представление о рентабельности инвестиций.

Используйте Гит.

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

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

Хороший подход к началу.

Я должен добавить, что ежедневное резервное копирование и контроль версий важны.

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

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

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