Продолжаю восхищаться теми, для которых, мы – программисты, консалтеры и консультанты работаем. Пользователь хочет большего от программы, которую он заказывает. При этом он не знает про треугольник проджект менеджера. Ему плевать на реляционную теорию. Он не понимает, что можно и что нельзя. Он входит во вкус. Он начинает понимать, что к чему. И вот здесь опасность – опасность завалить проект под гнетом его требований. Вы скажете ТЗ, вы скажете аналитики, вы скажете договор, вы скажете планирование. Я скажу – это всё полная … Кто-то выдвинул идею, что проджект менеджмент – фикция. Если вы руководите проектом с жестко заданным или “умножь время которое нужно программисту на два” временем, то вы им нихрена не руководите, а просто кусаете локти. 99 процентов функционала реализует 1 процент кода – вот Парето, без всякой чепухи. Поскольку проект – это инженерная задача, то она либо решается, либо не решается. Когда кто-то строит диаграммы Ганта и вбивает атноты в Outlook, думая что это как то спасает или управляет проектом, то он явно ошибается. Вы приходите к Васе: – Вася, вот задача, вот тебе 2 дня на ее решение. А у Васи голова болит, а Вася запарился уже одну и ту же кнопку приклеивать, а Васе хочется новыми технологиями заняться. Вопрос: “Управляем ли Вася?” Нет. Они либо решает, либо вы начинаете метаться в поисках спеца, который еще не факт что поможет. Который возможно будет просто потерей времени. К чему это все? Чтобы проект не завалился, его надо начинать раньше! Во всех смыслах, фаст старт, фальстарт, как хотите. Начинайте раньше думать о проблемах, начинайте больше “впаривать” пользователю то, чего он сам хочет. И сразу. — А вот так мы можем? — Да — А вот чтобы так было? — Да, а время у нас есть? Пользователь хочет большего, чем вы сможете ему предложит. Задача теперь в том, чтобы не завалиться на бок под весом требований. Удачи!
Комментариев нет
Leave a Comment
trackback address