ТОП 5 ошибок в управлении проектами. Без банальных вещей вроде: deadline, бюджет, роли. Будет то, о чем вы и не задумывались. Поехали!

 

Ошибка №1: Нет «follow up» после разговора.

 

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

Потратьте еще 2-5 минут, напишите итоги к чему пришли и вышлите на почту пунктами другой стороне.

Сэкономите массу нервов проверено 🙂

 

Ошибка №2: Нет логирования работы над проектом или ни кто не сохраняет рабочие версии.

 

Как-то один заказчик попросил вернуть деньги за прототип лендинга, который мы изменяли раз 15. Ему не нравится наша работа, все не то, плохо, не подходит. После показа «лога времени» и количества версий, которые мы сделали, для удовлетворения его фантазии, вопрос был исчерпан.

У программистов есть такая привычка. Например хранить версии изминений на «github». А у копирайтера , маркетолога или прототипировщика нет. Лучше сделать изменения в новом файле, чтобы в итоге вернуться к самому первому, если вы его сохранили то не будете переделывать. В глазах заказчика/руководства покажет профессионализм и крутой подход.

 


Ошибка №3: Лучше написать, чем не сделать ничего. Лучше позвонить, чем написать.

 

Лучше встретиться, чем позвонить. Это простое правило, я внедрял для своих project менеджеров.
Не значит что нужно со всеми встречаться. Это выстраивание иерархии действий. Иногда при переписке, «градус отношений» накаливается. А при разговоре, контакт опять налаживается.

Подумайте, кому вы можете позвонить уже завтра?

 

Ошибка №4: отсутствие четко прописанных договоренностей между сторонами. 

 

Вот только не надо писать: «Банально», «капитан очевидность». Очевидно для вас, но не для всех.

Как известно, написанное пером не вырубишь топором. Перед началом проекта пропишите условия. Ловите мой «маст хев» пунктов:

— Стоимость
— Порядок оплат
— Конечный продукт/результат
— Время выполнения работы и сдачи проекта
— Кто принимает решение и ведет коммуникацию с одной и второй стороны
— Риски (форс мажоры, «а что если кошка рожает», если вы долго утверждаете или нам нужно больше времени на работу и т.д.)
Пользуйтесь!

 

Ошибка №5: Не нужно обещать или брать на себя слишком много в проектах. 

 

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

Я пользовался самой распространённой моделью управления проектами: каскадной (англ. waterfall model). 

Наверно все ей пользуются?

Когда в проектах, стало учавствовать 20 человек и задачи расширялись, я перешел на «скрам» (scrum). 

Опишу для вас разницу.
waterfall — запланировали проект, написали тех. задание, сделали и получили конечный результат. 

scrum — делит «по кусочкам» и завершает каждый этап на 100% и до конца. Сначала одна небольшая часть проекта и утверждаем её. Сначала анализ рынка, затем прототип и не возвращаемся на законченные этапы. Есть еще другие преимущества скрама такие как: ретроспективы, собственно короткие скрам циклы. В общем всего не напишешь, покопайтесь в теме.

Считаю scrum уменьшает риск ошибок и реально ускоряет закрытие проекта.

У меня все! Было полезно? Буду рад услышать ваше мнение и темы которые вам было бы интересно раскрыть для следующих ценных постов.

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

Получите систему по созданию и эффективному управлению онлайн-командой

Отлично, прямо сейчас проверьте свою почту чтобы подтвердить подписку и получить первый урок или перейдите по этой ссылке http://onlineteam.me/8-steps-system/help/