ТОП 5 ошибок в управлении проектами. Без банальных вещей вроде: deadline, бюджет, роли. Будет то, о чем вы и не задумывались. Поехали!
Ошибка №1: Нет «follow up» после разговора.
В корпоративном мире это привычная практика. Поговорили в оффлайне = закрепили все текстом. Но в малом бизнесе такой практики нет. Поговорили, затем половину забыл заказчик, а остальное вы. Получаем недопонимание и факапы.
Потратьте еще 2-5 минут, напишите итоги к чему пришли и вышлите на почту пунктами другой стороне.
Сэкономите массу нервов проверено 🙂
Ошибка №2: Нет логирования работы над проектом или ни кто не сохраняет рабочие версии.
Как-то один заказчик попросил вернуть деньги за прототип лендинга, который мы изменяли раз 15. Ему не нравится наша работа, все не то, плохо, не подходит. После показа «лога времени» и количества версий, которые мы сделали, для удовлетворения его фантазии, вопрос был исчерпан.
У программистов есть такая привычка. Например хранить версии изминений на «github». А у копирайтера , маркетолога или прототипировщика нет. Лучше сделать изменения в новом файле, чтобы в итоге вернуться к самому первому, если вы его сохранили то не будете переделывать. В глазах заказчика/руководства покажет профессионализм и крутой подход.
⠀
Ошибка №3: Лучше написать, чем не сделать ничего. Лучше позвонить, чем написать.
Лучше встретиться, чем позвонить. Это простое правило, я внедрял для своих project менеджеров.
Не значит что нужно со всеми встречаться. Это выстраивание иерархии действий. Иногда при переписке, «градус отношений» накаливается. А при разговоре, контакт опять налаживается.
⠀
Подумайте, кому вы можете позвонить уже завтра?
Ошибка №4: отсутствие четко прописанных договоренностей между сторонами.
Вот только не надо писать: «Банально», «капитан очевидность». Очевидно для вас, но не для всех.
Как известно, написанное пером не вырубишь топором. Перед началом проекта пропишите условия. Ловите мой «маст хев» пунктов:
— Стоимость
— Порядок оплат
— Конечный продукт/результат
— Время выполнения работы и сдачи проекта
— Кто принимает решение и ведет коммуникацию с одной и второй стороны
— Риски (форс мажоры, «а что если кошка рожает», если вы долго утверждаете или нам нужно больше времени на работу и т.д.)
Пользуйтесь!
Ошибка №5: Не нужно обещать или брать на себя слишком много в проектах.
В начале своего пути, проекты не были сложными. Простой сайт/лендинг или настройка обычной рекламы.
Я пользовался самой распространённой моделью управления проектами: каскадной (англ. waterfall model).
Наверно все ей пользуются?
Когда в проектах, стало учавствовать 20 человек и задачи расширялись, я перешел на «скрам» (scrum).
Опишу для вас разницу.
waterfall — запланировали проект, написали тех. задание, сделали и получили конечный результат.
scrum — делит «по кусочкам» и завершает каждый этап на 100% и до конца. Сначала одна небольшая часть проекта и утверждаем её. Сначала анализ рынка, затем прототип и не возвращаемся на законченные этапы. Есть еще другие преимущества скрама такие как: ретроспективы, собственно короткие скрам циклы. В общем всего не напишешь, покопайтесь в теме.
Считаю scrum уменьшает риск ошибок и реально ускоряет закрытие проекта.
У меня все! Было полезно? Буду рад услышать ваше мнение и темы которые вам было бы интересно раскрыть для следующих ценных постов.
Хочу буть полезным для большего количества людей. Поможете? Поделитесь этим или первым постом с другом, коллегой по работе или бизнесу. Или с тем кому это может помочь.
