Топ-17 ошибок, совершаемых на фазе проектирования IT-решения

Автор: Ольга Азимбаева, руководитель направления бизнес анализа ITentika.

По статистике 80% IT-проектов выходят за рамки ранее запланированного бюджета или сроков. И это еще не самое страшное. Заплатить чуть больше или получить продукт чуть позже – очень неприятно. Но гораздо хуже получить в качестве продукта нечто, что станет неуклюжим «монстром» в перечне общих решений.

Почему так происходит и какие ошибки поджидают как заказчиков, так и исполнителей на фазе проектирования IT-решения, я сегодня и расскажу.

За 13 лет в IT-сфере я спроектировала более шести десятков различных систем, начиная от интернет-магазинов, где нужно было грамотно проработать пользовательский путь, и заканчивая системами по управлению всеми бизнес-процессами в распределительных центрах. Поэтому я не понаслышке знаю, какие ошибки может допустить сам исполнитель на этой фазе.

Ошибки исполнителей

1. Попытка решить задачу локально. Залатать конкретную дыру, как просили вместо того, чтобы поднять голову, осмотреться и предложить более эффективный путь. Подход в стиле – «Вот нам сказали, что нужно эту систему интегрировать с другой. Мы расписали sequence и data flow диаграммы, все прекрасно, можно приступать к разработке». Профессиональный «проектировщик» обязан вникать в цели бизнеса и «жить» проблемой, которую он решает.

2. Игнорировать многообразие заинтересованных лиц. Что может быть хуже, чем исполнитель, собирающий требования только с указанного ему человека и не учитывающий многогранную иерархию ролей и людей, которые затем внезапно зарубят проект при получении инвестиций.

3. Ошибиться в масштабах и сложности системы. Спроектировать решение гораздо сложнее, чем требовалось и, в итоге, не по карману заказчику. Либо, наоборот, недооценить (зачастую именно так) сложность решаемой задачи, заставляя заказчика снова и снова запрашивать новые инвестиции на «вот уже почти взлетевший продукт».

4. Пытаться продать джуна как сеньора. Излюбленный прием вендоров – продать джунов как мидлов, а мидлов как сеньоров. Думаю, понятно, чем это обычно заканчивается…

5. Потерять целостность. На данной фазе крайне важно постоянно держать общую картину решения в голове, уходя в проработку деталей послойно. Иначе это приведет к тому, что в разработку уйдет проработанный кусок, а остальное «ну как-нибудь». Стоит ли говорить о том, чем это «как-нибудь» чревато...

6. Замыкать все на себе. Сняли бизнес-процессы, но забыли положить на бумагу. Придумали архитектуру, но никого не посвятили в причины выбранного подхода. А потом заказчик не может даже вендора сменить при желании, потому что все спроектировано только в головах.

7. Забыть об обратной связи. Здесь важен баланс. Постоянно дергать заказчика по любой мелочи – конечно, не дело, но я видела и другую крайность, когда исполнитель уходил проектировать систему на год, а потом оказывалось «внезапно», что он спроектировал что-то не то.

8. Шаблонное мышление. Каждое IT-решение, написанное на заказ как костюм, сшитый по вашим меркам у портного. Одно и то же решение не может подойти двум разным бизнесам, даже если у них одна и та же проблема.

9. Забыть про человеческий фактор. Заказчики, в первую очередь, – люди. Необходимо выстраивать доверительные отношения, а не просто механически исполнять свою работу.

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

Ошибки Точки роста бизнес-заказчика

10. Самый плохой вариант — это отсутствие фазы проектирования как таковой. Зачем тратить время и ресурсы на проектирование, когда «все и так понятно». Однако фаза проектирования – критически важная фаза в цикле жизни ПО. Ее пропуск в лучшем случае означает появление «зоопарка» решений, в худшем – полный провал продукта.

11. Проектирование свободными ресурсами. Попытка спроектировать решение силами тех людей, кто оказался свободен от проектов в данный момент. Например, использовать штатного мидл аналитика для проектирования решений. Казалось бы, что там, требования собрать, в ТЗ расписать и выпустить на тендер. Но я как человек, каждый день смотрящий в тендерную документацию, могу вас заверить – мидл не справится с подобной задачей. Оценить стоимость разработки системы по такому ТЗ можно только с точностью в +-30%. Это тянет за собой следующую проблему. Такие тендеры выигрывает исполнитель, который не увидел дыр в документации и оценил систему по тому, что в ТЗ написано. А на деле там еще +30% функциональности потом необходимо дописать, за ваши же деньги.

12. Попытка сэкономить на лоскутной автоматизации. Решаем проблему здесь и сейчас, забывая про то, что решение необходимо вписать в общую архитектуру компании, интегрировать в процессы. В итоге получаем тот самый «зоопарк», для которого затем придется делать аудит, менять процессы и заниматься другими не менее занимательными и дорогостоящими процедурами.

13. Отсутствие коммуникации между департаментами. Приводит к пополнению «зоопарка». Помнится, как мы в течение месяца получили два запроса от одной и той же компании о написании крайне похожих систем. Просто потому, что люди не собираются, не общаются, не договариваются о единой стратегии развития.

14. Считать стоимостью системы только стоимость ее разработки. А как же стоимость поддержки? А железо? А необходимость модернизации, интеграции в процессы компании, обучение персонала, наконец?

15. Попытка решить процессные проблемы через автоматизацию. Автоматизация – отличный вариант для ускорения устоявшихся процессов. А если в организации творится хаос, никто ни о чем не может договориться, то автоматизация этих процессов в лучшем случае ничего не изменит, а в худшем – только еще больше все усложнит.

16. Внедрение новейших технологий потому, что модно. Сколько раз мы видели запросы в стиле «Внедрим ИИ/ML для …». К сожалению, модные технологии подходят не всем и не везде. И это тоже можно выяснить на фазе проектирования, не вписываясь в многолетний проект по разработке.

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

В любом проекте разработки IT-системы столько подводных камней, приводящих к колоссальным финансовым потерям, что иногда даже начинать страшно. Но есть и хорошая новость! Мы умеем делать фазы проектирования сложных систем. И именно на этой фазе становится понятно, стоит ли внедрять модную технологию, стоит ли автоматизировать незрелые процессы и какие риски будут сопровождать создание IT-системы. И тогда, понимая все это, можно принимать решение, стоит ли вообще начинать проект. А если начинать, то понимать, как идти и на какие «грабли» не наступать.