Почему множество ИТ-проектов проваливаются?

Для людей, кто не имел опыта работы с ИТ-проектами всё кажется достаточно банально - обсудили объем работ, заплатили, получили проект. Однако в реальности всё происходит не так.

Один из первых наших проектов был таким:

Мы обсудили проект, подписали договор на твердые условия по цене, получили предоплату, начали работы. Клиент говорит - “Мы же всё обсудили, приходите с готовым проектом”. Ну ок.

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

Клиент говорит:

Мы берем дизайн в работу, верстаем, разрабатываем, интегрируем, тестируем и приносим готовый проект, клиент говорит:

Мы говорим:

Он нам:

В итоге, что произошло? Клиент на момент подписания договора и даже утверждения дизайна проекта видел одну картину проекта. А после того, как смотрит на итоговый проект ему хочется чего-то другого.

Тут классическая проектная история, что Заказчик не хочет управлять проектом, но хочет результат. С высокой вероятностью его не устроит результат, так как он не хочет принимать проектные решения по ходу проекта, потому что не понимает и не хочет брать ответственности за проект(“ну это же вы так сказали, поэтому мы так и сделали”). Зачем вникать, когда можно посмотреть на готовое и оценить? Когда же проект выполнен можно на готовое посмотреть и сказать что не так. В данном случае, риск переделки проекта в любом случае на Исполнители(если что мы акт им не подпишут, пусть переделывают, как мы хотим).

Что же делать? Давайте тогда сделаем точное описание проекта(ТЗ). Но, как оказывается, детальное ТЗ тоже не панацея.

ОК, давайте поговорим про ТЗ. Пишем ТЗ - описываем всё, что нужно сделать на проекте.

Первый вопрос - сколько клиент должен заплатить за написание ТЗ?

Вариант №1. Нисколько/Бесплатно. Потом эти затраты включить в затраты проекта или как? Ок, а если клиент не согласиться на то, что мы спроектировали(по цене, срокам и т.д.). Поработать бесплатно? Надо признать, что проектировщики - это вероятно, самые дорогие специалисты, потому что понимают и бизнес-язык и разработку.

Вариант №2. Не бесплатно? А сколько? Сколько стоит изучить бизнес компании и ответить на вопрос каким образом они должны быть организован при новой системе? Ок, давайте возьмем какую-то метрику, например, количество рабочих мест, сущностей, с которыми работает Заказчик. Как будем оценивать качество работы? Страницами? Уровнем проектного решения?

Ну, ок, допустим даже с этими вопросам мы справились и у нас есть какая-то оценка трудоемкости проектировщика, который будет собирать требования и описывать их.

Насколько детализировано должны быть описаны требования клиента?

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

Возникает управленческий посыл: “В ТЗ не вошло - делать не будем?” и соответствующий ответ Заказчика: “Ну вы же профессионалы, должны были понимать, что без этого мы жить не сможем. Это же не сложно - вот тут немного поменяйте. И вот тут. Ну а иначе, сами понимает, акты мы вам не подпишем. Ну или деньги возвращайте.”

ОК. Тогда давайте писать ТЗ ещё детальнее, всё прописывать. Хорошо. Тогда давайте заложим больше часов проектировщика, и сдвинем сроки. И получаем: “Блин, что вы так долго ТЗ пишите, всё же итак понятно - вот отчет, а вот форма, а тут поля надо чтобы пользователи вбили.” или “Почему мы должны платить за работу, которая не даёт нам никакой результат? Вы же для себя пишите ТЗ.”

ОК, предположим, написали детальное ТЗ, выстрадали просто все бизнес-процессы, погрузились, описали каждый пиксель проекта. Всем всё понятно, делаем по ТЗ и всё. Что тут непонятного?

И тут происходит другая история:

“Ребята, у нас тут пришёл пользователь и говорит, что то, что он говорил на этапе проектирования ему уже не актуально, и у него есть другая, более горячая задача. Что делаем?”

Вариант №1. “Как что? Ничего. Этого нет в ТЗ. Пусть дальше страдает. Надо было раньше думать”. Ответ см. выше про акт и возврат денег.

Вариант №2. “Давайте новое ТЗ писать и заново его по процедуре согласования запустим, как раз через год оно у пользователя может быть и появится. ”

Как мы понимаем, ни первый, ни второй вариант не устраивает ни Заказчика ни Исполнителя.

Итак, что мы имеем: Вторая классическая история проектных работ. ТЗ не спасает, потому что дорого/долго и проект всё равно по ходу жизни измениться.

Есть вариант, когда штуки, описанные выше могут решаться, правда одни вопросы сменяются другими.

А давайте просто - вы ставите нам задачи, мы их делаем, а вы их оплачиваете? Ну как будто вы нас наняли на работу, а мы работаем. Если мы работаем плохо - вы нас увольняете, если хорошо, то поднимаете зарплату.

Какие тут риски:

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

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

А вам как больше нравится работать с проектами?