6 рекомендаций, как не допустить ошибок при заказной ИТ-разработке и получить от нее максимум выгоды
//
/ 6 рекомендаций, как не допустить ошибок при заказной ИТ-разработке и получить от нее максимум выгоды

6 рекомендаций, как не допустить ошибок при заказной ИТ-разработке и получить от нее максимум выгоды

10.01.2023
В нашей предыдущей статье мы дали полный обзор на два подхода к цифровизации бизнес-процессов: разработка ПО на заказ против готовых продуктовых решений. Как мы неоднократно упоминали, заказная IT-разработка несёт в себе столько же потенциала, сколько и сложности, а значит, подходить к ней нужно со всей ответственностью и готовностью вовлекаться. Чтобы максимально полно раскрыть тему разработки ПО на заказ, мы собрали наиболее часто встречающиеся ошибки и риски, с которыми сталкиваются компании, вставшие на путь цифровой трансформации с помощью разработки собственных ИТ-решений, а также вывели ряд рекомендаций, которые помогут обойти подводные камни и получить максимум эффективности от разрабатываемого продукта.

Ошибка: халатность в проработке бизнес-процессов.

Неправильно подобранная рабочая группа со стороны заказчика, отсутствие мотивации, не до конца сформированная логика процессов могут стать первой и самой критической ошибкой в начале проекта. Когда заказчик говорит партнеру: «Сделайте как-нибудь, а мы подстроимся» – это первый шаг в пропасть.

Решение

Со стороны заказчика должна участвовать замотивированная рабочая группа, в том числе сотрудник, ответственный за внедрение нового софта, с собственными KPI, сферой ответственности и зоной влияния.



Ошибка: попытка описать всё и сразу в условиях высокой изменчивости процессов.

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

Решение

Придерживайтесь agile-разработки, при которой есть возможность вносить изменения в ТЗ, менять приоритеты, добавлять и убирать «фичи» уже в процессе разработки без существенных временных и ресурсных потерь.



Ошибка: халатность в анализе требований.

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

Решение

Чтобы описать все критические процессы и систематизировать варианты их реализации, необходимо привлекать грамотного бизнес-аналитика, который подготовит максимально качественные требования для передачи разработчикам.



Ошибка: минимум вовлечения, максимум ожиданий.

Завышенные ожидания, перекладывание всей ответственности на партнера-интегратора, а также непонимание сотрудниками компании целей внедрения ПО – это еще одно препятствие на пути к успешному проекту.

Решение

Лучше заранее письменно, в договоре, прописать все риски (непредоставления информации, недопонимания постановок, т.д.), объем доработок к основному списку задач и время, в течение которого будет осуществляться поддержка готового продукта. Это повышает ответственность обеих сторон и защищает как заказчика, так и исполнителя.



Ошибка: начало разработки при отсутствии чёткого понимания рутинных процессов.

Нечасто, но иногда бывает так, что при разработке ПО первый приоритет отдается переводу всей ранее бумажной или ручной работы «в цифру» ради повышения прозрачности процессов и полноты и качества данных, при этом удобство интерфейса для пользователей отходит на второй план. Без чёткого понимания, как с новым ПО будут работать сотрудники, велик риск саботажа новой системы, и в итоге вы разработаете ПО, которым никто не пользуется.

Решение

Необходима коммуникация на всех уровнях процесса и осознанность в плане целей, задач, критериев успеха. Цифровая трансформация – это не только внедрение инновационных технологий, но и повышение цифровых компетенций всех сотрудников компании, ведь ПО создается именно для них.



Ошибка: все процессы по разработке и поддержке ПО завязаны полностью на внешнего партнера.

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

Решение

Если в компании есть свой ИТ-департамент, лучше сразу привлечь его к процессу разработки хотя бы частично, чтобы передать весь исходный код и документацию. В таком случае сопровождение, поддержка и доработки ПО пройдут более бесшовно и смогут продолжаться без привлечения другого подрядчика.



Конечно, на пути цифровой трансформации бизнес может столкнуться ещё с множеством подводных камней. Мы перечислили лишь наиболее распространённые ошибки, которые допускают компании. Если вы тоже задумываетесь о разработке ПО на заказ или готовитесь к старту проекта по цифровизации, свяжитесь с нами, наши специалисты будут рады ответить на ваши вопросы и дать дополнительные рекомендации.

Связаться с нами
ДРУГИЕ ПУБЛИКАЦИИ
Выбираем среду для разработки: сравнение Bun.js и Node.js — новая статья от инженера РЕЛЭКС
29
03.24
В новом DIY-медиа для ИТ-специалистов "вайти" опубликована статья нашего full-stack разработчика Ива...
Подробнее..
ЛИНТЕР БАСТИОН: гарантированная безопасность информации в соответствии с новыми требованиями
20
03.24
АО НПП «РЕЛЭКС» получило подтверждение соответствия СУБД ЛИНТЕР БАСТИОН «Требованиям по безопасности...
Подробнее..
Революция в мире реляционных СУБД. SoQoL — новый стандарт архитектуры систем управления данными
29
02.24

Компания «Реляционные экспертные системы» (АО НПП «РЕЛЭКС») объявляет о выходе коммерческой версии...

Подробнее..