Почему не все проекты получаются хорошо

А иногда, казалось бы, маленький и достаточно простой проект «не взлетает». Да, мы не идеальны (а кто идеален?). Даже ракеты носители с военными спутниками бывает падают при взлете и взрываются. Но размышления на эту тему позволяют нам стать лучше. Приглашаю поразмышлять вместе. Давайте?

Для нас очень важно сделать проект хорошо. Что такое хорошо? Есть формальные определения, но мы не будем занудствовать. Так что определим, что такое «проект хорошо получился», если говорить про запуск системы учета и управления:

1. Основные задачи, которые стоят перед сотрудниками клиента, они решают с помощью учетной системы
2. Руководство компании может из системы получить все нужные ему данные
3. Проект сделан в рамках ожидаемого бюджета
4. Проект сделан в приемлемые сроки
5. Заказчик доволен и процессом, и результатом 

Вы обратили внимания, сколь субъективны эти факторы? И это не зря, потому что люди работают с людьми, и субъективность избежать очень сложно…

Иногда проекты не получаются хорошо

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

Допустим сразу, что обе стороны, и Заказчик, и Исполнитель – могут сделать проект и хотят его сделать. Но и это не гарантия результата. И еще лирическое отступление. Меня читают очень разные люди, и может так случиться, что в какой-то из описанных далее ситуаций вы узнаете себя. Если это случилось, не спешите ругаться и закрывать статью, лучше дочитайте до конца и напишите мне на почту, или в комментариях в фейсбуке свои мысли – что пошло не так в вашем проекте? Когда и почему? Что можно было бы сделать по-другому?

Я искренне считаю, что даже если проект «не взлетел» по клиентским, кажется, причинам – если докопаться до корня, мы виноваты.

Если даже клиент «забил, забыл, всё сделал не так как должен был», ему простительно. Знаете, почему? Потому что клиент не делает проекты каждый день, а мы делаем. А значит мы должны на каждом шаге управлять им, помогать ему, направлять его, а если клиент сбился с пути и проект в результате пошел «не туда», это мы что-то не доделали.

Итак, что может пойти не так?

«Все успешные проекты успешны одинаково, а каждый неудачный проект, неудачен по-своему».

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

 Давайте вернемся к списку «что такое хорошо», и попробуем разобрать его? Итак, есть тезис, а есть «что могло пойти не так, и помешало наступлению всеобщего счастья?»

1. Основные задачи

ХОРОШО:

ПЛОХО:

• Самое простое – эти самые «основные задачи» не были известны исполнителю, вот он их и не решил.
  Исполнитель: не провел должного обследования, недостаточной глубины анализ, не формализованы требования, не написаны нормальные ФТ или ТЗ.
  Заказчик: рассказал не все, или просто не правду о своей работе, не предоставил всю информацию, невнимательно прочитал документы (ФТ, ТЗ), или вовсе не читал их – подписал, не глядя (надеюсь документы были?) 
• Второй вариант – «в пути собачка могла подрасти». Пока проект шел, бизнес поменялся, и теперь спроектированная ранее система уже не удовлетворяет его потребностям.
  Исполнитель: не общался с клиентом так часто, так заинтересованно и так глубоко, как надо было.
  Заказчик: предполагал, что исполнитель «итак всё понимает», прочитает мысли, заметит изменения и их учтёт.
• Третий вариант – задача нерешаема (а ожидалось, что будет решаться). При реализации оказалось, что решить задачу нельзя или можно, но усилия на ее решения неоправданно велики.

2. Получение нужных данных

• Нет механизмов для получения данных (по-простому говоря, нет нужной системы отчетности)
  Исполнитель: не собрал в начале проекта нужные отчетные формы, или собрал, но не все. 
  Заказчик: не показал какими отчетами хотел бы пользоваться, или в ходе проекта придумал новые отчеты, которые теперь «самые важные», но не рассказал об этом.
  
• Самих данных тоже нет.
• Истории – заказчик рассчитывал ее иметь в своей системе, а исполнитель не рассчитывал ее переносить… Или перенёс, но что-то в ней пошло не так. 
• Нет нужных разрезов аналитики в существующих данных – стороны не договорились, в каких разрезах нужно будет собирать управленческую отчетность.
• Текущих данных нет, потому что сотрудники не заносят их как надо, см. пункт 1.

3. Бюджет

• Не попали в бюджет, о котором договаривались из-за расширения объема работы.
• Долго копались и учились за счет заказчика, и решили выставить это клиенту (я же говорю, мы про адекватных подрядчиков и клиентов в этой статье разговариваем).
• Ожидания клиента о том, что такое для него «нормальный» бюджет в ходе проекта поменялись. В начале проекта клиент был готов инвестировать в проект миллион, а ближе к концу – финансовая ситуация в компании поменялась, да и проект, кажется, не так уж сложен (то есть, исполнитель хорошо работает), вроде бы миллион многовато. 

4. Сроки

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

5. Ожидание

Самая субъективная и самая сложная цель! Ей можно отдельное размышление посвятить, может так и сделаем как-нибудь.

Бывает так, что и бюджет не превышен, и формально все критерии приемки работ достигнуты, и пользователи системой пользуются, и руководство отчеты получает, вроде и со сроками ОК, но заказчик НЕ ДОВОЛЕН. Ну вот не доволен и всё тут.

Почему? Потому что ожидания и реальность не совпали в сторону «ожидания были больше». Как с этим бороться? Половина нашей работы - это управление ожиданиями, и всё равно не всегда получается. 

Почему это могло произойти?

Мы разобрали много разных «как хорошо было задумано» и «а получилось совсем не так». И даже попробовали проанализировать причины. А что дальше? Дальше нужно придумать по каждому пункту – что же делать в проекте, чтобы не допускать таких проблем?
Давайте прервемся ненадолго.