© 2023 IT-Метла
ТОП-17 ошибок
совершаемых на фазе проектирования IT-решения
По статистике, 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-системы. И тогда, понимая все это, можно принимать решение, стоит ли вообще начинать проект. А если начинать, то понимать, как идти, и на какие «грабли» не наступать.
Понравился материал?