Home » Менеджментtitle_li=Управление проектами » Козлы и капуста

Козлы и капуста

Постоянно наблюдаю на практике как заказчики провоцируют завал проекта в самом начале. Что они любят делать?

  • Не знают зачем это хотят
  • Не знают что конкретно хотят
  • Выбирают поставщика по цене.
  • Заранее вводят несколько ограничений в проект делая баланс не реальным. Например фиксируют сроки и давят по цене задавая требования в качестве.
  • Не оценивают команду поставщика. Не проверяют компетенции поставщика – его команды.
  • Не проверяют офис поставщика. А есть ли офис ВООБЩЕ? А какой он? А много ли там программистов? А не выглядят ли программисты как юродивые или пацаны со второго курса морборпуфпахфак?
  • Редко делают референс визиты к клиентам поставщика.
  • Выбирают там где могу получить легче взятку.
  • Провоцируют поставщиков снижать цены. Тем самым формируют основания для создания условий по понижению объема работ через хитрости в описании ТЗ, выделение на проект более дешевых ресурсов, снижение буферов на риски и вариации – все это создает самые отвратительные условия для взаимной работы. Когда мало денег обоим сторонам очень не комфортно.
  • Не устраивают очных ставок между поставщиками. Собранные поставщики вместе могут отлично друг друга дополнить и вы докопаетесь до истины.
  • Требуют дать детальный план проекта длительностью в 6-8 месяцев при описании требований к нему на 1-2 листиках
  • Не согласны на гибкую разработку. Составьте план по дня, приложите к договору и мы все 6 месяцев будем с ним сверяться. За каждый шаг влево-вправо – расстрел.
  • Отказываются формировать четкое ТЗ. Один из встречаемых аргументов – так это мы потом получим то что будет написано
  • Отказываются заказывать отдельно разработку ТЗ чтобы по нему потому получить правильную оценку. Аргумент – а вот мы заплатим одним – а другие потом не захотят делать это ТЗ (Бред! Хорошее ТЗ всем в радость кроме нерадивых заказчиков и исполнителей). Аргумент – а вот мы проанализируем и окажется что у нас не будет столько денег чтобы выполнить проект (Бред! Размер проекта можно увидеть при беглом анализе – а при точном правильно сформировать ожидания)
  • Предлагают не писать ТЗ – тут и так все понятно. Этот процесс вы уже раз пять делали – нам такой же как в той компании.
  • А зачем мы тратим столько времени и денег на тестирование и на анализ? Что тут и так не понятно что надо делать правильно и качественно?

Leave a Reply