Как управлять веб-проектом

Я веб-разработчик, работаю в небольшой фирме, занимающейся веб-разработкой. обычно у нас есть небольшой набор проектов, использующих PHP и MySQL, и небольшая команда, состоящая менее чем из 4 человек. Но иногда бывает трудно вспомнить подробности об этих проектах и ​​поддерживать задачи по мере роста проектов... и возникает путаница. Как лучше всего управлять веб-проектами?

Отличный вопрос. У веб-проектов есть свои проблемы.

Ответы (8)

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

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

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

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

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

Я бы порекомендовал вам начать с простых инструментов и придерживаться этой простоты по мере продвижения вперед. Иногда, если команды небольшие, простая общая доска может быть очень эффективной. В других случаях сосредоточьтесь на простых инструментах, таких как Project Path for 37 Signals, для поддержки задач и совместной работы.

Обратите внимание на такие инструменты, как BackPackit и Project Path от 37signals для задач и базовой совместной работы. Базовая функциональность этих инструментов бесплатна, и с командой из 4 человек вы сможете использовать эти продукты бесплатно.

Бесплатная версия Google Apps также часто эффективна, поскольку позволяет нескольким людям обновлять один и тот же лист Excel в Интернете. Вы можете попросить людей обновить один и тот же лист Excel, когда они закончат свои задачи. Этот подход является общим, в то время как другие инструменты, такие как Project Path, немного более конкретны и предлагают некоторые навороты, такие как уведомление по электронной почте, основные временные шкалы и т. д.

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

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

Вопрос показался несколько общим.

Надеюсь, этот ответ поможет. Если у вас есть другие конкретные вопросы, касающиеся этого, не стесняйтесь оставить и прокомментировать этот ответ, и мы постараемся ответить.

"возникает путаница" Это ключевая проблема здесь (на мой взгляд).

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

Вот что я предлагаю-

  1. Разбейте свой проект на более простые задачи. У которых есть четкая цель, сроки и критерии завершения
  2. Повысьте видимость задач, их обновлений/прогресса и блокировщиков/рисков на пути к выполнению этих задач – я бы порекомендовал короткие ежедневные стендапы. Вовлекайте все соответствующие заинтересованные стороны. В этом вашей мантрой должна быть видимость прогресса.
  3. Назначьте ответственного за сбор вышеуказанных данных – используйте большую белую доску.
  4. Убедитесь, что у вас есть надлежащая система отслеживания ошибок. Я бы не рекомендовал Excel. JIRA популярная, простая для понимания и легкая.
  5. Используйте низкотехнологичную информационную панель, чтобы выявлять проблемы с качеством и ход тестирования. http://www.satisfice.com/presentations/dashboard.pdf

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

удачи

Я предполагаю, что вы скоро добавите проблемы контроля версий в список проблем.

Все ответы на ваш пост указывают на одно: принять и следовать процессу. Я бы также рекомендовал всем присоединиться к «единому» процессу и распространить его на управление кодом и управление версиями веб-сайта. Методология — замечательная вещь для облегчения жизни.

Попробуйте использовать какую-нибудь систему отслеживания проблем ( ITS ) для задач и ошибок. JIRA и Trac довольно популярны. Вы сохраните свою историю организованной и доступной для поиска.

«Падение плана означает планирование неудачи»

Худшее, что может случиться с проектом, — это несоблюдение требований. Подойдет любой инструмент управления проектами или даже Excel. Но документируйте требования в полной мере. Альтернативы этому нет. Когда вы когда-либо начинаете проект, перечислите все детали, которые у вас есть и которые одобрены клиентом. Сохраняйте это в качестве основы и продолжайте обновлять по мере поступления новой информации или появления новых требований. Ваш лист запроса будет основан на этом. Ваш тестовый пример должен быть построен на этом документе требований.

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

да, верно @Deb

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

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

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

Посмотрите https://pm.stackexchange.com/questions/5600/project-management-software-for-a-small-team-with-shifting-priorities .

Хороший отдельный ответ, который также ссылается на другой контент на нашем сайте. Добро пожаловать в ПМСЭ! :)

Программное обеспечение для управления проектами может быть лучшим способом решения проблем, с которыми вы сталкиваетесь. Мы используем Microsoft Project 2010 в нашей организации, и он хорошо работает для нас. Он прост в использовании, помогает в совместной работе и отчетности. Есть бесплатная 30-дневная пробная версия. Таким образом, вы можете проверить это, чтобы увидеть, как это работает для вас.